Ein Testreport fasst zusammen, was getestet wurde, was gefunden wurde und welches Risiko offen bleibt. Den Rahmen liefert ISO/IEC/IEEE 29119-3:2021: die Norm beschreibt 15 Dokumenttypen für die Testdokumentation, darunter den Test status report und den Test completion report als eigenständige Typen (microTOOL, Stand 2026). Der ältere IEEE 829-2008 mit seinem Test Summary Report wurde 2013 durch die 29119-Reihe abgelöst (IEEE SA). Die zweite Hälfte der Frage bleibt in den meisten Anleitungen offen: wie der Report entsteht. Und eine Pass-Rate von 98 % sagt wenig aus, solange niemand weiss, wie viele Läufe instabil waren.

Kurz gefasst: Ein Testreport braucht Abdeckung gegen Anforderungen und Risiken, das Fehlerbild nach Schweregrad, das Restrisiko und eine datierte Freigabeempfehlung. ISO/IEC/IEEE 29119-3:2021 gibt die Dokumenttypen vor, ISTQB v4.0.1 listet die Inhalte von Fortschritts- und Abschlussbericht. Erzeugt wird der Report am besten automatisch: JUnit-XML aus dem Lauf, Allure als Darstellung, Ergebnis nach Jira/Xray.

Abbildung 1: Die sechs Pflichtinhalte eines Testreports im Rahmen von ISO/IEC/IEEE 29119-3:2021.

Was gehört in einen Testreport?

In einen Testreport gehören der Testumfang, die Abdeckung gegen Anforderungen und Risiken, der Ausführungsstand, das Fehlerbild nach Schweregrad und Alter, die Abweichungen vom Testplan sowie eine datierte Empfehlung mit dem verbleibenden Restrisiko. ISO/IEC/IEEE 29119-3:2021 kennzeichnet die einzelnen Informationselemente als verpflichtend, empfohlen oder möglich, statt eine starre Vorlage vorzuschreiben.

Dazu kommt der Kontext, ohne den kein Nachweis funktioniert: Testobjekt, Version oder Commit, Umgebung, Zeitraum, Autor und Datum. Der Normtext selbst ist kostenpflichtig, deshalb stehen hier keine wörtlichen Klauseln: die Dokumenttypnamen sind belegt, eine erfundene Pflichtliste wäre es nicht. Wie der Report in den grösseren Prozess passt, steht im Überblick zum Testmanagement.

Testfortschrittsbericht oder Testabschlussbericht: welcher wann?

ISTQB unterscheidet zwei Berichtsarten mit verschiedenem Zweck: Testfortschrittsberichte steuern den laufenden Test, Testabschlussberichte bewerten eine abgeschlossene Aktivität. Der Lehrplan formuliert es in Abschnitt 5.3.2 „Purpose, Content and Audience for Test Reports“ so: „Test reporting summarizes and communicates test information during and after testing.“ (ISTQB CTFL Syllabus v4.0.1, 2024).

Abbildung 2: Inhalte von Fortschritts- und Abschlussbericht laut ISTQB CTFL v4.0.1, Abschnitt 5.3.2.

Fortschrittsberichte „support the ongoing test control and must provide enough information to make modifications to the test schedule, resources, or test plan“. Abschlussberichte „summarize a specific test activity (e.g., test level, test cycle, iteration) and can give information for subsequent testing“ (ebd.). Die Inhalte listet der Lehrplan direkt auf:

Welche Testmetriken sind aussagekräftig?

Aussagekräftig sind die Metriken, die eine Freigabeentscheidung stützen. ISTQB nennt den Zweck in Abschnitt 5.3.1: „Test metrics are gathered to show progress against the planned test schedule and budget, the current quality of the test object, and the effectiveness of the test activities with respect to the test objectives or an iteration goal.“ (ebd.). Gruppiert werden sie in Projektfortschritts-, Testfortschritts-, Produktqualitäts-, Fehler-, Risiko-, Abdeckungs- und Kostenmetriken.

Vier Kennzahlen haben eine saubere Definition und lohnen sich im Bericht:

• Fehlerdichte: in einer Komponente gefundene Fehler geteilt durch deren Grösse, etwa Lines of Code oder Function Points (ISTQB Glossary).

• Defect Detection Percentage (DDP): Fehler, die eine Teststufe gefunden hat, geteilt durch die Summe aus diesen und allen später anderweitig gefundenen Fehlern (ISTQB Glossary).

• Escaped Defects: Fehler, die erst nach der Fertigmeldung auffallen, meist in Produktion (Plandek).

• Mean Time to Detect: die Zeitspanne zwischen dem Entstehen eines Fehlers und seiner Entdeckung durch Tests.

Für die letzten beiden kursieren Zielkorridore im Netz („unter 10 % ist gut“). Wir drucken sie nicht ab: keine der auffindbaren Quellen zeigt eine Methodik dahinter. Messen Sie stattdessen die eigene Zeitreihe über mehrere Releases desselben Produkts. Der Trend beantwortet die Frage, ob die Teststufe besser wird, ein fremder Branchenwert nicht.

Warum sagt Code Coverage wenig über Qualität?

Code Coverage misst, welcher Anteil des Codes bei einem Testlauf ausgeführt wurde, und das ist eine andere Frage als die nach der Fehlerfindung. Inozemtseva und Holmes untersuchten fünf grosse Open-Source-Java-Projekte mit je rund 100.000 Zeilen Code und über 1.000 Testmethoden. Ihr Ergebnis: der Zusammenhang zwischen Abdeckung und Fehlerfindungsstärke ist niedrig bis moderat, sobald die Grösse der Testsuite herausgerechnet wird, und strengere Kriterien wie Branch Coverage liefern keine besseren Aussagen als Statement Coverage (ICSE 2014).

Ein besseres Signal liefert die Mutationsanalyse. Just und Kollegen prüften 357 reale Fehler in fünf Open-Source-Anwendungen mit zusammen rund 321.000 Zeilen Code und fanden, dass die Erkennungsrate für Mutanten mit der Erkennung echter Fehler zusammenhängt, unabhängig von der Code Coverage (FSE 2014).

Dazu kommt der Effekt, den Charles Goodhart 1975 in der Ökonomie beschrieb und den Marilyn Strathern in der heute geläufigen Form zusammenfasste: „When a measure becomes a target, it ceases to be a good measure.“ Das ist eine ökonomische Beobachtung, keine softwaretechnische Studie. Sie beschreibt trotzdem präzise, was passiert, wenn ein Team auf 90 % Abdeckung verpflichtet wird: die Zahl kommt, die Assertions fehlen. Abdeckung gehört deshalb in Quality Gates als Nebenbedingung, nicht als Hauptziel, und ausführlicher in unseren Beitrag zur Testabdeckung.

Warum lügt eine Pass-Rate bei instabilen Tests?

Eine Pass-Rate ist nur so ehrlich wie die Stabilität der Tests dahinter, und in grossen Codebasen sind instabile Tests die Regel. Atlassian Engineering schreibt über die eigenen Repositories: „Test flakiness has been a significant contributor to build reliability issues in the past, responsible for as much as 21% of master build failures in the Jira Frontend repository.“ (Atlassian Engineering, 8. Dezember 2025).

Abbildung 3: Instabile Tests verzerren die Pass-Rate. Zahlen von Atlassian Engineering, Dezember 2025.

Im Jira-Backend-Repository führt Atlassian rund 15 % der Fehlschläge auf Flakiness zurück, mit Reruns, die pro Jahr über 150.000 Entwicklerstunden kosten. Das interne Werkzeug verarbeitet mehr als 350 Millionen Testausführungen pro Tag über mehr als 12 Produkte hinweg (ebd.). Vergleichbare Grössenordnungen nennt Atlassian aus zweiter Hand: 13 % bei Microsoft Research, 16 % in einer Google-Studie.

Damit kippt die Aussage jedes Reports, der nur eine Zahl zeigt. Ist 1 von 6 Fehlschlägen zufällig, ist auch jeder grüne Lauf mit stillem Retry verdächtig. Vier Angaben machen den Report wieder belastbar:

• die Zahl der Reruns, die zum grünen Ergebnis geführt haben

• die Liste der als instabil markierten oder in Quarantäne gestellten Tests

• die Pass-Rate getrennt nach stabilen und quarantänisierten Tests

• die Historie desselben Tests über die letzten Läufe

In Kundenprojekten sehen wir regelmässig Reports, deren Pass-Rate nach dem Ausweisen der Reruns um mehrere Punkte fällt. Die Software ist danach nicht schlechter, die Zahl ist nur ehrlicher.

Wie entsteht ein Testreport automatisch aus der Pipeline?

Ein automatisierter Testreport entsteht in fünf Schritten, ohne dass jemand Screenshots in ein Dokument kopiert:

Abbildung 4: Der automatisierte Weg vom Testlauf zum Report in fünf Schritten.

1. Der Testlauf schreibt Ergebnisse. Das Framework erzeugt maschinenlesbare Ergebnisdateien, meist JUnit-XML, dazu Screenshots und Logs als Anhänge.

2. CI sammelt die Artefakte ein. Der Job archiviert die Dateien, damit sie den Build überleben.

3. Ein Report-Tool rendert den Bericht. Aus den Rohdaten wird eine lesbare HTML-Darstellung mit Schritten, Anhängen, Historie und Trend.

4. Der Report wird versioniert abgelegt. Mit Commit-SHA, Build-Nummer, Zeitstempel und Umgebung.

5. Ergebnisse fliessen in die Managementebene. Als Test Execution in Jira/Xray oder ein anderes Testmanagement-Werkzeug, wo sie an Anforderungen und Releases hängen.

Ein bekanntes Problem steckt in Schritt 1: JUnit-XML hat keine offizielle Schemadefinition. Das Format ist der De-facto-Standard für den Austausch von Testergebnissen zwischen CI-Servern, Report-Tools und Testmanagement-Systemen, doch die Varianten sind auseinandergelaufen (Ant-Stil gegen Jenkins-Stil), und die vorhandenen XSD-Dateien sind veraltet. Community-Projekte dokumentieren die Konventionen, weil eine massgebliche Spezifikation fehlt (junitxml README). Rechnen Sie damit, dass ein Werkzeug Attribute ignoriert, die das vorige geschrieben hat.

Die CI-Plattformen unterscheiden sich hier deutlicher, als viele Teams erwarten. GitLab hat eine eingebaute Funktion namens Unit test reports: Der Job gibt JUnit-XML aus, `artifacts:reports:junit` in der `.gitlab-ci.yml` verweist darauf, und GitLab zeigt die Ergebnisse in Merge Requests und Pipeline-Ansichten mit Vergleich zwischen Quell- und Zielbranch (GitLab Docs). Den Job-Status ändert das nicht: ob der Job rot wird, entscheidet weiterhin der Exit Code. GitHub Actions hat keine vergleichbare eingebaute Funktion; die Lücke füllen Marketplace-Actions wie `dorny/test-reporter` oder `mikepenz/action-junit-report` (GitHub Community Discussion).

Allure Report oder Allure TestOps?

Allure Report ist ein quelloffenes, sprachübergreifendes Report-Werkzeug von Qameta Software unter Apache-2.0-Lizenz. Das README beschreibt es als „a flexible multi-language test report tool to show you a detailed representation of what has been tested and extract maximum from the everyday execution of tests.“ (GitHub, Stand 2026). Aktuelle Hauptversion ist Allure Report 3, jüngster Release 3.16.0 (geprüft am 30. August 2026).

Der Bericht enthält Testschritte, Anhänge wie Screenshots und Logs, Kategorien, Historie und Retries, Trends und eine Zeitachse, und er unterstützt über 50 Frameworks von JUnit und TestNG über pytest und Playwright bis NUnit (Allure Docs). Allure TestOps ist ein anderes Produkt: die kommerzielle Plattform desselben Herstellers mit zentraler Ergebnisablage, Historie pro Testfall über Läufe hinweg, Live-Dashboards und Testfallverwaltung (Qameta).

Autemos schreibt seine Ergebnisse als Allure-Report und schiebt sie nach Jira/Xray, weil Autemos eine Ausführungsengine ist und kein Testmanagement-Werkzeug. Welche Werkzeuge die Managementebene abdecken, vergleichen wir im Beitrag zu Testmanagement-Tools.

Was erwarten Prüfer in regulierten Umgebungen vom Testreport?

Prüfer erwarten aufbewahrte, datierte und nachvollziehbare Testnachweise, keine bestimmte Berichtsvorlage. Weder DORA noch das FINMA-Rundschreiben 2023/1 enthält eine Klausel über den Inhalt eines Testreports. Die Pflicht ist allgemeiner gefasst: DORA (Verordnung (EU) 2022/2554) verlangt in den Artikeln 24 bis 27 ein Programm für digitale operationale Resilienztests, Artikel 25 nennt unter anderem Schwachstellenbewertungen sowie szenariobasierte, Kompatibilitäts-, Leistungs- und Penetrationstests, abgestuft nach Grösse und Risikoprofil (EUR-Lex).

Zwei Absätze aus Artikel 24 sind für das Reporting trotzdem aufschlussreich. Absatz 5 verlangt von Finanzunternehmen ausser Kleinstunternehmen Verfahren, um „all issues revealed throughout the performance of the tests“ zu priorisieren, zu klassifizieren und zu beheben, dazu interne Validierungsmethoden als Beleg, dass jede gefundene Schwachstelle vollständig behoben wurde. Absatz 6 verlangt mindestens jährliche Tests aller IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen stützen (ebd.). Eine reine Prozentzahl belegt keine dieser Pflichten. Fehlerstatus, Alter, Klassifizierung und Restrisiko belegen sie.

Das FINMA-Rundschreiben 2023/1 „Operationelle Risiken und Resilienz – Banken“ ist seit dem 1. Januar 2024 in Kraft und erwartet dokumentiertes IKT-Risikomanagement, ein aktuelles Inventar der IT-Werte und wirksames Schwachstellenmanagement (FINMA). Für den Testreport heisst das: unveränderlich abgelegt, datiert und versioniert, einer Anforderung zuordenbar, ohne stille Nachbesserung.

Genau daran scheitern generierte Reports gelegentlich. Repariert ein Werkzeug einen kaputten Locator selbst und meldet den Lauf grün, verschwindet der Vorfall aus dem Nachweis. Autemos protokolliert jede Self-Healing-Aktion sichtbar und lässt sie von einem Menschen bestätigen. Die Verbindung vom Ergebnis zurück zur Anforderung stellt die Traceability-Matrix her, und in einer Pipeline mit Continuous Testing entsteht dieser Nachweis bei jedem Lauf.

Häufig gestellte Fragen

Welche Norm gilt heute für die Testdokumentation?

ISO/IEC/IEEE 29119-3:2021 ist die aktuelle Ausgabe des Dokumentationsteils der 29119-Reihe und ersetzt die Fassung von 2013. IEEE 829-2008, die Quelle des klassischen Test Summary Report, wurde 2013 durch die 29119-Reihe abgelöst (IEEE SA).

Was ist der Unterschied zwischen Testreport und Testbericht?

Im Softwaretest meinen beide Begriffe dasselbe Dokument. Achtung bei der Recherche: „Testbericht“ bezeichnet im deutschen Sprachgebrauch meistens den Warentest eines Konsumprodukts, nicht den Bericht über eine Testaktivität in einem Softwareprojekt.

Wie viele Metriken gehören in einen Testreport?

So wenige, wie die Entscheidung braucht. Abdeckung gegen Anforderungen und Risiken, Ausführungsstand, Fehlerbild nach Schweregrad und das benannte Restrisiko reichen für die meisten Freigabegespräche. Kennzahlen wie DDP oder Fehlerdichte lohnen sich als Zeitreihe über mehrere Releases.

Ist eine Pass-Rate von 100 % ein gutes Zeichen?

Nur zusammen mit der Information, wie sie zustande kam. Atlassian führt bis zu 21 % der Fehlschläge im Jira-Frontend-Repository auf instabile Tests zurück (Atlassian Engineering, 2025). Ohne Rerun-Zahl und Quarantäneliste ist eine Pass-Rate nicht interpretierbar.

Ersetzt Allure Report ein Testmanagement-Werkzeug?

Nein. Allure Report erzeugt HTML-Berichte pro Lauf mit begrenzter Historie über Läufe hinweg. Zentrale Ablage, Testfallverwaltung und langfristige Historie liefert das kommerzielle Allure TestOps oder ein Werkzeug wie Xray in Jira.

Fazit

Ein guter Testreport beantwortet drei Fragen: Was wurde abgedeckt, was ist offen, welches Risiko trägt die Freigabe. ISO/IEC/IEEE 29119-3:2021 gibt die Dokumenttypen vor, ISTQB v4.0.1 listet die Inhalte von Fortschritts- und Abschlussbericht, und beides lässt sich aus der Pipeline erzeugen: JUnit-XML aus dem Lauf, Allure als Darstellung, Ergebnis nach Jira/Xray. Zwei Zahlen verdienen Misstrauen: Code Coverage als Qualitätsmass, das laut ICSE-2014-Forschung nur schwach mit der Fehlerfindung zusammenhängt, und jede Pass-Rate ohne Rerun-Angabe.

Sie möchten sehen, wie Autemos Testergebnisse als Allure-Report und als Test Execution in Jira/Xray liefert? Sprechen Sie mit unserem Team.