Wie sollte ein Software-Tester mit übersehenen Defekten/Fehlern in der Produktion umgehen?

In all den Jahren, in den ich in der QA-Branche tätig bin, habe ich immer wieder Fehler auch übersehen, trotz intensivem testen. Das liegt auch daran, dass Fehler eben immer auch flexibel sind und man sich nicht auf einen Weg versteifen sollte, sondern immer auch das unmögliche denken. Das macht eigentlich auch einen sehr guten Tester aus. Ein Tester, der eben auch um die Ecke denken kann. Der nicht nur schwarz und weiß für mögliche Testszenarien hält.

Nehmt es nicht persönlich und seid professionell

Bei der Fehlersuche geht es nicht darum, jemandem die Schuld zu geben, sondern darum, die Qualität des Produkts zu verbessern. Wenn euer Vorgesetzter euch persönlich tadelt, ist das eine ungesunde und entmutigende Situation. Sie ist kontraproduktiv. Der Schwerpunkt sollte darauf liegen, was getan werden kann, um dies in Zukunft zu vermeiden, und nicht darauf, wer für den Vorfall verantwortlich ist.

Perfekte Software ist ein Mythos

Es wird immer Fehler geben – und es wird immer Fehler in der Produktion geben, das ist einfach so. Niemand kann ein Stück Software vollständig testen, genauso wenig wie jemand eine völlig fehlerfreie Software schreiben kann. Es ist zu komplex.

Ich werde ein Beispiel aus einem Artikel zitieren: Zehn Missverständnisse über Softwaretests. Das Zitat stammt aus einem Abschnitt, in dem erklärt wird, warum Fehler in der Produktion nicht bedeuten, dass die Tester versagt haben.

 

Es ist töricht zu glauben, dass Tester in der Lage sein sollten, alles zu erkennen, was in einem Programm falsch ist. Nehmen Sie eine einfache Taschenrechneranwendung, mit oder ohne wissenschaftliche oder andere erweiterte Funktionen. Betrachten Sie nun die Additionsfunktion. Um nur die Addition zweier ganzer Zahlen vollständig zu testen, müsste man die Addition jeder Zahl, die der Rechner verwenden kann, mit jeder Zahl, die der Rechner verwenden kann, testen und sicherstellen, dass das Ergebnis korrekt ist und die Anzeige korrekt ist.

Selbst mit einem sehr einfachen Taschenrechner, der keine Exponentialschreibweise anzeigt und nur von -999999 bis 999999 addieren kann, sind das 1999998 mögliche ganze Zahlen, die zu 1999998 möglichen ganzen Zahlen addiert werden müssen – oder (1999998)^2. Wenn es im Durchschnitt nur 5 Sekunden dauert, die Berechnung durchzuführen und das Ergebnis zu überprüfen, sind das immer noch mehr als 300000 Jahre, um jede mögliche Addition zweier Zahlen zu testen (und das bei einem Arbeitsalltag von 24/7/365). Niemand hat so viel Zeit.

Selbst wenn man die durchschnittliche Testzeit durch Automatisierung auf 0,1 Sekunden senken kann, vergehen immer noch Tausende von Jahren oder Tausende von Computern, bevor man alle möglichen Kombinationen getestet hat. Und denken Sie daran, dass es hier nicht einmal um etwas anderes als die Addition zweier ganzer Zahlen geht. Was passiert, wenn man Dezimalzahlen addiert? Andere Operationen? Mehr als zwei Zahlen? Es dauert nicht lange, bis die Zahl der möglichen Ergebnisse gegen unendlich geht.

 

Dies ist eine Gelegenheit

Ich würde mich nicht zu sehr auf die Tatsache konzentrieren, dass Sie einige Mängel übersehen haben. Betrachten Sie dies stattdessen als eine Chance. Zeigen Sie Ihren Vorgesetzten, was Sie unternommen haben, um die Qualitätskontrolle und die Tests zu verbessern:

• Untersucht, was diese Fehler und Mängel verursacht hat, identifiziert Probleme – Fehlen bestimmter Tests, User Stories, Testfälle, Akzeptanztests, Lasttests usw.
• Denkt an andere Stellen in eurem System, an denen diese Art von Problemen auftreten könnte – möglicherweise entdeckt ihr ähnliche Probleme in anderen Teilen Ihres Produkts/ Eurer Produkte, die aufzeigen und „reklamieren“ könnten. Dies kann ein gutes Zeichen für euren Vorgesetzten sein, dass ihr Lektion gelernt habt und versucht, die Situation zu verbessern.
• Erstellt automatisierte Testfälle für diese Fehler – so stellen ihr sicher, dass diese Fehler beim nächsten Mal frühzeitig erkannt werden und es nicht in die Produktion schaffen.
• Sammelt Abdeckungs- und Komplexitätsberichte – prüft , ob es kritische und komplexe Teile des Systems gibt, die nicht durch Tests abgedeckt sind
• Prüfung alternativer Testmethoden, z. B. Eigenschafts-basiertes Testen als Alternative zum herkömmlichen beispielbasierten Testen
  bei manuellen Tests solltet ihr versuchen, die von euch verwendeten Techniken zu erweitern; hier findet ihr einige weiterführende Ressourcen:

• Test Heuristics Cheat Sheet
• What are some Problem solving techniques that can be used in testing?
• How can a Software Tester use „Out of the Box“ thinking approach to find more bugs?

 

Und nun überlegt euch Folgendes:

• Ihr habt die Probleme in der Produktion gefunden. Nicht bei den Kunden. Das bedeutet, dass sie noch abgefangen wurden, bevor sie externen Benutzern „ausgesetzt“ wurden, und es bedeutet, dass das Unternehmen, sollten Kunden sie melden, sagen kann: „Ja, das ist ein bekanntes Problem und wir arbeiten an einer Lösung für eine zukünftige Version“. Das ist kein Versagen.
• Ihr habt verantwortungsbewusst gehandelt und die Probleme gemeldet, sobald ihr sie entdeckt hattet. Damit habt ihr das Risiko, dem euer Unternehmen ausgesetzt ist, begrenzt.
• Wenn Ihr Manager und Ihre Stakeholder Perfektion erwarten, werden sie enttäuscht sein. Sie haben die Fehler im Code nicht verursacht. Es ist durchaus möglich, dass auch Ihre Entwickler das nicht getan haben: Die Fehler könnten durchaus das Ergebnis unklarer Spezifikationen oder eines Kommunikationsfehlers zwischen dem Produktverantwortlichen und den Entwicklern sein. Oder es könnte sich um das handeln, was ich als „heimliche Verbesserungen“ bezeichne, bei denen das Produkt nicht ganz so funktioniert, wie die Kunden es erwarten, sodass sie es als Fehler melden, obwohl sie die Anwendungsfalldokumente abgezeichnet haben.
• Die Tatsache, dass ihr euch darüber den Kopf zerbrecht, ist ein Zeichen für euer Engagement und nicht dafür, dass ihr ein Versager seid. Einem Versager wäre das völlig egal.
  Sind Sie Superman? Gott? Nein, natürlich nicht. Die Erwartung, dass ihr jeden Fehler in einer Software finden könnt, die nahezu unendlich viele mögliche Benutzerpfade hat (vor allem, wenn ihr die Möglichkeit in Betracht zieht, eine beliebige Anzahl von Wiederholungen rückgängig zu machen), bedeutet, dass ihr selbst erwarten, eine Art unfehlbares Wesen zu sein.

Überzeugt euren Vorgesetzten, euch zu unterstützen

• Hört auf, euch selbst die Schuld zu geben, akzeptiert, dass sich Fehler in die Produktion eingeschlichen haben, aber akzeptiert nicht, dass ihr deshalb unzuverlässig seid. Ihr habt in der gegebenen Situation Ihr Bestes getan.
• Führt eine Ursachenanalyse durch. Dabei geht es nicht nur darum, warum ihr bestimmte Fehler übersehen habt, sondern auch darum, wie diese Fehler überhaupt in die Codebasis gelangt sind. Die Frage „Wie kann ich für einen Code verantwortlich gemacht werden, den ich nicht geschrieben habe?“ kann nützlich sein, ebenso wie der Hinweis darauf, dass man nicht alles testen kann.
  Schuldzuweisungen sind kontraproduktiv, ihr müsst euren Vorgesetzten fragen, warum ihr beschuldigt werdet, wenn ihr den Fehler nicht in den Code eingebracht habt, obwohl es viel produktiver wäre, Maßnahmen zu ergreifen, um zu verhindern, dass ähnliche Fehler in Zukunft in den Code eingebracht werden.
• Zeigt eurem Vorgesetzten, wie ihr diese Testaufgabe gelöst habt, damit auch hier das Verständnis da ist, und entsprechend auch weitere hilfreiche Maßnahmen getätigt werden können. Es gilt immer zu verhindern, wie man diese Fehler in der Produktion zu verhindern sind. Hier kann entsprechend Testautomatisierung hilfreich sein, und natürlich auch ein besserer Workflow. Zu hinterfragen sind auch immer die Defintion of Ready und Definition of Done.