Tag Archives: Softwaretest

Wie oft — und wie dramatisch — Software-Tester versagen


Dass es wirklich höchste Zeit wird, auch die Effektivität von Software-Testern systematisch zu kontrollieren, zeigt eine ganz unglaubliche Sicherheitslücke, die im Februar 2015 in gleich mehreren Tausend per Internet zugänglicher Anwendun­gen entdeckt wurde:

Wie die Computerwoche schrieb, handelte es sich um Konfigurationsfehler die zur Folge hatten, dass — im Prinzip wenigstens — jeder Internet-Nutzer mehrere Millionen Kundendaten nach Name, Adresse, E-Mail und Kreditkartennummer im Internet nicht nur abrufen, sondern auch manipulieren konnte.

Von den zahlreichen Entwicklern dieser vielen Anwendungen war ganz offensicht­lich keinerlei ernsthafter Sicherheitstest durchgeführt worden.

Will da noch jemand behaupten, sie hätten professionell genug gearbeitet?

Und ganz offensichtlich hat auch niemand unter den Verantwortlichen ernsthaft ge­prüft, wie vollständig der Test, für den sie bezahlt hatten, denn nun eigentlich war.

Glaubt die Software-Industrie wirklich, sich derart dilettantisches Vorgehen noch lange leisten zu können?

|

Man lese auch: Was es bedeuten kann, wenn Software-Tester versagen

Advertisement

Wie man als CIO Budget für Softwaretest optimal einsetzt


Projekte, die eine Modernisierung unternehmenskritischer Software-Applikationen großer Unternehmen zum Ziel haben, werden größer und größer und verursachen heute Kosten, die gar nicht mehr so selten 3-stellige Millionenhöhe erreichen.

Einen ganz beträchtlichen Teil solcher Ausgaben verursacht der Test der neuen Lösungen: Typischerweise arbeitet daran ein großes Team (in Fällen, die ich zwischen 2003 und 2010 beobachten konnte, waren es bis zu 50 Personen über Jahre hinweg).

Natürlich versucht der CIO des Auftraggebers dann hin und wieder, kosten­günstigere Dienstleister zu finden. Das gängige Verfahren: Es erfolgt eine neue Ausschreibung der Testaufgabe mit dem Ziel, zu prüfen,

  • ob der gegenwärtige Dienstleister nicht allzu teuer oder zu wenig kreativ geworden ist (z.B. deswegen, weil er bestrebt sein wird, mit der Zeit weniger erfahrenes, für ihn billigeres Personal einzusetzen)
     
  • oder ob es konkurrierende Anbieter gibt, die ihn deutlich zu unterbieten in der Lage sind, Offshore-Anbieter etwa.

Sehr oft steht am Ende einer solchen Ausschreibung der Austausch des Anbieters, d.h. der Austausch des gesamtem, großen Teams von Testern und Testmanager.

Das aber kann gefährlich sein, denn

  • erstens geht dabei eine große Menge von Knowhow verloren (die neuen Tester müssen sich ja erst wieder mit der zu testenden Applikationslogik bekannt machen)
     
  • und zweitens ist zunächst noch völlig offen, wie effektiv das neue Team denn nun wirklich arbeiten wird.

Mit anderen Worten:

Die Wahrscheinlichkeit, dass der Befreiungsschlag gelingt, ist ebenso groß wie die Wahrscheinlichkeit, dass er misslingt. Rechnet man die Kosten der notwendigen Einarbeitung des neuen Teams hinzu — Kosten also, die gar nicht anfielen, wenn man beim alten Dienstleister geblieben wäre —, so ist die Wahrschein­lichkeit, dass solcher Wechsel unterm Strich eher Verlust denn Gewinn bedeutet, ziemlich hoch.

Andererseits:

Das Team über Jahre hinweg einfach arbeiten zu lassen, ohne zu versu­chen, die Effektivität des Dienstleisters zu maximieren, wäre ganz sicher auch nicht richtig.

Was also sollte man tun?

Die naheliegenste Lösung ist folgende:

Sobald absehbar ist, dass ein Testteam über längere Zeit hinweg eine gewisse Größe haben muss, sollte man es aufteilen in zwei etwa gleich große Teams, die

  • unter der Regie zueinander konkurrierender Dienstleister
  • unabhängig voneinander an derselben Testaufgabe arbeiten.
  • Wenigstens eines dieser Teams sollte seine Testwerkzeuge selbst wählen dürfen.

Ihre Effektivität sollte einem strengen Monitoring durch den Auftraggeber unter­liegen, so dass der z.B. alle 6 Monate beiden Teams mitteilen kann, wie effektiv jedes von ihnen im Vergleich zum jeweils anderen gearbeitet hat (Effektivität = Kosten dividiert durch die Summe der Gewichte vom Team aufgedeckter Fehler in den zu testenden Applikationen).

Vorteile dieser Lösung:

  • Keiner der beiden Auftragnehmer kann sich leisten, unerfahrende Leute einzusetzen oder ungeeignetes Werkzeug zu nutzen (denn täte er das, würde sofort erkennbar werden, wie seine Effektivität verglichen mit der seines Konkurrenten zurückgeht).
     
  • Sobald eines der beiden Teams deutlich weniger effizient arbeitet als das andere, sieht man, dass es höchste Zeit wird, es auszutauschen.
     
  • Kosten für den Neuaufbau von Knowhow werden so minimiert, und nie ent­steht eine Situation, in der zu wenig gut eingearbeitete Tester verfügbar sind.
     
  • Schon im jeweils eigenen Interesse wird so jedes Team sich optimale Werk­zeuge aussuchen und wird bestrebt sein, das eigene Vorgehen ständig zu überdenken und effektiver zu gestalten.
     
  • Diese Lösung ist kostenneutral.
     
  • Zudem minimiert sie die Wahrscheinlichkeit, dass gelegentlicher Austausch des Dienstleisters zu einer gravierenden Fehlentscheidung wird.

Man bedenke:

Zu beurteilen, wie effektiv Tester arbeiten, ist anders kaum möglich (denn: Die Zahl beim Test gefundener Fehler hängt ja nicht nur davon ab, wie geschickt die Tester vorgehen, sondern auch davon, wie gut die Entwickler gearbeitet haben). Kurz:

Die oben vorgestellte Lösung scheint der einzige Weg zu sein, über den ein CIO erreichen kann, dass die Gelder, mit denen er den Test finanziert, so wirkungsvoll wie nur irgend möglich eingesetzt sind.
 

Test Automation Tools


Diskussionsforum zur Seite Test Automation Tools

und zu meinen Aussagen, das Messen von Testabdeckung betreffend:

Klar sein muss:

Nur nachgewiesene Testabdeckung kann zeigen, ob ausreichend getestet wurde.

 

Crashkurs für Testmanager


Der internationale Standard ISTQB will vollständige Sammlung all dessen sein, was Praktiker und Theoretiker bisher an Testmethodik erarbeitet und zusammen­getragen haben.

Leider wird in den zur ISTQB-Zertifizierung führenden Kursen viel zu wenig unterschieden zwischen praktikabler Methodik einerseits und wenig praktikabler andererseits.

Der wirklich in jedem Testprojekt praktikable Teil ist beschrieben in

Wer darüber hinaus weitere praktische Anleitung sucht, dem empfehle ich zu lesen:

.