Testing ist nur die Spitze des Q-Eisbergs

Interpretiert man den heute gängigen Begriff Testing so wie er im Allgemeinen verwendet wird, dann versteht man hierunter die funktionale und / oder nicht-funktionale Verifikation und / oder Validieren von Anforderungen eines oder mehrerer Endergebnisse nach der Realisierung und damit gegen Ende des Sprints. Das dies allerdings nur die sprichwörtliche Spitze des Q-Eisbergs ist wird oft vergessen. Es erfordert nicht unerheblich viele Aktivitäten im Vorfeld bis ein Test durchgeführt werden kann.

Das agile Vorgehen unterliegt teilweise immer noch dem Trugschluss, dass nichts mehr dokumentiert werden muss. Schlüssige und konsistente Anforderungen wurden durch Stories ersetzt die teilweise noch nicht mal mehr ganze Sätze enthalten. Das mit diesem Mindset die Qualität auf ganzer Strecke leidet sieht man am Fertigstellungsgrad zuvor geplanter Sprints. Die Überführung von unfertigen Stories in den nächsten Sprint wird allgemein hingenommen und fast stillschweigend akzeptiert. Ich weiss es ist etwas provokativ formuliert, aber dennoch nicht so realitätsfremd wie man meinen könnte. Ich bin ein grosser Fan des agilen Vorgehens und insbesondere von TDD. Ich habe Kent Beck 1997 auf einem Summer School Workshop kennengelernt und die ersten Erfahrungen mit TDD gemacht. 2019 habe ich den Certified Scrum Master CSD gemacht, und der Schulungsleiter fragte mich wie ich den Kurs fand? Meine Gegenfrage war: “Was habt ihr die letzen 20 Jahre gemacht? Ich sehe keinen Unterschied zu 1997”. Was ich nicht verstehe ist, dass all die entwickelten Q-Massnahmen die die letzten 20 Jahren ausgemacht haben teilweise über Board geworfen werden. Für Regressionstests ist zu wenig Zeit. Progressionstests werden auf ein Minimum reduziert und an eine Impact-Analyse ist kaum zu denken. Man fängt wieder an von der Hand in den Mund zu leben. Mit einer kurzen und knappen Beschreibung von Stories schleichen sich auch Inkonsistenzen ein. Das Ergebnis sind oft unterschiedliche Interpretationen desselben Sachverhalts. Zum Beispiel wird die Forderung nach Mehrsprachigkeit eines Features vom Product Owner nicht dokumentiert und als gegeben vorausgesetzt. Effizienzsteigerungen durch weglassen war noch nie eine gute Idee. Selbst die Verlinkung mit anderen Dokumenten, die die jeweilige Story unterstützt führt oft zu einer Zerfaserung des Wissens und damit zu Lücken bei der Herleitung der Testfälle.

Und hier sind wir schon mitten im Thema und unter der Oberfläche des Q-Einbergs. Die sich daraus ergebenen Inkonsistenzen und Anforderungslücken werden erst spät oder gar nicht entdeckt. Während des Reviews heisst es dann “Works as Design”. Was keinem wirklich hilft. Auch während der Retrospection wird wenig Kritik geäussert. Die Teilnehmer halten sich meist bedeckt. Eine Feedback-Kultur wird zwar gefordert aber nur bedingt gefördert.

Kommen wir zurück zu unseren Q-Eisberg. Wir sehen an der Oberfläche ein oder mehrere Ergebnisse eines Sprint. Wir wollen vor der Kollision wissen, ob wir es mit so einem Brocken aufnehmen können. Oder wird der Eisberg uns in den unternehmerischen Abgrund reissen, weil Anforderungen nicht korrekt umgesetzt wurden oder Testlücken vorhanden sind? Was können wir tun, um diesen Zustand zu ändern? Aus meiner Sicht sind dies primär zwei Punkte:

1. Prozess-Ebene: Einführung einer konsequenten Prozessverantwortung mit messbaren Leitplanken für den gesamten Sprint. Nicht nur die Ergebnisse müssen stimmen, sondern auch die Einhaltung der Regeln. Ansonsten haben wir eine Garbage-In-Garbage-Out-Situation.
2. Inhalts-Ebene: Die Fokussierung auf objektiv messbare Prüfpunkte bei der Formulierung der geforderten Features einer Story. Dies reduziert den Interpretationsspielraum und gibt dem Entwickler eine hervorragende Ausgangssituation, um den Test-Driven-Development-Approach umzusetzen.

Ich plädiere seit langem für eine Fokussierung auf Prüfpunkte und Quality Gates und weniger die prosaische Beschreibung von Stories, die zudem gefährlich interpretativ sind. Durch die Formulierung objektiver Prüfpunkte seitens des Product Owners wird ein messbares Quality Gate definiert. Erst mit diesem Approach kann aus meiner Sicht von einem effizienten und vor allem effektiven Vorgehen gesprochen werden.