Testen im agilen Kontext: habe ich genug getestet – wann höre ich auf?

Eine Frage, die vermutlich jedem Softwaretester irgendwann begegnet: wann habe ich genug getestet? Oder: wann höre ich auf? Insbesondere in iterativen Entwicklungsprozessen ist diese Frage nicht einfach zu beantworten. In diesem Artikel gehe ich auf die Antworten anderer Softwaretester ein und beantworte die Frage abschließend anhand meiner eigenen Erfahrungen.

Definition von Testendekriterien und Abgrenzung von der Definition of Done

Gemäß ISTQB sind Testendekriterien definiert als “die Menge der abgestimmten generischen und spezifischen Bedingungen, die von allen Beteiligten für den Abschluss eines Prozesses akzeptiert wurden.” Weiter heißt es, Endekriterien verhinderten es, dass eine “Aktivität als abgeschlossen betrachtet wird, obwohl Teile noch nicht fertig sind.”

Diese Definition kann nützlich sein, um das Testende von der Abnahme eines Features abzugrenzen. Bezogen auf Scrum sprechen wir bei Abnahmekriterien üblicherweise von der Definition of Done. Diese geht jedoch weiter, als bis zum Ende des Testens.

Im Folgenden beziehe ich mich ausschließlich auf den Prozessschritt Testen in der agilen Softwareentwicklung.

Projekt-getriebene Testendekriterien: Testfälle, Codeabdeckung, Deadlines

User Elham Jamal beantwortet in diesem populären Beitrag auf LinkedIn die Frage nach dem Testende mit harten Testendekriterien:

1. Testing Deadlines
2. Completion of test case execution
3. Completion of Functional and code coverage to a certain point
4. Bug rate falls below a certain level and no high priority bugs are identified
5. Management decision

Angemerkt sei, dass er keinen Bezug auf das agile Vorgehensmodell nimmt. Ich möchte die einzelnen Kriterien dennoch im agilen Kontext diskutieren:

1. Deadlines sind ein rein zeitliches Kriterium. Beendet der Tester seine Arbeit, weil die Deadline es so vorsieht, scheint er nach anderen Kriterien nicht fertig zu sein – sonst hätte er bereits aufgehört. Zudem beginnt das Testen im Scrum-Prozess oft erst kurz vor der Deadline – dem Sprintende.
2. Testfälle entstehen basierend auf dem Modell der Software, bevor der Tester sie wirklich nutzen kann. Daher deckt ein rein Testfall-basiertes Testen möglicherweise nicht die relevanten Schwachstellen der endgültigen Software ab.
3. Es ist eine sinnvolle Strategie, die Abdeckung funktionaler Anforderungen und der Codeabdeckung als ein messbares Instrument heranzuziehen, um das Testende zu bestimmen. Im agilen Kontext ist es allerdings zeitkritisch, in Iterationen von 2-3 Wochen und einem verbleibenden Testzeitraum von wenigen Tagen eine vollständige Abdeckung der beiden Aspekte zu erreichen.
4. Das Testende anhand der Fehlerrate zu bestimmen, ist im agilen Kontext ebenfalls kritisch. Bei kleinen Features bewegen wir uns im Rahmen von möglicherweise nur ein bis zwei Fehlern pro Feature. In solch einem Falle ist eine quantitative Grenze schwierig zu ziehen.
5. Ähnlich wie bei Punkt 1 wird in die Arbeit des Testers eingegriffen. Ein externer Einfluss als Testendekriterium ist mit hoher Wahrscheinlichkeit nicht im Sinne der Softwarequalität.

Fehler-Vorhersage als Testendekriterium

Yegor Bugayenko schreibt in diesem Blogbeitrag: “the only valid criteria for exiting a testing process is the discovery of a forecasted amount of bugs”. Wie er in seinem Beitrag schildert, muss im Laufe des Testprozesses eine möglichst genaue Prognose über die verbleibenden Fehler entstehen. Anhand dieser Daten kann der Tester einschätzen, ob das Produkt ausreichend getestet ist, um es auszuliefern.

Ich stimme dieser Aussage weitestgehend zu. Hat der Tester ausreichend Daten gesammelt, kann er zusammen mit dem Team entscheiden, ob die Software gut genug ist, um sie auszuliefern. Und dennoch fehlt mir eine konkrete Ableitung, wann der Tester demnach aufhören kann zu testen.

Risiko-basierte Testendekriterien

Wie wir in zukünftigen Beiträgen noch genauer beleuchten werden, verfolgen wir den Ansatz des risikogetriebenen Testens. Hieraus lassen sich auch auf Risiken basierende Testendekriterien ableiten. Kurz umrissen bedeutet risikogetriebenes Testen: Risiken analysieren, Risiken priorisieren, Risiken minimieren.

Anders als die Ansätze in den referenzierten Beiträgen bietet das risikogetriebene Testen eine handfeste Strategie, um das Testende zu begründen.

Das Testende wird bereits im zweiten Schritt – der Risikopriorisierung – vorbestimmt. Es sei angemerkt, dass die Priorisierung der Risiken nur zwei Fragen beleuchtet: Welche Risiken sollen im Rahmen des Tests erkundet werden? Welche Risiken nehmen wir in Kauf, ohne ihnen nachzugehen? Der Tester ist genau dann fertig, wenn er genügend Daten über potentielle Risiken gesammelt hat. Daten sammeln meint hier sowohl den explorativen Test als auch Absprachen mit dem Product Owner oder den Entwicklern.

Offen bleibt also die Frage, wie ausführlich der Tester seinen explorativen Test gestaltet, um das jeweilige Risiko zu erkunden. In der Praxis handhabe ich es so, dass ich anhand der Rahmenbedingungen Zeit, Aufwandsschätzung und Kritikalität entscheide, wann ich ein Risiko ausreichend erkundet habe.

Fazit: Der Test ist beendet, wenn ausreichend Daten bereitstehen

Richtet sich das Ende nach Deadlines oder durch Vorgaben des Projektmanagers, testen wir in der Regel zu viel oder zu wenig. Beides ist kostspielig und ineffizient. Stattdessen sollte der Tester seine Arbeit systematisch abschließen. Hierzu benötigt er Erkenntnisse anhand derer ein Team entscheiden kann, ob es die Software ausliefern möchte.

Harte Testendekriterien eignen sich für das agile Vorgehensmodell nur bedingt. Stattdessen lassen sich solche Kriterien als Hilfsmittel nutzen, um eine Software oder eine Softwarekomponente systematisch zu erkunden.