Führung im Test: Dokumentation

Der Wert von Dokumentation

In strukturierten Projekten werden Dokumente üblicherweise als eigenständige Liefergegenstände betrachtet. In agilen oder kontinuierlichen Ansätzen kann Dokumentation eher als Nebenprodukt mit mehr oder weniger Nutzen entstehen.

Das Schreiben von Dokumenten ist vielleicht die Hauptaufgabe professioneller technischer Redakteure, doch für die meisten Praktiker ist es eine lästige Pflicht – so nützlich es auch sein mag. Obwohl das Verfassen von Dokumenten für manche langweilig sein mag, liegt das eigentliche Problem darin, dass in vielen Fällen die meisten Dokumente schlicht Zeitverschwendung sind. Sie haben wenig Mehrwert, sind veraltet, ungenau – oder alles zusammen.

Jeder Testmanager hat einmal Teststrategien verfasst, die niemand gelesen oder akzeptiert hat. Tester schreiben Unmengen an Testplänen, -skripten und -berichten, aber der einzige für Stakeholder relevante Inhalt sind die einseitigen Zusammenfassungen am Anfang oder Ende.

Das liegt an häufigen Problemen mit der Dokumentation, denen wir in großen wie kleinen Projekten begegnen. Für jedes Dokument, das wir schreiben, gibt es mehrere Fragen, die wir uns stellen müssen:

• Welche Art von Dokument? Eine Richtlinie oder Strategie, ein Ansatz oder Plan, ein Design oder eine Implementierung, oder ein Ergebnis und dessen Bewertung?
• Welches Ziel verfolgt das Dokument?
• Welche Inhalte sind notwendig, um das Ziel zu erreichen?
• Welche Wissensquellen werden für die Erstellung der Inhalte benötigt?
• Wenn das Dokument sich im Zeitverlauf ändern soll, wie wird es gepflegt?
• Welcher Detaillierungsgrad ist erforderlich?

WERDE TEIL DER COMMUNITY

Bereichern Sie Ihren Posteingang mit mehr Führungserkenntnissen aus der Tech-Welt für bessere Software und Systeme.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Die Risiken von Vorlagen und Copy/Paste

Wenn euer Projekt festlegt, dass ein bestimmtes Dokument – z.B. ein Systemtestplan oder ein Risikoregister – benötigt wird, ist es verlockend, im Internet nach einer passenden Vorlage dafür (oder für viele anderen Dokumententypen) zu suchen.

Manche Vorlagen berufen sich darauf, einem bestimmten Standard oder einer Konvention zu entsprechen und schon tausendfach heruntergeladen und verwendet worden zu sein. Mitunter scheint eine Vorlage exakt auf euren Zweck zugeschnitten zu sein. Aber, wie wir sehen werden: Selbst wenn das Inhaltsverzeichnis umfassend wirkt, kann euch das Schwierigkeiten bereiten.

Es kann auch sein, dass ihr oder andere in eurem Unternehmen bereits ähnliche Dokumente für frühere Projekte erstellt habt. Es ist dann verlockend, das alte Dokument zu kopieren und umzubenennen, die Referenzen auf das alte Projekt zu ändern und den Inhalt entsprechend anzupassen.

Achtung: Nach meiner Erfahrung als unabhängiger Prüfer ist das sehr weit verbreitet – und oft ein echtes Problem. 

Zunächst einmal ist es meist offensichtlich, dass eine Kopie oder Überarbeitung vorgenommen wurde. Die Sprache im Text wirkt oft vom Projekt losgelöst, es gibt Lücken und überflüssige Textpassagen überall. Woran liegt das?

Die Verwendung einer vorgefertigten Vorlage oder eines bestehenden Dokuments als Quelle birgt mehrere Risiken:

• Es wirkt umfassend, kann jedoch Themen enthalten, die unpassend sind, und andere, die wesentlich sind, auslassen.
• Es liefert Überschriften für ein Dokument, aber keinerlei Hinweise darauf, welcher Inhalt für die jeweiligen Überschriften geeignet ist.
• Es könnte Text enthalten, der wiederverwendbar aussieht und unverändert aus einem vorherigen, nicht zusammenhängenden Projekt kopiert wurde, aber dieser Text kann einen falschen Eindruck vermitteln oder ungenau bzw. unvollständig sein.

Vorlagen können hilfreich sein, um Überschriften und grundlegendes Layout zu erhalten, aber das Hauptproblem mit Vorlagen ist folgendes:

Die Versuchung bei Vorlagen besteht darin, ihnen zu sehr zu vertrauen und dann für die verschiedenen Abschnitte leeres Gerede zu schreiben. Schließlich könnten Sie denken, das Dokument erfülle einfach eine „Pflichtaufgabe“ und niemand wird es sowieso lesen. Das Risiko von Vorlagen besteht darin, dass man aufhört nachzudenken und ein Dokument erstellt, das wenig Mehrwert bietet.

Arten von Testdokumentation

In diesem Abschnitt betrachten wir die verschiedenen Formen der Testdokumentation und besprechen einige Überlegungen in strukturierten oder agilen/kontinuierlichen Projekten im Vergleich zum traditionellen Wasserfallmodell. 

Der grundlegende Satz an Testdokumenten fällt typischerweise in folgende Kategorien:

• Richtlinien und Strategie (manchmal auch als Master-Testplan bezeichnet)
• Testdefinition (auch Spezifikation oder Testpläne genannt, was verwirrend sein kann)
• Testdesign
• Testfälle
• Testverfahren oder -skripte
• Testdurchführung
• Zeitplan
• Protokoll
• Testbericht

Die oben genannten Dokumenttypen decken die Definition des Testprozesses, die wichtigsten Aktivitäten der Definition und Durchführung sowie die Berichterstattung ab. 

Es gibt noch mehrere andere testbezogene Dokumente, die in bürokratischeren Umgebungen beispielsweise Testumgebungsdefinitionen und -verwaltungsprozesse, Abnahmeverfahren, Prozesse zum Incident Management und so weiter umfassen würden (auf das Incident Management gehen wir in einem späteren Artikel noch ein).

Eine weitere offensichtliche Auslassung in der obigen Liste ist ein Gesamtplan oder Zeitplan für Testaktivitäten. Ein Zeitplan ist streng genommen kein Testdokument, sondern ein Teilaspekt eines Gesamtprojektplans für ein strukturiertes Projekt (auch zur Zeitplanplanung wird es einen eigenen Artikel geben – bleiben Sie gespannt!).

Richtlinie, Strategie, Master-Testplan

Testdurchführung (Planung, Protokoll)

Zweck	Um die Reihenfolge der Testdurchführung festzulegen Um den Status der Tests – ausgeführt/nicht ausgeführt und Status – zu protokollieren Um die Testergebnisse zur Berichterstattung bereitzustellen
Inhalt	Testkennung, Tester, Datum/Uhrzeit der Ausführung, Status Für Tests, die anomales Verhalten aufweisen (optional): Details zum ausgeführten Test, falls diese vom Skript abweichen Tatsächliches versus erwartetes Ergebnis Weitere Beobachtungen, Interpretation Teststatus (Defekt, Konfigurations- oder Umgebungsabweichung usw.) ID des Beobachtungs- oder Defektberichts (falls zutreffend)
Quellen	Testfall-/Testprozeduren-Inventar, Tester
Wartung	Die Planung ändert sich entsprechend dem Umfang der Tests, und Verfahren werden angepasst, entfernt oder dem Plan hinzugefügt. Tests werden wahrscheinlich mehrmals durchgeführt – als Wiederholungstests oder Regressionstests. Das Protokoll sollte eine vollständige Historie aller im Umfang enthaltenen Tests aufbewahren.
Agile/Kontinuierliche Gesichtspunkte Falls bei agilen/kontinuierlichen Projekten auf Testdefinitionsdokumente verzichtet wird, wird dies teilweise dadurch ausgeglichen, dass Tester dazu angeregt werden, bessere Protokolle zur Testdurchführung zu führen. Finden Tests in Sessions anhand von Testaufträgen (Charters) statt, wird von den Testern erwartet, dass sie sorgfältige Notizen zu den durchgeführten Tests machen. Es gibt nur wenige spezialisierte Testprotokollierungswerkzeuge, die mehr als Notizbücher sind, sodass viele Tester einfache Texteditoren, Notiz-Apps oder Papiernotizbücher nutzen. Protokolle dienen dazu, sämtliche relevante Aktivitäten und Beobachtungen während der Sessions festzuhalten. Ein typisches Protokoll für exploratives Testen würde Aspekte enthalten wie: Struktur der untersuchten Funktionen (eine Übersicht über das "Testgebiet") Beobachtungen und Fragen zu den im Test behandelten Funktionen Modelle, Listen, Tabellen mit Testobjekten und Testideen Durchgeführte Tests, in ausreichender Detailtiefe dokumentiert, um sie reproduzieren zu können Festgestellte Unregelmäßigkeiten – Fehler, fragwürdiges Verhalten, langsame Antwortzeiten, schlechte Benutzererfahrung usw. Aufgewendete Zeiten für Erkundung, Testaufbau, Testdurchführung, Analysen, Fehlerprotokollierung, erneutes Testen, Regressionstests, unproduktive Zeit Datum/Uhrzeit des Eintrags Wenn Tester ihre Sessions in Notizen oder anderen Werkzeugen protokollieren, verwenden sie häufig eigene Auszeichnungen oder andere domänenspezifische Sprachen zur Strukturierung. Diese können von einfachen Eigenbau-Werkzeugen verarbeitet werden, um Zusammenfassungen für das Testberichtswesen zu erstellen. Durch Werkzeuge (proprietär oder Open-Source) durchgeführte Tests werden automatisch protokolliert. In der Regel können diese Protokolle vom Werkzeug selbst oder durch benutzerdefinierte Abfragen ausgewertet werden.

Testbericht

Zweck	Um das Ergebnis einer Testphase, ausgewählter Tests oder einer Testsitzung zu kommunizieren Kann sich auch auf technische Anforderungen oder nicht-funktionale Testaktivitäten beziehen; in diesem Fall würde sich der Inhalt an das Testziel anpassen Um Stakeholder zumindest teilweise zu informieren und ihnen so eine Entscheidungsgrundlage zur Akzeptanz oder Freigabe eines Systems oder Teilsystems zu geben.
Inhalt	Teststart/-endzeiten und -dauer Testumgebung Getestete Software- und Systemversion(en) Ziele und Umfang des Testings (aus Teststrategie, Testdefinition) Erzählende Zusammenfassung der Ergebnisse Als funktionierend beurteilte Funktionen Als behoben geltende Risiken Wesentliche, noch ausstehende Tests (fehlgeschlagen oder blockiert) Teilweise oder gar nicht getestete Funktionen Teilweise oder nicht angegangene Risiken Details der Testergebnisse mit Ausgaben aus Testprotokollen etc. Status von Workarounds für offene Anomalien Testanalysen Testfortschritt und Status im Zeitverlauf Statistiken zu Vorfällen
Quellen	Teststrategie, Testdefinitionen, Testprotokoll, Vorfallberichte Ein Großteil des Inhalts eines Testberichts stammt aus den zur Aufzeichnung der Testdefinition(en), des Testprotokolls und des Vorfall- bzw. Fehlerprotokolls verwendeten Tools.
Wartung	Dies ist eine Momentaufnahme einer Testdurchführungsphase und wird nicht gepflegt.
Agile/Kontinuierliche Überlegungen Der Zweck eines Testberichts in einem agilen Projekt kann sich auf eine einzelne Iteration oder einen Sprint, das Testen für ein Release oder eine übergeordnete Testphase wie Integration oder Gesamtsystemabnahme beziehen. In jedem Fall bleibt der Zweck unverändert. Ein Großteil des Inhalts eines Testberichts stammt aus Tools oder Notizen von Testern. Die erzählende Zusammenfassung der Ergebnisse wird von einem Testleiter oder dem Tester für eine kleinere Testphase verfasst. Wie üblich wird der Bericht wahrscheinlich weniger formell sein und es gibt vermutlich weniger Rohdaten, die die Grundlage für detaillierte Analysen bilden könnten. Während der Iteration(en) kann der Fortschritt beispielsweise in Form von gelieferten, getesteten und von den Nutzern abgenommenen Features oder Stories in einem Tool oder auf einem öffentlichen Kanban-Board festgehalten werden. Dadurch werden die Stakeholder während der gesamten Iteration über den Fortschritt informiert und ein formeller Bericht am Ende eines Testzeitraums ist weniger nötig. Die Sichtbarkeit des Fortschritts ist ein zentrales Anliegen agiler Teams. Mit regelmäßigen, vielleicht täglichen Stand-Ups beispielsweise an einem Scrum-Board tauschen die Teammitglieder ständig ihren Wissensstand aus, stellen sich gegenseitig Fragen und einigen sich permanent auf einen Status (und nächste Schritte). So kann es sein, dass ein formeller Testbericht nie benötigt wird, weil das Team immer informiert und auf dem aktuellen Stand ist. Wenn die Tester schriftliche Notizen zu ihren Sitzungsaktivitäten festhalten, stehen keine analysierbaren Daten für automatisierte Berichte zur Verfügung, sodass die Sitzungs- und Fortschrittsberichterstattung öffentlich und visuell präsentiert werden könnte. Das erfordert Disziplin und gute Kommunikationsfähigkeiten seitens der Tester. Der Testleiter oder Testmanager muss daraufhin einen entsprechend informativen Bericht für die Stakeholder auf Basis von mündlichen Berichten liefern.

More Articles

• 9 Arten von Softwaretests in der Softwaretechnik
• 5 Arten von Performancetests + Top-Tools
• Softwaretest-Trends: Neueste QA-Technologien, Statistiken & Daten

Einige Tipps

Das Thema Dokumentation in Projekten ist sowohl für Tester als auch andere Projektbeteiligte ein sensibles.

Hier sind einige Dinge, die Sie beim Gestalten Ihrer Dokumentation beachten sollten.

1. Dokumentation muss einen klar definierten Zweck und eine Zielgruppe haben. Wenn Ihre Zielgruppe die Dokumentation nicht benötigt, wird sie sie nicht lesen. Wenn sie nicht zu den eigenen Zielen passt, wird sie nicht akzeptiert.
2. Es ist im Allgemeinen besser, eine Aktivität zu dokumentieren, bevor oder während Sie sie durchführen. Beispielsweise werden bei TDD die Tests geschrieben, bevor der Code entsteht. Test-Session-Protokolle sollten während der Sitzung aufgenommen und nicht nachträglich geschrieben werden.
3. Die wesentlichen Daten, um einen Aspekt des Testens festzuhalten, können minimal sein. Ein im Notizbuch eingetragener Test kann für den Tester ausreichend sein, ist aber kaum auswertbar. Ein einfaches Textprotokoll mit etwas Markup wäre genauso schnell zu erstellen, könnte aber von einem eigens dafür geschriebenen Tool analysiert werden.
4. Testprozeduren sind möglicherweise überhaupt nicht notwendig, wenn die Tester das System gut kennen. Eventuell reicht ein Testziel oder Charter. Vorgefertigte Testfälle können mit minimalem Aufwand z. B. in einer Tabellenkalkulation dokumentiert werden.

Abschließend

Wenn Sie für Ihre Stakeholder eine umfassende Dokumentation vorbereiten und diese sie nicht lesen, liegt es daran, dass sie darin keinen Mehrwert sehen.

Es ist wirkungsvoller, einem Stakeholder erst einmal ein leeres Blatt Papier zu geben und gemeinsam die Themen zu ergänzen, die Sie in einem Dokument sehen möchten. Es kann sein, dass viele Inhalte gefordert werden, aber tatsächlich nur wenig benötigt wird. Fragen Sie immer wieder: 'Warum wird das von ihnen verlangt?'

Danke fürs Lesen, seien Sie beim nächsten Mal wieder dabei, wenn wir die Ärmel hochkrempeln und mit etwas Testplanung starten.

Melden Sie sich für den QA Lead Newsletter an, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir wärmstens empfehlen, wenn Sie tiefer in dieses und andere Themen eintauchen möchten. Falls Sie sich anmelden, verwenden Sie unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie $60 auf den vollen Kurspreis!