Agiles Testmanagement löst ein Paradox: Der klassische Testmanager als zentraler Plan-und-Steuerungs-Knoten passt nicht in selbstorganisierte Sprint-Teams. Trotzdem brauchen agile Organisationen jemanden, der Test-Strategie, Tool-Standards und Cross-Team-Qualität verantwortet. Die Rolle wandelt sich, sie verschwindet nicht.
Dieser Praxis-Guide zeigt dir, wie sich die Tester-Rolle in Scrum-Teams verändert hat, welche Aufgaben pro Sprint anfallen und wie eine Teststrategie aussieht, die Whole-Team-Ansatz und Test-Pyramide vereint. Außerdem bekommst du eine Vergleichstabelle „klassisch vs. agil" und ein konkretes Sprint-Test-Plan-Beispiel aus der Beratungs-Praxis.
Für die Framework-Übersicht (Scrum, Kanban, SAFe) zweigt der Cluster zum Pillar Agiles Testing 2026: Framework-Guide ab. Wer den CI/CD-Werkzeugkasten sucht, springt zu Agiles Testmanagement in der CI/CD-Pipeline.
Inhaltsverzeichnis
Was ist agiles Testmanagement?
Agiles Testmanagement koordiniert Test-Strategie, Tool-Stack und Cross-Team-Qualität in Scrum-, Kanban- oder SAFe-Organisationen. Es ersetzt keine Sprint-interne Testdurchführung, sondern schafft den Rahmen: Welche Test-Stufen gelten? Wie wird Testautomatisierung priorisiert? Welche Tools nutzen wir konzernweit?
Der ISTQB Foundation Level Agile Tester Syllabus (CTFL-AT) beschreibt agiles Testmanagement als Aktivität, die in jedem Sprint stattfindet, nicht als Phase davor oder danach. Der zentrale Begriff: Whole-Team-Ansatz. Qualität ist Verantwortung des gesamten Teams, nicht eines isolierten QA-Silos.
Praxis-Realität: Viele Teams nennen ihre Vorgehensweise „agil", führen aber im Hintergrund klassisches Testmanagement durch. Wer Sprint-Pläne mit V-Modell-Test-Phasen mischt, bekommt das Schlimmste aus beiden Welten. Die 10 goldenen Regeln im Testmanagement 2026 helfen, den Übergang zu strukturieren.
Klassisches vs. agiles Testmanagement
| Kriterium | Klassisch (Wasserfall) | Agil (Scrum/Kanban/SAFe) |
|---|---|---|
| Test-Planung | Einmalig zu Projektstart | Sprint-Planning + PI-Planning, kontinuierlich |
| Testkonzept | Statisches Dokument am Anfang | Lebendes Artefakt, pro Inkrement angepasst |
| Testmanager-Rolle | Gatekeeper, Plan-Verwalter | Coach, Strategie-Architekt, Tool-Vermittler |
| Testdurchführung | Eigenes Team, nach Entwicklung | Im Sprint-Team, parallel zur Entwicklung |
| Testautomatisierung | Optional, oft Nachzügler | Pflicht ab Sprint 1, Teil der Definition of Done |
| Defekt-Behandlung | Bug-Tracking-Tool, oft asynchron | Story-Ticket-Integration, Same-Sprint-Fix |
| Reporting | Test-Status-Berichte pro Phase | Burndown + Defect-Density pro Sprint |
| Risiko-Management | Big-Bang am Projekt-Ende | Pro Sprint, kontinuierliche Reflektion |
Die Tabelle macht deutlich: Es geht nicht nur um andere Tools, sondern um andere Mental-Modelle. Wer als klassischer Testmanager in ein Scrum-Team wechselt, muss die Steuerungs-Aufgaben loslassen und sich auf Strategie + Coaching konzentrieren.
Die Rolle des Testers im Scrum-Team
Im Scrum-Framework gibt es offiziell nur drei Rollen: Product Owner, Scrum Master, Developer. Tester sind „Developer" im Sinne von „cross-funktionalem Team-Mitglied, das zur Lieferung beiträgt". In der Praxis bedeutet das:
- Der Tester ist Teil des Sprint-Teams, nicht extern angehängt
- Er prägt Sprint Planning, Backlog Refinement und Definition of Done aktiv mit
- Er schreibt Test-Code statt nur Test-Skripte zu pflegen
- Er teilt sich die Verantwortung für Qualität mit dem Rest des Teams
Ein häufiges Missverständnis: „Cross-funktional heißt, jeder macht alles." Falsch. Cross-funktional bedeutet, dass alle Fähigkeiten im Team vorhanden sind, nicht dass jede Person alle Fähigkeiten beherrscht. Ein Tester mit Spezialwissen in Performance-Testing oder Security-Testing bleibt Spezialist. Die Framework-Übersicht Scrum/Kanban/SAFe zeigt, wie sich die Rolle je nach Framework unterscheidet.
Aufgaben des Testers pro Sprint
Ein typischer 2-Wochen-Sprint sieht aus Tester-Sicht so aus:
- Tag 1 (Sprint Planning): Akzeptanzkriterien pro Story klären, Definition of Done bestätigen, Test-Aufwand schätzen. Test-Tasks landen direkt im Sprint Backlog.
- Tag 2-3 (Test-Design): Specification by Example und Beispiel-Tabellen erarbeiten. Bei BDD-Teams Gherkin-Szenarien gemeinsam mit Product Owner.
- Tag 3-8 (Sprint-Mitte): Parallel zur Entwicklung Testautomatisierung schreiben, manuelle Tests planen. Pair-Programming mit Entwicklern an Test-Coverage.
- Tag 8-10 (Sprint-Ende): Exploratives Testen, Edge-Case-Verifikation, Defect-Triage. Sprint-Review-Vorbereitung.
- Tag 10 (Review + Retro): Live-Demo der Inkremente, Test-Metriken im Retro besprechen. Was war flaky? Wo fehlt Coverage?
Wichtig: Die manuellen Tests müssen pro Sprint kleiner werden. Andernfalls erstickt der Tester ab Sprint 3 in Regression. Testautomatisierung ist nicht Kür, sie ist Pflicht. Tool-Optionen findest du im Testmanagement-Tools-Vergleich 2026.
Teststrategie im agilen Umfeld
Eine agile Teststrategie steht auf drei Säulen: Test-Pyramide, Risiko-basierter Test-Fokus und Shift-Left-Prinzip.
Test-Pyramide: Viele Unit-Tests an der Basis (schnell, billig, stabil), eine mittlere Schicht Integrations- und Komponententests, eine schlanke Spitze End-to-End-Tests. Wer die Pyramide auf den Kopf stellt (viele E2E-Tests, wenige Unit-Tests), bekommt Flaky-Tests, lange Feedback-Zyklen und teure Wartung.
Risiko-basierter Test-Fokus: Nicht jede Story braucht 80 % Coverage. Kritische Pfade (Authentifizierung, Bezahlung, Datenverarbeitung) brauchen sie. Wenig riskante Stories (CSS-Anpassungen, Text-Änderungen) brauchen sie nicht. Das im Sprint Planning klären, nicht im Code Review.
Shift-Left: Tests starten so früh wie möglich. Akzeptanzkriterien werden im Backlog Refinement geklärt. Static Code Analysis läuft im Pre-Commit-Hook. Unit-Tests im Build. Integrations- und Komponententests im CI-Lauf. Mehr zum klassischen Konzept in Testkonzept nach ISTQB, das auch im agilen Kontext die Grundlage bildet.
Agiles Testmanagement in SAFe und LeSS
Sobald mehrere Teams an einem Produkt arbeiten, brauchst du Cross-Team-Koordination. SAFe und LeSS lösen das unterschiedlich:
SAFe (Scaled Agile Framework): Ein System-Test-Coordinator auf ART-Ebene koordiniert alle Test-Aktivitäten im Agile Release Train. PI-Planning alle 8-12 Wochen klärt gemeinsame Test-Standards. System-Demo am Ende jeder Iteration zeigt das integrierte Inkrement. Wer sich als Testmanager in SAFe zertifizieren will, findet die Optionen in der SAFe-Zertifizierungen-Übersicht.
LeSS (Large-Scale Scrum): Weniger Rollen, mehr Selbstorganisation. Die Test-Koordination findet in Team-übergreifenden Communities of Practice statt. Test-Strategie wird im LeSS Forum besprochen und im Common Sprint Backlog verankert.
Beide Frameworks haben einen Punkt gemeinsam: Auf Team-Ebene bleibt es Scrum oder Kanban. Skalierung ändert nichts an der Sprint-internen Test-Praxis. Sie ergänzt nur die Cross-Team-Schicht. Wer die agile Geschichte vertiefen will, findet sie im Beitrag zum Agilen Manifest und seinen 12 Prinzipien.
Sprint-Test-Plan: Beispiel aus der Praxis
So sieht ein konkreter Sprint-Test-Plan für eine User-Story aus einem E-Commerce-Projekt aus:
| Story | Akzeptanzkriterium | Test-Art | Wer | Automatisiert? |
|---|---|---|---|---|
| Warenkorb-Mengenanpassung | Eingabefeld nur Werte 1-99 | Unit-Test | Entwickler | Ja |
| Warenkorb-Mengenanpassung | Gesamtpreis aktualisiert sich live | Komponenten-Test | Entwickler | Ja |
| Warenkorb-Mengenanpassung | API-Endpunkt /cart/update gibt 200 | API-Test | Tester | Ja |
| Warenkorb-Mengenanpassung | End-to-End-Flow Hinzufügen → Anpassen → Checkout | E2E-Test | Tester | Ja |
| Warenkorb-Mengenanpassung | Accessibility WCAG 2.1 AA | Static + manuell | Tester | Teilweise |
| Warenkorb-Mengenanpassung | Cross-Browser Chrome/Firefox/Safari | Visual-Regression | Tester | Ja (Playwright) |
| Warenkorb-Mengenanpassung | Performance unter 200 Concurrent Users | Last-Test | Performance-Tester | Ja (k6) |
Sechs der sieben Test-Arten sind automatisiert. Die manuelle Schicht beschränkt sich auf das, was Tools nicht abdecken (Usability, kontextuelle Accessibility-Bewertung). Genau diese Aufteilung skaliert auf 100 Stories pro Sprint, klassische Test-Pläne nicht.
Stolperfallen und Anti-Patterns
- Tester ohne Sprint-Stimme: Wer im Sprint Planning nur zuhört, statt Akzeptanzkriterien aktiv zu prägen, bleibt Auftragsempfänger. Im Backlog Refinement aktiv werden, sonst kommt das Test-Design zu spät.
- Definition of Done ohne Test-Anforderungen: Wenn die DoD nur „Code Review passed" sagt, gibt es kein gemeinsames Qualitätsverständnis. Pflicht-Felder: Unit-Test grün, Akzeptanzkriterien erfüllt, manuelle Smoke-Tests durchgelaufen.
- Test-Cases statt Test-Code: Ein 200-seitiger Excel-Test-Plan im Sprint ist kein agiles Testen. Test-Spezifikation in Gherkin oder als ausführbare Specification by Example macht Tests zur Single Source of Truth.
- Bug-Backlog als Friedhof: Defekte stauen sich, weil sie „später gefixt" werden. Regel: Defects from current Sprint = Same Sprint Fix. Alles andere wird priorisiert wie eine User Story.
- Tester gegen Entwickler: Wenn der Tester der „Bug-Finder" und der Entwickler der „Bug-Erzeuger" ist, leidet das Team. Pair-Testing und gemeinsames Test-Design lösen das Anti-Pattern auf.
- Whole-Team in Theorie, Silo in Praxis: Viele Teams nennen sich „Whole Team", aber Tests landen am Sprint-Ende beim Tester. Sichtbarer Indikator: Welche Spalte auf dem Board hat den Stau? Wenn „In Test" der Engpass ist, gibt es kein echtes Whole-Team-Testing. Vertiefung der Praxis-Regeln im Testmanagement-Guide 2026.
Fazit
Agiles Testmanagement ist nicht das Gegenteil von klassischem Testmanagement, sondern die Anpassung an iterative Liefer-Zyklen. Die Test-Strategie braucht Test-Pyramide, Risiko-Fokus und Shift-Left. Die Tester-Rolle wechselt von Gatekeeper zu Coach und Sprint-Team-Mitglied. Die Definition of Done verankert Test-Anforderungen.
Wer als klassischer Testmanager in ein agiles Team kommt, sollte zwei Dinge mitbringen: technische Code-Skills und die Bereitschaft, Steuerungs-Aufgaben loszulassen. Wer als agiler Tester in ein klassisches Team kommt, sollte den Mut haben, Test-First und Whole-Team-Ansatz zu propagieren. Mehr zur Rolle des Testmanagers im klassischen Kontext findest du in Was macht ein Testmanager?.
FAQ
Was unterscheidet einen agilen Tester von einem klassischen Tester?
Der klassische Tester arbeitet nach festen Phasen mit definierten Test-Stufen. Der agile Tester arbeitet in jedem Sprint parallel zur Entwicklung, automatisiert von Beginn an und gestaltet Akzeptanzkriterien aktiv mit. Code-Skills sind Pflicht, nicht Kür.
Brauche ich als Testmanager eine SAFe-Zertifizierung?
Wenn dein Unternehmen SAFe einführt: Ja. Die SAFe Practice Consultant (SPC) oder Release Train Engineer (RTE) Zertifizierung gibt dir den Fachkontext. Eine Übersicht der relevanten Zertifizierungen für Testmanager findest du in der SAFe-Zertifizierungen-Übersicht.
Wie schreibe ich eine agile Teststrategie?
In drei Schritten: 1) Test-Pyramide festlegen (welche Test-Stufen, welcher Anteil). 2) Risiko-Klassifizierung pro Story-Typ (kritisch vs. niedrig). 3) Definition of Done mit Test-Anforderungen verankern. Konkrete Vorlagen im Testkonzept-Artikel.
Wann scheitert agiles Testmanagement?
Wenn der Whole-Team-Ansatz nur Lippenbekenntnis ist, wenn Testautomatisierung als „später-mal" priorisiert wird und wenn die Definition of Done keine Test-Anforderungen enthält. Im SAFe-Kontext zusätzlich: Wenn der System-Test-Coordinator als Vollzeit-Steuerer statt als Strategie-Coach agiert.
Welche Rolle hat der Testmanager in selbstorganisierten Teams?
Coach statt Steuerer. Er definiert Test-Strategie, Tool-Standards und Cross-Team-Konventionen. Operative Testdurchführung delegiert er ins Sprint-Team. In SAFe-Organisationen heißt diese Rolle oft „System-Test-Coordinator" oder „Quality Architect".
Wie viel Testautomatisierung brauche ich in agilen Teams?
Pflicht für Unit-Tests, Integrationstests und Smoke-Tests pro Story. Empfehlung für API-Tests bei Service-Grenzen. End-to-End-Tests bleiben schlank (10-20 % der Test-Suite). Manuelle Tests konzentrieren sich auf Exploratives Testen, Usability und Accessibility.
Was ist der Whole-Team-Ansatz im agilen Testing?
Qualität ist Aufgabe des gesamten Teams, nicht nur des Testers. Entwickler schreiben Unit-Tests. Tester schreiben API- und E2E-Tests. Product Owner formuliert Akzeptanzkriterien. Scrum Master entfernt Test-Blocker. Niemand schiebt Qualität ab.