Testreporting ist ein Führungswerkzeug, das Testmanagern zeigt, wo ein Projekt steht, wie es dahin kam und wohin es sich bewegt. Ein bewährter Aufbau gliedert sich in eine 3x3-Matrix: drei fachliche Spalten für Testvorbereitung, Testausführung und Fehler, kombiniert mit drei Zeilen für Ist-Stand, Verlauf und Datenqualität.
Das Wichtigste in Kürze
- Ein Testreporting, das auf einer 3x3-Matrix aus Testvorbereitung, Testausführung und Fehler aufgebaut ist, deckt nach Erfahrung aus mehreren Projekten in 95 Prozent aller Fälle den tatsächlichen Informationsbedarf der Stakeholder ab.
- Die Prognose ist eine Kernfunktion des Testreportings: Wer auf Basis historischer Ausführungsdaten hochrechnet, wann das Testziel erreicht wird, schafft die Grundlage für konkrete Entscheidungen über Termine, Ressourcen oder Zielkorrekturen.
- Schlechte Datenqualität verfälscht jeden Ist-Stand: Ein automatisiertes internes Kontrollsystem, das definierte Pflichtattribute wie Teilprojektzugehörigkeit überwacht, macht fehlerhafte Datenpflege sichtbar, bevor sie das Reporting nach außen korrumpiert.
- Konstanz im Format zahlt sich direkt aus: Stakeholder, die dasselbe Reporting-Layout aus früheren Projekten kennen, orientieren sich sofort, ohne dass jede Kennzahl neu erklärt werden muss.
Testreporting ist ein Führungswerkzeug, kein Pflicht-Diagramm
Ein Testreporting entscheidet sich nicht im ruhigen Projekt, sondern im stürmischen. Matthias Gross beschreibt das mit dem Bild einer Schiffsfahrt: Bei 28 Grad und leichtem Wellengang lässt sich jedes Schiff steuern. Erst wenn links und rechts fünf Meter hohe Wellen stehen und der Horizont verschwindet, zeigt sich, ob Führung und Steuerung funktionieren.
Genau in dieser Lage liefert ein Reporting den Wert, für den es existiert. Es zeigt nicht nur einen Status, es ist die Grundlage für Entscheidungen: länger testen, mehr investieren oder mit einem breiteren Zielkorridor in Produktion gehen.
Wer das Reporting als Pflichtübung versteht, produziert Diagramme. Wer es als Steuerungsinstrument versteht, leitet daraus Maßnahmen ab. Der Unterschied liegt nicht im Tool, sondern in der Frage, ob die Zahlen zu einer Handlung führen.
Warum jedes Reporting mit einem Ziel beginnt
Ohne definiertes Ziel steuerst du ins Nichts. Wer in See sticht, ohne den Hafen zu kennen, treibt umher. Im Testen ist das Ziel zwar grob klar: möglichst fehlerfrei in Produktion, mit hoher Testabdeckung. Den Idealpunkt mit 100 Prozent Abdeckung und null Fehlern erreicht aber kaum ein Projekt.
Deshalb arbeitet Matthias mit einem Zielkorridor statt mit einem einzelnen Punkt. Wenn das Schiff zwanzig Meter weiter links oder dreißig Meter weiter rechts anlandet, ist das oft akzeptabel. Ein Go-live mit fünfunddreißig Blocker-Bugs und siebzig Prozent Abdeckung liegt dagegen klar außerhalb des Korridors.
Das Ziel ist abzustimmen, mit Team, Projektleitung und Auftraggeber, weil es die produzierte Qualität definiert. Der erste Schritt bleibt trotzdem, dass das Ziel überhaupt existiert und benannt ist. Erst dann lässt sich eine Position dazu bestimmen.
Die 3x3-Matrix: ein Reporting, das in 95 Prozent der Fälle reicht
Ein vollständiges Testreporting passt in eine Matrix aus drei Spalten und drei Zeilen. Die drei Spalten stehen für die fachlichen Artefakte, die drei Zeilen für die Dimensionen, in denen jedes Artefakt betrachtet wird.
Die Spalten bilden den Weg der Software ab:
- Testvorbereitung: alles auf dem Weg hin zum fertigen Testfall.
- Testausführung: wie es den Tests in der Ausführung geht.
- Fehler: Anzahl, Kritikalität und Abarbeitung der gefundenen Fehler.
Die Zeilen liefern zu jeder Spalte eine andere Betrachtung:
- Ist-Stand: die aktuelle Position, oft als Kuchendiagramm. Beispiel Testvorbereitung: 80 Prozent abgeschlossen, 20 Prozent offen.
- Verlauf: wie der Stand zustande kam, über die letzten Tage und Wochen.
- Messqualität (IKS): ein internes Kontrollsystem, das die Verlässlichkeit der Daten misst.
Wenn alle neun Felder mit einer Grafik oder Kennzahl gefüllt sind, steht ein Reporting, das in der überwiegenden Zahl der Fälle ausreicht. Was die meisten Stakeholder wissen wollen, sind ohnehin nur drei Dinge: Wie steht die Vorbereitung, wie läuft die Ausführung, wie sieht es bei den Fehlern aus.
Das Befüllen der neun Felder ist mehr Arbeit, als es zunächst aussieht. Matthias berichtet, dass Teams, die den Ansatz erstmals nutzen, genau hier ins Schwitzen kommen. Der Aufwand zahlt sich aus, sobald die Felder einmal stehen und als Steuerungsinstrument dienen.
Wie aus dem Verlauf eine belastbare Prognose wird
Die Verlaufszeile existiert nicht zur Dekoration, sie speist die Prognose. Aus dem historischen Verlauf und dem Know-how aus dem Projekt lässt sich hochrechnen, wie lange die Mannschaft bei aktueller Performance noch braucht, um das Ziel zu erreichen.
Diese Prognose kollidiert regelmäßig mit einem festen Termin. Wenn der Go-live in Kalenderwoche 25 steht, die Hochrechnung aber Kalenderwoche 28 ergibt, liegen drei Wochen Differenz offen auf dem Tisch.
Mit dieser Information lassen sich Maßnahmen einleiten, bevor es eng wird. Drei Optionen stehen zur Wahl: das Release verschieben, mehr in die Ausführung investieren oder mit einem breiteren Zielkorridor leben. Ohne Prognose merkst du die Differenz erst, wenn die Hypercare-Phase es in sich hat.
Datenqualität messen, bevor das Reporting lügt
Ein Reporting ist nur so gut wie die Daten dahinter. Die dritte Zeile, das interne Kontrollsystem, drückt die Datenqualität als Prozentwert aus: 100 Prozent bedeuten saubere Daten, ein Einbruch auf 80 Prozent ist ein Alarmsignal.
Gemessen werden die Attribute, die das Reporting tatsächlich braucht, etwa Status, Datum oder Teilprojekt. Der Status ist meist sauber gepflegt. Problematischer sind Felder wie das Teilprojekt, wenn das Tool keine saubere Auswahl erzwingt.
Wenn der IKS-Wert von 100 einbricht und auf einmal bei 80 ist, ist das für mich ein Indikator, ich muss steuern, entgegenwirken. Ich weiß schon, dass ich nach außen den falschen Ist-Stand kommuniziere, aber kann im Hintergrund schon steuernd eingreifen. — Matthias Gross
In Matthias’ aktuellem Projekt gibt es neun Teilprojekte. Das Feld ist nicht verpflichtend und erlaubt Mehrfachwerte. Ein Testfall mit zwei Teilprojekten oder mit einem unbekannten Wert verfälscht die Auswertung, weil er entweder doppelt zählt oder ganz untergeht.
Die Regel dahinter ist klar: Ein Testfall gehört zu genau einem gültigen Teilprojekt. Eine Automation prüft jeden Testfall gegen die hinterlegte Liste und berechnet daraus den IKS-Wert. Kommt ein neues Teilprojekt dazu, wird die Liste erweitert.
Diesen Wert behält Matthias intern. Außenstehenden müsste man ihn erklären, deshalb dient er der eigenen Steuerung und fließt nicht ins externe Dashboard. Er ist die Kontrollinstanz, die verhindert, dass das Reporting eine Position meldet, die dreihundert Meter neben der echten liegt.
Wie sich das Reporting automatisieren lässt
Die ersten vier Schritte sind manuelle Aufbauarbeit, der fünfte automatisiert sie. Ein Reporting wird regelmäßig gebraucht, also müssen die einmal definierten Schritte ohne Handarbeit reproduzierbar sein.
Matthias’ Team lädt die Daten über die Jira-API mit dem Zusatz Expand Change Log aus. Damit kommt die komplette Ticket-Historie ins Python-Skript. Dort entstehen saubere Snapshots, verdichtet auf das Wochenende, passend zum wöchentlichen Reporting im Wasserfall.
Die Verdichtung folgt einer klaren Logik. Ein Ticket mit drei Änderungen in einer Woche zählt nur mit dem letzten Stand am Wochenende. Ein Ticket, das seit Wochen nicht angefasst wurde, bekommt trotzdem seinen Snapshot.
Die aufbereiteten Rohdaten landen in Excel und werden dort über Pivot-Tabellen zum Dashboard. Diese Trennung ist bewusst gewählt: Die Datenaufbereitung bleibt robust in Python, das flexible Zusammenstecken neuer Sichten geht in Excel und gelingt auch ohne Programmierkenntnisse.
| Schicht | Werkzeug | Aufgabe |
|---|---|---|
| Datenquelle | Jira-API (Expand Change Log) | komplette Ticket-Historie auslesen |
| Aufbereitung | Python | Snapshots erzeugen, auf Wochenende verdichten |
| Auswertung | Excel mit Pivot-Tabellen | Dashboard, flexible Sichten |
| Verteilung | PDF aus dem Dashboard | wöchentlich gleiche Sicht für das Management |
Das Management bekommt jede Woche ein PDF mit denselben Kennzahlen. Technisch versierte Stakeholder erhalten direkten Zugriff auf das Excel und ziehen sich eigene Sichten, etwa welche Abteilung gerade welche Testfälle hält.
Konstanz schlägt Metrik-Flut
Der größte Nutzen entsteht durch immer dieselbe Darstellung. Matthias läuft seit Jahren in jedem Projekt mit derselben 3x3-Matrix herein. Wer das Vorgehen schon aus früheren Projekten kennt, findet sich sofort zurecht: hier Vorbereitung, da Ausführung, dort die Fehler.
Diese Konstanz ist der Gegenentwurf zum überladenen Jira-Dashboard mit tausend Tortendiagrammen, bei dem niemand weiß, was er damit anfangen soll. Variiert wird nur die Detailtiefe, nicht die Struktur.
Bei einer größeren Migration mit mehreren Teilprojekten zeigt die Matrix zunächst das Gesamtprojekt. Per Reinzoomen lässt sich die identische Neun-Felder-Sicht für ein einzelnes Teilprojekt wie Finance herstellen. So bekommen Teilprojektleitung und Gesamtprojektleitung Detailtiefe, ohne dass die Grundstruktur wechselt.
Weitere Auswertungen sind oft keine neuen Kennzahlen, sondern andere Schnitte derselben Daten. Eine Abteilungssicht statt einer Teilprojektsicht etwa lässt sich schnell bauen, sobald die Zugehörigkeit als Attribut vorliegt.
Mit den Daten chatten, ohne das lineare Reporting anzutasten
Ein KI-Experiment hat das Reporting ergänzt, nicht ersetzt. Das automatisierte, wöchentlich gleiche Reporting bleibt unangetastet, weil seine Stärke gerade in der Konstanz liegt.
Daneben hat das Team eine Möglichkeit geschaffen, mit den Daten zu chatten. Die in Python aufbereiteten Daten wandern in eine PostgreSQL-Datenbank, verschaltet über n8n, Ollama und WebUI. Über eine Chat-Oberfläche lassen sich Fragen stellen und neue Sichten oder Ideen abrufen.
Der Aufwand steckte vor allem im System-Prompt, bis die Lösung verlässlich funktionierte. Das Ergebnis hat einen klaren Platz: Es liefert spontane, explorative Antworten. Die unantastbare Basis mit immer denselben Kennzahlen ersetzt es nicht.
