Motivation
Im Rahmen von agiler Softwareentwicklung muss dem Testen eine hohe Bedeutung innerhalb der Entwicklung eingeräumt werden, da durch die Eigenverantwortlichkeit der Teams und dem Trend zum Continuous Deployment die Prüfung der entwickelten Software von einer separaten Testabteilung häufig entfällt. Dies wird häufig durch Vorgehensweisen wie der testgetriebenen Entwicklung realisiert, während der Unit-Tests, Integrationstests und Systemtests direkt vom Entwicklungsteam erstellt werden. Da diese Teams zumeist nur aus Entwicklern bestehen, kann es zu dem Problem kommen, dass einige Bereiche der zu entwickelnden Anwendung aufgrund von fehlenden Tests nicht die Qualität aufweisen, die von Auftraggeber und Anwender gewünscht ist. Grund für dieses Testdefizit ist nicht das Unvermögen der Entwickler, sondern der Zeitdruck und die inhärente Blindheit eigenen Programmierfehlern gegenüber. Zur Vermeidung dieses Problems kann eine in der Definition of Done festgelegte explorative Testsession zum Ende eines Sprints bzw. einer bearbeiteten User-Story helfen.
Exploratives Testen: Was ist das?
Im Gegensatz zum unorganisierten und eher ineffektiven AdHoc-Testen ist das Explorative Testen ein strukturiertes Testvorgehen, welches sich einen bestimmten Bereich der Anwendung herausgreift und diesen entsprechend einer zuvor erstellten Test-Charter auf mögliches Fehlverhalten testet. Eine Definition für diese Art des Testens wird von Elisabeth Hendrickson in ihrem Buch „Explore It!“ genannt:
Simultaneously-designing and executing test to learn about the system, using your insigths from the last experiment to inform the next.
Die Charter beschreibt dabei den Bereich, die Werkzeuge und die gesuchte Information, die bei diesem Test gefunden werden soll. Der Fokus darf dabei wie bei einer guten User-Story nicht zu weit oder zu eng gefasst sein. Dazu liefert Elisabeth Hendrickson ebenfalls ein gutes Template:
Explore (Target)
with (Resource)
to discover (Information)
Vorgehen
Wenn eine Test-Charter erstellt ist und der Test begonnen werden kann, dann gibt es trotzdem noch das Problem, dass die testende Person wissen muss, was eigentlich fehlerhaftes Verhalten in der Anwendung darstellt und was nicht. Zwar liefern die User-Stories mit den dazugehörigen Akzeptanzkriterien Hinweise, die aber in vielen Bereichen nicht ausreichend sind, da sie vieles voraussetzen, was in den Köpfen der Beteiligten enthalten ist, aber nicht zwingend bei allen die gleiche Ausprägung hat. Um ein Vorgehen beim Test zu finden bzw. gewünschte Testergebnisse vorherzusagen, können Heuristiken eingesetzt werden (Wikipedia).
A heuristic […] is any approach to problem solving, learning, or discovery that employs a practical method not guaranteed to be optimal or perfect, but sufficient for the immediate goals.
Testorakel
Testorakel dienen dazu, das Verhalten der Anwendung in bestimmten Bereichen vorherzusagen. Sie helfen Testergebnisse zu prüfen und so das Verhalten der Anwendung auf Korrektheit zu prüfen. Mögliche Orakel sind z.B. User-Stories (falls sie konkret genug sind) oder Richtlinien von Betriebssystem-Herstellern (z.B. für iOS von Apple).
Mnemonics
Mnemonics können dazu dienen, das Vorgehen und die Sichtweise auf die zu testende Anwendung auf bestimmte Aspekte zu fokussieren. Ein Beispiel hierzu ist das von James Bach geprägte Mnemonic SFDIPOT (San Francisco Depot):
- Structure (What the product is)
- Function (What the product does)
- Data (What data it processes)
- Interface (How does it use connections)
- Platform (What it depends on)
- Operation (How it will be used)
- Time (How time has influence)
Weitere Mnemonics sind unter anderem hier zu finden.
Weitere Varianten
Neben den oben genannten Möglichkeiten einen explorativen Test zu strukturieren und ein Vorgehen zu finden, gibt es noch zahlreiche weitere Möglichkeiten. Eine wäre unter anderen, die Personas, die ggf. bei der UX-Analyse erstellt worden sind, als Grundlage für den Testentwurf zu verwenden. Auch eine Betrachtung der Anwendung entsprechend ihres Verhaltens (state and transition) oder ihrer Datenspeicherung (CRUD) wäre möglich.
Fazit
Aufgrund der häufigen Erstellung von Releases in der agilen Entwicklung kann es zu Problemen mit der Qualität der Software kommen. Um dies zu vermeiden, ist die Aufnahme des Explorativen Testens in die Definition of Done ein adäquates Mittel, da mit Hilfe dieser Testmethodik Probleme, die aufgrund von Zeitdruck und fehlendem Fokuswechsel durch die Entwickler auftreten können, vermieden werden.
