Qualitätssicherung ist Detektivarbeit

Die Qualitätssicherung in der Softwareentwicklung hat viele Parallelen zur Arbeit von Detektiven. So braucht es in beiden Berufen eine starke Analysefähigkeit, kreatives Denken und den Blick fürs Detail. Was Softwaretester:innen und Detektive noch alles gemeinsam haben, das erfahrt ihr in diesem Blogbeitrag.

Als Spezialist für Software-Qualitätssicherung kommt Autor Jörg Irle zu einer Beobachtung:

Manchmal ist es so, als sei man Sherlock Holmes, Hercules Poirot oder Miss Marple auf der Suche nach Spuren und fragt sich „Was ist hier nur geschehen?“. Ein Mensch mit Testinstinkt hat manchmal auch die gleichen genialen Geistesblitze, wie die genannten Namen. Die berühmten Detektive werden in ihren Geschichten oft engagiert, um Verbrechen aufzuklären. Glücklicherweise kommen wir aber im Normalfall nicht post mortem zum Einsatz!

Ein Detektiv kommt nicht nur im Nachgang eines bereits eingetretenen Schadens, sondern auch um Sachverhalte zu klären, Situationen zu analysieren und auch um ggf. andere Menschen auf eine Probe zu stellen. Sein Einsatz dient ebenso dazu, präventiv zu agieren, um mögliche Schäden zu vermeiden.

Was macht ein Detektiv, Der einen Ermittlungsauftrag erhält?

• Analyse der Ausgangssituation
• Sammlung ergänzender Informationen
• Einen Plan erarbeiten
• Ermittlung durchführen und dokumentieren
• Ermittlungsergebnisse auswerten

Klingt das nicht vertraut? Gleich einem Detektiv, der einen Fall übernimmt, machen wir in der Qualitätssicherung Vorermittlungen und analysieren erst mal das Umfeld, machen eine Bestandsaufnahme. Wir arbeiten investigativ und recherchieren. Unsere Rechercheobjekte sind sowohl Geschäftsprozesse, Anwendungsfälle und die wie auch immer spezifizierten Anforderungen als auch die eingesetzte Technik (Systeme).

Befragungen sind hier ein wichtiger Teil des Jobs. Auch wenn schon zum Zeitpunkt deiner Beauftragung viel spezifiziert wurde, gibt es oft noch Fragen, die keiner gestellt hat, Ungereimtheiten oder Lücken in den Spezifikationen, insbesondere aus Testperspektive. Mit entsprechenden Befragungstechniken interviewen wir Stakeholder des Projekts, um für den Test zusätzliche wichtige Informationen zu erhalten. Wir müssen Risiken einschätzen können, um die Eintrittswahrscheinlichkeit und/oder den potenziellen Schaden zu minimieren. Ggf. muss man hier auch mal getroffene Annahmen hinterfragen.

• „Ist es sichergestellt, dass nur vollständig korrekte Daten in den Prozess einfließen?“
• „Was passiert, wenn System X nicht antwortet?“
• „Wie soll das System auf ein Geburtsdatum in der Zukunft reagieren oder wenn die antragstellende Person minderjährig ist?“
• „Was passiert, wenn man den Prozess zur Umstellung Sommer-/Winterzeit laufen lässt?“
• …

Hier lohnt es sich, auch die Perspektive eines „Kriminellen“ - wie ein Detektiv es tut - einzunehmen und umgekehrt zu fragen: Was muss ich tun, damit das System ein Fehlverhalten erzeugt? Wie kann ich das provozieren? (Error Guessing).

Soweit wir nun wissen, worum es geht und was unser Testauftrag ist, planen wir unsere Aktivitäten. Wann ist was zu tun? Was muss wann an vorbereitenden Tätigkeiten erfolgen (Bereitstellung von Infrastruktur, Aufbereitung von Testdaten, … )? Welche Tools (Lupen) können wir wo einsetzen, um unsere Recherche bestmöglich zu unterstützen? Benötige ich evtl. noch Spezialisten? Wann kann welche Funktionalität getestet werden? Wer führt welche Tests durch? Welche weiteren offenen Fragen müssen noch geklärt werden? …

Dann kommen wir zu unserer eigentlichen Ermittlungsarbeit. Hier heißt es nun genau hinsehen! Wir haben zwar einen Plan gemacht, aber es geht nicht nur um das Abarbeiten eines Plans. Wie bei der Detektivarbeit müssen wir auf die Details achten und genau hinschauen was passiert. Da stößt man dann auf einmal auf eine Überraschung, eine Anomalie!

Dann kommt der spannendste Teil der Recherchearbeit, in dem man flexibel reagieren musst. Das Ergebnis entspricht nicht dem erwarteten Verhalten. Woran liegt’s? Lässt sich das Verhalten reproduzieren? Haben wir etwa einen Fehler? Gab es ein ähnliches Verhalten evtl. auch schon mal in einem anderen Test? Lassen sich vielleicht irgendwelche Zusammenhänge erkennen? Haben wir das SUT (system under test) evtl. falsch bedient oder sind Eingaben nicht so, wie sie sein sollten? Aber vielleicht sind ja sogar unsere Annahmen falsch und wir müssen uns selbst und unseren Test hinterfragen.

Hier kommt einem natürlich auch die erfahrene „Schnüffelnase“ als Ermittler:in zugute. Ob aus diesem Test oder im Umgang mit anderen Systemen erkennt man evtl. Muster, die einen auf die richtige Fährte lenken.

Sie wollen Ihr Softwaretesting optimieren?

Mit dem Testprozess-Audit der viadee können Sie Ihre Softwarequalität nachhaltig erhöhen.

Ebenfalls mit der Ermittlungs- und Recherchearbeit verbunden ist eine gute Protokollierung unserer Ergebnisse. Die Ermittlungsergebnisse eines Detektivs, bspw. in der Personenüberwachung, können schwerwiegende Folgen für die betroffene Person haben. Gleichermaßen haben unserer Ermittlungs- bzw. Testergebnisse einen entscheidenden Einfluss auf den Softwareeinsatz in einem Unternehmen, ja am Ende sogar auch die betriebswirtschaftlichen Abläufe. Wir müssen ein sorgfältiges und klares Bild vermitteln, auf dessen Basis die erforderlichen Entscheidungen getroffen werden können.

Während wir aus Film und Fernsehen viele Detektivgeschichten kennen, in denen am Ende ein:e Täter:in überführt wird, kennen wir aber auch ein anderes Ende der Story: unsere intensiven Recherchen haben ergeben, dass kein Fehlerverhalten entdeckt werden konnte bzw. alle Mängel abgestellt wurden - unser SUT ist produktionstauglich. Unser Auftraggeber liest unseren Bericht und wird glücklich und zufrieden sein.

Downloadtipp: Leitfaden für die Ermittlungsarbeit als Softwaretest-Detektiv