Agiles Testen

Agile Methoden werden immer häufiger in der Softwareentwicklung eingesetzt. Eine kürzlich durchgeführte Umfrage ergab, dass Scrum die breiteste agile Methode zur Umsetzung der Prinzipien des agilen Manifests sind. Jedoch sowohl das agile Manifest als auch die Scrum-Beschreibung ignorieren die Testaktivitäten und die Testorganisation.
Obwohl empfohlen wird, Methoden der testgetriebenen Entwicklung oder der kontinuierlichen Integration zu verwenden, beschreiben sie aber nicht den Testprozess des Systems. Testaktivitäten und Testorganisation spielen eine entscheidende Rolle und entscheidend für den Erfolg agiler Methoden.

Der wesentliche Unterschied zwischen dem Testen in agilen Projekten und dem klassischen Testen besteht darin, dass wesentlich früher angefangen wird und die gleichen Tests häufiger durchgeführt werden müssen. Schließlich wird das System ständig verändert und häufiger ausgeliefert. Im Vergleich zu klassischen Projekten zahlt sich automatisiertes Testen in agilen Projekten deutlich früher aus. Aufgrund der Bedeutung des Testens in agilen Projekten hat sich eine besondere Sichtweise auf das Testen herausgebildet:
In agilen Projekten wird Testen als ausführbare Spezifikation verstanden. Wie bei klassischen Projekten wird auch bei agilen Projekten zwischen technischen Spezifikationen in Form von Unit-Tests und Anwendungsdomänen-Spezifikationen in Form von Akzeptanztests unterschieden. Ein agiles Team, wie es zum Beispiel das Vorgehensmodell Scrum definiert, ist selbst organisiert. Idealerweise gibt es keinen externen Projektmanager und erst recht keinen Testmanager. Diese Rollen übernehmen die Mitglieder des Teams selbst. Dennoch hat das Agile Testing dieselben Aufgaben, die auch das klassische Testmanagement bewältigen muss:

Testplanung
Testschätzung und Testorganisation
Testerstellung und Testdurchführung
Testüberwachung, Teststeuerung und Dokumentation

Alle Aufgaben laufen parallel in einer Iteration ab und nicht in nacheinander folgenden Aktivitäten wie im klassischen Testmanagement. Zudem berücksichtigt Agile Testing die klassischen Teststufen. Denn diese Stufen definieren unterschiedliche Testarten, die gleichzeitig bestimmte Testmethoden und –werkzeuge nach sich ziehen. Sowohl klassische als auch agile Projekte nutzen diese Methoden und Werkzeuge. So lassen sich zum Beispiel codenahe Komponententests durch automatisierte Techniken ausführen, während Sie Systemtests meist manuell durchführen. Allerdings ordnet agile Testing diese Stufen in ein anderes System ein, weil es die Teststufen nicht nacheinander durchführt.

Entwickler-Tests

Entwickler Test sind in der agilen Entwicklung von hoher bedeutung, durch die frühe und kontinuierliche Lieferung von Softwarebausteinen, sind Sie der erste Baustein im agile Test. Hier konzentriert man den Test auf das Wesentliche, es fordert eine explizite und regelmäßige Entscheidung über das, was zu erstellen ist und was weggelassen wird.
Entwicklertests werden in der täglichen Entwicklungsarbeit durchgeführt. Der Zweck ist die Überprüfung des täglichen Entwicklungsergebnisse für SprintTasks. Jeder Entwickler bearbeitet seine Sprint-Tasks, diese dienen auch der Testgrundlage für die Entwicklung der benötigten Testfälle.

Testservices für:

Testmanagement
Coaching von Projektmitarbeitern
Testautomatisierung
Security Awareness Schulungen
Penetrationstest
Barrierefreiheitstest

Sprint Test

Wo der Entwicklertest im täglichen Rahmen stattfindet, wird der Sprint erst gegen Ende eines Sprints durchgeführt, wenn das Inkrement fertig wird. Obwohl Aktivitäten im Entwicklertest eine kontinuierliche Qualitätsüberwachung ermöglichen, ist am Ende eines Sprints ein dedizierter Test des Inkrements notwendig, um folgende Testziele zu gewährleiten:

Korrekte Funktionsweise des Inkrements und das zusammenspiel mit vorhergegangenen Inkrementen.
Sicherstellung das frühere Inkremente nicht verändert wurden

Regressionstest sind hier von entscheidener Bedeutung, da die menge der Regressionstest in einen agilen Projekt sehr schnell steigt, sollte eine Testautomatisierung so früh wie möglich eingestezt werden um den manuellen Testaufwand zu reduzieren. Die Testgrundlage ist hier nicht wie beim Entwicklertest der einzelne Task, sondern der gesamte Sprint welcher das Testobjekt definiert. Zur Testdurchführung gehören im Inkrementtest als Teststufen neben dem Entwicklerintegrationstest insbesondere auch der Systemtest, der prüft, ob das entsprechende Inkrement als ein Ganzes funktioniert und so vom Benutzer akzeptiert wird. Als Testarten gehören zu diesem Testtyp nicht nur die funktionalen Tests und Regressionstests, sondern insbesondere auch die nicht-funktionalen Tests, wie beispielsweise Performanztests, UsabilityTests usw.

Testservices für:

Testmanagement
Coaching von Projektmitarbeitern
Testautomatisierung
Security Awareness Schulungen
Penetrationstest
Barrierefreiheitstest

Release Test

Der Release-Test ist ursprünglich in Scrum nicht vorgesehen. Doch gerade dieser wird in der Praxis als relevant und wichtig angesehen, weil dabei das Produkt in seiner Gesamtheit getestet werden kann. Der Release-Test kann nun ebenfalls als ein Sprint aufgebaut werden und ist damit weiter Scrum-konform. Die Testbasis ist hier nun das gesamte Product Backlog, da hier nicht nur ein Inkrement nach einem Sprint, sondern das gesamte Produkt das Test – objekt ist.

Anstatt eines Sprint-Backlogs kann analog ein sogenanntes Test-Backlog erstellt werden,

welches die gesamten Release-Tests enthält. Als Teststufen enthalten diese Release-Tests Systemintegrationstests, In be – trieb nahmetests und insbesondere Akzeptanztests. Im Release-Test können die Testfälle aus den Inkrementtests wieder verwendet werden, sodass für den Testentwurf kein erheblicher Zusatzauf wand entsteht. Als Testart ist hier neben den funktionalen und nicht-funktionalen Tests auch das sogenannte End-To-End-Testing zu finden, welches über das gesamte System und Pro – dukt im Zusammenspiel aller Kompo – nenten stattfindet. Für die Durchführung der Tests wird das Test-Backlog analog zum Sprint-Backlog in Test-Tasks aufgeteilt, welche täglich entwickelt und durchgeführt werden. Weiterhin findet ein Daily Scrum statt, um die Arbeit zu besprechen. Auf stündlicher Basis findet neben den Tests auch das Debugging statt, um Fehler zu finden und zu beheben. Am Ende des Tages steht ein Test-Report an. Am Ende des Sprints findet nicht nur eine Auswertung der speziellen Definition of Done bezüglich des Releases statt, sondern ebenfalls die finale Kundenabnahme des Produktes. Zur Unterstützung der Release-Tests können ebenso wie beim Entwicklertest GUI-Testwerkzeuge, Last- und PerformanzTestwerkzeuge usw. zum Einsatz kommen.

Testservices für:

Testmanagement
Coaching von Projektmitarbeitern
Testautomatisierung
Security Awareness Schulungen
Penetrationstest
Barrierefreiheitstest

Werden manuelle Tests dann noch benötigt?

Bei Softwareänderungen ist es nötig Änderungen im Testskript vorzunehmen. Es kann passieren, dass das Testskript zwar noch durchläuft, aber nicht mehr alles korrekt prüft.

„Definition of READY“ (DoR)

Eine DoR wird verwendet, um eine frühe Testbarkeit der Software zu gewährleisten. Es handelt sich im Grunde um eine Checkliste, die zum Einsatz kommt, wenn die User Story vom Product Owner erstellt und in deren Qualitätssicherung verwendet wird, spätestens aber bei der Überführung der Story aus dem Produkt, wird die DoR den Weg in das Sprint Backlog finden.

„Definition of DONE“ (DoD)

Ganz kurz: die DoD verankert Qualitätsziele. Es ist eine weitere Checkliste, die beschreibt, welche Ziele das Team bei der Umsetzung der Story erreichen muss, bevor sie als „bereit für die Einreichung in einem Sprint-Review“ betrachtet werden kann. In der DoD liegen Testziele wie z.B. die erforderlichen Testtypen, die zu erreichende Testabdeckung und Testende-Standards fest (z.B. alle gefundenen Fehler beseitigen). Eine DoD dient somit unmittelbar der Sicherung der Produktqualität, wie auch der Kundenzufriedenheit.

„Definition of TEST“ (DoT)

Eine DoT verankert die Teststrategie im agilen Team. Sie legen die für das Team geltenden Spielregeln in einem zentralen Dokument, der sogenannten Teamcharta, fest. Die Charta ist auch ein idealer Ort, um gängige Methoden zu verankern, wie z. B. Testfalldesign und Tool-Nutzung für Tester. DoT beschreibt, wie Testfälle basierend auf welchen Informationen (wie der Risiko- und Wertklassifizierung der Story und ihrer Beschreibung) entworfen, implementiert und ausgeführt werden. Daher ersetzt es die bekannten risiko- oder wertorientierten Teststrategieartefakte im klassischen Testen. Der Quadrant für agiles Testen ist ein guter Ausgangspunkt, um agile Teststrategien zu definieren.