Testplan, Testprotokoll und Dokumentation

Die letzten sieben Lektionen haben dir das Handwerkszeug gegeben: Teststufen, Black-Box, White-Box, TDD, Unit-Tests, Mocking. Jetzt kommt etwas Unspektakuläres aber Pflichtbestandteil jeder professionellen Test-Arbeit: Dokumentation. Was du nicht aufschreibst, hast du nicht getestet – aus Sicht der Qualitätssicherung, deines Kunden oder eines Auditors.

Diese Lektion zeigt die drei wichtigsten Dokumente: Testplan (vorab, was wollen wir testen?), Testfall (konkrete Beschreibung eines einzelnen Tests) und Testprotokoll (nachher, was war das Ergebnis?). Wir orientieren uns am IEEE-Standard 829, der in der IHK-Klausur durchaus auftauchen kann.

1) Warum überhaupt Test-Dokumentation?

Wenn du allein an einem Hobby-Projekt arbeitest, brauchst du keine Test-Dokumente. In jedem professionellen Umfeld dagegen ist sie unverzichtbar. Die Gründe:

• Nachweisbarkeit: bei Auditierungen, ISO-Zertifizierungen, in regulierten Branchen (Medizin, Auto, Banken) musst du beweisen können, dass getestet wurde.
• Vertragsabwicklung: das Pflichtenheft definiert, was zu liefern ist – Testprotokolle beweisen die Erfüllung. Wichtig für Abnahme & Zahlung.
• Wissenstransfer: neue Mitarbeiter, Test-Übergabe an externe Firmen, Wartung in 5 Jahren – die Doku ist das Gedächtnis.
• Reproduzierbarkeit: wenn ein Tester einen Bug findet, muss ein Entwickler ihn nachstellen können. Ohne Doku → unlösbarer „klappt bei mir"-Streit.
• Planung & Controlling: was haben wir getestet, was nicht, wo stehen wir, wie viel Zeit brauchen wir noch?

Eine schöne Analogie: Test-Dokumentation ist wie das Logbuch eines Schiffes. Niemand braucht es, solange das Schiff sicher fährt. Wenn aber ein Sturm kommt, ein Audit ansteht oder das Schiff verkauft wird, ist es plötzlich Gold wert.

2) Die Dokument-Hierarchie

Test-Dokumente bilden eine Hierarchie – grob skizziert, basierend auf IEEE 829 (heute ISO/IEC/IEEE 29119):

3) Testplan – das „Wie wollen wir testen?"

Ein Testplan wird vor der Test-Phase erstellt. Er beantwortet: Was wird getestet, von wem, wann, womit, unter welchen Bedingungen? Der IEEE 829-Standard listet folgende Kapitel:

4) Testfall – die konkrete Anweisung

Ein Testfall beschreibt einen einzelnen, ausführbaren Test. Er muss so präzise sein, dass ihn auch jemand anderes (oder du selbst in 6 Monaten) reproduzieren kann. Die klassische Schablone:

5) Testprotokoll – was tatsächlich passiert ist

Das Testprotokoll ist die Ergebnis-Dokumentation. Es entsteht während oder nach der Durchführung. Im einfachsten Fall ist es eine Tabelle:

6) Bug-Report – wenn ein Test fehlschlägt

Bei einem FAIL entsteht ein Bug-Report (Fehlerbericht). Er muss so präzise sein, dass ein Entwickler den Fehler in Minuten reproduzieren kann – nicht in Stunden raten muss, was du gemeint hast. Eine bewährte Struktur:

7) Testplan vs. Testprotokoll – nicht verwechseln

Klausur-Klassiker: was ist der Unterschied?

8) Testabschlussbericht

Am Ende der Test-Phase wird alles in einem Testabschlussbericht zusammengefasst. Er ist die Entscheidungsgrundlage für „Release oder nicht?". Typische Inhalte:

• Test-Umfang: was wurde getestet, was nicht?
• Test-Statistik: Anzahl Tests, Pass-Rate, Coverage-Werte (vgl. L4).
• Offene Fehler: Bugs nach Schwere klassifiziert.
• Bewertung: empfehlen wir das Release oder nicht?
• Risiken: was könnte in Produktion noch schiefgehen?
• Empfehlungen: was sollte vor Live-Gang noch passieren?

Diesen Bericht liest typischerweise der Test-Manager oder Product Owner als Grundlage für die Release-Entscheidung. Bei Konzern-Software auch ein Auditor oder das Management.

9) Best Practices für saubere Test-Dokumentation

• Eindeutige IDs: jeder Testfall, jeder Bug bekommt eine Nummer. Erleichtert Querverweise enorm.
• Versionierung: Test-Dokumente gehören ins Git, mit dem Code zusammen.
• Templates nutzen: ein Mal eine gute Vorlage, immer wieder verwenden. Konsistenz spart Zeit.
• So viel wie nötig, so wenig wie möglich: nicht jeder Furz braucht Doku, aber wichtige Tests schon.
• Automatisch generieren wo möglich: CI-Tools erzeugen aus Unit-Tests automatisch JUnit-XML-Reports. Tools wie Allure machen daraus schöne HTML-Dashboards.
• Bug-Reports mit Anhängen: Screenshots, Logs, Browser-Konsole. Ein Bild sagt mehr als tausend Worte.
• Living Documentation: gerade in agilen Teams werden Testfälle und Spezifikationen verschmolzen (Stichwort BDD/Gherkin – siehe L5).

10) Klausurrelevante Punkte

• Drei Hauptdokumente: Testplan (vorher), Testfall (Anweisung), Testprotokoll (nachher).
• IEEE 829 als Standard kennen und mindestens 4-5 Kapitel eines Testplans nennen können.
• Testfall-Pflichtfelder: Voraussetzung, Eingabe, Schritte, erwartetes Ergebnis.
• Status-Werte: PASS, FAIL, BLOCKED, SKIPPED.
• Bug-Report: was muss drin sein (Reproduzierbarkeit, Erwartet vs. Tatsächlich, Umgebung).
• Unterschied Plan/Protokoll: Strategie vs. Beweis.

Zusammenfassung

Drei Hauptdokumente: Testplan (vorher: was/wer/wann/womit), Testfall (konkrete Anweisung pro Test), Testprotokoll (nachher: Ergebnisse). IEEE 829 als Standard. Testfall-Pflichtfelder: ID, Voraussetzungen, Eingabe, Schritte, erwartetes Ergebnis, Status. Status: PASS, FAIL, BLOCKED, SKIPPED. Bug-Report: reproduzierbare Schritte, erwartet vs. tatsächlich, Umgebung. Testabschlussbericht als Release-Entscheidungsgrundlage. Nächste: Testergebnisse präsentieren.