Führung im Test: Dokumentation

Paul Gerrard

on Feb 3, 2026

QUICK SUMMARY

Hinweis der Redaktion: Willkommen zur Reihe „Leadership in Test“ von Softwaretest-Guru und Berater Paul Gerrard. Die Serie soll Testern mit einigen Jahren Erfahrung – insbesondere in agilen Teams – helfen, als Testleiter oder Manager erfolgreich zu sein. Im vorherigen Artikel haben wir ein Risikomanifest für Manager skizziert. In diesem Artikel stellen wir die altbewährte Frage […]

TABLE OF CONTENTS Der Wert von Dokumentation Die Gefahren von Vorlagen und Copy/Paste Arten der Testdokumentation Empfehlungen zur Gestaltung von Dokumentation

Hinweis der Redaktion: Willkommen zur Reihe „Leadership in Test“ von Softwaretest-Guru und Berater Paul Gerrard. Die Serie soll Testern mit einigen Jahren Erfahrung – insbesondere in agilen Teams – helfen, als Testleiter oder Manager erfolgreich zu sein.

Im vorherigen Artikel haben wir ein Risikomanifest für Manager skizziert. In diesem Artikel stellen wir die altbewährte Frage „Wie viel Testen ist genug?“. Spoiler: Das entscheiden die Stakeholder.

Melden Sie sich für den Newsletter The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Serie erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test-Kurs, den wir sehr empfehlen, um tiefer in dieses und andere Themen einzusteigen. Und das Beste: Wenn Sie unseren exklusiven Gutscheincode QALEADOFFER verwenden, erhalten Sie $60 Rabatt auf den vollständigen Kurspreis!

Unabhängig von Projekt, Unternehmen oder Methode – für Dokumentation gibt es immer einen Platz. Gute Dokumentation ist ein Segen, denn sie liefert eine nützliche Aufzeichnung von Vorgehen, Umfang, Plänen, Designs sowie Ergebnissen von Analyse-, Entwicklungs- und Testaktivitäten.

In diesem Artikel gehe ich auf Folgendes ein:

Der Wert von Dokumentation
Die Tücken von Vorlagen und Kopieren/Einfügen
Arten von Testdokumentation
Tipps für die Gestaltung von Dokumentation

Los geht's.

Der Wert von Dokumentation

In strukturierten Projekten gelten Dokumente in der Regel als eigene Liefergegenstände. In agilen oder kontinuierlichen Ansätzen entsteht Dokumentation dagegen oftmals als Nebenprodukt – mit mehr oder weniger Wert.

Das Verfassen von Dokumenten mag die Hauptaufgabe professioneller Technischer Redakteure sein, für die meisten Fachleute jedoch ist es eine lästige Pflicht – ganz gleich, wie hilfreich es sein mag. Auch wenn das Schreiben von Dokumenten für manche Menschen langweilig ist: Das eigentliche Problem ist, dass die meisten Dokumentationen in vielen Zusammenhängen schlicht Zeitverschwendung sind. Sie sind wenig wert, veraltet, ungenau – oder alles zusammen.

Jeder Testmanager hat schon einmal Teststrategien erstellt, die niemand gelesen oder akzeptiert hat. Tester schreiben seitenweise Testpläne, -skripte und -berichte, und der einzige für Stakeholder wertvolle Inhalt sind die einseitigen Zusammenfassungen am Anfang oder Ende.

Wir haben alle schon Dokumente verfasst, von denen wir wissen, dass sie wenig wert sind und niemand lesen wird.

Das liegt an gängigen Problemen mit Dokumenten, die uns in großen wie kleinen Projekten begegnen. Für jedes Dokument, das wir schreiben, sollten wir uns mehrere Fragen stellen:

Welche Art von Dokument? Eine Richtlinie oder Strategie, ein Ansatz oder Plan, ein Design oder eine Umsetzung, ein Ergebnis und eine Interpretation?
Welches Ziel verfolgt das Dokument?
Welche Inhalte sind nötig, um dieses Ziel zu erreichen?
Welche Wissensquellen werden benötigt, um die Inhalte zu erstellen?
Falls das Dokument sich im Laufe der Zeit ändern muss: Wie wird es gepflegt?
Welcher Detaillierungsgrad ist erforderlich?

Als Testmanager oder Team müssen Sie entscheiden, welche Arten und Formate von Dokumenten geeignet sind – und, falls sie als genaue Aufzeichnungen oder sogenannte „lebende“ Dokumente dienen sollen, wie sie gepflegt werden.

Die Tücken von Vorlagen und Kopieren/Einfügen

Wenn Ihr Projekt festlegt, dass ein bestimmtes Dokument – beispielsweise ein Systemtestplan oder ein Risikoregister – benötigt wird, ist es verlockend, eine passende Vorlage (oder eine von vielen anderen Dokumentarten) im Internet zu suchen.

Manche Vorlagen behaupten, einer bestimmten Norm oder Konvention zu entsprechen, und wurden angeblich schon tausendfach heruntergeladen und genutzt. Mitunter scheint eine Vorlage perfekt auf den eigenen Zweck zu passen. Aber – wie wir sehen werden – selbst wenn das Inhaltsverzeichnis umfassend wirkt, kann es zu Problemen führen.

Es kann auch vorkommen, dass Sie oder andere in Ihrer Firma bereits für ein früheres Projekt ein ähnliches Dokument erstellt haben. Es ist dann verlockend, dieses zu kopieren, umzubenennen, die Projektreferenzen zu ändern und den Inhalt entsprechend anzupassen.

Warnung: Aus meiner Erfahrung als unabhängiger Reviewer ist das sehr verbreitet – und häufig ein echtes Problem.

Zunächst einmal ist meistens sofort offensichtlich, dass ein Text kopiert oder bearbeitet wurde. Die Sprache im Text wirkt oft vom Projekt losgelöst und es gibt überall Lücken und überflüssigen Text. Woran liegt das?

Die Nutzung einer vorgefertigten Vorlage oder eines bestehenden Dokuments als Quelle birgt verschiedene Risiken:

Es wirkt umfassend, könnte jedoch Themen enthalten, die unpassend sind, sowie andere ausschließen, die wesentlich sind.
Es liefert Überschriften für ein Dokument, gibt aber keinerlei Hinweise dazu, 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 – doch dieser Text könnte einen falschen Eindruck vermitteln oder ungenau oder unvollständig sein.

Vorlagen können dabei helfen, Überschriften und das grundlegende Layout zu bekommen, doch das Hauptproblem an Vorlagen ist folgendes:

*Das Verwenden einer Vorlage kann zwar etwas Zeit sparen; das Risiko besteht jedoch darin, dass Sie nicht genügend über das Schreiben nachdenken.*

Die Versuchung bei Vorlagen ist, ihnen zu sehr zu vertrauen und dann bedeutungslose Fülltexte für einzelne Abschnitte zu schreiben. Schließlich könnten Sie denken, das Dokument erfülle nur eine ‚Pflichtübung‘ und niemand wird es tatsächlich lesen. Das Risiko bei Vorlagen ist, dass Sie aufhören nachzudenken und ein Dokument schreiben, das wenig Mehrwert besitzt.

Arten der Testdokumentation

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

Die wichtigsten Testdokumente lassen sich in die folgenden Kategorien einteilen:

Richtlinie und Strategie (manchmal bekannt als Master-Testplan)
Testdefinition (auch als Spezifikation oder Testpläne bezeichnet, was gelegentlich verwirrend ist)
Testentwurf
Testfälle
Testverfahren oder -skripte
Testdurchführung
Planung
Protokoll
Testbericht

Die oben genannten Dokumentenarten decken die Definition des Testprozesses, die Schlüsseltätigkeiten Definition und Ausführung sowie die Berichterstattung ab.

In stärker bürokratischen Umgebungen gibt es noch weitere testbezogene Dokumente, die beispielsweise Testumgebungsdefinitionen und -managementprozesse, Abnahmeverfahren, Prozesse zum Störfallmanagement und dergleichen umfassen können (auf das Störfallmanagement werden wir in einem zukünftigen Artikel noch eingehen).

Ein weiterer offensichtlicher Punkt, der oben fehlt, wäre ein Gesamtplan bzw. Zeitplan für die Testaktivitäten. Ein Zeitplan ist allerdings kein wirkliches Testdokument, sondern meist ein Teil eines übergeordneten Projektplans in einem strukturierten Projekt (auch zur Zeitplanerstellung werden wir in einem späteren Artikel noch etwas schreiben – also bleiben Sie dran!).

Richtlinie, Strategie, Master-Testplan

*Zweck*	Eine Richtlinie deckt in der Regel eine Organisation ab und umfasst eine Teilmenge von Themen, die alle Projekte abdecken. Eine Strategie bezieht sich normalerweise auf ein einzelnes Projekt (oder eine Anwendung) Insgesamt liefert die Strategie getroffene Entscheidungen zu logistischen Fragen bezüglich Vorgehen, Übergaben, Verantwortlichkeiten, Umgebungen usw. Einige dieser Entscheidungen können im Voraus getroffen und in der Strategie dokumentiert werden Einige Entscheidungen können jetzt noch nicht getroffen werden, aber die Strategie kann den Prozess, die Methode oder die Informationen dokumentieren, die es ermöglichen, Entscheidungen (im Projekt) zu treffen Für unsichere Situationen oder ungeplante Ereignisse, in denen Entscheidungen zu treffen sind, dokumentiert die Strategie die allgemeinen Prinzipien (oder den Prozess), denen zu folgen ist.
*Inhalt*	Stakeholder, Ziele, wichtigste Risiken Testprinzipien/Vorgehen, die übernommen werden sollen, z.B. risikobasierter Testansatz Testprozess (Phasen des Testens): Ziele und Geltungsbereich Abnahmekriterien Methoden, Techniken Liefergegenstände (Dokumente) Verantwortlichkeiten Nicht-funktionale/technische Testaktivitäten (Test-)Lieferantenmanagement-Richtlinie Vorfallmanagementprozess Quellen für Testdaten Testumgebungen Tools/Automatisierungsstrategie Dokumentationsformate/-vorlagen
*Quellen*	Stakeholder, Anwender, BAs, Entwickler, Betrieb
*Wartung*	In der Regel ein Einmaldokument, das für ein Projekt oder Programm definiert ist
*Agile/kontinuierliche Betrachtungen* Die Teststrategie für agile Projekte, die beispielsweise Scrum verwenden, ist wahrscheinlich recht knapp und umfasst nur wenige Seiten (sofern sie überhaupt dokumentiert wird). Der Testprozess hat möglicherweise keine Phasen, aber es gibt wahrscheinlich eine Definition von Tests auf verschiedenen Ebenen. Zum Beispiel: Testen in einem Sprint oder einer Iteration Testen einer Freigabe Systemintegrationstests (mit anderen Systemen oder Schnittstellen) Anwender-Tests (im Sprint und/oder auf Release-Ebene). Wie Tools beim Entwicklertesten verwendet werden (und z.B. die Nutzung von BDD oder TDD), wird wahrscheinlich nicht dokumentiert, aber es wird erwartet, dass Entwicklungsteams ein Vorgehen entwickeln und sich mit anderen Teammitgliedern abstimmen, wenn sie neuen Code einchecken. Die Rolle von Testern könnte darin bestehen, Features interaktiv zu testen, sobald sie von Entwicklern bereitgestellt werden, oder als Testcoach für das restliche Team zu agieren. Wie bei der Verwendung von Tools und/oder TDD würde sich die Arbeitsweise im Laufe der Zeit weiterentwickeln und möglicherweise niemals formell dokumentiert werden.

Testdefinition (Entwurf, Fälle, Verfahren)

*Zweck*	Um den Ablauf oder die Nachvollziehbarkeit zwischen Wissensquellen und den durchzuführenden Tests darzustellen Um die Abdeckung (gegenüber mehreren Modellen) von Aspekten der Anforderungen, Systemfunktionen oder des Benutzerverhaltens zu dokumentieren Um es Stakeholdern zu ermöglichen, Umfang, Vorgehen, Abdeckung und getroffene Entscheidungen bei der Erstellung der durchzuführenden Tests zu prüfen Um Anweisungen für die Durchführung von Tests auf einem vorher vereinbarten Detailgrad bereitzustellen.
*Inhalt*	Testumfang – sowohl auf hoher Ebene (z.B. Features) als auch auf niedrigerer Ebene (z.B. Verhaltensmodelle) Abdeckung der Tests im Vergleich zu den Punkten im Scope (z.B. eine Anforderungsabdeckungsmatrix oder ein anderes Testmodell) Testfälle, die Funktionen, Vorbedingungen, Eingaben und Nachbedingungen (einschließlich erwarteter Ergebnisse) identifizieren Testverfahren, die zur Ausführung ausgewählter Testfälle wiederverwendbar sind.
*Quellen*	Stakeholder, Benutzer, Anforderungen, Designs und Spezifikationen
*Wartung*	Grundsätzlich sollte es bei festen Anforderungen eine abgestimmte Version dieser Dokumente geben Wo sich Anforderungen oder Scope ändern, müssen Tester die Dokumente anpassen, die nachverfolgbaren Aspekte der Dokumentation pflegen und ein Konfigurationsmanagement oder Änderungsprotokoll bereitstellen.
*Agile/kontinuierliche Betrachtungen* Der Bereich der Testdefinition unterscheidet sich im agilen Ansatz am deutlichsten von strukturierten Projekten. Testende, die sich auf Features konzentrieren, sobald sie geliefert werden, könnten möglicherweise gar keine Dokumentation erstellen. Dies ist angemessen, wenn es beispielsweise eine systemweite Richtlinie oder Charta für Feature-Testing gibt. Wahrscheinlicher ist jedoch, dass es für jedes Feature eine kurze Charta für das Testen in einer explorativen Testsitzung gibt. Eine Charta ist wie ein Plan für einen kurzen Zeitraum der Erkundung. Die Charta würde typischerweise Folgendes identifizieren: Den Umfang der Testsitzung – die abzudeckenden Features und/oder eine bestimmte Funktionalität oder ein bestimmtes Verhalten des Systems Das Ziel der Sitzung – bestimmte Aspekte des Verhaltens zu erforschen, sich auf ein Risiko oder einen Ausfallmodus zu konzentrieren, ausgewählte Szenarien anzuwenden Die Dauer der Sitzung liegt typischerweise zwischen 45–120 Minuten. Die Sitzung ist zwangsläufig im Umfang begrenzt, jedoch steht es Testenden frei, den Scope zu überschreiten, wenn sie dies für wertvoll erachten Eine Charta kann darauf abzielen, die Erkundung in den Fokus zu nehmen – um herauszufinden, was ein Feature tut, um bestimmte prüfenswerte Verhaltensweisen zu identifizieren, um zu bewerten, wie viel Testing/wie viele Sitzungen für ein großes oder komplexes Feature benötigt werden, um zu verstehen, welche Testdaten benötigt werden könnten usw. Eine Charta kann sich speziell auf das Testen eines Features konzentrieren, dabei aber Bereiche hervorheben, die mehr Aufmerksamkeit erfordern als andere. BDD-Tools und Stories in einem ausgewählten Format, z.B. Cucumber- oder Gherkin-formatierte Stories und Szenarien, können die Nachvollziehbarkeit und den Inhalt liefern, die Testentwürfe und -verfahren sonst hätten. Jedes Szenario mit den Klauseln „gegeben/wenn/dann" identifiziert Vorbedingungen, Eingaben und Nachbedingungen. Sie beziehen sich jeweils auf ein einzelnes Feature und bilden damit einen minimalen Testfall/-ablauf und sind mindestens auf Features rückverfolgbar. Tests, die für die Ausführung durch Tools geskriptet wurden, können eine Zwischendokumentation haben oder auch nicht. Teams verlassen sich mehr auf die Beobachtung automatisierter Tests und die Testdaten-Tabellen automatisierter Skripte als auf dokumentierte Testentwürfe.

Testausführung (Planung, Protokoll)

*Zweck*	Festlegung der Reihenfolge, in der Tests durchgeführt werden Erfassung des Teststatus – durchgeführt/nicht durchgeführt und Status Bereitstellung der Testergebnisse für das Reporting
*Inhalt*	Testkennzeichen, Tester, Datum/Uhrzeit der Ausführung, Status Für Tests, die ein anomales Verhalten zeigen (optional): Details des durchgeführten Tests, sofern sie vom Skript abweichen Tatsächliche vs. erwartete Ergebnisse Weitere Beobachtungen, Interpretation Teststatus (Fehler, Setup- oder Umgebungsanomalie etc.) Beobachtungs- oder Fehlerbericht-ID (sofern zutreffend)
*Quellen*	Testfall-/Verfahrensverzeichnis, Tester
*Pflege*	Der Zeitplan ändert sich parallel zum Umfang der Tests und den Verfahren, die im Plan angepasst, entfernt oder hinzugefügt werden. Tests werden in der Regel mehrfach als Wiederholungs- oder Regressionstests durchgeführt. Das Protokoll sollte eine vollständige Historie aller relevanten Tests enthalten.
*Agile/Kontinuierliche Überlegungen* Wenn agile/kontinuierliche Projekte keine Test-Definitionsdokumente erstellen, gleichen sie dies teilweise dadurch aus, dass Tester angehalten werden, bessere Protokolle der Testdurchführung zu führen. Wenn das Testen in Sessions anhand von Testaufträgen erfolgt, wird vom Tester erwartet, dass er aussagekräftige Notizen zu den durchgeführten Tests anlegt. Es gibt nur wenige spezielle Testprotokollierungswerkzeuge, die mehr als einfache Notizbücher bieten; daher verwenden viele Tester einfache Texteditoren, Notizzettel oder Papiernotizbücher. Protokolle werden häufig genutzt, um alle wichtigen Aktivitäten und Beobachtungen während der Ausführung festzuhalten. Ein typisches Exploratives-Testprotokoll kann folgende Aspekte enthalten: Struktur der untersuchten Funktionen (eine Karte des Bereichs) Beobachtungen, Fragen zu untersuchten Funktionen während der Session Modelle, Listen, Tabellen der Testobjekte und Testideen Ausgeführte Tests, in ausreichendem Detail dokumentiert, um sie reproduzieren zu können Gefundene Anomalien – Fehler, fragwürdiges Verhalten, langsame Reaktionen, schlechte Nutzererfahrung usw. Verbrauchte Zeit für Exploration, Testaufbau, Testen, Untersuchung, Fehlerprotokollierung, Wiederholungstests, Regressionstests, unproduktive Zeit Datum/Uhrzeit der Eintragung Protokollieren Tester ihre Session-Aktivitäten in Notiz- oder anderen Tools, verwenden sie eine eigene Markup- oder Domänensprache, um ihre Notizen zu strukturieren. Diese können von einfachen internen Tools analysiert werden, um Zusammenfassungen der Aktivitäten für den Testbericht bereitzustellen. Tests, die von Werkzeugen (ob proprietär oder Open Source) ausgeführt werden, protokollieren automatisch. In der Regel sind diese Protokolle durch das Werkzeug oder benutzerdefinierte Prozeduren abfragbar.

Testbericht

*Zweck*	Um das Ergebnis einer Testphase, ausgewählter Tests oder einer Testsitzung zu kommunizieren Kann auch auf technische Anforderungen oder nicht-funktionale Testaktivitäten zutreffen, wobei sich der Inhalt entsprechend dem Testziel unterscheidet Um Stakeholder teilweise zu informieren und ihnen die Möglichkeit zu geben, eine Entscheidung zur Abnahme oder Freigabe eines Systems oder Subsystems zu treffen.
*Inhalt*	Testbeginn/-ende und Dauer Testumgebung Software- und Systemversion(en) im Test Ziele und Umfang der Tests (aus Teststrategie, Testdefinition) Erzählender Ergebnisbericht Funktionen, die als funktionsfähig bewertet werden Risiken, die als adressiert betrachtet werden Offene, wichtige Tests (fehlgeschlagen oder blockiert) Funktionen teilweise oder gar nicht getestet Risiken teilweise oder nicht adressiert Testdetailergebnisse mit Ausgaben aus Testprotokollen usw. Status von Umgehungslösungen für offene Anomalien Testanalysen Testfortschritt und Status im Zeitverlauf Vorfallstatistiken
*Quellen*	Teststrategie, Testdefinitionen, Testprotokoll, Fehlerberichte Ein Großteil des Inhalts eines Testberichts wird durch die eingesetzten Werkzeuge zur Aufzeichnung von Testdefinition(en), Testprotokoll und Fehler- oder Defektprotokoll bestimmt.
*Pflege*	Dies stellt eine Momentaufnahme einer Testausführungsphase dar und wird nicht fortlaufend 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 Systemabnahme beziehen. In jedem Fall bleibt der Zweck unverändert. Ein Großteil des Inhalts eines Testberichts stammt aus Werkzeugen oder Notizen der Tester. Die erzählende Zusammenfassung der Ergebnisse wird von einem Testleiter oder – bei kleineren Testphasen – vom Tester selbst verfasst. Wie üblich wird der Bericht vermutlich weniger formell sein und es werden wahrscheinlich weniger Rohdaten vorliegen, die Grundlage für ausgefeilte Analysen sein könnten. Sicherlich kann während der Iteration(en) der Fortschritt hinsichtlich ausgelieferter, getesteter und durch Benutzer akzeptierter Features oder Stories in einem Tool oder auf einem öffentlichen KanBan-Board erfasst werden. Auf diese Weise bleiben die Stakeholder während der Iteration stets über den Fortschritt informiert, und es wird weniger Bedarf für einen formellen Bericht am Ende eines Testzeitraums geben. Die Sichtbarkeit des Fortschritts ist ein zentrales Anliegen für agile Teams. Mit regelmäßigen, vielleicht täglichen Stand-ups etwa an einem Scrum-Board teilen die Teammitglieder ihre Sicht auf den Fortschritt, stellen gegenseitig Fragen und einigen sich kontinuierlich auf eine Position (und nächste Schritte). So kann ein formeller Testbericht unter Umständen entfallen, da das Team immer informiert und auf dem neuesten Stand ist. Wenn die Tester schriftliche Notizen zu ihren Sitzungsaktivitäten anfertigen, stehen keine analysierbaren Daten für automatisierte Berichte zur Verfügung, sodass Sitzungs- und Fortschrittsberichte visuell und öffentlich präsentiert werden könnten. Das erfordert hohe Disziplin und gute Kommunikationsfähigkeiten seitens der Tester. Der Testleiter oder Manager muss daraufhin einen entsprechend informativen Bericht für Stakeholder auf Basis mündlicher Berichte erstellen.

Einige Hinweise

Das Thema Dokumentation in Projekten ist für Tester wie auch für andere Projektteammitglieder ein sensibles Thema.

Die meisten Menschen empfinden das Schreiben von Dokumentation als lästige Pflicht.

Hier ein paar Dinge, die Sie bei der Gestaltung Ihrer Dokumentation berücksichtigen sollten.

Dokumentation muss einen klar definierten Zweck und eine Zielgruppe haben. Wenn Ihre Zielgruppe die Dokumentation nicht benötigt, wird sie diese nicht lesen. Wenn sie nicht zu deren Zielen passt, werden sie sich nicht einbringen.
Es ist in der Regel besser, eine Aktivität zu dokumentieren, bevor oder während sie durchgeführt wird. TDD dokumentiert zum Beispiel Tests, bevor Code geschrieben wird. Testprotokolle sollten während der Sitzung aufgezeichnet und nicht nachträglich erstellt werden.
Die wesentlichen Daten, um einen Aspekt des Testens zu dokumentieren, können minimal sein. Ein Test, der im Notizbuch festgehalten wird, mag dem Tester genügen, lässt sich aber nicht einfach auswerten. Möglicherweise wäre ein einfaches Textprotokoll mit etwas Markup genauso schnell zu erfassen und könnte zudem mit einem individuellen Tool ausgewertet werden.
Detaillierte Testprozeduren sind eventuell gar nicht notwendig, wenn die Tester das zu testende System gut kennen. Vielleicht genügt nur ein Testziel oder ein Testauftrag. Vorgefertigte Testfälle können minimal in einer Tabelle dokumentiert werden.

Abschließend

Not macht erfinderisch – auch bei der Dokumentation.

Wenn Sie für Ihre Stakeholder umfassende Dokumentation erstellen und diese nicht gelesen wird, liegt es daran, dass sie den Nutzen darin nicht erkennen.

Es ist besser, einem Stakeholder ein leeres Blatt Papier hinzulegen und gemeinsam die Themen hinzuzufügen, die für ihn relevant sind. Vielleicht fordert er seitenweise Inhalt, doch was wirklich benötigt wird, ist oft recht einfach. Fragen Sie immer wieder: „Warum möchte er das?“

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

Melden Sie sich für den Newsletter von The QA Lead 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 sehr empfehlen, um tiefer in dieses und andere Themen einzutauchen. Wenn Sie sich anmelden, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER und sparen Sie $60 auf den regulären Kurspreis!

Want more from The CTO Club?