Testmanagement: Vom Testkonzept zur Fortschrittskontrolle

Was ist Testmanagement?

Testmanagement umfasst die Konzeptionierung, Zeitplanung, Schätzung, Überwachung, Berichterstattung, Steuerung und den Abschluss 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.

Testkonzept: Das zentrale Steuerungsdokument

Das Testkonzept ist das Rückgrat des Testmanagements. Es hält fest, was getestet wird, wie es getestet wird, mit welchen Ressourcen und in welchem Zeitrahmen. Ein solides Testkonzept 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: das Testkonzept einmal schreiben und danach nie wieder anfassen. Testkonzepte müssen leben. Ändert sich der Projektumfang, verschieben sich Ressourcen oder tauchen unerwartete Risiken auf, muss das Konzept angepasst werden. Sonst verliert es seine Funktion. Ein veraltetes Testkonzept 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 das Testkonzept 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 Fehler 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.
• Fehler-Metriken: gefundene Fehler nach Schweregrad, Verhältnis gefundener zu behobenen Fehlern, Alterung offener Fehler. Diese Zahlen zeigen, wie schnell der Rückstand abgebaut wird, nicht wie gut die Tests sind.
• Testüberdeckung: Anforderungsüberdeckung, Code-Überdeckung bei automatisierten Tests.
• Testeffektivität: Fehler pro ausgeführtem Testfall, Fehlerfindungsrate (Anteil der im Test gefundenen Fehler an allen später bekannt gewordenen).
• 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 Fehleranzahl 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, Retrospektiven treten an die Stelle formaler Lessons-Learned-Sitzungen. Beim Daily Scrum lohnt eine Präzisierung: Es ist ein 15-Minuten-Event der Developers, in dem sie den Fortschritt zum Sprint Goal prüfen und ihren Plan für den nächsten Tag anpassen. Ein Berichtstermin für Testkennzahlen ist es nicht. Blockierende Testbefunde werden dort natürlich sichtbar, aber das eigentliche Testmonitoring läuft daneben, über Dashboards und die Absprachen im Team. Daraus folgt 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 Azure DevOps oder Jira in Kombination mit Erweiterungen wie Xray unterstützen die Verwaltung von Testfällen und Fehlern 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: Das Testkonzept 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.