Agiles Testen

Als agiles Testen (von lateinisch agilis „flink, beweglich“) wird das Prüfen von Software im Rahmen eines agilen Entwicklungsprojekts bezeichnet. Testen in agilen Entwicklungsprojekten bedarf dabei vor allem eines Fokus auf die Unterstützung des Entwicklungsteams. Viele Eigenschaften von agilen Testern helfen auch einem traditionellen Tester, allerdings werden die damit verbundenen Probleme nicht so deutlich und deshalb nicht von jedem Projektteam behoben. Agiles Testen folgt den Prinzipien des agilen Manifests und wendet die agilen Prinzipien auf das Testen an.

Überblick

Agiles Testen muss so gestaltet sein, dass es die Ziele agiler Softwareentwicklung optimal unterstützt, nämlich

• hohe Kundenzufriedenheit, die durch die enge Zusammenarbeit zwischen Kunde bzw. Kundenvertreter (bei Scrum beispielsweise der Product Owner) und Entwicklungsteam entsteht,
• hohe Produktqualität, die durch eine konsequente Ausrichtung der Entwicklungsaktivitäten auf Fehlerprävention und frühzeitige Fehlerfindung entsteht,
• hohe Entwicklungsgeschwindigkeit, die durch die Reduktion von Blindarbeit (unnötige Dokumentation, unnötige Fehlerkorrekturarbeit usw.) bewirkt wird,
• schnelle Reaktion auf Änderungen, die durch kurze Iterationen ermöglicht wird,
• hohe Teammotivation, die durch Selbstorganisation und dauerhaft einhaltbares Arbeitstempo unterstützt wird.

Dabei müssen unter Umständen Werte des Testens im „klassischen“, meist phasenorientierten oder iterativ-inkrementellen Vorgehen Berücksichtigung finden, z. B. in einem regulierten Umfeld:

• gute Planbarkeit, Verfolgbarkeit und Nachweisbarkeit der Testaktivitäten
• hohe Systematik des Testentwurfs, daraus resultierend eine hohe und reproduzierbare Testabdeckung

Grundprinzipien

Um den Ansprüchen nach Geschwindigkeit und Vermeidung unnötiger Arbeit einerseits sowie Systematik und Vertrauenswürdigkeit andererseits gerecht zu werden, sollte ein agiles Testvorgehen auf folgende Grundprinzipien aufgebaut sein:

Schnelles Feedback

Neu entwickelter oder geänderter Programmcode muss noch vor dem Ausliefern getestet werden. In iterativen Methoden wie Scrum bedeutet das, dass ein agiler Tester das Team durch schnelles Feedback meistens innerhalb von zwei Wochen mit Informationen über die erschaffene und geänderte Funktionalität versorgen muss. Damit dieser schnelle Feedbackzyklus funktionieren kann, müssen zum einen Funktionen bereits nach wenigen Tagen in einer ersten testbaren Version vorliegen. Außerdem wird der Tester noch bei der Definition der Funktion vor dem Sprint mit eingebunden.

Um möglichst schnelles Feedback zum derzeitigen Stand des Teams liefern zu können, setzen viele Teams dabei auf eine ausgewogene Balance zwischen einem hohen Automatisierungsgrad und leichtgewichtigen manuellen explorativen Tests. Dabei unterstützen Programmierer die Arbeit von Testern bei der Automatisierung, während Tester mit ihren kritischen Fähigkeiten die Ausgangsbasis für die Testautomatisierung liefern. Außerdem sind sich agile Teams darüber im Klaren, dass sich nicht alles automatisieren lässt. Entsprechende Risiken wie schlecht ausgelegte Benutzeroberflächen und versteckte Bedienelemente adressieren sie deshalb über explorative Tests.

Hoher Automatisierungsgrad

Um schnelle Reaktionsfähigkeit auf sich ändernde Anforderungen sowie das permanente Refactoring von Programmcode zu unterstützen, müssen möglichst viele systematische Testfälle entworfen und automatisiert werden. Dies umfasst sowohl strukturbasierte Tests (Unit Tests) als auch fachlich orientierte System- und Akzeptanztests.

Geringer Overhead

Der Aufwand für nicht unmittelbar operative Testaktivitäten (also z. B. Testmanagement, Fehlermanagement, Dokumentationsarbeit) muss so gering wie möglich gehalten werden.

Auflösung von Testrollen

Den agilen Prinzipien folgend wird die Verantwortung für alle Testaktivitäten auf das gesamte Team verteilt. Hierdurch verschwinden die Grenzen zwischen den klassischen Testrollen (Testmanager, Testanalyst, Tester) und teilweise auch die Grenzen zwischen Softwareentwickler und Tester. Wegen der notwendigen hohen Qualifikation sowohl für Entwicklungs- als auch für Testarbeiten ist letzterem allerdings eine enge Grenze gesetzt.

Auflösung von Teststufen

Für eine sequentielle Abfolge von Teststufen (z. B. Unit-, Integrations- und Systemtest), ist innerhalb der typischen agilen Iterationslänge von 2–3 Wochen keine Zeit. Die durch die unterschiedlichen Teststufen abgedeckten unterschiedlichen Testziele sind aber nach wie vor zu erreichen und müssen durch inhaltlich unterschiedlich gestaltete Testaktivitäten in „Mikro-Testzyklen“ (typischerweise eine Abfolge von Unit-, Integrations- und Systemtests in weniger als 24 Stunden) abgedeckt werden. Die Teststufen sollten im agilen Kontext eher als inhaltliche Testarten statt zeitlicher Testphasen verstanden werden.

Enge Zusammenarbeit im Team

Der Wunsch nach schnellem Feedback und die Übernahme der Verantwortung für das Testen durch das gesamte Team bedingen eine enge Zusammenarbeit zwischen den „Testern“ (d. h. den mehrheitlich mit dem Testen beschäftigten Teammitgliedern) und den „Entwicklern“ sowie den „Testern“ und den Kundenvertretern (im Scrum dem Product Owner). Diese Zusammenarbeit wird durch direkte Kommunikation (und damit weitgehenden Verzicht auf Dokumentation, die für Kunde und Team keinen Wert besitzt) sowie paarweise Zusammenarbeit (das sogenannte Pairing) erreicht.

Scrum-Framework

Durch „Verankerung“ des systematischen Testens in einigen Scrum-Artefakten sowie an einigen Schlüsselstellen des Prozesses können die Ziele des agilen Testens realisiert werden.

„Definition of READY“ (DoR)

Die DoR dient der frühzeitigen Sicherstellung der Testbarkeit. Sie ist eine Checkliste, die bei der Erstellung der User Stories durch den Product Owner sowie bei deren Qualitätssicherung und spätestens bei der Übernahme von Stories vom Produkt- ins Sprint Backlog Anwendung findet. Stories, die nicht „ready“ im Sinne der Definition sind, dürfen beim Sprint-Planungsmeeting vom Team zurückgewiesen werden. Die DoR sichert die fachliche sowie die technische Testbarkeit der Stories ab und fordert die Definition von möglichst operationalen Akzeptanzkriterien ein. Gute Akzeptanzkriterien entstehen durch den Ansatz „specification by example“. Ein guter Ausgangspunkt für eine DoR sind die sogenannten INVEST-Kriterien für Anforderungen. Bei der Erstellung der Stories ist ein Pairing von Tester und Product Owner sinnvoll, um das methodische Wissen über Testen und Qualitätssicherung mit dem Fachwissen des Product Owner zu vereinen.

„Definition of DONE“ (DoD)

Die DoD verankert die Qualitätsziele. Sie ist eine weitere Checkliste und beschreibt, welche Ziele vom Team bei der Umsetzung der Story erreicht werden müssen, bevor diese als „fertig zur Vorlage im Sprint-Review“ betrachtet wird. In der DoD werden Testziele wie z. B. die notwendigen Testarten, die zu erreichende Testabdeckung und die Testendekriterien (i. a. die Entfernung aller gefundenen Fehler) festgeschrieben. Die DoD dient damit unmittelbar der Sicherstellung der Produktqualität und der Kundenzufriedenheit.

„Definition of TEST“ (DoT)

Die DoT verankern die Teststrategie in einem agil arbeitenden Team. Sie fassen die für das Team gültigen „Spielregeln“ in einem zentralen Dokument, der sogenannten „Team Charta“, ab. Diese Charta ist auch ein idealer Platz für die Verankerung von gemeinsamen Vorgehensweisen, z. B. zum Testfallentwurf und zur Toolnutzung für die Tester.

In einer DoT wird beschrieben, auf Basis welcher Informationen (z. B. Risiko- und Werteinstufung einer Story sowie deren Beschreibung), auf welche Weise Testfälle entworfen, implementiert und durchgeführt werden sollen. Sie ersetzt damit das aus dem „klassischen“ Test bekannten Artefakt der risiko- oder wertorientierten Teststrategie. Ein guter Ausgangspunkt für die Definition einer agilen Teststrategie sind die „agile testing quadrants“.

Sprint begleitende Tests

Es gilt der Grundsatz von Realisierung und Test non-stop. Während des Sprints muss dafür gesorgt werden, dass die „Tester“ vom ersten Tag an ins Team integriert sind und parallel mit (bzw. zusammen mit) den „Entwicklern“ an der Realisierung der Stories arbeiten. Schlüsselfertigkeiten hierfür sind:

• Die Beteiligung der Tester an der Sprint-Planung und den Daily Scrum Meetings
• Die zeitliche Verschränkung von Entwicklungs- und Testaktivitäten. Hierzu sind Prinzipien wie „Test Driven Development“ bzw. „Test First“ und Pairing zwischen Entwicklern und Testern geeignet
• Die transparente Repräsentation von Tests in der Planung und Statusverfolgung durch geeignete Darstellung auf dem Taskboard, dem zentralen Planungsmittel des agilen Teams
• Die Implementierung von systematischen Unit Tests, d. h. solchen, die durch Anwendung systematischer Testmethoden wie Äquivalenzklassenanalyse, Zustandsanalyse oder Entscheidungstabellen entstehen
• Die Kombination von systematischen Tests und explorativen Tests. Letztere liefern besonders schnell Feedback und finden Fehler, die von systematischen Tests ggf. nicht gefunden werden können
• Der Betrieb einer CI- (continuous integration, kontinuierliche Integration) Umgebung, in der automatisierte Unit-, Integrations- und Systemtests beim Einbringen von Änderungen (Check-in) nach einer geeigneten risikoorientierten Strategie ausgewählt und als Regressionstests durchgeführt werden

Reife Testautomation

Nicht nur Unit- und Integrationstests, sondern auch System- und Akzeptanztests müssen frühzeitig im Sprint (möglichst zeitgleich mit der Implementierung einer Story oder sogar davor im Sinne von „Test First“) entworfen und automatisiert werden. Während des Sprints müssen sie permanent lauffähig sein, um als „Sicherheitsnetz“ bei Änderungen und Refactorings zu dienen. Auf der Ebene von Black Box-Tests erweisen sich für den Aufbau einer solchen frühzeitig einsetzbaren, gegen Änderungen und Fehlverhalten der Software robusten Testautomatisierung verschiedene Frameworks als besonders sinnvoll, beispielsweise

• „behaviour-driven“ Frameworks wie beispielsweise Cucumber (Ruby, Java etc.), SpecFlow (.NET) oder Jasmine (ECMAScript)
• „keyword-driven testing“ Frameworks
• „model-driven testing“ Frameworks

Beispielsweise kann die Geschäftsanforderung, in Form der User Stories, in Gherkin verfasst und mittels eines BDD-Frameworks automatisiert getestet werden, während das Fehlverhalten von Integrationspunkten und die Performancekriterien mit Hilfe eines Test-Harnisch geprüft wird. Die Aufgabe der Tester besteht hierbei darin, zusätzliche Testfälle zu identifizieren und die Anwendung, insbesondere durch Fehleingaben, bewusst zu einem Fehlverhalten zu bewegen.

Weiterführende Literatur

• Scott Ambler: Agile Modeling. Effective Practices for eXtreme Programming and the unified Process. John Wiley & Sons, New York NY 2002, ISBN 0-471-20282-7.
• Mike Cohn: Agile Estimation and Planning. Prentice Hall PTR, Upper Saddle River NJ u. a. 2005, ISBN 0-13-147941-5.
• Esther Derby, Diana Larsen: Agile Retrospectives. Making good Teams great. Pragmatic Bookshelf, Raleigh NC u. a. 2006, ISBN 0-9776166-4-9.
• Thomas Roßner, Christian Brandes, Helmut Götz, Mario Winter: Basiswissen Modellbasierter Test. dpunkt.verlag, Heidelberg, 2010, ISBN 978-3-89864-589-8.
• Andreas Spillner, Thomas Roßner, Mario Winter, Tilo Linz: Praxiswissen Softwaretest – Testmanagement. Aus- und Weiterbildung zum Certified Tester – Advanced Level nach ISTQB-Standard. 3., überarbeitete und erweiterte Auflage. dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-746-5.
• Silke Geisen, Baris Güldali: Agiles Testen in Scrum – Testtypen und Abläufe. OBJEKTspektrum Online Themenspecials, Ausgabe Agility/2012.
• Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl, Siegfried Tanczos: Agile Testing - Der agile Weg zur Qualität. Carl Hanser Verlag, München 2013, ISBN 978-3-446-43194-2 (agile-testing.at [abgerufen am 11. September 2013]). 
• James A. Whittaker, Jason Arbon, Jeff Carollo: How Google Tests Software. Addison-Wesley Professional, 2012, ISBN 978-0-321-80302-3.