Matthias Passer

Lesezeit: 7 Minuten

TalkAbout

Testautomatisierung: Baumstruktur wird Straße

TestVille: Ein Blick sagt mehr als tausend Worte Testautomation ist eine feine Sache, und es gibt unzählige Tools und Frameworks, die die Automatisierung unterstützen. Wenn es allerdings um das Reporting geht, holen uns immer wieder die 90er ein – Excel-Listen und Balkendiagramme werden mit Prozentzahlen bestandener und fehlgeschlagener Testfälle und der Abdeckung von Code und…

TalkAbout

TestVille: Ein Blick sagt mehr als tausend Worte

Testautomation ist eine feine Sache, und es gibt unzählige Tools und Frameworks, die die Automatisierung unterstützen. Wenn es allerdings um das Reporting geht, holen uns immer wieder die 90er ein – Excel-Listen und Balkendiagramme werden mit Prozentzahlen bestandener und fehlgeschlagener Testfälle und der Abdeckung von Code und Anforderungen gefüllt. Der Zahlen- und Balkenwald ist dabei meist wenig aussagekräftig und erfordert die volle Aufmerksamkeit und Konzentration der Zuhörer.

Stadtmetapher statt Zahlenwald

TestVille schafft hier Abhilfe und bringt Leben in die Einöde von Excel und BarCharts. Unser Ziel für TestVille war es, ein einfaches, intuitiv verstehbares und cooles Open-Source-Tool zur Visualisierung, Analyse und Präsentation von Testautomatisierungs- und Testmanagementdaten in Audits und Statusmeetings zu schaffen. Dafür haben wir auf eine hausinterne Entwicklung aufgesetzt, die zur Visualisierung von impliziten Codestrukturen in Software-Audits und Sanierungsprojekten gebaut wurde: CodeCharta.

Baumstruktur im Stadtplan

Das Prinzip ist denkbar einfach: Ein Software- bzw. Testautomationsprojekt hat eine innere hierarchische Baumstruktur, die auf die Struktur eines Stadtplans übertragen wird. Im Fall von TestVille zeigen wir die Stadt mit einer Hauptstraße (dem Testprojekt), von der mehrere größere Nebenstraßen abzweigen; die Nebenstraßen symbolisieren die Kritikalität der Anforderungen im Softwareprojekt. Von diesen Nebenstraßen zweigen wiederum Seitenstraßen ab, die konkrete Anforderungen bzw. Epics mit der entsprechenden Kritikalität darstellen. Die Seitenstraßen sind von Gebäuden flankiert; die Gebäude stellen konkrete Testfälle dar und bilden die Priorität der Testfälle ab.

Jedes Gebäude besitzt mit Farbe, Grundfläche und Höhe drei frei konfigurierbare Parameter, die mit Kennzahlen belegt werden können: In untenstehender Abbildung zeigt die Farbe die Anzahl der Überarbeitungen des jeweiligen Testfalls an, die Grundfläche die Anzahl der Testschritte, und die Höhe die Anzahl der Ausführungen eines Testfalls. Andere denkbare Parameter sind etwa die Anzahl der durch einen Testfall gefundenen Defekte sowie deren Kritikalität oder Status. Diese Visualisierung macht die Kennzahlen sichtbar.

TestVille im Einsatz. Ein Fallbeispiel

Nehmen wir mal beispielshalber an, wir sollen ein Testautomatisierungsprojekt im Rahmen eines Audits beurteilen. Das in Jira gepflegte Testprojekt wird als XML-Datei exportiert und über einen Konsolenbefehl in das für die Visualisierung benötigte JSON-Format konvertiert. Dieses öffnen wir über die Onlineversion von TestVille. Es öffnet sich eine Visualisierung wie in Abbildung 1 gezeigt.

Wir sehen, dass von der Hauptstraße fünf Nebenstraßen abzweigen, also die Epics im Automationsprojekt nach fünf Kritikalitätsstufen unterschieden werden, die sich durch die Farbe der Straßenmarkierung unterscheiden. Von diesen zweigt jeweils eine Seitenstraße ab, d.h. jedem Epic ist nur eine User Story zugeordnet. Die Seitenstraßen sind unterschiedlich stark mit Gebäuden bevölkert, für jede User Story gibt es so unterschiedlich viele Testfälle. Die Gebäude an einer Seitenstraße stehen entsprechend ihrer Priorität gruppiert auf farblich markierten Fundamenten.

Ideal und Wirklichkeit

In einer idealen Testautomationssuite würden wir eine Art grüner Vorstadtwohnsiedlung vorfinden, d.h. ein dichtes Netz von Straßen bzw. Anforderungen/User Stories mit gleichmäßig verteilten kleinen Gebäuden bzw. Testfällen anstatt weniger großer Straßen mit teilweise sehr hohen und ausladenden Gebäuden. In unserem Beispiel ergibt sich das Bild eines kleinen Industriegebiets, was dem Idealfall also stark widerspricht.

Sehen wir uns die Konfiguration der Gebäude an, um zu sehen, was genau an den Testfällen nicht ideal ist: Die Grundfläche bezeichnet hier die Anzahl der Testschritte. Je mehr Schritte ein Testfall besitzt, desto fragiler wird er. Im vorliegenden Beispiel existieren große Hallengebäude von Testfällen mit bis zu 100 Schritten; diese sind auf den ersten Blick klar zu erkennen. Die Höhe der Gebäude variiert ebenfalls stark; diese entspricht der Anzahl der Ausführungen des jeweiligen Testfalls. Hier würde im Idealfall eine annähernd gleiche Höhe erwartet. Natürlich gibt es Testfälle, die jünger sind als andere und darum weniger oft ausgeführt, aber die Koexistenz einzelner Testfälle, die bis zu 150 mal ausgeführt wurden, und zahlreicher Testfälle, die gar nicht ausgeführt wurden – die farblosen “Geistergebäude”- , entspricht nicht dem Zweck einer automatisierten Testsuite.

Die Farbe der Gebäude steht im abgebildeten Beispiel für die Anzahl der Updates eines Testfalles und vermittelt für die meisten ausgeführten Testfälle ein recht günstiges Bild: Grüne Gebäude wurden maximal viermal angepasst, einige gelbe Gebäude wurden maximal neunmal angepasst, und knapp zwei Dutzend Testfälle wurden zehnmal oder häufiger nachgepflegt. Das spricht dafür, dass der Großteil der Testfälle stabil läuft und insgesamt nur wenige Korrekturen benötigen.

Mehrwert und Einsatzmöglichkeiten

Ist man mit den semantischen Grundlagen der Stadtmetapher vertraut, erschließen sich dem Betrachter diese Informationen auf den ersten Blick. Mit einer Tabellen- oder Graphenansicht ist diese Dichte und Deutlichkeit von Informationen nicht erreichbar; außerdem würde es zumindest mehrerer Graphen bedürfen, um das komplette Bild zu erhalten, das die TestVille-Visualisierung bietet. Die Visualisierung macht die Daten leichter zugänglich; außerdem sieht man im direkten Vergleich von zwei Bildern die Veränderung.

Der Einsatz von TestVille bietet sich aber nicht nur für bereits gewachsene Projekte mit ausführlicher Testautomation an, sondern auch für junge Entwicklungsprojekte; hier kann bei regelmäßigen Datenabzügen des verwendeten Testmanagement-Tools die eigene Stadtentwicklung live miterlebt werden. Falls sich hier mit der Zeit ungünstige Entwicklungen auf der Gesamtebene des Testprojekts einschleichen, können diese leicht und früh erkannt und korrigiert werden.

So bietet TestVille nicht nur eine optische Abwechslung zu den üblichen Reporting-Mitteln, sondern einen echten Mehrwert in sämtlichen Situationen, in denen Wissen zum Stand des eigenen Testprojekts vermittelt werden soll, ob im Daily Scrum, im Jour fixe oder als Einzelpräsentation im weiteren Projekt- und Managementumfeld.


Testville ist Open Source. Wir stellen es auf Github zum Download bereit.

Über den Autor

Matthias Passer

Softwareentwickler

Matthias ist 2017 zunächst als Softwaretester zu MaibornWolff gestoßen, bevor er in die Entwicklung wechselte. Für ihn steht die Analyse von komplexen Problemen und deren Lösung im Fokus seiner Arbeit. Diese umfassen die Architektur und das Design von Software, die ein Problem in der “echten Welt” lösen soll, aber auch die gute alte Bug-Analyse, um problematischen Code zu identifizieren und korrigieren.