Agiles Testen

Veröffentlicht auf 26. September 2014

Agiles Testen unterscheidet sich deutlich vom Testen in traditionellen Projekten. Der agile Tester besitzt mehr Verantwortung, muss weitaus flexibler sein, mehr technische Kenntnisse und mehr Soft Skills mitbringen. Dabei unterstützt er während des kompletten Sprints das Team für das Ziel kontinuierlich, qualitativ hochwertige Software an den Kunden zu liefern.

Seine Aufgaben bestehen aus:
* Teamaufgaben (Planning, Review, Retro, ...)
* Reviews (User Stories, Dokumente, Design, ...)
* der Klärung offener Umsetzungsfragen durch Kommunikation mit allen Beteiligten
* der Automatisierung von Regressionstests (API, GUI) für die Continuous Integration
* Verwaltung von Testumgebung und Testdaten.
* und nicht zuletzt den Testaufgaben und -planung.

Da User Stories meistens nur aus Beschreibungen und Akzeptanzkriterien, aber nicht aus detaillierten Anforderungen bestehen und festgeschriebene Vorgaben selten sind, muss sich der agile Tester diese großteils in Eigenverantwortung, durch offene Kommunikation selbst erarbeiten. Diesen Bedingungen folgend haben sich die folgenden agilen Testmethoden etabliert:

Exploratives Testen

Ein agiler Tester nimmt sich ohne große Vorbereitung und Planung ein bestimmtes Feature / eine Komponente vor und überlegt sich auf seiner Erfahrung basierend Testfälle, die er direkt ausführt. Die Testfälle können kurz notiert werden um sie später zu dokumentieren, Fehler werden aber sofort erfasst und gemeldet.
Nach dem Prinzip der "Simplicity" wird so lange getestet bis mit gutem Gewissen weitere Tests für unnötig empfunden werden.

Sessionbasiertes Testen

Diese Methode soll die Probleme des Explorativen Tests (Zeit, Dokumentation, Nachvollziehbarkeit) lösen und gibt konkrete Funktionen vor, die innerhalb eines genauen Zeitrahmens zu prüfen sind.
Der agile Tester notiert dabei nebenher seine Testschritte (Aktions-Log, Video, ...) und versucht innerhalb der gegebenen Zeit eine möglichst große Testabdeckung zu erreichen.
Konnte er in der Zeit die Funktion zufriedenstellend testen, ist der Test beendet, ansonsten muss ein Product Owner / Test Manager entscheiden, wie lange weitergetestet werden darf. Fehler werden in der regel im Nachhinein dokumentiert, da durch die Dokumentation Fehler jederzeit nachstellbar sein sollten.

Für den Sessionbasierten Test eignet sich die Kombination mit Scenario Testing. Hierzu kann ein Use Case so umgebaut werden, dass ein Szenario, Anwendungsfall oder eben eine "Geschichte" aufgebaut wird, welche dann versucht wird in der Software abzubilden. Es soll eine realistischerer Test der Software gewährleistet werden.

Um beide Methoden noch spezifischer zu machen können auch verschiedene Sichtweisen eingebracht werden:
* Stress - Welche Benutzeraktionen bringen die Software an ihre Grenzen?
* Sabotage - Wie kann ich die Software korrumpieren?
* Handbuch - Funktionieren alle dokumentierten Sachverhalte?
* "Affentest" - Ich stell mich mal etwas unbeholfen an!