Werkzeuggestütztes Testdesign: Ein Plädoyer

Prozessunterstützende Werkzeuge erleichtern uns die tägliche Arbeit. Sie helfen uns, Software zu entwickeln und zu testen oder das Projekt zu steuern. Doch es gibt es gibt einen blinden Fleck: das Testdesign. Gute Tests scheinen vom Himmel zu fallen. Man muss sie nur niederschreiben oder programmieren.

Tatsächlich gibt es ein enormes Verbesserungs- und Einsparungspotenzial, welches in den meisten Organisationen ungenutzt liegen gelassen wird. Weshalb sollten sich Tester mit einem Text-Editor zufriedengeben, während die Kollegen aus der Entwicklung diverse Tools zur Unterstützung ihrer Arbeit einsetzen? Schauen wir uns diese Frage einmal genauer an.

Wo kommen wir her? – Die Industrialisierung der Softwareentwicklung

Es gibt sie schon lange, die Rufe nach einer “IT-Fabrik”¹ bzw. nach “industrieller Softwareentwicklung”. Es muss doch möglich sein, Softwareentwicklung genauso auf Produktivität zu trimmen, wie dies beispielsweise in der Fertigung von Autos der Fall ist! In ihrem Leitfaden aus dem Jahr 2010 definiert die Bitkom vier Pfeiler der IT-Industrialisierung²:

• Automatisierung,
• Wiederverwendung,
• Spezialisierung und
• kontinuierliche Verbesserung.

Speziell im Bereich Automatisierung sind wir in den letzten 20 Jahren enorm vorangekommen. Den Entwicklerinnen und Entwicklern stehen – nicht zuletzt dank des Trends zur Agilität – zahlreiche Werkzeuge zur Verfügung. Denken Sie nur an Continuous Integration bzw. Continuous Deployment (CI/CD).

Doch auch in den anderen Bereichen hat sich viel getan. Architekturmuster unterstützen die Modularität von Softwaresystemen und damit deren Wiederverwendung. Experten für Gebrauchstauglichkeit, IT-Sicherheit und neuerdings auch für KI-Systeme sind so gefragt, dass sie kaum noch zu finden sind. Auch die kontinuierliche Verbesserung, die oft dem Tagesgeschäft zum Opfer fällt, ist zumindest im Bewusstsein der Beteiligten angekommen.

Also alles eitel Sonnenschein?

Wo stehen wir? – Ein scharfer Blick auf den Softwaretest

Leider – oder vielleicht zum Glück – besteht Softwareentwicklung nicht nur aus Programmieren. Ein wichtiger Teil ist die Qualitätssicherung. Ganzheitlich betrachtet beginnt Qualitätssicherung damit, klar zu kommunizieren, was eigentlich entwickelt werden soll. Viele Unternehmen haben daher Tools wie Jira / Confluence oder ein anderes ALM (Application Lifecycle Management) Tool eingeführt, in dem theoretisch alles Wichtige steht und das für alle Projektbeteiligten zugänglich ist. Im ALM-Tool kann ich auch Testfälle erfassen, die ich dann im Idealfall automatisiert durchführe.

Auch die Testautomatisierung ist naturgemäß werkzeuggestützt und nutzt wiederverwendbare Bibliotheken. Die sogenannten Low Code bzw. No Code Tools ermöglichen es den Fachexpertinnen und -experten, sich auf das Wesentliche zu konzentrieren, nämlich auf die Inhalte.

Merkwürdigerweise gibt es genau an dieser Stelle im Softwaretest einen blinden Fleck: das Testdesign (auch Testentwurf genannt). Von außen wenig wahrgenommen, bemühen sich Fachexperten meist völlig ohne Werkzeugunterstützung, ihr Bestes zu geben und “gute” Tests zu erstellen. “Gut” bedeutet in der Regel “umfassend, fachlich korrekt und nicht zu teuer”.

Testdesign erfolgt immer, völlig unabhängig vom Testprozess. Hier ein paar Beispiele:

Manuelle Tests gegen Anforderungen bzw. User Storys

Für jede Anforderung bzw. User Story sollte der Test alle Akzeptanzkriterien abdecken. Ein sorgfältiges Testdesign stellt sicher, dass alles, was gefordert wurde, auch geprüft wurde. Darüber hinaus denken sich Tester Fehlerszenarien und Sonderfälle aus, um das System an seine Grenzen zu bringen. Je nach gefordertem Dokumentationsgrad, werden diese Tests vorab niedergeschrieben (als Testspezifikation), oder nur stichwortartig in einer Testfallbeschreibung erfasst. Wichtig ist, dass die Vollständigkeit bezüglich der Vorgaben gegeben und nachvollziehbar ist.

Automatisierte Tests

Auch automatisierte Tests erfordern Testdesign. Sie unterscheiden sich darin überhaupt nicht von manuellen Tests. Schließlich ist ein Testskript nur so gut wie die Prüfungen, die darin automatisiert wurden. Die Dokumentation des Testdesigns erfolgt jedoch oft nur rudimentär, oft in Form von Kommentaren im Code. Diese konzentrieren sich dann oft auf das Design des Testskripts an sich. Testdesign und Code-Design sind jedoch unterschiedliche Dinge! Im einen geht es um die Testidee, im anderen um die die Art und Weise, wie das Skript programmiert ist.

Explorative Tests

Selbst den explorativen Tests liegt eine Art Testdesign zugrunde, denn auch explorative Tester denken über Äquivalenzklassen, Grenzwerte und Fehlerszenarien nach. Erfahrenen Testerinnen und Testern ist diese Vorgehensweise in Fleisch und Blut übergegangen. Das macht sie zu begnadeten “Kritikern” des Produktes. Aufgeschrieben wird diese Expertise kaum.

Gerade die geringe Dokumentation des Testdesigns führt dazu, dass diese wichtige, gedankliche Leistung, praktisch nicht wahrgenommen wird. Dies gilt sogar für Testprozesse, die noch klassisch nach V-Modell mit Testspezifikationen arbeiten. Denn diese Spezifikationen enthalten üblicherweise die Details zur Testdurchführung, in denen sich die zugrunde liegenden Überlegungen verlieren.

Dabei steht und fällt die Qualität der Tests mit dem Testdesign. Warum spiegelt sich dies nicht im Grad der Unterstützung wider? Testdesign erfolgt meist manuell, ohne jede Werkzeugunterstützung. Hier können wir nicht von “Industrialisierung” sprechen. Das ist bestenfalls Handwerk, wenn nicht gar Kunst!

Wo wollen wir hin? – Werkzeugunterstützung im Testdesign

Es wird Zeit, dass sich die Manager des Testdesigns bewusst werden. Schließlich sprechen wir hier nicht nur von einer entscheidenden Aktivität im Testprozess, sondern auch von einem enormen Verbesserungspotential.

Wie sehr sich die Produktivität im Testdesign steigern ließe, wird im Vergleich zur Programmierung, also der Implantierung von Quellcode deutlich. Von Entwicklern würde niemand erwarten, Quellcode in Notepad++ zu schreiben. Wie denn auch? Der oder die betreffende Person hätte innerhalb von wenigen Monaten gekündigt. Entwickler haben ihre integrierte Entwicklungsumgebung (IDE) mit Syntax-Highlighting, Autovervollständigung von Texten, Werkzeuge für statische und dynamische Codeanalyse u.v.a.m.

Tester scheinen leidensfähiger zu sein. Wir sind ja schon glücklich, wenn wir besagtes ALM-Werkzeug haben, weil es uns erlaubt, Testfälle mit Anforderungen / User Storys zu verknüpfen. Dies erleichtert nämlich den Nachweis der Vollständigkeit. Ansonsten haben wir Felder für Testschritte, erwartete und tatsächlich beobachtete Ergebnisse. Mit etwas Glück hilft eine Rechtschreibprüfung, den gröbsten Unsinn zu vermeiden. Alle weiteren Felder wie z.B. die Priorität dienen bereits dem Testmanagement. Werkzeugunterstützung sieht anders aus!

Dabei gibt es diese Werkzeuge durchaus, wie die nachfolgende Auflistung – ohne Anspruch auf Vollständigkeit – zeigt:

Visualisierung von komplexen Zusammenhängen

Alle Werkzeuge, mit denen komplexe Zusammenhänge graphisch dargestellt werden können, tragen zu Klärung von Anforderungen und damit auch zum Testdesign bei. Dazu gehören einfache Flowchart-Editoren (z.B. Miro, Draw.io, Yest for Jira…) ebenso wie komplexere Modellierungs-Werkzeuge (z.B. Sparx Systems Enterprise Architect oder Camunda).

Ermittlung von zu testenden Regeln / Szenarien

Agile Coaches haben diverse Methoden in petto, die ebenso einfach wie effizient dabei helfen, das Gespräch über neue Funktionalität in Gang zu bringen und den Testbedarf abzustecken. Prominente Beispiele sind Example Mapping und Storyboards. Für beide Methoden benötige ich kaum mehr als Stift und Papier.

Systematische Prüfung von Äquivalenzklassen und Grenzwerten

Systematik kann auf vielfältige Weise erreicht werden. Klassifikationsbäume, Entscheidungstabellen, die explizite Modellierung der Werte – alles, was die Gedanken im Testdesign sichtbar werden lässt, ist hilfreich. Welche Methode unterstützt wird, hängt vom gewählten Werkzeug ab. Beispiele sind Tessy mit dem integrierten Classification Tree Editor, die Entscheidungstabellen in Yest und alle Tools für modellbasiertes Testen (MBT).

Testfallerstellung und -überarbeitung

Pairwise Testing Tools unterstürzen die Generierung von kombinatorischen Tests³.

Modellbasierte Testfallgeneratoren erzeugen Testfälle aus Modellen. Die zahlreichen, auf dem Markt verfügbaren MBT-Tools unterscheiden sich dabei nicht nur in der Art und Weise der Generierung, sondern auch im Grad der Unterstützung für die Erstellung und Überarbeitung der Modelle und der generierten Testfälle. So bietet Yest eine umfangreiche Entwicklungsumgebung für Tester⁴, während TestCompass sich auf das strikte Minimum beschränkt⁵.

Was brauchen wir? – Mehr Wertschätzung für das Testdesign

Vielleicht ist das hier gezeichnete Bild zu pessimistisch. Die bahnbrechende Entwicklung generativer KI wird in Zukunft sicherlich zur besseren Unterstützung des Testdesigns beitragen. Doch KI benötigt Ausgangsdaten, die eine gute Qualität aufweisen – und gerade daran hapert es oft.

Tatsächlich holen Tester im Testdesign nach, was in der Anforderungsermittlung versäumt oder einfach auf die Backlog-Refinement-Sitzungen verschoben wurde. Es ist nicht zielführend, diese beiden Aktivitäten zu trennen. Test-First-Ansätze wie Behavior-Driven Development (BDD) oder Visual ATDD (eine agile Form des modellbasierten Tests) haben dies verstanden. Wer das Testdesign an den Anfang des Prozesses stellt, schlägt zwei Fliegen mit einer Klappe. Wir sollten das Testdesign nicht als lästigen Kostenfaktor, sondern als wertsteigernde Form der Klärung von Anforderungen verstehen, die eine geeignete Werkzeugunterstützung braucht und verdient. Was wir wirklich brauchen, ist mehr Wertschätzung für das Testdesign!

Hinweise:

Melden Sie sich gerne bei Anne Kramer, wenn Sie sich mit Ihr über Testdesign austauschen oder einen Blick in das visuelle Testdesign Tool Yest werfen wollen. Schreiben Sie ihr einfach eine Mail oder vernetzen Sie sich mit ihr auf LinkedIn.

[1] Der Weg zur modernen IT-Fabrik
[2] Bitkom: Industrielle Softwareentwicklung. Leitfaden und Orientierungshilfe
[3] Software Pairwise Testing Tools
[4] Test generation with Yest
[5] TestCompass

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.