Agile Transformationen auf Projekt- und/oder auf Unternehmensebene sind kein neuer Trend mehr, sondern längst im Arbeitsalltag moderner Unternehmen etabliert. Hierbei findet man in der Literatur allerlei hilfreiche Anleitungen und Best-Practice-Ansätze zum Transformieren der Entwicklungsprozesse, der notwendigen Werkzeuge und dem Einleiten des notwendigen Kulturwandels. Der Transformationsprozess bedarf einer zeitintensiven Vorbereitung und ausdauernden Umsetzung. Doch bekommen im Laufe dieser Umsetzung auch die Testprozesse auf Projekt- und/oder Unternehmensebene die entsprechende Aufmerksamkeit? Denn an erster Stelle in der Prio-Liste dürften diese eher selten auftauchen. Und wie sieht es mit den Testteams/-abteilungen oder externen Dienstleistern aus? Oder fallen diese Aspekte nach anfänglicher Packen-wir-es-an-Mentalität, der Einführung von agilen Werkzeugen (Trello, Jira, etc.) und der Etablierung eines DevOps-Ansatzes dem nachlassenden Änderungswillen zum Opfer? Johann Wolfgang von Goethe schrieb einst: "Aller Anfang ist leicht, und die letzten Stufen werden am schwersten und seltensten erstiegen".
Die zentrale Frage lautet also: Sind die Test- bzw. Entwicklungsteams am Ende der initialen Transformation mit den notwendigen Prozessen, Werkzeugen und Fähigkeiten ausgestattet, um in der agilen Welt nicht nur überlebensfähig zu sein, sondern Schritt halten zu können? Der “Fail Fast” Gedanke sollte in diesem Fall nicht für die Testteams gelten.
Um diese Frage beantworten zu können, schauen wir uns an, welche Ziele bzgl. Softwaretests im agilen Umfeld erreicht werden sollen, damit das Epic “Agile Transformation des Testprozesses und der Testteams” auf “Done” gesetzt werden kann.
Die Anpassung des Testprozesses bzw. der übergeordneten Teststrategie bedarf einiger Überlegungen und Vorbereitungen. So muss beispielsweise analysiert werden, wer die zu testende Software produziert. Wird die Software nur im eigenen Unternehmen produziert und dort auch getestet, kann der Test ganzheitlich durch agile Entwicklungsteams abgedeckt werden. Wird die Software jedoch von einem externen Dienstleister geliefert und muss z.B. aufgrund von regulatorischen Anforderungen im eigenen Unternehmen getestet und abgenommen werden, wird die Team- und Aufgabendefinition deutlich komplexer. An dieser Stelle ist es nicht ausreichend, wenn der Dienstleister die Software agil entwickelt (und intern testet), der Testprozess im Projekt aber nicht darauf abgestimmt ist.
Gleiches gilt, wenn die Software intern entwickelt, aber teilweise von externen Dienstleistern getestet wird, z.B. Last- und Performance- bzw. Security-Tests. Die Teststrategie und -prozesse müssen auch diese Fälle mit berücksichtigen und es muss ein interdisziplinäres Zusammenarbeitsmodell mit den jeweiligen Dienstleistern erarbeitet und abgestimmt werden, in denen es den Testenden ermöglicht wird, Input für z.B. automatisierte Tests zu liefern oder sich die Software bzw. die Artefakte frühestmöglich anschauen zu können. Anderenfalls hört die Agilität mit hoher “Velocity” an der Grenze der Organisationen auf und es kommt unweigerlich zu Verzögerungen und unkalkulierbaren Risiken.
Die Organisation der Testteams muss so angepasst werden, dass diese unabhängig etwaiger Unternehmensgrenzen näher bzw. im besten Fall in das Entwicklungsteam rücken können. Dies bedeutet jedoch, dass Anwendende aus den Fachbereichen, die die Tests bisher manuell (als Nebentätigkeit zum eigentlichen Tagesgeschäft) ausgeführt haben, zukünftig keine (oder nur noch sehr wenige) Tests ausführen sollten bzw. können. Aber sie werden in der agilen Welt sehr wohl noch benötigt, nämlich um den fachrelevanten Input für die zu automatisierenden Testfälle zu liefern oder ggfs. abnahmerelevante und nicht automatisierbare End-to-End-Tests auszuführen. Hier müssen die eingesetzten Werkzeuge und Frameworks entsprechende Abstraktionsebenen bieten, sodass dieser Input schlussendlich in ausführbarem Code mündet.
Im Rahmen der Transformation muss auch geprüft werden, ob Schulungsbedarf (methodisch, technisch) im Team besteht oder ob neue Teammitglieder mit gänzlich anderen Fähigkeiten notwendig sind, da sich bestehende Rollen verändern bzw. neue Rollen hinzukommen. Dabei muss nicht jedes Teammitglied Testautomatisierungskenntnisse besitzen oder Unit-Tests schreiben können, jedoch sollten alle Teammitglieder über Software-Testmethoden und die verwendeten Werkzeuge im Bilde sein. Die Fähigkeit, Code lesen zu können und diesen weitestgehend zu verstehen, erweist sich jedoch in einem agilen Team als sehr hilfreich. Graham Bath geht in seiner Keynote des German Testing Board Testing Summit [1] sogar noch weiter und ist der Meinung, dass Testende zukünftig in der agilen Welt fünf Kern-Kompetenzen besitzen müssen:
Das Thema DevOps steht nicht im direkten Bezug zum Softwaretest, ist aber eine wichtige Voraussetzung, um die Artefakte schneller, nachvollziehbar und getestet bereitstellen und in letzter Instanz auch in die Produktion überführen zu können. Denn für den Test unerlässlich ist eine vollständige, funktionierende und schnell verfügbare Testumgebung. Somit sollte neben der Organisations- und der Prozessanpassung auch zwingend das Umgebungsmanagement bzw. die Bereitstellung der Software auf den Prüfstand gestellt und weitestgehend automatisiert werden. Denn auch hier lauert die Gefahr, dass viel Zeit verloren geht und der Arbeitsfluss gestört wird. Ziel sollte es folglich sein, die benötigte Infrastruktur (z.B. Testumgebungen) ebenfalls in den Entwicklungsprozess aufzunehmen, Stichwort: Infrastructure as Code. Denn zwischen der entwickelten Software und dem Umgebungsmanagement bestehen nicht nur zeitliche, sondern auch inhaltliche Abhängigkeiten. Und gerade im Bezug auf die inhaltlichen Abhängigkeiten können die zeitlichen wie monetären Kosten für ein spät erkanntes Problem, z.B. fehlende Systemvoraussetzungen der Testumgebung, schnell in die Höhe schießen.
Nachdem die Ziele nun geklärt sind, schauen wir uns an, wie die Unternehmen den Umsetzungsgrad bzgl. Agilität derzeit einschätzen. Diese Frage wurde in der Softwaretest-Umfrage von 2020 [2] gestellt. Die Auswertung zeigt, dass an dieser Stelle noch viel Potential vorhanden ist. Deutlich sichtbar wird dies z.B. beim Grad der automatisierten Tests in den jeweiligen Teststufen.
Es ist klar zu erkennen, dass in den Teststufen wie Abnahme- und Systemintegrationstest, in denen in klassischen Modellen viele manuelle Tests ausgeführt werden, noch wenig Automatisierung zum Einsatz kommt. Wenn für diese Teststufen im Projekt nachgelagert ein Testteam manuell den Großteil der Tests ausführt, ist die agile Transformation noch nicht am Ende. Und genau an dieser Stelle werden erfahrungsgemäß häufig die Weichen für das weitere Vorgehen gestellt. Die Transformation läuft schon eine ganze Weile, der Entwicklungsprozess wurde umgestellt, es wurden entsprechende Werkzeuge bereitgestellt und es gibt auch bereits eine Deployment-Pipeline. Doch wer jetzt aufgibt und die Transformation für beendet erklärt, verspielt einen Großteil der gewünschten Effekte. Denn das “schwächste” Glied in der Kette bestimmt die Gesamtgeschwindigkeit, wobei die Schwäche nicht auf das Testteam bezogen ist, sondern auf deren Situation. Denn zum Zeitpunkt X bekommen diese eine neue Version der Software zur Verfügung gestellt und müssen im vorgegebenen Zeitrahmen alle relevanten Tests durchführen und im Zweifel die Teststufe bei wichtigen Korrekturen nochmals wiederholen. Dabei verschiebt sich häufig der Endtermin bzw. die geplante Übernahme in die Produktion NICHT, so dass im Re-Test der Umfang deutlich reduziert werden muss, was am Ende des Tages qualitativ negative Auswirkungen haben kann.
Die Transformationen sind entweder noch im vollem Gange oder das Thema Softwaretest bekommt im gesamten Transformationsprozess nicht die Aufmerksamkeit, die notwendig ist, um von einer agilen Vorgehensweise profitieren zu können. Am Ende des Tages sind es nicht die verwendeten Werkzeuge, die den Unterschied machen, sondern eine Kombination aus einem agil ausgelegten Testprozess, mit einem agil organisierten Entwicklungs- und Testteam und mit einem auf Automatisierung ausgerichteten DevOps-Prozess. Nur wer in der Lage ist, jegliche Änderungen schnell und automatisiert zu testen und die Artefakte zu veröffentlichen, gewinnt tatsächlich an Geschwindigkeit und Qualität. Sie sollten nun in der Lage sein, Ihren aktuellen Umsetzungsgrad der agilen Transformationen, vor allem im Bezug auf den Softwaretest zu bewerten, die Lücken zu identifizieren und Stück für Stück zu schließen. Fangen Sie klein an, denn das Erreichen von Zwischenzielen motiviert zum Weitermachen!
Work on improvements: step by step, day by day.
Gerne tauschen wir uns mit Ihnen bei Bedarf zu den Themen “Agile Transformation” und “Testautomatisierung” aus. Sprechen Sie uns an oder vereinbaren Sie direkt einen Termin mit uns.
