Testmanagement ist die Planung, Schätzung, Überwachung und Steuerung von Testaktivitäten, üblicherweise verantwortet von einer Testmanagerin oder einem Testmanager. Zwei Regelwerke beschreiben, wie das abläuft: der ISTQB-Lehrplan CTFL v4.0 mit sieben Testaktivitäten und die Normenreihe ISO/IEC/IEEE 29119 für Prozesse und Dokumentation. Für Banken und Versicherer im DACH-Raum kommt eine dritte Anforderung dazu, nämlich der prüfbare Nachweis, dass und wie getestet wurde. Dieser Beitrag ordnet Prozess, Rolle, Werkzeuge und Aufsichtsanforderungen und führt in die vier Detailartikel dieses Clusters.

Kurz gefasst: Testmanagement plant, überwacht und steuert Testaktivitäten. ISTQB CTFL v4.0 gliedert sie in sieben Aktivitäten von der Testplanung bis zum Testabschluss, ISO/IEC/IEEE 29119-3:2021 regelt die Testdokumentation und hat IEEE 829 abgelöst. Laut Capgemini-Anbieterumfrage haben erst 8 % der Unternehmen eine vollständig etablierte, KPI-gestützte Teststrategie (Capgemini World Quality Report 2025-26, 2025).

Abbildung 1: Die sieben Testaktivitäten nach ISTQB CTFL v4.0.1 laufen iterativ und parallel, nicht als Wasserfall.

Was ist Testmanagement, und wer verantwortet es?

Testmanagement ist die Disziplin, die Testaktivitäten plant, schätzt, überwacht und steuert. Das ISTQB-Glossar definiert den Begriff als „the planning, estimating, monitoring and control of test activities, typically carried out by a test manager“ (ISTQB Glossary). Gegenstand sind Umfang, Ressourcen, Risiken, Kriterien und Fortschritt einer Testaufgabe.

Die zugehörige Rolle ist ebenfalls definiert. Ein Testmanager ist laut Glossar „the person responsible for project management of testing activities and resources, and evaluation of a test object“. Die Bewertung des Testobjekts steht in dieser Definition gleichrangig neben der Projektsteuerung, und genau daran hängt die Freigabeempfehlung.

Im Projektalltag verantwortet die Rolle sechs Dinge:

• Umfang, Teststufen und Testarten für das Vorhaben

• Risikobewertung und die daraus abgeleitete Priorisierung

• Aufwand, Termine, Personal und Testumgebungen

• Eintritts- und Austrittskriterien, oft als Quality Gates formuliert

• Berichtsweg an Projektleitung, Fachbereich und interne Revision

• Empfehlung zur Freigabe oder zur Verschiebung eines Release

Wer die Begriffe darunter sortieren möchte, findet sie in unserer Übersicht zu den Grundlagen des Softwaretestens.

Wie läuft der Testmanagement-Prozess nach ISTQB ab?

Der ISTQB Certified Tester Foundation Level Syllabus beschreibt in Abschnitt 1.4.1 sieben Testaktivitäten; Kapitel 5 „Managing the Test Activities“ behandelt ihre Steuerung. Maßgeblich ist Version 4.0.1 vom 15. September 2024 (ISTQB CTFL Syllabus v4.0.1, 2024).

1. Testplanung legt die Testziele fest und wählt ein Vorgehen, das sie innerhalb der gegebenen Rahmenbedingungen erreicht.

2. Testüberwachung und Teststeuerung: Die Überwachung prüft laufend alle Testaktivitäten und vergleicht den Fortschritt mit dem Plan, die Steuerung ergreift die nötigen Maßnahmen.

3. Testanalyse beantwortet laut Syllabus die Frage „what to test?“, und zwar über messbare Abdeckungskriterien.

4. Testentwurf beantwortet die Frage „how to test?“ und führt zu Testfällen, Testdaten und Testabläufen.

5. Testrealisierung stellt bereit, was zur Ausführung nötig ist: Skripte, Testdaten, Umgebungen, Reihenfolge.

6. Testdurchführung führt die Tests gemäß Ausführungsplan aus (Testläufe) und protokolliert die Ergebnisse.

7. Testabschluss fällt an Meilensteinen an, etwa am Ende einer Teststufe, einer Iteration, eines Projekts oder eines Release.

Diese sieben Aktivitäten sind ausdrücklich keine starre Abfolge. Der Syllabus schreibt selbst: „Although many of these activities may appear to follow a logical sequence, they are often implemented iteratively or in parallel.“ Fast alle Ratgeber im Netz stellen die Liste trotzdem als Wasserfall-Pipeline dar. Testüberwachung und Teststeuerung laufen über die gesamte Projektlaufzeit mit, und in iterativen Vorhaben wiederholen sich Analyse, Entwurf, Realisierung und Durchführung pro Sprint.

Zwei Präzisierungen, weil sie in der Praxis Fehler verursachen. Erstens heißt die zweite Aktivität seit v4.0 „test monitoring and test control“; die kürzere Form aus dem Vorgängerlehrplan ist mit der Umbenennung entfallen. Zweitens zitieren viele Zusammenfassungen und auch KI-Antworten weiterhin den Lehrplan von 2018 in Version 3.1.1. Auf Advanced Level ersetzt CTAL-TM v3.0, veröffentlicht am 30. Mai 2024, den Lehrplan von 2012; die englischen Prüfungen zur alten Fassung liefen am 30. Mai 2025 aus (ISTQB, 2024).

Wie die Planungsaktivität als Dokument aussieht, zeigt unser Beitrag zum Testplan mit Aufbau und Vorlage.

Welche Standards regeln Testmanagement und Testdokumentation?

Die maßgebliche Normenreihe ist ISO/IEC/IEEE 29119, und IEEE 829 ist seit 2013 abgelöst. Teil 2 der Reihe beschreibt Testprozesse, die „can be used to govern, manage and implement software testing for any organization, project or testing activity“, und richtet sich ausdrücklich auch an Testmanager (ISO, 2021).

Abbildung 2: Die Teile der Normenreihe ISO/IEC/IEEE 29119 mit ihren aktuellen Ausgaben.

IEEE 829 definierte bis 2008 die klassischen Testdokumente, darunter den Test Summary Report. Die Norm wurde 2013 durch ISO/IEC/IEEE 29119-1, -2 und -3 ersetzt (IEEE SA). Mehrere gut platzierte deutschsprachige Ratgeber führen IEEE 829 bis heute als geltende Grundlage für Testdokumentation. Wer einer Revision eine Dokumentationsstruktur begründen muss, zitiert 29119-3:2021.

Was ist an der 1:10:100-Regel belegt?

Die 1:10:100-Regel zu Fehlerkosten ist empirisch nicht belegt. Sie geht auf Arbeiten von Barry Boehm aus den Jahren 1976 und 1981 zurück sowie auf eine Schulungsunterlage des IBM Systems Sciences Institute von 1981, die nie als Studie veröffentlicht wurde. Trotzdem steht der Faktor in unzähligen Testkonzepten und Business Cases.

Die belastbarste Gegenprüfung stammt von Menzies, Nichols, Shull und Layman. Ihre Untersuchung von 171 Projekten aus den Jahren 2006 bis 2014 kommt zu einem klaren Ergebnis: „We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction“ (arXiv:1609.04886, Empirical Software Engineering).

Die Richtung bleibt plausibel, denn früh gefundene Fehler sind im Schnitt günstiger zu beheben. Der Multiplikator ist es nicht. Für die Testplanung heißt das: Aufwände über Risiko, Kritikalität und regulatorische Pflicht begründen, nicht über einen Faktor, den ein Auditor oder ein CFO in zwei Minuten auseinandernimmt.

Als Größenordnung taugt der CISQ-Report besser: 2,41 Billionen US-Dollar Kosten schlechter Softwarequalität in den USA, davon rund 1,52 Billionen technische Schuld (CISQ, 2022). Wer ihn zitiert, nennt beide Einschränkungen mit: gesponsert von Synopsys und Undo, und nur auf die USA bezogen.

Wie organisiert man Testmanagement in Jira mit Xray?

Xray ist eine Jira-App, die Testfälle, Testausführungen und Testläufe als eigene Jira-Vorgangstypen führt, sodass Anforderung, Test, Ausführung und Fehler im selben Backlog liegen. Für Teams, die Anforderungen ohnehin in Jira verwalten, entfällt damit die Synchronisation zwischen zwei Systemen.

Das Datenmodell besteht aus wenigen Bausteinen: Test, Precondition, Test Set, Test Plan, Test Execution und Test Run. Ein Test Run ist die Verbindung zwischen einer Test Execution und einem einzelnen Test, und genau auf dieser Ebene hängen Fehlerverknüpfungen und Ausführungsprotokolle.

Automatisierte Ergebnisse kommen über die REST-Schnittstelle hinein, unter anderem als JUnit XML, TestNG XML, Cucumber JSON oder im Xray-eigenen JSON-Format. Der Requirement Traceability Report zeigt anschließend die Anforderungen über Tests, Testläufe und Fehler hinweg.

Ein Punkt, den Vendor-Material selten sagt: Xray führt keine Tests aus. Es nimmt Ergebnisse entgegen und ordnet sie Anforderungen zu. Das Ausführen übernimmt ein Framework oder eine Automatisierungsplattform, und die Zuordnung läuft in der Regel über den Test-Key im Automatisierungscode.

Die vollständige Einrichtung, das Vorgangstyp-Glossar und die Importendpunkte stehen im Detailartikel zu Testmanagement in Jira mit Xray.

Wie verbindet eine Traceability-Matrix Anforderung, Testfall und Fehler?

Eine Traceability-Matrix ist ein Bericht, der jede Anforderung mit den Testfällen, Testläufen und Fehlern verknüpft, die sie abdecken. Für eine Revision beantwortet sie zwei Fragen: Ist jede Anforderung getestet, und was ist bei den offenen Fehlern der Stand.

Fachlich unterscheidet man drei Richtungen. Vorwärtsverfolgung führt von der Anforderung zu Entwurf, Code und Test. Rückwärtsverfolgung führt von einem Artefakt zurück zur auslösenden Anforderung. Bidirektionale Verfolgbarkeit verlangt beides gleichzeitig und ist in sicherheitskritischen Domänen der Normalfall.

Keine Normungsorganisation veröffentlicht eine verbindliche Spaltenliste für eine Traceability-Matrix. In der Praxis hat sich ein kleiner Kern durchgesetzt: Anforderungs-ID, Anforderungsbeschreibung, Testfall-ID, Status des Testfalls, Fehler-ID und Abdeckungsstatus. Welche Spalten dazukommen, entscheidet die Domäne und der Prüfzweck.

Der teure Fehler ist die Tabellenkalkulation. Eine von Hand gepflegte Matrix ist ab dem ersten Änderungsantrag veraltet, und niemand merkt es, bis geprüft wird. Werkzeuge wie Xray, Azure DevOps oder Polarion erzeugen die Sicht zur Laufzeit aus den verknüpften Elementen. Damit ist die Matrix ein Bericht und kein Dokument, das jemand nachträglich zusammensucht.

Was das im regulierten Umfeld bedeutet, steht in unserem Beitrag zum Testen in regulierten Branchen; Spaltenmodelle und Beispiele liefert der Detailartikel zur Requirements Traceability Matrix.

Welches Testmanagement-Tool passt zu einem regulierten Unternehmen?

Ein Testmanagement-Tool verwaltet Testfälle, plant Testzyklen und berichtet Ergebnisse; ein Testautomatisierungswerkzeug führt Tests aus. Beide Kategorien werden regelmäßig verwechselt, und die Verwechslung führt zu Ausschreibungen, in denen Selenium und TestRail auf derselben Liste stehen.

Abbildung 3: Testmanagement-Tool und Testautomatisierung sind zwei Ebenen, verbunden über ein Importformat.

Der Markt sortiert sich in vier Gruppen: Jira-native Apps wie Xray und Zephyr, eigenständige SaaS-Werkzeuge wie TestRail, PractiTest oder Testmo, Enterprise-ALM-Plattformen wie qTest und Polarion sowie Open-Source-Systeme wie TestLink und Kiwi TCMS.

Für einen Schweizer oder deutschen Finanzdienstleister entscheiden meist fünf Kriterien, und zwar in dieser Reihenfolge:

• Datenresidenz: Gibt es eine EU- oder Schweiz-Region, und ist sie wählbar

• Betriebsmodell: SaaS, dedizierter Tenant oder On-Premise

• Auditierbarkeit: Änderungsprotokoll, Rollenmodell, dokumentierte Freigaben

• Importformate für automatisierte Ergebnisse, in der Praxis meist JUnit XML

• Anbindung an das vorhandene Anforderungs- und Ticketsystem

Die Datenresidenz eliminiert in Bankprojekten regelmäßig die Hälfte der Kandidaten in der ersten Runde, noch bevor ein Feature-Vergleich beginnt. Preislisten sind dabei die unzuverlässigste Quelle im Markt, weil mehrere Anbieter nur auf Anfrage kalkulieren und Reseller-Zahlen kursieren, die niemand verifizieren kann.

Der Werkzeugvergleich mit Betriebsmodellen, Regionen und den überprüften Preisen steht im Detailartikel zu den Testmanagement-Tools.

Was gehört in einen Testreport?

Ein Testreport beantwortet drei Fragen: Was wurde getestet, was ist das Ergebnis, und welches Restrisiko bleibt. ISTQB unterscheidet dabei zwei Typen, den Testfortschrittsbericht während der Testdurchführung und den Testabschlussbericht am Ende einer Teststufe, eines Testzyklus oder einer Iteration.

ISO/IEC/IEEE 29119-3:2021 beschreibt die zugehörigen Dokumenttypen, darunter Testfortschritts- und Testabschlussbericht, und markiert die einzelnen Informationselemente als verpflichtend, empfohlen oder möglich. Das ist die Struktur, die eine Revision erwartet, und sie ist deutlich schlanker als die Berichte, die Teams sich selbst auferlegen.

Sinnvolle Kennzahlen sind Anforderungsabdeckung, Fehlerdichte, Defect Detection Percentage, offene Fehler nach Schweregrad und der Anteil instabiler Tests. Die reine Bestehensquote ohne Flaky-Rate ist die häufigste Art, wie ein Testreport unabsichtlich lügt: Ein grüner Lauf nach drei Wiederholungen sieht im Bericht aus wie ein grüner Lauf beim ersten Versuch.

Codeabdeckung als Qualitätsmaß ist mit Vorsicht zu behandeln. Sie zeigt, welcher Code ausgeführt wurde, nicht, wie gut geprüft wurde. Details dazu stehen in unserem Beitrag zur Testabdeckung.

Welche Metriken sich lohnen, wie Allure-Reports aufgebaut sind und was CI-Systeme von sich aus liefern, steht im Detailartikel zum Testreporting.

Was erwarten Aufsicht und Revision im DACH-Raum?

Aufsichtsrecht verlangt kein bestimmtes Testmanagement-Tool, sondern ein nachweisbares Testprogramm. DORA, die Verordnung (EU) 2022/2554, verpflichtet in Artikel 24 Absatz 1 Finanzunternehmen außer Kleinstunternehmen, ein „sound and comprehensive digital operational resilience testing programme“ einzurichten, aufrechtzuerhalten und zu überprüfen, und zwar als fester Bestandteil des IKT-Risikomanagementrahmens nach Artikel 6 (EUR-Lex). Die Verordnung gilt seit dem 17. Januar 2025.

Abbildung 4: Reifegrad der Teststrategie laut Capgemini World Quality Report 2025-26.

Konkreter wird Artikel 24 Absatz 6: Finanzunternehmen außer Kleinstunternehmen müssen mindestens jährlich sicherstellen, dass alle IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen stützen, angemessen getestet werden. Damit hat die Testabschluss-Aktivität aus dem ISTQB-Prozess für Finanzunternehmen einen festen Takt und einen Adressaten.

In der Schweiz ist der Bezugspunkt das FINMA-Rundschreiben 2023/1 zu operationellen Risiken und Resilienz bei Banken. Es wurde am 7. Dezember 2022 veröffentlicht, ist seit dem 1. Januar 2024 in Kraft und ersetzt das Rundschreiben 2008/21 (FINMA). Es adressiert das IKT-Risikomanagement von Banken allgemein und schreibt keine Berichtsvorlage für Softwaretests vor.

Praktisch laufen beide Regelwerke auf dieselbe Erwartung hinaus: aufbewahrte, datierte und nachvollziehbare Testnachweise mit klarer Zuordnung zu Anforderungen und Freigaben. Wer diese Nachweise erst zum Prüfungstermin zusammensucht, verliert Wochen und überlässt die Lücken der Revision.

Wie kommen automatisierte Testergebnisse in die Managementebene?

Über eine Importschnittstelle. Die Automatisierung führt Tests in der Pipeline aus, erzeugt ein maschinenlesbares Ergebnisformat und schreibt es in das Testmanagement-System, wo es an Anforderung und Freigabe hängt. Diese Naht ist in den meisten Testkonzepten unterbeschrieben und in Audits der häufigste Bruch.

Autemos sitzt auf der Ausführungsseite dieser Naht. Die Plattform führt Web-, Mobile-, API- und Desktop-Tests aus, erzeugt Allure-Reports und meldet Ergebnisse nach Jira/Xray sowie in Pipelines wie GitLab, GitHub Actions und Jenkins. Ein Testmanagement-Tool ist Autemos nicht, und das ist die ehrliche Abgrenzung: Testfallverwaltung, Zyklusplanung und Freigabeworkflow bleiben in der Managementebene. Wie die Ausführungsseite aussieht, zeigt die Übersicht zu den Test-Workflows.

Laut der Capgemini-Anbieterumfrage World Quality Report 2025-26 bewegen sich 47 % der Unternehmen auf eine unternehmensweite Testautomatisierungsstrategie zu, während nur 8 % eine vollständig etablierte, KPI-gestützte Strategie haben und 60 % Schwierigkeiten mit sicheren, skalierbaren Testdaten melden (Capgemini, 2025). Die Zahlen stammen von einem Anbieter mit eigenem Testgeschäft und sind entsprechend zu lesen. Wie die Ergebnisse fortlaufend in Quality Gates einfließen, beschreibt unser Beitrag zum Continuous Testing.

Welcher Detailartikel beantwortet welche Frage?

Die vier Vertiefungen dieses Clusters decken je einen Teil der Managementebene ab:

Häufig gestellte Fragen

Was ist der Unterschied zwischen Testmanagement und Testautomatisierung?

Testmanagement plant, überwacht und steuert Testaktivitäten und dokumentiert Ergebnisse; Testautomatisierung führt Testfälle technisch aus. Ein Testmanagement-Tool speichert Testfälle und Zyklen, eine Automatisierungsplattform startet Browser, API-Aufrufe oder mobile Geräte. Beide Ebenen sind über Importformate wie JUnit XML miteinander verbunden.

Welche Norm gilt für Testdokumentation?

Es gilt ISO/IEC/IEEE 29119-3 in der Ausgabe 2021. Sie ersetzt die Ausgabe 2013, die ihrerseits IEEE 829-2008 abgelöst hat (IEEE SA). Wer heute noch IEEE 829 als Grundlage einer Dokumentationsstruktur nennt, zitiert eine zurückgezogene Norm.

Wie viele Testaktivitäten kennt ISTQB?

Sieben: Testplanung, Testüberwachung und Teststeuerung, Testanalyse, Testentwurf, Testrealisierung, Testdurchführung und Testabschluss. Die Liste steht in Abschnitt 1.4.1 des Foundation-Level-Syllabus v4.0.1 vom 15. September 2024 (ISTQB, 2024). Ältere Quellen mit der Fassung 3.1.1 von 2018 sind überholt.

Schreibt DORA ein Testmanagement-Tool vor?

Nein. DORA Artikel 24 Absatz 1 verlangt ein eingerichtetes, gepflegtes und überprüftes Programm für digitale operationale Resilienz als Teil des IKT-Risikomanagements, ohne ein Produkt zu benennen. Absatz 6 setzt zusätzlich einen mindestens jährlichen Testtakt für Systeme mit kritischen oder wichtigen Funktionen. Prüfbar sein müssen Umfang, Durchführung und Nachverfolgung, nicht das Werkzeug.

Braucht jedes Projekt einen dedizierten Testmanager?

Nein, aber die Aufgaben brauchen einen Verantwortlichen. In kleinen Teams übernimmt sie oft die Produktverantwortung oder ein erfahrener Tester. In regulierten Vorhaben ist eine benannte Person üblich, weil Freigabeempfehlung und Berichtsweg an eine Rolle gebunden sein müssen, die gegenüber der Revision auskunftsfähig ist.

Fazit

Testmanagement lässt sich auf drei überprüfbare Bausteine reduzieren: die sieben Aktivitäten aus ISTQB CTFL v4.0, die Dokumentationsstruktur aus ISO/IEC/IEEE 29119-3:2021 und den Nachweis gegenüber Aufsicht und Revision. Alles andere ist Werkzeugwahl. Wer Zahlen wie die 1:10:100-Regel aus Testkonzepten streicht und stattdessen mit Risiko und Nachweispflicht argumentiert, kommt in Prüfungsgesprächen weiter.

Die Naht zwischen Ausführung und Managementebene entscheidet, wie viel Handarbeit am Ende übrig bleibt. Automatisierte Läufe, die ihre Ergebnisse selbst in Jira/Xray schreiben, ersparen genau die Fleißarbeit, die vor einem Audit sonst Wochen kostet. Wenn Sie prüfen möchten, wie diese Anbindung in Ihrer Umgebung aussehen würde, sprechen Sie mit unserem Team.