Lösungen

Test

Test

Beim Wasserfallprojektmanagement werden Entwicklung und Tests in zwei verschiedene Schritte aufgeteilt: Entwickler entwickeln ein Feature und "schmeißen es dann über den Grenzzaun" zum Qualitätssicherungsteam (QA), damit dieses das Feature testen kann. Das QA-Team schreibt detaillierte Testpläne und führt diese aus. Es erfasst außerdem Fehler, wenn es gründlich nach Regressionen in vorhandenen Features sucht, die möglicherweise durch die neue Arbeit verursacht wurden.

Viele Teams, die diese Wasserfall- oder andere herkömmliche Testmodelle verwenden, stellen fest, dass die Menge der Tests exponentiell mit dem Produkt wächst – und das QA-Team ausnahmslos Probleme hat, Schritt zu halten. Project Owner stehen vor einer unliebsamen Entscheidung: das Release verschieben oder beim Testen nachlässig sein. (Du darfst einmal raten, welche Option zu 99 % gewinnt.) In der Zwischenzeit ist die Entwicklung zu einer anderen Aufgabe übergegangen. Es wachsen also nicht nur die technischen Schulden, sondern die Behebung der einzelnen Fehler macht ebenfalls einen aufwendigen Kontextwechsel zwischen zwei Teilen der Codebasis erforderlich. Eine verzwickte Situation.

Um das Ganze noch zu verschlimmern, werden QA-Teams herkömmlicherweise danach belohnt, wie viele Bugs sie finden, was Entwickler in die Defensive drängt. Gibt es keinen besseren Weg für Entwickler und das QA-Team, die Anzahl der Bugs im Code zu reduzieren und gleichzeitig die unangenehmen Kompromisse zu vermeiden, die Product Owner eingehen müssen? Wäre dann nicht eine insgesamt bessere Software möglich?

Damit kommen das agile Testen ins Spiel.