Thought Leadership
Um die Qualität einer Software sicherzustellen, testen wir sie. Dabei gibt es unterschiedliche Testverfahren: Pentests adressieren die Sicherheit einer Software, Code Reviews prüfen ihre Codequalität. In diesem Beitrag widmen wir uns dem explorativen Testen – das den Bedienkomfort einer Software in den Fokus nimmt.
Der Tag des Projektabschlusses steht unmittelbar bevor. Über Monate hinweg haben wir Zeit, Schweiß und Nerven in die Entwicklung investiert. Alles ist bereit für ein erfolgreiches Roll-out: Die Anforderungen sind x-fach reviewed, der Code hat alle statischen Analysen mit Bravour passiert, die Coverage unserer Unittests liegt bei traumhaften 90 % +, die Testautomatisierung signalisiert grünes Licht und auch die Hürde der fachlichen Freigabe ist genommen … Und doch will sich noch keine rechte Champagnerlaune einstellen, steht doch eine gewisse Sorge im Raum, dass da nach wie vor Dinge in der Anwendung schlummern, die den ganzen Unterschied machen – zwischen einem „Anforderungen umgesetzt“ und einem „Großartige Software!“
Was können wir also tun, um die letzten Meter auf dem Weg zum Qualitätsgipfel zu erschließen?
Was ist exploratives Testen?
Eine mögliche Option bietet das explorative Testen. Bei dieser Methode stehen nicht Testpläne im Mittelpunkt, sondern „entdecken“ wir Tester die Anwendung schrittweise selbst, indem wir sie benutzen. Parallel dazu erstellen wir unsere Testfälle und optimieren sie iterativ in dem Maße, in dem wir mehr über die Anwendung lernen. Gefragt sind hierbei vor allen Dingen Intelligenz, Intuition und Erfahrung. Im Gegensatz zu den klassischen Testmethoden – die dadurch keineswegs obsolet werden – fokussiert sich der explorative Ansatz auf die grundsätzliche Benutzbarkeit der Anwendung. Denn Schwächen in der Darstellung, umständliche Arbeitsabläufe oder logische Brüche, werden oft erst im Nutzererlebnis offenbar.
Bild 1: Der Mensch ist unersetzlich!
Exploratives Testen vs. automatisiertes Testen
So testen wir ohne Testplan – aber nicht ohne Plan. Ein bewährtes Format für diese Methode ist die explorative Testsession. Sie gibt den Rahmen vor, in dem ein ausgewählter Kreis an Teilnehmern einen zuvor bestimmten Funktionsumfang der Software in vorgegebener Zeit explorativ testet.
Bild 2: Ohne Testplan, aber trotzdem planvoll.
Workflow beim explorativen Testen
Damit das Ganze koordiniert passiert, benötigt es ein bisschen Vorbereitung – das Nichtvorhandensein eines Testplans bedeutet nämlich keinesfalls, dass der Testerkreis planlos drauflos testet! Im Folgenden führe ich Fragen auf, die wir im Vorfeld von explorativen Tests klären sollten.
Wie viele Tester sind sinnvoll? Ein größerer Teilnehmerkreis liefert ein breiteres Spektrum auswertbarer Ergebnisse, bedeutet aber auch mehr Organisation: die Beschaffung eines geeigneten Raumes, die Bereitstellung der technischen Ausstattung, mehr Zugänge zur Testumgebung usw. Meiner Erfahrung nach gibt es keine optimale Teilnehmerzahl per Definition, wichtig ist nur, dass genügend Moderatoren da sind, die während der Session Eindrücke sammeln und offene Fragen klären können. Ein Schlüssel von einem Moderator auf maximal acht Teilnehmer halte ich noch für praktikabel.
Wer genau soll testen?
Eine heterogene Besetzung hat den Vorteil, dass aus unterschiedlichen Perspektiven getestet wird. Deshalb beziehen wir alle am Projekt beteiligten Rollen mit ein: Projektleiter, Entwickler, Product Owner, Mitarbeiter auf der Fachseite. Gerade für Entwickler, die oft „abgekoppelt“ vom Auftraggeber operieren, kann es sehr spannend sein, zu sehen, wie ihre Umsetzung von den späteren Usern angenommen wird. Eine Beteiligung des Kunden bietet uns übrigens zusätzlichen Benefit: das gemeinsame Testerlebnis verbessert das gegenseitige und gemeinsame Verständnis und damit die Beziehung zueinander. Auch eine Besetzung mit projektfremden Mitarbeitern kann interessante Anhaltspunkte liefern, da diese unvoreingenommener an das unbekannte System herangehen. Bei einer solchen Besetzung sollten wir allerdings einplanen, dass die Teilnehmer in der Regel mehr Anleitung benötigen – etwa in Form eines verständlichen Szenarios – damit sie vollständig im Bilde sind.
Wieviel Zeit darf der Test in Anspruch nehmen?
Wir legen vorab unbedingt einen Zeitrahmen fest. Exploratives Testen birgt sonst die Gefahr, dass sich die Teilnehmer in der Anwendung verrennen. Diese Gefahr steigt mit zunehmender Komplexität des zu testenden Systems an. Auf der anderen Seite nimmt die Konzentration der Tester im Laufe der Session ab. Ein Umfang von einer bis maximal drei Stunden hat sich in der Praxis bewährt.
Was genau testen wir?
Was wir ebenfalls vorher abstecken sollten, ist der Umfang an Funktionsbereichen, die wir innerhalb des gesetzten Zeitrahmens mit dem angedachten Teilnehmerkreis abdecken wollen. Je nach Bedarf können wir dazu auch Teams bilden und die Bereiche unter ihnen aufteilen, damit nicht alle dieselben Funktionen testen. Dieses Vorgehen bietet uns für künftige Testsessions außerdem die Option, Aufgaben zwischen Testteilnehmern zu rotieren, so dass immer jemand anderes seine Eindrücke dazu widerspiegelt.
Wie dokumentieren wir?
Auch wenn wir die Tests nicht mit Ballast überfrachten wollen, können wir auf eine Dokumentation nicht grundsätzlich verzichten. Wir benötigen die Testergebnisse a.) für die Auswertung und b.) für den Nachweis, dass und welche Funktionen wir getestet haben. Das Reporting bauen wir parallel zu unseren Testaktivitäten auf – es sollte sich an der Devise „so wenig wie möglich, so viel wie nötig“ orientieren. Dabei können wir wichtige Informationen wie Session, Datum, Resultat und gefundene Fehler in Form von Checklisten oder Mindmaps festhalten oder auf andere etablierte Methoden zurückgreifen.
Exploratives Testen in agilen Projekten
Exploratives Testen ist bestens auch für ein agiles Projektumfeld geeignet. Die Tests sind so leichtgewichtig, dass sie problemlos in die CI/CD – Pipeline eingetaktet werden können. Überdies sichert uns das Einbeziehen des Kunden ein frühzeitiges und kontinuierliches Feedback.
Eine Checkliste kann helfen
Für die Umsetzung des explorativen Tests können wir Etappen bilden. Aus meiner Sicht genügen drei: Vorbereitung, Durchführung und Auswertung. Wir notieren uns, an welche Aufgaben wir in welcher Etappe denken müssen. Was das angeht, bin ich Fan der Checkliste. Sie hilft uns dabei, nichts zu vergessen. Wir betrachten sie nicht als statische, tote Worddatei oder Wiki, sondern passen sie regelmäßig an unsere Erfahrungen und Bedürfnisse an.
So oder ähnlich könnte sie aussehen:
Tabelle: Checkliste exploratives Testen.
Vorteile von explorativem Testen
Und wie profitiert der Kunde von explorativen Tests? Einige nützliche Effekte wurden bereits erwähnt, seien an dieser Stelle aber noch einmal zusammengefasst:
Explorative Tests …
… untersuchen die Benutzbarkeit und steigern so die Nutzerakzeptanz
… betrachten Funktionsbereiche aus unterschiedlichen Perspektiven
… ergänzen klassische Testsetups – für eine ganzheitliche Testabdeckung
… verbessern die Kundenbeziehung durch dessen Beteiligung
… legen versteckte Potenziale für das Change Management frei
… benötigen nur geringen zeitlichen Aufwand
Auf die Plätze … fertig … Test!
Unsere Empfehlung ist: Nicht zu kompliziert machen, besser einfach loslegen, die Theorie kann sonst erdrückend sein. Die erste Testsession kann Schwächen haben – und das ist auch gut so, weil wir daraus lernen werden. Das Attribut „selbstlernend“ gilt nicht nur für den Test, sondern auch für den organisatorischen Prozess. Schmeißen wir also raus, was sich in den ersten Durchläufen als ineffektiv gezeigt hat, ergänzen an den Stellen, wo wir Lücken festgestellt haben, passen unsere Checkliste an und beziehen den Kunden in die Lessons learned mit ein, damit auch seine Eindrücke und Wünsche für künftige Tests berücksichtigt werden.
