Agile Softwareentwicklungsprojekte sind auf dem Vormarsch. Selbst die konservativsten Organisationen entwickeln ihre Software inzwischen agil. Wo früher Dokumentation und Meilensteinplanung an erster Stelle standen, hat sich die Wertschätzung in Richtung auslieferbarer Software und Flexibilität verschoben.
Aus Sicht eines Softwaretesters stellt sich somit die Frage, was sich denn in agilen Projekten in Hinblick auf das eigene Arbeiten, ändert.
Um genau zu sein: Nicht so viel, wie man denken könnte!
Die Methoden, um Testfälle zu erstellen, also der Werkzeugkasten eines jeden Testers, bleibt derselbe. Man kann also alle Techniken die man über die Jahre erlernt hat, um systematisch Testfälle herzuleiten, weiterhin verwenden.
Auch verschiedene Teststufen, wie z.B. Unit-, Integrations-, System- und Abnahmetest, werden normalerweise auch in agilen Projekten durchlaufen. Aber nicht mehr sequentiell, sondern, je nach Fortschritt der User Story, alle zur selben Zeit.
Die hauptsächliche Änderung gegenüber traditionellen Softwareentwicklungslebenszyklusmodellen liegt darin, dass man nicht das ganze System von vornherein plant, entwickelt und testet, sondern immer nur, mehr oder weniger, kleine Teile.
Deshalb arbeitet man in agilen Projekten auch mit relativ kurzen Iterationen von wenigen Wochen, nach denen potentiell auslieferungsfähige Software entwickelt wird, was auch den kompletten Test, inklusive der Regressionstests, umfasst.
Dass ein kompletter Test eines Systems in der Entwicklung, insbesondere mit häufigen Änderungen an bereits bestehendem Code, herausfordernd ist, liegt auf der Hand.
Dennoch ist es kein aussichtsloses Unterfangen, dieses innerhalb einer Iteration zu erledigen.
Die gute Nachricht zuerst: In agilen Projekten ist das ganze Team für die Qualität verantwortlich, nicht wie in klassischen Projekten, in denen die Qualität gerne ganz in die Verantwortung der Tester geschoben wird. Aus diesem Grund ist zum einen die Ausgangsqualität der Software-unter-Test schon deutlich höher, und zum anderen testen alle Teammitglieder mit.
Außerdem kann man durch die geeignete Wahl der Teststrategie und der verwendeten Testtechniken die Arbeit minimieren und durch konsequente Priorisierung auch das Risiko, welches mit nicht oder spät durchgeführten Tests einhergeht, minimieren.
Ein weiterer Faktor, der zum Gelingen des Vorhabens beiträgt, ist ein hoher Automatisierungsgrad der Tests. Dies ist insbesondere deswegen wichtig, weil die Software in agilen Projekten stetiger Änderung unterliegt und deshalb Regressionstests an Bedeutung gewinnen.
Wie kann eine agile Teststrategie aussehen?
Eine agile Teststrategie sollte, wie eigentlich jede Teststrategie, die geplanten Tests priorisieren und die Testtiefe für die Testbedingungen festlegen.
Der wahrscheinlich am weitesten verbreiteten Ansatz hierfür ist risikoorientiertes Testen. Dieses Paradigma gilt im agilen Umfeld ebenso wie im traditionellen, da Testen eine risikomindernde Methode für die meisten Qualitätsrisiken darstellt.
Aus diesem Grunde sollte bei der Priorisierung und Ausarbeitung der User Stories neben dem Aufwand auch das Risiko geschätzt werden.
Dieser geringe Zusatzaufwand hilft uns dabei die knappe Testzeit innerhalb einer Iteration optimal auf die „wichtigen“ Aspekte des Systems zu fokussieren.
Nach den üblichen agilen Planungsrunden, wie z. B. dem Backlog Refinement oder dem Sprint Planning, wissen wir also was wir testen wollen und was davon wie wichtig ist.
Bezüglich des „Wie“ können wir auf ein häufig genutztes Denkmodell zurückgreifen: die agilen Testquadranten.
Diese visualisieren gängige Testarten nach ihrem Zweck anhand von zwei Dimensionen. Einerseits, ob die Tests einen technischen oder einen fachlichen Fokus haben, und ob sie dazu dienen, die Entwicklung zu lenken und zu unterstützen oder das System auf den Prüfstand zu stellen.
Eine ausgewogene Teststrategie berücksichtigt alle vier Quadranten, wobei die Tests auf der linken Seite meist in Form von (Akzeptanz-)testgetriebener Entwicklung mit einem hohen Grad an Automatisierung implementiert werden und die Tests auf der rechten Seite Schwachstellen im System auf fachlicher (bspw. explorative Tests) oder technischer (nicht-funktionale Qualitätsmerkmale) Ebene aufdecken sollen.
Wenn man seine Produktentwicklung neu startet, ist das Thema Testautomatisierung relativ einfach zu handhaben. Man sollte Automatisierung von Beginn an berücksichtigen. Und wenn man auf TDD setzt, hat man schon eine solide Basis an automatisierten Unit-Tests für den gesamten Code.
Das Konzept von TDD kann man auch auf die fachlich orientierten Tests ausweiten, indem man zumindest die Akzeptanztests der User Stories im Rahmen von ATDD von Anfang an automatisiert. Fachliche Tests sind aber leider, insbesondere wenn man sie via des User Interface automatisiert, relativ instabil und anfällig für Änderungen.
Hier kann ein zweites prominentes Denkmodell agilen Testens Orientierung bieten:die Testautomatisierungspyramide.
Der Gedanke hinter diesem Modell ist einfach – automatisierte Tests werden aufwendiger, teurer und haben eine längere Laufzeit, je näher am Benutzer sie automatisiert werden. Deshalb sollten automatisierte Tests auf der niedrigstmöglichen Stufe der Pyramide automatisiert werden.
Für fachliche Tests bedeutet dies zu prüfen, ob diese gegen APIs oder direkt gegen Services automatisiert werden können.
Dieser Blogbeitrag soll Dir Deinen Einstieg in das agile Testen in Deinem Projekt erleichtern
Wie machst Du nun am besten weiter? Am besten fängst Du einfach an und probierst aus, wie eine Teststrategie in Deinem agilen Projekt aussehen kann.
Du solltest hierbei keine Angst haben, denn der iterative Ansatz agiler Methoden eröffnet Dir die Möglichkeit, diese Teststrategie immer wieder anzupassen und zu verbessern.
Ich wünsche Dir viel Erfolg beim Experimentieren und bei der Umsetzung.
trendig
