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 ein veränderter Text nur zum Teil angezeigt, und ein Button hat derart unpassende Farben, dass die Beschriftung nur schwer erkennbar ist. Dies 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 mit explorativem 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 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 englisch Session-Based Testing genannt. SBTM setzt auf die Erfahrung der Mitglieder agiler Teams und geht davon aus, dass diese gut in der Lage sind Vermutungen anzustellen. In unserem Beispiel mit dem Fahrzeugkonfigurator könnte eine solche Vermutung daraus entstehen, dass es schon ö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. Durch Testchartas sind zeitlich eingeschränkte, intensive Testaktivitäten mit klaren Testzielen und daher mit einer eindeutigen Zielrichtung 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 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 (= explorativer Test) 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 Testerinnen und Testern wird dabei durchgespielt, dass sie die Erkundung des Testobjektes wie den Besuch einer unbekannten Stadt angehen. Sie sollen sicher gehen, dass sie wesentliche Sehenswürdigkeiten kennenlernen. Die Testerinnen und Testern beginnen üblicherweise mit einem gemeinsamen Blick auf einen Stadtplan. Die „Reisegruppe“ beschließt, welche Teile der Stadt interessant sind.   Sind die Stadteile festgelegt, so schicken Sie die einzelnen Interessengruppen in unterschiedliche Bereiche.
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 kann idealerweise das ganze Team oder auch Personen außerhalb des Teams mitwirken. Der Fokus liegt hier nicht explizit auf Teilnehmenden mit Test-Knowhow. Dadurch lassen sich im gleichen Zeitraum viele Testchartas verfolgen und alle Teammitglieder lernen die ganze Anwendung auch aus neuen Blickwinkeln kennen. Da Erfahrung gemeinsam besonders gut wächst, ist es sehr bewährt, immer wieder auch zu zweit oder in noch größeren Gruppen die Testchartas zu erforschen.

Vergleicht man das klassische Testverfahren mit dem sitzungsbasierten Testen, 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 Tests unreflektiert abgearbeitet werden - die Testerinnen und Tester 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.

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.

Auf jeden Fall sollen Bugs gefunden werden! Wenn die entsprechenden Sitzungen über einen längeren Zeitraum vernachlässigt wurden, sind die Listen von offensichtlichen Fehlern, die durch explorative Tests aufgedeckt werden, manchmal erschreckend lang. Aufgrund der relativ 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 Testsitzung 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.

Vielmehr muss gefragt werden, 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 könnten beispielsweise mit Hilfe von SBTM strukturiert werden – am Ende wollen die meisten sowieso das System selbst bedienen können, weshalb es nahe liegt die Teilnehmenden einfach direkt mit einer Testcharta auf eine Erkundungsmission zu schicken.

imbus unterstützt Sie durch Trainings, in denen wir Ihren Teammitgliedern die genannten Techniken verständlich und praxisnah beibringen.

Wir können Sie auch im täglichen Doing unterstützen, indem wir ihrem Team einen erfahrenen Quality Engineer zur Verfügung stellen, welcher diese explorativen 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!

Jetzt Termin vereinbaren!