Testmanagement: Vom Testplan zur Fortschrittskontrolle

Was ist Testmanagement?

Das ISTQB definiert Testmanagement als “den Prozess der Konzeptionierung, Zeitplanung, Schätzung, Überwachung, Berichterstattung, Steuerung und des Abschlusses von Testaktivitäten”. Diese Aufzählung beschreibt mehr als eine Rolle mit einem Titel auf der Visitenkarte. Sie umreißt eine Funktion, die dafür sorgt, dass Testaktivitäten zielgerichtet, ressourceneffizient und nachvollziehbar ablaufen, statt sich in gut gemeinter Betriebsamkeit zu verlieren.

Ohne Testmanagement entsteht kein reproduzierbarer Prozess. Die Folgen sind in vielen Projekten mit bloßem Auge zu besichtigen: Tests werden ad hoc ausgeführt, Ergebnisse lassen sich nicht vergleichen, Risiken bleiben unkontrolliert. Und am Ende des Projekts weiß niemand mit Bestimmtheit zu sagen, was eigentlich getestet wurde und was nicht. Genau hier setzt Testmanagement an: Es schafft die Grundlage, auf der fundierte Qualitätsentscheidungen überhaupt erst möglich werden, statt Bauchgefühl gegen Termindruck antreten zu lassen.

Kernaufgaben des Testmanagements

Die Aufgaben des Testmanagements umspannen den gesamten Testprozess, von der ersten Planungsidee bis zum formalen Abschluss:

• Planen: Testumfang, Teststrategie, Zeitplan und Ressourcenbedarf festlegen.
• Schätzen: Testaufwand realistisch einschätzen, auf Basis von Erfahrungswerten, Projektgröße und Risikoanalyse.
• Organisieren: Teams aufstellen, Werkzeuge auswählen, Testumgebungen bereitstellen.
• Überwachen: Testfortschritt kontinuierlich verfolgen und Abweichungen früh erkennen.
• Steuern: Bei Abweichungen vom Plan eingreifen und Maßnahmen einleiten.
• Kommunizieren: Stakeholder regelmäßig über Teststand, Risiken und Qualitätssignale informieren.
• Abschließen: Testaktivitäten formal beenden, Erfahrungen dokumentieren, Lessons Learned festhalten.

So sauber sich diese Aufgaben aufzählen lassen, so wenig laufen sie in der Praxis nacheinander ab. Überwachung und Steuerung sind Daueraufgaben, solange der Testprozess läuft. Und auch die Planung ist kein einmaliges Ereignis zu Projektbeginn. Sie wird kontinuierlich fortgeschrieben, sobald die Wirklichkeit vom Plan abweicht. Und das tut sie zuverlässig.

Testplanung: Das zentrale Steuerungsdokument

Der Testplan ist das Rückgrat des Testmanagements. Er hält fest, was getestet wird, wie es getestet wird, mit welchen Ressourcen und in welchem Zeitrahmen. Ein solider Testplan beantwortet zumindest die folgenden Fragen:

• Was ist der Testumfang, und was ist explizit ausgeschlossen?
• Welche Teststufen werden durchgeführt?
• Welche Ein- und Ausstiegskriterien gelten?
• Wer ist für welche Testaktivitäten verantwortlich?
• Welche Testdaten, Testumgebungen und Werkzeuge werden benötigt?
• Wie wird mit Risiken umgegangen?

Zur Testplanung gehört auch die Schätzung des Aufwands. Sie stützt sich auf Erfahrungswerte aus vergleichbaren Projekten, auf die Komplexität der zu testenden Systeme und auf die Ergebnisse der Risikoanalyse. Methoden wie die Dreipunkt-Schätzung oder die Function-Point-Analyse helfen, daraus realistische Werte abzuleiten. Statt einer Zahl, die vor allem den Terminwünschen gefällt.

Ein Fehler begegnet einem dabei besonders häufig: den Testplan einmal schreiben und danach nie wieder anfassen. Testpläne müssen leben. Ändert sich der Projektumfang, verschieben sich Ressourcen oder tauchen unerwartete Risiken auf, muss der Plan angepasst werden. Sonst verliert er seine Funktion. Ein veralteter Testplan ist kein Steuerungsdokument mehr, sondern Archiv. Und niemand steuert ein Projekt aus dem Archiv heraus.

Teststrategie und Risikoorientierung

Die Teststrategie beschreibt das grundsätzliche Vorgehen auf übergeordneter Ebene. Sie legt fest, welche Teststufen zum Einsatz kommen, welche Testarten relevant sind, wie mit Risiken umgegangen wird und wo die Schwerpunkte liegen. Während der Testplan projektspezifisch bleibt, kann eine Teststrategie durchaus organisationsweit gelten und so von Projekt zu Projekt einen gemeinsamen Rahmen vorgeben.

Gutes Testmanagement ist risikobasiert, aus einem einfachen Grund: Nicht jede Funktion trägt dasselbe Risiko, und nicht jedes Risiko rechtfertigt denselben Testaufwand. Die Risikoanalyse betrachtet zwei Dimensionen: die Eintrittswahrscheinlichkeit eines Fehlers und die Auswirkung, wenn er tatsächlich auftritt. Funktionen, bei denen beides hoch ausfällt, werden intensiver getestet. Bereiche mit geringem Risiko erhalten bewusst weniger Aufwand. Wichtig dabei: Risikobasiertes Testen ist keine Rechtfertigung, Qualitätssicherung stillschweigend zu kürzen. Es ist eine Methode, Testressourcen dort zu bündeln, wo sie den größten Nutzen bringen. Das gelingt nur, wenn Risiken explizit identifiziert, bewertet und dokumentiert werden. Nicht bloß im Kopf des Testmanagers herumspuken.

Monitoring, Steuerung und Reporting

Testmonitoring bedeutet, den laufenden Testprozess zu beobachten und fortwährend mit dem Plan abzugleichen. Teststeuerung bedeutet, bei Abweichungen tatsächlich einzugreifen. Beides sind Daueraufgaben für die gesamte Laufzeit des Testprozesses, keine Punkte, die man einmal abhakt. Typische Steuerungsmaßnahmen: Ressourcen neu verteilen, Testprioritäten an das aktuelle Risikobild anpassen, Testziele nachjustieren, wenn sich Anforderungen geändert haben, oder die Einstiegskriterien für spätere Teststufen prüfen, bevor man in sie hineinläuft.

Reporting schließlich macht den Teststand für die Stakeholder transparent. Ein guter Statusbericht enthält den aktuellen Testfortschritt, die gefundenen und offenen Defekte nach Schweregrad, die Risikoabdeckung, die Abweichungen vom Plan und eine klare Einschätzung der Qualitätslage. Ein Statusbericht, der nur grüne Ampeln zeigt, ist dagegen kein guter Statusbericht, sondern ein verdächtig glatter. Er beschreibt keine Realität, er verwaltet Erwartungen. Wer als Testmanager nie unbequeme Zahlen berichtet, hat entweder ein wundersames Projekt oder einen Bericht, dem man nicht trauen sollte.

Metriken im Testmanagement

Metriken machen den Testprozess messbar und geben Diskussionen einen gemeinsamen Bezugspunkt. Zu den wichtigen Metriken im Testmanagement zählen:

• Testfall-Fortschritt: geplante gegen ausgeführte gegen bestandene Testfälle.
• Defekt-Metriken: gefundene Defekte nach Schweregrad, Behebungsrate, Alterung offener Defekte.
• Testüberdeckung: Anforderungsüberdeckung, Code-Überdeckung bei automatisierten Tests.
• Testeffektivität: Defekte pro ausgeführtem Testfall, Verhältnis von gefundenen zu behobenen Defekten.
• Risikoabdeckung: Anteil der identifizierten Risiken, die durch Testaktivitäten adressiert werden.

So nützlich diese Zahlen sind: Sie bleiben Indikatoren und werden nie zu Wahrheiten. Eine hohe Testüberdeckung bedeutet nicht, dass alle kritischen Szenarien geprüft wurden. Und eine geringe Defektanzahl kann zweierlei heißen: Die Software ist gut, oder die Tests sind zu schwach, um etwas zu finden. Metriken müssen deshalb immer im Kontext gelesen werden, nie isoliert. Eine Zahl ohne die Geschichte dahinter führt schneller in die Irre, als sie Orientierung gibt.

Testmanagement in agilen Teams

In agilen Umgebungen verteilen sich die klassischen Testmanagement-Aufgaben auf mehrere Schultern, denn das Scrum-Modell kennt keine explizite Testmanager-Rolle. Die Planung findet im Sprint-Planning statt, das Monitoring ist Teil des Daily Scrum, und Retrospektiven treten an die Stelle formaler Lessons-Learned-Sitzungen. Daraus folgt aber nicht, dass Testmanagement in agilen Projekten überflüssig würde. Nur, dass seine Aufgaben anders zugeschnitten sind.

Wer in agilen Teams Testmanagement verantwortet, braucht deshalb vor allem drei Fähigkeiten: ohne formale Hierarchie koordinieren, über Team-Silos hinweg kommunizieren und Qualitätsrisiken sichtbar machen, solange sie noch Risiken sind und keine Incidents. Werkzeuge wie Jira, Azure DevOps oder Xray unterstützen die Verwaltung von Testfällen und Defekten in iterativen Projekten. Aber sie ersetzen das Denken nicht. Sie schaffen Transparenz, die in schnellen Iterationszyklen anders kaum herzustellen wäre. Und genau diese Transparenz ist es, die aus Werkzeugen einen Nutzen macht.

Typische Stolperfallen

Einige Fehler tauchen im Testmanagement mit einer gewissen Regelmäßigkeit auf, unabhängig von Branche und Projektgröße.

Zu später Testeinstieg: Beginnt die Testplanung erst, wenn die Implementierung bereits läuft, fehlt die Testbasis für die frühen Teststufen. Komponenten werden übergeben, bevor überhaupt Testfälle existieren. Das erzeugt Zeitdruck ausgerechnet in den Phasen, in denen gründliches Testen den größten Unterschied machen würde.

Fehlende Ausstiegskriterien: Ohne klare Kriterien dafür, wann der Test abgeschlossen ist, wird einfach weitergetestet, bis die Zeit abläuft. Das ist kein Prozess, das ist Improvisation. Ausstiegskriterien gehören an den Anfang des Projekts, nicht in die Woche vor dem Release.

Metriken als Ziel: Sobald Testteams für hohe Testfallzahlen optimieren statt für Fehleraufdeckung, verlieren ihre Metriken den Sinn. Viele flache Tests, die wenig finden, sind kein Qualitätsmerkmal. Sie sind eine gut aussehende Kennzahl ohne Substanz.

Isoliertes Testteam: Test als reines Kontrollgremium am Ende der Prozesskette findet Fehler zu spät und zu teuer. Testmanagement muss in den Entwicklungsprozess integriert sein. Nicht als nachgelagerter Filter arbeiten, durch den am Schluss durchrauscht, was vorher niemand angeschaut hat.

Aus der Praxis

Was ich in Projekten immer wieder sehe, ist weniger ein Mangel an Dokumenten als ein Mangel an Gebrauch: Der Testplan existiert, aber niemand schaut mehr hinein. Die Teststrategie wurde im Kick-off präsentiert und seither nie wieder angefasst. Metriken werden brav erhoben, aber nie diskutiert. Das alles ist kein Testmanagement, das ist Dokumentenproduktion. Und dieser Unterschied entscheidet darüber, ob die Arbeit Wirkung entfaltet oder nur Ablage füllt.