Agile Testkonzepte

Bild: Public Domain Images/Amanda Mills - CC0 1.0

Zu den wohl unagilsten Dingen die mir auf verschiedenen Projekten begegnet sind gehörten die Testkonzepte mitsamt der damit verbundenen Testmanager. Die gesamten Dokumente waren durchzogen von Wasserfall, V-Modell, Command & Control, Dokumentationszwängen und ähnlichen Management-Relikten des zwanzigsten Jahrhunderts. Bedingt dadurch, dass nicht nur ich derartige Erfahrungen gemacht habe, ist die Idee des Testkonzepts im agilen Umfeld stark beschädigt und wird häufig kategorisch abgelehnt. Das muss allerdings nicht so sein. Ich habe bereits mehrfach als agiler Testmanager gearbeitet und in diesem Rahmen agile Testkonzepte schreiben dürfen - ohne dass das als Widerspruch zum agilen Vorgehen empfunden wurde. Es kommt eben darauf an wie man es macht.

Aber was gehört in ein agiles Testkonzept?

Im Grunde das Gleiche, das man auch in einem "klassischen" Testkonzept erwarten würde. Es sollte dort geklärt werden wer was wann wie und wo testet. Folgende Punkte sollten sich meiner Meinung nach dort finden:

• Was bedeutet Testen im agilen Umfeld? (so früh und umfassend wie möglich)
• Wer trägt QA-Verantwortung? (alle)
• Was wird getestet? (sowohl die neuen Features als auch regressiv alle alten)
• Wie wird getestet? (möglichst automatisiert)
• Auf welchen Ebenen wird getestet? (auf allen, in Form einer Testpyramide)
• Wann beginnt die Testphase?  (ganz am Anfang, bzw. es gibt sie nicht gesondert)
• Welche Tools werden eingesetzt? (z.B. Jenkins, Fitnesse)
• Auf welchen Umgebungen wird getestet? (möglichst produktionsnah)
• Wie lang sind die Testzyklen (idealerweise maximal ein Tag, siehe Punkt 4)
• Gibt es spezielle Test-Arten? (z.B. Lasttests, Penetrationstests, A/B-Tests)
• Wie werden die Ergebnisse dokumentiert? (im Idealfall durch das Test-Tool selbst)

Darüber hinaus kann es je nach Einzelfall Sinn machen weitere Bereiche aufzunehmen, zum Beispiel diese:

• Wie ist die Rolle des Testers definiert? (Teil des Entwicklungsteams)
• Wie ist die Rolle des Test-/QA-Managers? (Servant Leader)
• Gibt es Testvorgaben in den Anforderungen? (Ja, Definition of Done und Akzeptanzkriterien)
• Wer verfasst diese Vorgaben? (der Product Owner zusammen mit dem Team)
• Werden interne und externe Regulierungsvorgaben erfüllt? (z.B. durch Mapping-Tabelle)
• Sonstiges (z.B. Test Driven Development)

Derartig aufgebaute Testkonzepte umfassen meiner Erfahrung nach je nach Prosa-Anteil bis zu 20 Seiten, sind also deutlich schlanker als die noch weit verbreiteten "Telefonbücher". Von mir (mit)verfasste derartige Konzepte waren auch bereits Untersuchungsgegenstand von Revisionsabteilungen und haben somit ihre Praxistauglichkeit unter Beweis gestellt. Voraussetzung dafür ist allerdings die Bereitschaft des Managements sich auf agile Vorgehensmodelle einzulassen und nicht auf dem "haben wir immer schon so gemacht" zu bestehen. Das ist zwar nicht immer gegeben, aber in diesen Fällen gibt es ganz andere Probleme als das Testkonzept.