Kennen Sie das? Sie arbeiten in einem agilen Projekt oder Team. Es werden selbstverständlich Unit-Tests und Stand-Up-Meetings durchgeführt. Und natürlich wird nach einer geeigneten Methodik wie Scrum oder Kanban gearbeitet.

Doch wie sieht es mit der Testorganisation und dem Testmanagement aus? Formale Teststufen und Testphasen sind nicht festgelegt. Solche Fragen treiben Sie um:

• Die Anforderungen ändern sich, aber was ist mit den Tests?
• Welche Tests sind in agilen Projekten überhaupt erforderlich?
• In agilen Methoden wie z. B. Scrum sucht man vergeblich nach Begriffen wie Testrollen, Testphasen, Teststufen oder Testarten. Aber mit welchen Strategien werden Tests dann erfolgreich umgesetzt?
• Wie lassen sich Tests in agilen Entwicklungsprozessen erfolgreich einsetzen, ohne das
  Tempo agiler Entwicklung zu bremsen?

Projekte agil durchzuführen ist nicht neu. Testen auch nicht. Was fehlt, ist eine Brücke zwischen diesen beiden Themen. Idealerweise sollte eine geeignete Teststrategie im agilen Umfeld die Qualität erhöhen und auch Ressourcen sparen. Mit agilem Testmanagement erreichen wir genau das.

„Whole Team“-Ansatz
Im agilen Testmanagement ist es entscheidend, dass alle im Team ihren speziellen Beitrag zum Gesamterfolg leisten und dass Tester:innen in Planungs-, Design- und Schätzaktivitäten eingebunden werden. Ideal ist es, wenn alle auch Aufgaben außerhalb der eigenen Rolle übernehmen, um als „Generalisierter Spezialist“ einsetzbar zu sein (T-Shape).

Tester:innen brauchen in agilen Projekten auch eine „Just-Do-It“-Mentalität. Die Wertschätzung der Tester:innen in einem agilen Team entsteht nur, wenn diese helfen, etwas zu verbessern oder zu vervollständigen.

Tester:in und Entwickler:in als Paar
Wir empfehlen, dass Entwickler:innen und Tester:innen in agilen Teams von Anfang an für bestimmte Stories zusammenarbeiten, um ein besseres Verständnis der User Stories, Zeitersparnis im Fehlermanagement, ein besseres Vertrauensverhältnis und eine beschleunigte Testfallerstellung zu erreichen.

Schaffen einer eigenen agilen Teststrategie
Jedes Team hat per se einen eigenen Entwicklungsprozess, ob es will oder nicht.
Auch wenn Teams scheinbar keinen formalen Methoden folgen, setzen sie dennoch welche ein, ohne diese zu benennen oder zu dokumentieren. Die eine, erfolgversprechende agile Methode, die für jedes Team und jedes Projekt passt, gibt es nicht. Deshalb ist es notwendig, aus bewährten Vorgehensweisen wie z. B. Scrum, Test Driven Development, eXtreme Programming – und speziell für Tests auch aus Full-Lifecycle-Testing-Ansätzen – die richtigen Aktivitäten und Ergebnistypen auszuwählen und an das eigene Vorhaben anzupassen.

• Welche Inspektionen und Reviews werden benötigt? Für Stories, Testfälle, Architektur, Code usw.?
• Welche Standards z. B. für Code-Design sind sinnvoll?
• Welche Dokumentationspflichten müssen eingehalten werden?
• Welche Praktiken werden eingesetzt: Scrum, Test Driven Design (TDD), Pair Programming, …?

Hierbei sollten die Werte aus dem Manifest für Agile Softwareentwicklung stets für die Auswahl maßgebend sein, aber auch eventuell regulatorische Anforderungen. Entscheidend ist dabei, nur ein Minimalset an Ergebnistypen festzulegen.

Gleiche Sprache und gleiches Verständnis schaffen
In agilen Methoden sind Rollen wie Testmanager oder auch Tester:in häufig nicht beschrieben. Alle sind auch Tester:in, aber es ist nicht immer klar, welche Tätigkeiten damit verbunden sind und welche Teststufen, Testarten und Testtypen verwendet werden sollten. Um diese Unklarheiten zu beseitigen, ist es empfehlenswert, im agilen Umfeld eine Teststrategie zu erstellen, die erklärt, wie Tests im Projekt oder Team durchgeführt werden. Dabei sollte der Fokus nicht auf der Prozessbeschreibung liegen, sondern auf der Erklärung der testspezifischen Begriffe.

Alle geplanten Testarten sollten im selben Sprint wie die Entwicklung der User Stories durchgeführt werden und nicht erst im nächsten Sprint.

Test ist Teil der Definition of Done. Zwischen Entwicklung und Test müssen gemeinsame Kriterien für „Done“ etabliert werden. „Done“ bedeutet auch, dass alle geplanten Tests des Sprints oder des Releases erfolgreich im Sinne vereinbarter Kriterien für Design und Programmierung durchgeführt wurden. Nur so kann das Sprintergebnis dem Kunden zur Verfügung gestellt werden.

In komplexen Vorhaben ist der „Whole Team“-Ansatz und Test Driven Development (TDD) alleine nicht ausreichend. Es fehlt das Know-how für manche Tests wie z. B. Last- und Performance-Tests, End-To-End Integration Tests oder Penetration Tests. Hier hilft der Einsatz eines unabhängigen Teams, das solche Tests parallel durchführt. Dies scheint ein Widerspruch zum „Whole Team“-Gedanken zu sein. Ist es auch! Aber es ist leider in manchen Fällen erforderlich, dass ein unabhängiges, zentralisiertes Testteam das Team ergänzt, um bestimmte Aufgaben parallel zur laufenden Entwicklung zu übernehmen. Dies betrifft zum Beispiel die folgenden Testarten:

• Integrationstests vor Produktivsetzung
• Last- und Performancetests
• End-Of-Lifecycle-Tests
• Tests in komplexen verteilten Umgebungen
• Tests mit tiefem Spezialwissen wie z. B. korrekte Umsetzung gesetzlicher Anforderungen oder Aufdecken von Sicherheitslücken im Quellcode
• Usability-Tests
• Tests mit besonderen Berechtigungen auf Testdaten
• Test von Qualitätsanforderungen

Im Gegensatz zu traditionellen unabhängigen Testteams sind diese „unabhängigen“ Teams in einem agilen Umfeld nur für spezielle Aufgaben zuständig, die auch nur einen kleinen Teil des gesamten Tests abdecken. Der überwiegende Aufwand in der Testdurchführung verbleibt im „Whole Team“.

Änderungsmanagement ist besser als Anforderungsmanagement und Fehlermanagement

Fehler sollten auch als eine Art Anforderung betrachtet werden, die wie andere Anforderungen priorisiert, geschätzt und in den Backlog für die spätere Umsetzung aufgenommen werden. Fehler (oder Änderungen), die im laufenden Sprint behoben werden können, sollten diesen Prozess jedoch nicht durchlaufen. Das heißt, nur komplexe Fehler kommen in den Backlog. Als Folge daraus werden Anforderungsmanagement und Fehlermanagement in agiler Entwicklung am besten in Form eines guten Änderungsmanagements umgesetzt, das nicht zwischen Anforderungen und Fehlern unterscheidet.

Im Allgemeinen lässt sich daraus ableiten, dass bekannte Testtechniken für die agile Entwicklung genutzt werden. Die Herausforderung besteht hauptsächlich darin, sie bewusst und auch vor allem gewollt an die agile Methodik anzupassen und sie passend im Entwicklungsprozess zu integrieren.