Zehntausend Städte — Test-Objektifizierung & Dokumentation

Oder doch?

Ich habe schon oft beobachtet, wie QA-Teams mit enormem Pflichtbewusstsein und Fleiß die heroische Aufgabe angehen, all ihre Tests komplett zu dokumentieren. Für einen Release. Danach gerät die Dokumentation meist ins Abseits, verstaubt irgendwo digital im Netzwerk. Und das nicht, weil das Team den Sinn darin nicht mehr sieht. Sie sind einfach völlig erschöpft von der Mühe, alles für den nächsten größeren Release aktuell zu halten. 

In ihrem Eifer haben die QA-Teams nämlich hyperdetaillierte Testbeschreibungen erstellt – alles wurde bis ins manisch-mikroskopische Detail zerlegt. Für jede Facette oder jedes Attribut einer Funktion oder Nutzerinteraktion gibt es eigene Testdokumente. Für eine im Kern einzige Testaufgabe werden Dutzende einzelner Beschreibungen und Tasks erstellt. Es ist, als würde jemand an der Supermarktkasse $80 Einkauf mit Kleingeld bezahlen wollen.

Das Resultat dieses übermäßigen Detaillierungswahns: Es entstehen hunderte, manchmal tausende Testbeschreibungen pro Release. Ohne es zu merken, hat QA einen halben Dickens-Roman geschrieben. Eine „Geschichte von zehntausend Städten“. Schon mal einen davon gelesen? Ich auch nicht.

Die Konsequenz ist, dass niemand Zeit oder Geduld hat, diese unzähligen Testbeschreibungen zu aktualisieren. Denn die nächste Softwareiteration zu testen, ist immer wichtiger – schließlich bringt das Umsatz, während das Aktualisieren der Testdokumentation keinen einbringt. 

Und zusätzlich machen es Testdokumentations-Tools ausgesprochen schwer, Massenänderungen an Testdokumenten vorzunehmen. Globale Anpassungen von Testklassen sind in den meisten Anwendungen umständlich und wenig intuitiv (das gilt übrigens auch für viele Defect-Tracking-Programme – selbst heute noch). Das erhöht den Zeitaufwand und belastet Nerven und Motivation zusätzlich.

Das Ergebnis: Die ganze akribisch erstellte Testdokumentation wird liegen gelassen und nicht weiter genutzt. Die investierte Zeit war letztlich für die Katz. Denn sie ist nicht wiederverwendbar – ein One-Hit-Wonder. Es ist das „I Melt With You“ der Softwaretests. Dabei ist Testdokumentation unabdingbar, um systematisches, reproduzierbares Testen zu ermöglichen. Daher das Dilemma.

Doch es gibt einen Ausweg. Und so schwer mir das auch fällt, als Vorbild hierfür sollten wir einen Blick auf das Engineering werfen – oder zumindest zur Inspiration. In den Anfängen der kommerziellen Software standen Ingenieure vor einem ähnlichen Problem: Aufgrund der damals beschränkten Programmiersprachen mussten sie für jede Funktion dieselben Basiseigenschaften, Aktionen und Schutzmechanismen immer wieder neu programmieren. Speziell das Speicher-Management/Garbage Collection war da ein gutes (und gefährliches) Beispiel.

Dadurch entstanden Unmengen an unnötigem, doppelt geschriebenem Code und es wurde eine Menge Zeit vergeudet (nicht, dass Entwickler das immer stören würde – Ebay gibt es ja nicht ohne Grund). Dann kam jemand auf die Idee des objektorientierten Programmierens. So konnten Programmierobjekte mit geerbten Standardattributen definiert werden. Der gleiche Code musste nicht mehrfach geschrieben (oder eingefügt) werden. Schlechte Codequalität hing also nicht mehr von Gedächtnisleistung oder Tippfähigkeiten eines einzelnen Entwicklers ab. Dafür ist QA ewig dankbar.

Das liefert QA ein hilfreiches Bild beim Kampf mit der Sackgasse Testdokumentation. Das Konzept der Objektorientierung aus der Technik kann zwar nicht direkt auf dieses Problem angewendet werden, aber als Metapher bietet es wertvollen Input. Cleverness bedeutet schließlich, sich flexibel an neue Situationen anzupassen.

Im Laufe meiner Karriere stand ich oft vor dem Problem, Testdokumentation zu erstellen, die umfassend, aber prägnant ist – und die sowohl sofort umsetzbar als auch für künftige Releases problemlos wiederverwendbar bleibt. Die Lösung, auf die ich letztlich gekommen bin: Das Konzept des „Objekts“ direkt auf die Testdokumentation anwenden. 

Dabei geht es um weit mehr als nur Vorlagen für Testdokumentation. Die sind für Standardisierung wichtig, helfen hier aber nicht weiter. Ich habe mir überlegt, Tests so zu dokumentieren, dass sämtliche Varianten, Wechselwirkungen, Workflows und Sonderfälle in einem einzigen Dokument abgebildet werden. Sobald mir (endlich!) dieses Licht aufging, erschien die Lösung plötzlich ganz einfach. Und absolut machbar.

Schauen wir genauer hin.

Die rote Pille schlucken

Die Lösung ist, jeden einzelnen Test – und damit auch sein zugehöriges Dokumentationsartefakt – nicht als bloße Beschreibung oder Überprüfung eines einzigen Datenpunkts oder spezifischen Falls zu sehen. Sondern als Beschreibung der gesamten Matrix (sehen Sie, was ich meine?) der Bedingungen, unter denen das Feature oder die Fähigkeit validiert werden muss. 

Dies beinhaltet einen ganzheitlichen Ansatz für die Definition einzelner Tests. Eine zusammenhängende, einheitliche Testaufgabe kann nicht sinnvoll in Dutzende unabhängige „Tests“ aufgespalten werden, ohne auf paradoxe Weise die Spezifität im Hinblick auf die gesamte Funktionalität zu verwischen. Es ist eine Situation wie „den Wald vor lauter Bäumen nicht sehen“.

Hier ist es sinnvoll, das Konzept des Testkontexts zu betrachten. Denn um die Idee eines Testobjekts effektiv umzusetzen, müssen Sie zunächst in der Lage sein, den unveränderlichen Kern eines Funktionalitätsteils von seinen sekundären Anwendungs- und Betriebskontexten zu trennen. Dies ist eine Fragestellung, die der atomare Stil der Testdokumentation ausklammert, sodass Tester nie lernen, diese Analyse systematisch und bewusst durchzuführen. Ein weiterer Nachteil der atomaren Vorgehensweise.

Vereinfacht gesagt sind Testkontexte für eine Funktion oder ein System die Menge an Bedingungen, Umgebungen, Abläufen oder Zuständen, die sich unabhängig voneinander innerhalb der Grenzen der Funktion verändern können. Betriebssysteme und deren Versionen sind ein eindeutiges Beispiel dafür. Fremdsprachen sind ein weiteres. Systemzustände sind ein weiteres Beispiel (z. B. bei einem Webserver: Speicher-Caching ein- oder ausgeschaltet). Sobald Sie diesen Unterschied verstanden haben, werden Ihnen leicht viele weitere relevante Beispiele für die von Ihnen getesteten Produkttypen einfallen.

Nachdem Sie diese Analyse abgeschlossen haben (die ohnehin die Grundlage jeder professionellen Testplanung sein sollte), sind Sie in der Lage, kompakte Formen der Testdokumentation zu erstellen, die diese Unterscheidung verinnerlichen. In dem von mir beschriebenen System besteht ein einzelnes Testdokumentations-Artefakt aus:

1. Eine Beschreibung der zu testenden Kernfunktion oder Fähigkeit.
2. Eine Liste aller Kontexte, in denen die Kernfunktionalität validiert werden muss.
3. Alles Weitere, was Sie ohnehin normalerweise aufgenommen hätten (Voraussetzungen für die Gültigkeit des Tests, notwendige Systemressourcen und -berechtigungen zur Durchführung des Tests, ein Link zu den entsprechenden Produktanforderungen usw.). Nichts davon wird durch meinen Vorschlag ersetzt.

Nun denken Sie vielleicht: „Moment mal, das könnten ganz schön viele Kontexte sein!“. Ja, schon. Aber betrachten Sie es so: Auf diese Weise entsteht für Sie keine Mehrarbeit. Tatsächlich wird sie sogar reduziert. Umfassende Testpläne lassen sich einfacher mit unserer kuratierten Liste von Software-Testwerkzeugen für die Dokumentation erstellen. Denn diese Methode wird die Anzahl der einzelnen Tests, die Sie erstellen und künftig pflegen (oder auch nicht mehr pflegen) müssen, *deutlich* verringern. Im atomaren Ansatz wäre für jeden Kontext ein eigenes Testdokumentations-Artefakt notwendig gewesen – was direkt zu dem Catch-22 am Anfang dieses Artikels führt.

Diese Methode der Testdokumentation hat bestimmte Konsequenzen für den Ablauf, die zunächst unbequem oder gar beunruhigend erscheinen mögen – nicht nur für die QA, sondern auch für andere Projektbeteiligte. Wenn sich jedoch alle die Zeit nehmen, sie zu verstehen, werden sie erkennen, dass es tatsächlich Verbesserungen sind. Für jeden Beteiligten.

Wichtigste Konsequenz ist, dass durch das Zusammenfassen der Kontextmatrix einer Funktion in den Haupttest logisch gilt: Wenn dieser einzelne Test in nur einem seiner Kontexte fehlschlägt, gilt der gesamte Test als fehlgeschlagen. Selbst wenn es nur ein Kontext ist. Ich kann mir vorstellen, dass dies für Panik in den Reihen des Engineerings sorgt. Denn es könnte den Anschein haben, als setze man ihnen absichtlich Hürden und erhöhe die Schwelle dafür, dass ein Test als „bestanden“ zählt, auf ein unmögliches Niveau. Doch diese Befürchtung lässt sich leicht zerstreuen. Weisen Sie sie auf zwei Dinge hin, und sich selbst auf ein drittes:

1. Diese Methode wird tatsächlich die Anzahl der durch Tests generierten Bugs gegen ihre Arbeit reduzieren. Denn mit der atomaren Methode hätte das Scheitern in jedem einzelnen Kontext einen eigenen separaten Bug erzeugt – was wiederum die Gesamtzahl der Bugs für diese Funktion erhöht hätte. Das wird Ingenieur:innen und Projektmanager:innen ein Lächeln ins Gesicht zaubern.
2. Zweitens liefert das Testen nach dieser Methodik automatisch Kontext für das tatsächliche Ausmaß des Funktionsfehlers. Denn was ist die erste Frage, die ein:e Ingenieur:in, der/die den Fehler beheben soll, immer stellt? „Äh, tritt das überall auf? Oder nur im Kontext X?“ Anstatt nun hektisch zurück an den Schreibtisch zu rennen und den Test im Kontext X noch einmal laufen zu lassen (weil Sie das bei den ursprünglichen Tests vielleicht vergessen hatten?), kennen Sie die Antwort bereits – und der/die Entwickler:in verliert so auch die Ausrede, der Behebung des Fehlers auszuweichen (was weniger Bugs gibt, gleicht QA an anderer Stelle wieder aus).
3. Drittens sorgt die Kontextanalyse für die Testdokumentation dafür, dass Sie sich beim Dokumentieren des Tests tatsächlich mit allen relevanten Kontexten befasst haben. Das bedeutet, dass Sie seltener diese panikartigen Momente haben werden – drei Tage vor oder, schlimmer noch, nach der Veröffentlichung – in denen Ihnen auffällt, dass Sie in einem sehr wichtigen Kontext gar nicht getestet haben. Panikbasierte QA-Arbeit ist nicht sehr effektiv – und auch keine besonders angenehme psychologische Erfahrung.

In Machina

Diese objekt-inspirierte Methode der Testdokumentation wird die Anzahl der zu erstellenden Dokumentations-Artefakte drastisch reduzieren und es somit wahrscheinlicher machen, dass Sie diese tatsächlich kontinuierlich für künftige Releases aktualisieren können und wollen.

Der einzige Wermutstropfen dabei ist, dass nur wenige Testdokumentations-Anwendungen Tests standardmäßig auf diese Weise dokumentieren können. Sie gehen vom atomaren Dokumentationsmodell aus, da dieses leider der Standard ist, und bieten deshalb keine eingebauten Funktionen, das hier beschriebene objektorientierte Modell einfach abzubilden. 

Deshalb habe ich oft auf viel weniger ausgefeilte Anwendungslösungen zurückgegriffen – wie Excel – die dafür tatsächlich wesentlich flexibler und leichter anzupassen sind, weil es sich um universelle Werkzeuge handelt. Der Nachteil dieser Strategie ist allerdings, dass die Integration mit Jira & Co. umständlich wird. Aber vielleicht wird Integration auch überschätzt.

Jedenfalls bleibt die Tatsache bestehen, dass viele Anwendungen zur Test- und Fehlerdokumentation es geradezu teuflisch schwer machen, Massenänderungen an einzelnen Einträgen vorzunehmen. Unabhängig davon, welche Protokolle Sie für deren Erstellung nutzen. Aber das ist ganz gleich, wie Sie Ihre Testdokumentation verfassen. Immer schön ein Problem nach dem anderen, Leute.

Ich entschuldige mich gleich im Voraus (oder in Ihrem Fall schon jetzt rückblickend), dass ich Ihnen keine Vorlage für Testobjekte gebe. Meiner Erfahrung nach ist es meist keine gute Idee, Vorlagen bereitzustellen, weil die Leute einfach mit Ihrer Vorlage arbeiten. Die Verfügbarkeit von fertigen, generischen Vorlagen verhindert und hemmt meist die Kreativität des Teams, eine eigene Vorlage zu entwickeln, die zu den tatsächlichen Anforderungen, Prozessen und Werkzeugen vor Ort passt. Also bitte nicht böse sein.

Ich bin immer offen für Ihre Fragen und Anregungen. Schreiben Sie mir einfach oder schicken Sie mir eine Nachricht auf LinkedIn.

Und wie immer: Viel Erfolg!