Exploratives Testen (in agilen Projekten)

Stellen Sie sich folgendes Szenario vor: Sie entwickeln für einen Automobilhersteller die Software „CarConfigurator“ zur Konfiguration von Neuwagen. Sie haben bereits alle Regressionstests automatisiert, sowohl Modultests, Integrationstests, Akzeptanztests und sogar die End-2-End Systemintegrationstests. Alles läuft vorbildlich in einem Continuous Integration-Umfeld und wird mit jeder neuen Version automatisch durchgetestet. Eigentlich sollte jetzt sichergestellt sein, dass sich bei Ihnen keine neuen Fehler einschleichen können. Trotzdem zeigen sich im Produktivbetrieb „offensichtliche“ – um nicht zu sagen „dumme“ – Fehler. So wird zum Beispiel ein veränderter Text nur zum Teil angezeigt, und ein Button hat derart unpassende Farben, dass die Beschriftung nur schwer erkennbar ist. Das birgt die Gefahr in sich, dass der Nutzer die schlechte Qualität der Software auch mit einer schlechten Qualität der Neuwagen in Verbindung bringt. Dies können Sie durch exploratives Testen vermeiden: Durch den Test mit der erfahrungsbasierten Brille werden viele offensichtliche, aber auch versteckte und ungewöhnliche Fehler vor der Freigabe gefunden.

Beim systematischen Testen befolgt man den zuvor erstellten Testplan. Bei genauen Plänen kann es allerdings passieren, dass zu wenig Freiraum bleibt, um auf neue Erkenntnisse reagieren zu können. Wenn alle Leute nur reagieren, besteht die Gefahr, dass man keiner gemeinsamen Strategie mehr folgt.

Sitzungsbasiertes Testmanagement (SBTM) bietet die Möglichkeit, kurzfristig auf neue Erkenntnisse zu reagieren und gleichzeitig eine gemeinsame Strategie zu entwickeln. Meist wird es Session-Based Testing genannt. SBTM setzt auf die Erfahrung der Mitglieder agiler Teams und geht davon aus, dass diese in der Lage sind Vermutungen anzustellen. In unserem Beispiel mit dem Fahrzeugkonfigurator könnte eine solche Vermutung daraus entstehen, dass es bereits öfter Probleme mit nicht sichtbaren Texten in den Infoboxen eines Ausstattungspakets gab. Diese Vermutungen werden in klare Ziele für die Durchführung einer Sitzung, den Testchartas verdichtet. Aufgrund dieser sind zeitlich eingeschränkte, intensive Testaktivitäten mit klaren Zielen und daher mit einer eindeutigen Richtung versehen. Testchartas sind Leitplanken für die Tester, welches Testelement sie untersuchen sollen und welche Besonderheiten zu beachten sind. Am einfachsten ist es, die Testcharta mit einem klaren Auftrag für die Sitzung zu vergleichen.

Die Testcharta formuliert in unserem Beispiel das Ziel, neue Textbox-Elemente für Ausstattungspakete im Fahrzeugkonfigurator mit überlangen Texten zu beschreiben. Diese Testcharta übernimmt ein Entwickler oder eine Entwicklerin in der Testdurchführung, die weiß welche GUI-Elemente im Framework neu entstanden sind, zusammen mit einem Tester innerhalb eines Zeitraums von 90 Minuten.

Auf diese Weise wird aus dem vermeintlich willkürlichen Ausprobieren am Testobjekt ein gezieltes Experiment (= exploratives Testen) in einem vorgegebenen Zeitrahmen (= Testsitzung). Abschließend lässt sich der reaktive Ansatz des explorativen Testens fördern, in dem Testmanager, Entwicklungs-Teammitglieder oder andere interessierte Personen am Ende einer Sitzung gemeinsam in einem Debriefing die wesentlichen Erkenntnisse besprechen und weitere Ideen zur Vorgehensweise entwickeln. Und schon wird aus Erfahrung wieder wertvolles Wissen!

Genau genommen handelt es sich bei Touren um eine der möglichen Kreativitätstechniken, bei denen man mit Hilfe von Metaphern Testchartas finden kann, um Testsitzungen zu gestalten. Dabei wird beispielsweise die Analogie zur Erkundung einer Stadt gezogen. Mit den Testenden wird dabei durchgespielt, dass sie die Erkundung des Testobjektes wie den Besuch einer unbekannten Stadt angehen sollen. Dabei gilt es sicherzugehen, dass wesentliche Sehenswürdigkeiten kennengelernt werden. Die Testerinnen und Tester beginnen üblicherweise mit einem gemeinsamen Blick auf einen Stadtplan. Die „Reisegruppe“ beschließt, welche Teile der Stadt interessant sind: sind die Stadteile festgelegt, werden die einzelnen Interessengruppen in unterschiedliche Bereiche geschickt.

Am Abend treffen sich die Ausflügler bei einem Getränk und tauschen sich über das Erlebte aus. Davon inspiriert, plant die Gruppe das weitere Vorgehen und überlegt, welche Teile der Stadt als nächstes erkundet oder noch einmal intensiver betrachtet werden sollen.

Mit Hilfe dieser „Visualisierung“ des Testobjekts als Stadt und Beschreibung der Test-Touren wird es einfach, Erkundungsziele, also Testchartas abzuleiten und sinnvolle Sitzungen für exploratives Testen zu planen.

Beim explorativen Test können idealerweise das ganze Team sowie externe Personen mitwirken – der Fokus liegt hier nicht explizit auf Teilnehmenden mit Test-Knowhow. Dadurch lassen sich im gleichen Zeitraum viele Testchartas verfolgen und alle Mitglieder lernen die gesamte Anwendung zusätzlich aus neuen Blickwinkeln kennen. Da Erfahrung gemeinsam besonders gut wächst, ist es ratsam, immer wieder auch zu zweit oder in noch größeren Gruppen die Testchartas zu erforschen.

Vergleicht man das klassische Testverfahren mit dem SBT, so fällt folgender Unterschied auf: Im strukturierten Testvorgehen werden die Testfälle üblicherweise aus Anforderungsdokumenten, der sogenannten Testbasis, abgeleitet. Dabei kann eine Testabdeckung überwacht werden – sind alle Anforderungen durch einen Test abgedeckt? Oftmals sind diese Testfälle bereits fertig spezifiziert, bevor das Testobjekt überhaupt für den Test zur Verfügung steht. Kommt es dann zur Ausführung der Testfälle, z. B. im Systemtest, besteht die Gefahr, dass die Prüfungen unreflektiert abgearbeitet werden – die Testenden werden oft nicht explizit dazu angehalten oder haben schlichtweg wenig Zeit, links und rechts vom Testfall nach Fehlern zu suchen. Mit anderen Worten: Es wird oft als ausreichend angesehen, das Vorhandensein der geforderten Funktionalität zu überprüfen. Dieses Vorgehen ist typisch für Softwareprojekte, die nach dem Wasserfall- oder V-Modell durchgeführt werden.

Mehr Flexibilität und Kreativität beim explorativen Testen

Beim explorativen Testen stehen die Testfälle mit dem Beginn des Tests noch nicht zwingend zur Verfügung. Genauer betrachtet gibt es keine Testfälle im klassischen Sinn – die Tester und Testerinnen halten sich an die Idee bzw. den kreativen Ansatz ihrer Testcharta. Durch Ihre Entdeckungen werden unter Umständen die zu untersuchenden Bereiche verfeinert und für die nächste explorative Sitzung eingeplant. Es lässt sich also sagen, dass die „Testfälle“ in den Sessions „reifen“. Zusätzlich werden neue Stellen im Testobjekt entdeckt, die näher untersucht werden sollten. Diese Flexibilität bei der Fokussierung auf ein bestimmtes Ziel, sowie die damit einhergehende Kreativität beim Ausdenken von Testfällen ist ein erheblicher Unterschied zum klassischen Testvorgehen und kann dadurch einen wesentlichen Nutzen generieren.

SBTM eignet sich auch für Testobjekte, für die keine Testbasis (fehlende Ausgangsdokumente) zur Verfügung steht.
Der explorative Test kann insbesondere im agilen Umfeld Mehrwert generieren – wenn Tester und Testerinnen innerhalb eines Sprints eine schnelle Aussage zu der Qualität des Testobjektes treffen sollen. SBTM ist eine optimale Ergänzung zu den Akzeptanzkriterien.

Exploratives Testen soll auf jeden Fall immer Bugs finden! Werden die entsprechenden Sitzungen über einen längeren Zeitraum vernachlässigt, fallen die Listen von offensichtlichen Fehlern (die durch explorative Tests aufgedeckt werden) oft erschreckend lang aus. Aufgrund der breiten und kreativen Ausrichtung der Testchartas auf Themenfelder, in denen Risiken vermutet werden, führen explorative Testsitzungen häufig zu unklaren Ergebnissen. Ob der Befund dann einen Bug, einen (bislang nicht spezifizierten) Feature-Wunsch oder nur die eigene Voreingenommenheit des explorativ Testenden aufzeigt, sollte in diesen Fällen nach der Sitzung in einem gemeinsamen Debriefing geklärt werden. Es gibt die Möglichkeit Überblickssitzungen zu halten, die sich von vorneherein mehr auf die Generierung von Erfahrung, als auf die Findung von Bugs konzentrieren.

Exploratives Testen ist der entscheidende „Sanity Check“, der verhindern kann, dass andere – ebenfalls wichtige – Testansätze aus der Spur laufen. Es sollte daher nicht die Frage gestellt werden, ob Session-Based-Testing berücksichtigt wird, sondern vielmehr, ob der Mix aus „klassischem“ und Session Based Testing gut gewählt ist.

Wollen Sie SBTM einführen, so kann das vielleicht zunächst nicht „on top“ geschultert werden. Gibt es Bereiche, bei denen Sie weniger klassischen Testaufwand benötigen, wenn Sie SBTM einführen? Dann wäre dies ein Ansatz, sich Zeit für SBTM zu schaffen. Demo-Termine mit den Abnehmern werden beispielsweise mit Hilfe von SBTM strukturiert– am Ende wollen die meisten das System sowieso selbst bedienen, weshalb es nahe liegt die Teilnehmenden einfach direkt mit einer Testcharta auf eine Erkundungsmission zu schicken.

Damit Sie exploratives Testen verstehen unterstützt imbus Sie durch Trainings. Hier vermitteln  wir Ihren Teammitgliedern die genannten Techniken verständlich und praxisnah.

Wir unterstützen Sie auch im täglichen Doing, indem wir ihrem Team einen erfahrenen Quality Engineer zur Verfügung stellen, welcher z.B. explorative Tests vorbereiten und deren Durchführung koordinieren kann.

Möchten Sie die Themen lieber selbst angehen, dabei aber von einem erfahrenen Coach angeleitet werden?
Sprechen Sie uns an –  wir helfen Ihnen gerne weiter!

Weitere Informationen per E-Mail.