Qualität ist mehr als Testen: Reverse Engineering

Bild: Pixabay / Ennelise - Lizenz

Zu den häufigsten Problemen mit denen man als agiler Tester konfrontiert wird gehört das völlige oder weitgehende Fehlen von schriftlichen Anforderungen oder Dokumentationen. Im Normalfall ist das ein starker Indikator dafür, dass das Team Agilität nicht verstanden hat und sie nach dem Dilbert-Modell eingeführt hat. Viele Tester neigen in solchen Situationen dazu, die Entwickler zu fragen was sie programmiert haben, um dann genau das zu testen. Dieses Vorgehen ist deshalb häufig weil es der einfachste und schnellste Weg ist - und ausserdem ist es grundfalsch!

Was bei diesem Ansatz völlig unter den Tisch fällt ist die eigentlich wichtigste Frage, die nämlich ob das was entwickelt wurde tatsächlich das ist was der Kunde/Product Owner/Auftraggeber wirklich wollte. Ohne festgehaltene Anforderungen oder Dokumentationen besteht ein hohes Risiko, dass einer der folgenden Fälle eingetreten ist oder eintreten wird:

• Der Ersteller der Anforderungen wusste selbst nicht genau was er wollte und hat daher "hinreichend unscharf" formuliert. In diesem Fall sind ausufernde Diskussionen um Anspruch und Wirklichkeit kaum zu vermeiden.
• Der Ersteller der Anforderungen wusste was er wollte, konnte es aber nicht formulieren. Mit großer Wahrscheinlichkeit entspricht das Ergebnis nicht seinen Vorstellungen.
• Der Ersteller der Anforderungen wusste was er wollte, hat es aber mittlerweile wieder vergessen. Auch hier werden lange Diskussionen das Ergebnis sein.
• Die Entwickler haben eine "pragmatische Lösung" gefunden, oder mit anderen Worten: sie haben die Anforderung ganz oder in Teilen ignoriert.

Die dringend notwendige (und hochgradig undankbare) Aufgabe des agilen Testers muss es jetzt sein, so genanntes Reverse Engineering zu betreiben. Das bedeutet zunächst, noch vor dem Testen die ursprüngliche Anforderung zu recherchieren, sie von ihrem Ersteller absegnen zu lassen und erst auf dieser Basis fortzufahren. Und fortfahren bedeutet in diesem Fall zunächst nicht das Testen, sondern vielmehr ein Gespräch mit dem Entwicklern, in dem diese sagen können wie die Anforderung von ihnen verstanden worden ist. Im Regelfall stellt sich bereits an dieser Stelle heraus, dass die (rekonstruierte) Anforderung und die Implementation spürbar auseinenderliegen. Ein Softwaretest in dem Sinn, dass überprüft wird ob Anforderung und Implementation übereinstimmen macht von da an praktisch keinen Sinn mehr.

An die Stelle des Testens sollte jetzt sinnigerweise eine Analyse treten, an deren Ende die Antworten auf die folgenden Fragen stehen sollten:

• Welche Teile der rekonstruierten Anforderung sind umgesetzt worden?
• Welche Teile der rekonstruierten Anforderung sind nicht umgesetzt worden?
• Was ist umgesetzt worden obwohl es in der rekonstruierten Anforderung nicht gefordert war?
• Was ist umgesetzt worden obwohl es mit der rekonstruierten Anforderung nicht kompatibel ist?

Auf Basis dieser Erkenntnisse können dann neue Anforderungen (diesesmal nach Möglichkeit schriftlich) formuliert werden um den Spalt zwischen Anspruch und Wirklichkeit zu schließen. Erst danach macht das Durchführen von Tests wirklich Sinn.

PS:
Ein Tipp aus der Praxis: Sobald es absehbar ist, dass das Fehlen schriftlicher Anforderungen und Dokumentationen dazu geführt hat, dass das Verständnis von Anforderungsersteller und Entwicklern sich auseinanderentwickelt hat, besteht das Risiko von verstärktem Blaming und Fingerpointing. Es ist an dieser Stelle immer eine gute Idee sich a) nicht daran zu beteiligen und b) anzumerken, dass ein gemeinsames Arbeiten an einer Lösung wesentlich zielführender ist als gegenseitige Schuldzuweisungen.