Benutzer:Trossner/Agiles Testen

Begriffsdefinition

1. Sammelbegriff für alle Aktivitäten des (Software-) Testens, die im Rahmen eines agilen (Software-) Entwicklungsprojekts stattfinden.
2. Testen, das den Prinzipien des agilen Manifests folgt und die agilen Prinzipen auf das Testen anwendet.

Ü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 sollen die Werte des Testens im „klassischen“, meist phasenorientierten oder iterativ-inkrementellen Vorgehen Berücksichtigung finden:

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

Grundprinzipien der Umsetzung

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

Schnelles Feedback

Alle testvorbereitenden Aktivitäten wie Testkonzeption, Testplanung und Testfallentwurf müssen so früh wie möglich durchgeführt werden, damit neu entwickelter oder geänderter Programmcode möglichst sofort getestet werden kann. Es gibt daher keine dedizierten Testphasen oder Testzeiträume; getestet wird permanent während der gesamten Entwicklungszeit der Software. Deswegen ist exploratives Testen in agilen Projekten weit verbreitet.

Hoher Automatisierungsgrad


Um schnelle Reaktionsfähigkeit auf sich ändernde Anforderungen sowie das permamente 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 Management-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 Entwickler 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.

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 besitzen) sowie paarweise Zusammenarbeit (das sogenannte Pairing) erreicht.

Konkrete Umsetzung im 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.

Frühzeitige Sicherstellung der Testbarkeit durch die „Definition of READY“ (DoR)

Die DoR 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 Product 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.

Verankerung von Qualitätszielen in der „Definition of DONE“ (DoD)

Die DoD als weitere Checkliste 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.

Verankerung der Teststrategie in einer „Definition of TEST“ (DoT)

Agil arbeitende Teams fassen die für sie gültigen „Spielregeln“ oftmals in einem leichtgewichtigen 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“ .

Test non-stop – Realisierung von sprint-begleitenden Tests

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
• „keyword-driven testing“ Frameworks
• „model-driven testing“ Frameworks

Umdenken der Tester

Ebenso wichtig wie die Erlangung obiger technischer und planerischer Fertigkeiten ist eine Umorientierung der „Tester“. Die früher angestrebte Unabhängigkeit zwischen Entwicklungs- und Testmannschaft muss zu Gunsten der engen Zusammenarbeit aufgegeben werden. Statt auf freigegebene Anforderungs- und Designdokumente zu warten, ist der Tester im agilen Team aufgerufen zu Kommunikation, Interaktion und aktiver Informationsbeschaffung. Im Mittelpunkt der Testaktivitäten steht das Ziel, die Entwicklung des Systems durch schnelles Feedback abzusichern. Dieses geänderte Wertesystem wurde im November 2011 anlässlich des 20. QS-Tags in Nürnberg in Form des "Agilen Test-Manifests" niedergeschrieben und von ca. 80 Konferenzteilnehmern unterzeichnet.

Weiterführende Literatur

• [Ambler 2002] Ambler, S.: Agile Modeling. John Wiley & Sons, New York, 2002. ISBN 978-0-471-20282-0
• [Cohn 2005] Cohn, M.: Agile Estimation and Planning. Prentice Hall International, 2005. ISBN 978-0131479418
• [Derby 2006] Derby, E.; Larsen, D.: Agile Retrospectives. Pragmatic Programmers, 2006. ISBN 978-0977616640
• [Roßner 2010] Roßner, T.; Brandes, C.; Götz, H.; Winter, M.: Basiswissen Modellbasierter Test. dpunkt-Verlag, Heidelberg, 2010, ISBN 3-898-64589-4
• [Spillner 2011] Spillner, A.; Roßner, T.; Winter, M.; Linz, T.; Praxiswissen Softwaretest - Testmanagement: Aus- und Weiterbildung zum Certified Tester - Advanced Level nach ISTQB-Standard. 3. Aufl. dpunkt.verlag, Heidelberg, 2011. ISBN 978-3-89864-746-5