Agile Software-Entwicklung ist vom Startup bis zum Konzern ein vorherrschendes Thema. Neben dem Buzzword Agilität, das manch ein*e Entwickler*in wohl zum Unwort des Jahres küren würde, hat sich dieses Vorgehen als Favorit für Entwicklungsteams durchgesetzt. Und das nicht ohne Grund: Die agile Software-Entwicklung – sei es Kanban, Scrum oder andere Ausprägungen – bringt viele Vorteile mit. Während die Teams sich über eine weitestgehend selbstorganisierte Umsetzungsarbeit freuen, profitieren Manager:innen von der Kundenorientierung, die den Nutzen der Software maßgeblich verbessert.
Aber wie sieht es mit der Qualitätssicherung aus?
Bei Scrum und auch einigen anderen agilen Entwicklungsmethoden ist Qualität ein Team- Effort: Jede*r ist mitverantwortlich für das Thema und soll es mit vorantreiben. Doch in der Praxis führt dies häufig zu Problemen. Welche das sind, und wie man diesen begegnen kann, erfahrt ihr in unserem Beitrag.
Der Whole Team Approach und fehlende Verantwortlichkeit
In der agilen Software-Entwicklung ist der Whole Team Approach ein bedeutender Unterschied zur traditionellen Entwicklungsorganisation. Das Team soll gemeinsam alle Kenntnisse und Fähigkeiten bündeln, um hochwertigen Code zu erstellen. Das bedeutet, dass nicht mehr nur die Testerinnen und Tester für die Qualität verantwortlich sind, sondern alle Teammitglieder. (Quelle: Agile testing : a practical guide for testers and agile teams / Lisa Crispin, Janet Gregory. — 1st ed. (2009), S.60 ff.)
Während diese Herangehensweise ein hohes Maß an Kommunikation fördert und fordert, sowie die allgemeine Qualität des Produkts, kann das Thema Verantwortlichkeit zum Problem werden. Harte Deadlines oder Last Minute-Änderungen führen zu angespannten Situationen, in denen die Zeit für Tests reduziert wird, um mehr Raum für die Entwicklung zu erhalten. Gibt es dedizierte Tester:innen, deren Hauptaufgabe das Testing ist, ist die Reduzierung des Testings weniger wahrscheinlich. Aber was tun, wenn es eine solche Rolle nicht gibt?
In solchen Situationen ist es hilfreich, die Relevanz von Qualität und Testing sichtbar zu machen und die Folgen von kurzfristigen Änderungen an Funktionen bzw. der Software klarer zu kommunizieren. Hier spielt der Whole Team Approach auch eine seiner Stärken aus, indem das ganze Team hinter dieser qualitätssichernden Maßnahme steht. Eine weitere Möglichkeit, die zwar nicht ganz dem Whole Team Approach gerecht wird, aber leicht anzuwenden ist, ist die Etablierung eines „Qualitäts-Botschafters“, der das gesamte Team an ihre Verantwortung erinnert. Diese Aufgabe kann natürlich ein*e Tester*in übernehmen, doch auch jede andere Rolle im Team ist dafür geeignet.
Fluch und Segen: Hohe Entwicklungs-geschwindigkeit
Die agile Software-Entwicklung wartet mit diversen Vorteilen und Versprechungen auf. Dazu zählt auch eine höhere Entwicklungsgeschwindigkeit bzw. der größere Output an neuen Features. Wird diese hohe Zahl von Features jedoch nicht ausreichend getestet oder werden Bugs nicht gefixt, türmt sich die sogenannte technische Schuld auf. Diese führt dazu, dass die Wartung und auch das Beheben von zukünftigen Bugs immer aufwendiger wird. Bildlich gesprochen, muss dann im Berg der technischen Schulden nach der Ursache gesucht werden.
Auch für diese Herausforderung gilt es möglichst früh an die Qualitätssicherung zu denken. Es gilt grundsätzlich, und das vor allem bei dringenden Anpassungen oder den allzu häufigen kurzfristigen Änderungen, immer zu kommunizieren, was dies für ein Risiko hat und welche Aufgaben neben der eigentlichen Entwicklung noch mit dem Änderungswunsch einhergehen. Auch die allgemeine Kommunikation über langfristige Kosten der technischen Schulden kann hier unterstützen. So gehört das Abbauen der technischen Schuld auch zu den Maßnahmen der Qualitätssicherung und sollte Teil einer Qualitätsstrategie sein.
Testing findet weiterhin am Ende statt
Durch die agilen Entwicklungsmethoden sollte ein Umdenken stattfinden, weg von sequenziellen Phasen. In zahlreichen Projektteams wird bei diesem Wandel das Thema QA jedoch außen vorgelassen. Das führt in der Konsequenz dazu, dass besonders die letzten Tage eines Sprints im Zeichen des Testings stehen. (Quelle: Agile testing : a practical guide for testers and agile teams / Lisa Crispin, Janet Gregory. — 1st ed. (2009), S.19f.) In dieser Phase gibt es sicherlich nur wenige Entwickler:innen, die noch einen kritischen Bug finden möchten, den es zu fixen gilt.
Eine mögliche Herangehensweise ist die Verwendung von Test Driven Development oder Behaviour Driven Development, bei denen die Akzeptanzkriterien schon früh in der Entwicklung berücksichtigt werden, auf deren Basis dann erste (Unit-)Tests erstellt werden. Diese Herangehensweise involviert das gesamte Team stärker in den Abnahmeprozess und erleichtert dabei zusätzlich die Kommunikation über das erwartete Verhalten.
Eine weitere Option diese Herausforderung zu meistern, ist der Shift-Left-Approach, bei dem die QA schon in den Entwicklungsprozess involviert wird, bevor die erste Zeile Code geschrieben wurde. Somit wird schon bei der Erstellung von User Stories und Anforderungen das Testing mitgedacht. Ebenso mögliche Probleme, die in der Entwicklung entstehen können, die an dieser Stelle gelöst werden, bevor sie überhaupt im Code auftauchen. (Quelle: Shift-Left Testing, L. Smith 2001. Abrufbar unter: https://www.drdobbs.com/shift-left-testing/184404768)
Fazit zur agilen Qualitätssicherung
Die Rolle der Testerinnen und Tester erfährt durch den Wechsel zur agilen Software-Entwicklung tiefgreifende Änderungen, die sich nicht nur auf ebendiese auswirkt, sondern auf das gesamte Produktteam.
Um den Änderungen und natürlich auch den neuen Möglichkeiten gerecht zu werden, muss ein Umdenken stattfinden: Die Aufgabe der Tester*innen besteht nicht mehr nur aus der Ausführung von Tests, sondern sie sind Botschafter für die Produktqualität. Daher wirken sie schon früh im Entwicklungsprozess mit und unterstützen sowohl Produkt- als auch Entwicklungsteams bei ihrer Arbeit. Viele Teams haben mittlerweile keine dedizierten Tester:innen mehr und übernehmen die Aufgaben gemeinsam. Hier gilt aber ebenso, dass die Einstellung zum Thema Qualität stimmen muss und nicht erst zum Ende eines Sprints bedacht wird. Eine tiefe und vor allen Dingen frühe Integration der Qualitätssicherung in den Entwicklungsprozess sorgt dafür, Risiken zu minimieren. So lassen sich die Prinzipien der agilen Software-Entwicklung gut umsetzen und die verbundenen Erwartungen, erfolgreich erfüllen.
