Die agile Transformation bringt Herausforderungen mit sich. Nach vielen Software-Test-Projekten, die wir begleitet haben, gibt es trotz all der Individualität dennoch ein paar typischen Probleme, die immer wieder auftreten. Und ebenso ein paar Faktoren, die die Transformation positiv beeinflussen und beschleunigen.
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. Durch dieses Vorgehen werden die Probleme aber nur teilweise gelöst.
Qualität im agilen Team bedeutet vor allem Verantwortung eines jeden Einzelnen. Und auch wenn es äußerst sinnvoll ist, die Sicht eines Testers im Team zu haben, befreit das nicht 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, Product Owner, Tester und welche Rollen man sonst noch besetzen möchte.
Daher ist es wichtig sich bei der Beschäftigung mit Testen im agilen Kontext immer vor Augen zu führen, dass es eben nur ein Teil der Qualitätsmaßnahmen ist. Es gilt viel mehr daran zu arbeiten, Qualität im Team zu fördern und leben. So geben alle folgenden Methoden und Hinweise einen Impuls und Ansatzpunkt, der aber in den Projekten individuell und kontextabhängig weitergedacht werden muss.
Agilität ist Veränderung und Veränderung braucht Zeit. Testen mit seinen verschiedenen Aspekten in den agilen Kontext zu transferieren, benötigt Zeit. Hinzu kommt, dass es im Agilen auch immer darum geht, Bestehendes zu hinterfragen – das betrifft auch die Testmethoden und Testansätze. Hier gilt es wachsam zu sein und nicht vorschnell zu urteilen, ob eine Veränderung etwas bewirkt hat oder nicht. Auswirkungen einer Veränderung sind vielleicht erst in einiger Zeit bzw. Iterationen sichtbar. Wer hier vorschnell die Änderung bereits rückabwickelt, vergibt vielleicht eine wertvolle Chance zur Weiterentwicklung.
Tools, Methoden oder Gurus werden gerne als Lösung für all die Herausforderungen gesehen, die den Übergang zum agilen Vorgehen präsentiert. Typisches Beispiel “zur Beschleunigung” der Tests: Testautomatisierung. Doch wenn das Fundament 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 offenbart der Spruch “A fool with a tool is still a fool”, dass der Werkzeugeinsatz (z.B. zur Testautomatisierung) gut überlegt und passend zum übrigen Projektaufsatz gewählt sein will.
Agilität lebt von Werten wie Selbstverantwortung, Transparenz und mutigen Entscheidungen. Dafür muss z.B. für die Entwicklung der Teststrategie auch der notwendige Freiraum gelassen werden. Tester müssen die Möglichkeit haben, Methoden und Tools auszuprobieren, wieder zu verwerfen und andere Wege einzuschlagen. Das bedingt auch eine angemessene Fehlerkultur, in der Fehler als Chance zum Lernen im Team angesehen werden und nicht als Versagen eines Einzelnen. Darauf ist besonders auch bei der Moderation von Retrospektiven zu achten.
Hier ist auch ein Umdenken durch Vorgesetzte, z.B. dem Linien-Testmanager, notwendig. Wenn Entscheidungen der Tester immer wieder in Frage gestellt bzw. von oben ausgehebelt werden, wirkt sich das rasch auf die Motivation im Team aus und führt zum genauen Gegenteil dessen, was man mit dem agilen Vorgehen erreichen will: Statt einem vor Kreativität und Leistung sprudelnden Team, wird dann auf Dinge gesetzt wie Absicherung, Protokollierung und Entscheidungsvorlagen.
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, aber speziell auch auf Tester, die aus traditionellen Projekten in agile kommen. Es geht für den Tester 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 oft für Entwickler aus einem traditionellen Projektumfeld ungewohnt, selbst zur Qualität beizutragen und nicht einfach nur die fertigen Module “über die Mauer” zum Testteam zu werfen.
Dieses Aufbrechen des Silo-Denkens benötigt Fingerspitzengefühl bei der Unterstützung. Es ist eine Gratwanderung zwischen Empathie und Aufrechterhaltung des notwendigen Veränderungsdrucks. Ebenso ist es ein Prozess, der sich über mehrere Monate ziehen kann, bis diese Verhaltensmuster verändert sind.
Unserer Erfahrung nach ist einer er größten Hebel für den Erfolg vom agilen Testen das ordentliche Durchführen von Retrospektiven. Das gilt im Übrigen nicht nur für den agilen Kontext, sondern genauso für den traditionellen. Die Betonung liegt hier auf “ordentlich”. Denn ein Meeting, in dem der Großteil nicht aktiv ist und sich der Rest im “Jammern über die letzten Wochen” ergeht, hat nichts mit einer Retrospektive zu tun. Gerade in dieser Selbstreflektion des Teams steckt die Kraft, schnell die eingeschlagenen Wege zu beurteilen, Prozesse zu korrigieren und den Elefanten im Raum anzusprechen – über den sonst niemand spricht.
Für Qualitäts- und Testthemen lohnt es sich, bei Bedarf eigene Retrospektiven durchzuführen, die nur diese Themen adressieren. Das kann gerade in der Startphase des agilen Tests hilfreich sein, 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 – z.B. bei der Wahl der Test-Tools oder eines Frameworks – der falsche war. Retrospektiven können helfen, diese Punkte frühzeitig aufzudecken und Konflikte erst gar nicht entstehen zu lassen.
Die konkrete Umsetzung von agilem Testen ist von vielen Faktoren abhängig: Unternehmen, Projekt, Strukturen, Anwendung, Team…. Das betrifft alle Themen von der Release-Planung und dem Anteil der Hardening Iterations an den Iterationen, über die Art und den Umfang des Kunden-Feedbacks über den Grad der Testautomatisierung bis hin zu Detailgrad und Umfang der Ergebnisse sowie deren Dokumentation. Jedes Projekt und jede Organisation ist hochgradig individuell und der Wechsel zu agilen Methoden lebt von Erfahrungen, Best Practices und Austausch. Und so möchten wir Sie hier gerne ermutigen: Sprechen Sie mit anderen über ihre Vorhaben. Es gibt so viel Wissen und Erfahrungen in Ihrem Unternehmen und Netzwerken – nutzen Sie diese und gestalten Sie ihren eigenen agilen Weg.