Agile Testing scheitert selten an der Methode. Meist scheitert es daran, dass Qualität nicht vom ganzen Team getragen wird. In vielen Software-Test-Projekten mit agiler Transformation tauchen trotz aller Individualität immer wieder dieselben Probleme auf: die Beschränkung auf den Test, fehlende Geduld und der Glaube an das eine Werkzeug. Ebenso gibt es Faktoren, die die Umstellung beschleunigen, allen voran Freiraum für Selbstverantwortung und gut gemachte Retrospektiven.
Problem #1: Beschränkung auf den Test
Agiles Vorgehen schafft Transparenz, und so werden Mängel in der Qualität schnell sichtbar. Die erste Reaktion in der Praxis ist häufig, die geballte Kraft auf “agiles Testen” bzw. “agile Tester” auszurichten, eben mit der Motivation, den Fokus auf die Qualität zu legen. Damit sind die Probleme aber nur teilweise gelöst.
Qualität im agilen Team bedeutet vor allem die Verantwortung jedes Einzelnen. Die Sicht eines Testers im Team ist sinnvoll, sie befreit aber niemanden von der gemeinsamen Verantwortung für Qualität. Nicht der agile Tester bringt die Qualität, auch nicht die Testmethoden. Qualität muss im gesamten Team gelebt werden: vom Entwickler, vom Product Owner, vom Tester und von allen weiteren Rollen, die man besetzen möchte.
Daher ist es wichtig, sich beim Testen im agilen Kontext immer vor Augen zu führen, dass es nur ein Teil der Qualitätsmaßnahmen ist. Die eigentliche Arbeit besteht darin, Qualität im Team zu fördern und zu leben. Alle folgenden Methoden und Hinweise geben deshalb einen Impuls und Ansatzpunkt, der in den Projekten individuell und kontextabhängig weitergedacht werden muss.
Problem #2: keine Geduld beim Agile Testing
Agilität ist Veränderung, und Veränderung braucht Zeit. Testen mit seinen verschiedenen Aspekten in den agilen Kontext zu übertragen, dauert. Hinzu kommt, dass es im Agilen immer auch darum geht, Bestehendes zu hinterfragen. Das betrifft auch die Testmethoden und Testansätze. Ob eine Veränderung etwas bewirkt hat, sollte man deshalb aufmerksam beobachten und nicht vorschnell beurteilen. Die Auswirkungen sind vielleicht erst nach einiger Zeit bzw. nach mehreren Iterationen sichtbar. Wer eine Änderung vorschnell rückabwickelt, vergibt womöglich eine wertvolle Chance zur Weiterentwicklung.
Problem #3: Tools und Methoden als Allheilmittel
Tools, Methoden oder Gurus werden gerne als Lösung für all die Herausforderungen gesehen, die der Übergang zum agilen Vorgehen mit sich bringt. Typisches Beispiel “zur Beschleunigung” der Tests: Testautomatisierung. Doch wenn die Basis nicht stabil ist, löst auch das Tool das Problem nicht. Ganz im Gegenteil: “Wer Mist automatisiert, hat immer noch Mist, nur schneller.” So stolpert man auch leicht in die Methoden-Falle: Wir müssen soundso testen! Warum? Weil das so im Buch steht! Ebenso zeigt der Spruch “A fool with a tool is still a fool”, dass der Werkzeugeinsatz (z. B. zur Testautomatisierung) gut überlegt und passend zum übrigen Projektaufbau gewählt sein will.
Erfolgsfaktor #1: Freiraum für Selbstverantwortung
Agilität lebt von Werten wie Selbstverantwortung, Transparenz und mutigen Entscheidungen. Dafür braucht es Freiraum, zum Beispiel bei der Entwicklung der Teststrategie. Tester müssen die Möglichkeit haben, Methoden und Tools auszuprobieren, wieder zu verwerfen und andere Wege einzuschlagen. Das setzt eine angemessene Fehlerkultur voraus, in der Fehler als Chance zum Lernen im Team gelten und nicht als Versagen eines Einzelnen. Darauf ist besonders bei der Moderation von Retrospektiven zu achten.
Hier ist auch ein Umdenken bei Vorgesetzten nötig, z. B. beim Linien-Testmanager. Werden Entscheidungen der Tester immer wieder infrage gestellt oder von oben ausgehebelt, wirkt sich das rasch auf die Motivation im Team aus. Das Ergebnis ist das genaue Gegenteil dessen, was man mit dem agilen Vorgehen erreichen will: Statt kreativ und mit voller Leistung zu arbeiten, setzt das Team dann auf Absicherung, Protokollierung und Entscheidungsvorlagen.
Erfolgsfaktor #2: Klassisches Denken aufweichen
Die mitunter größte Herausforderung bei der Transformation ist, das “alte” Denken aus den Köpfen zu bekommen. Das trifft auf das Team als Ganzes zu, speziell aber auf Tester, die aus traditionellen Projekten in agile wechseln. Für den Tester geht es nicht mehr darum, “seinen” Bereich abzuarbeiten (Testkonzept, Testentwurf, Testdurchführung, Fehlermanagement), sondern darum, sein Know-how dem Team zur Verfügung zu stellen. Ebenso ist es für Entwickler aus einem traditionellen Projektumfeld oft ungewohnt, selbst zur Qualität beizutragen, statt die fertigen Module einfach “über die Mauer” zum Testteam zu werfen.
Dieses Aufbrechen des Silo-Denkens braucht Fingerspitzengefühl. Es ist eine Gratwanderung zwischen Empathie und dem notwendigen Veränderungsdruck. Und es ist ein Prozess, der sich über mehrere Monate ziehen kann, bis sich die alten Verhaltensmuster verändert haben.
Erfolgsfaktor #3: Retrospektiven
Einer der größten Hebel für den Erfolg von agilem Testen ist das ordentliche Durchführen von Retrospektiven. Das gilt übrigens für den traditionellen Kontext genauso wie für den agilen. Die Betonung liegt auf “ordentlich”. Ein Meeting, in dem der Großteil passiv bleibt und sich der Rest im “Jammern über die letzten Wochen” ergeht, hat mit einer Retrospektive nichts zu tun. Gerade in der Selbstreflexion des Teams steckt die Kraft, eingeschlagene Wege schnell zu beurteilen, Prozesse zu korrigieren und auch die Probleme anzusprechen, über die sonst niemand spricht.
Für Qualitäts- und Testthemen lohnt es sich, bei Bedarf eigene Retrospektiven durchzuführen, die nur diese Themen adressieren. Das hilft gerade in der Startphase des agilen Tests, wenn die grundlegende Teststrategie oder die Ausprägung der Testautomatisierung erarbeitet wird. Nichts ist frustrierender, als nach Wochen oder Monaten festzustellen, dass der eingeschlagene Weg, etwa bei der Wahl der Test-Tools oder eines Frameworks, der falsche war. Retrospektiven helfen, solche Punkte früh aufzudecken und Konflikte erst gar nicht entstehen zu lassen.
Bonus-Erfolgsfaktor #4: der eigene Weg
Die konkrete Umsetzung von agilem Testen hängt von vielen Faktoren ab: Unternehmen, Projekt, Strukturen, Anwendung, Team. Das betrifft die Release-Planung, den Anteil der Hardening Iterations, Art und Umfang des Kundenfeedbacks und den Grad der Testautomatisierung. Es betrifft auch Detailgrad und Umfang der Ergebnisse sowie deren Dokumentation. Jedes Projekt und jede Organisation ist anders, und der Wechsel zu agilen Methoden lebt von Erfahrungen und Austausch. Ein konkreter nächster Schritt steht schon beim dritten Erfolgsfaktor: eine eigene Retrospektive nur für Qualitäts- und Testthemen. Dort lässt sich klären, welche der hier genannten Probleme im eigenen Projekt auftreten und wer im Unternehmen oder im eigenen Netzwerk damit schon Erfahrung hat.
Häufig gestellte Fragen
Wer trägt in einem agilen Team die Verantwortung für Qualität?
Qualität ist Sache des gesamten Teams, nicht einer einzelnen Rolle. Weder ein agiler Tester noch bestimmte Testmethoden erzeugen für sich genommen Qualität. Entwickler, Product Owner, Tester und alle weiteren Beteiligten tragen sie gemeinsam. Die Sicht eines Testers im Team bleibt sinnvoll, sie ersetzt aber die geteilte Verantwortung nicht. Testen ist nur ein Teil der Qualitätsmaßnahmen.
Wie schnell lässt sich beurteilen, ob eine Veränderung im Testvorgehen etwas gebracht hat?
Oft erst nach mehreren Iterationen. Agilität bedeutet Veränderung, und Veränderung braucht Zeit, gerade wenn eingespielte Testmethoden und Testansätze hinterfragt werden. Wer eine Änderung vorschnell zurücknimmt, weil sich noch kein Effekt zeigt, vergibt möglicherweise eine wertvolle Chance zur Weiterentwicklung. Wachsamkeit ja, vorschnelles Urteil nein.
Beschleunigt Testautomatisierung die Tests in einem agilen Projekt zuverlässig?
Nicht, wenn das Fundament instabil ist. Ein Werkzeug löst kein Problem, das im Vorgehen selbst liegt: Wer Mist automatisiert, hat immer noch Mist, nur schneller. Der Einsatz von Werkzeugen will gut überlegt und passend zum übrigen Projektaufbau gewählt sein. Dieselbe Falle droht bei Methoden, die man übernimmt, weil sie so im Buch stehen.
Was passiert, wenn Vorgesetzte die Entscheidungen agiler Tester regelmäßig überstimmen?
Die Motivation im Team sinkt schnell, und das Ergebnis kehrt sich um. Statt eines Teams, das Kreativität und Leistung zeigt, entstehen Absicherung, Protokollierung und Entscheidungsvorlagen. Tester brauchen Freiraum, um bei der Teststrategie Methoden und Tools auszuprobieren, wieder zu verwerfen und andere Wege zu gehen. Dazu gehört eine Fehlerkultur, die Fehler als Lernchance des Teams behandelt.
Was ändert sich für Tester und Entwickler, die aus klassischen Projekten in agile Teams wechseln?
Die Arbeitsteilung entfällt. Der Tester arbeitet nicht mehr seinen eigenen Bereich ab, also Testkonzept, Testentwurf, Testdurchführung, Fehlermanagement, sondern stellt sein Know-how dem Team zur Verfügung. Entwickler können fertige Module nicht mehr über die Mauer zum Testteam werfen, sondern tragen selbst zur Qualität bei. Dieses Aufbrechen des Silo-Denkens kann sich über mehrere Monate ziehen.
Woran erkennt man, dass eine Retrospektive nichts bringt?
Wenn der Großteil der Teilnehmer passiv bleibt und der Rest über die letzten Wochen jammert, ist es keine Retrospektive. Ihre Kraft liegt in der Selbstreflexion des Teams: eingeschlagene Wege schnell beurteilen, Prozesse korrigieren und den Elefanten im Raum ansprechen, über den sonst niemand spricht. Das gilt im agilen wie im traditionellen Kontext.
Gibt es eine allgemeingültige Blaupause für agiles Testen?
Nein. Die Umsetzung hängt von Unternehmen, Projekt, Strukturen, Anwendung und Team ab. Das betrifft die Release-Planung, den Anteil der Hardening Iterations, Art und Umfang des Kundenfeedbacks, den Grad der Testautomatisierung sowie Detailgrad und Dokumentation der Ergebnisse. Der Weg dorthin lebt von Erfahrungen, Best Practices und dem Austausch mit anderen im Unternehmen und im eigenen Netzwerk.
