Agiles Testing ist 2026 die Default-Vorgehensweise in Scrum-, Kanban- und SAFe-Teams. Trotzdem scheitern viele Teams daran, dass sie agile Rituale übernehmen, aber den Test-Prozess noch wie im Wasserfall führen: spät, separiert, von einem isolierten QA-Team.
Dieser Framework-Guide zeigt dir die vier Prinzipien, die ein wirklich agiles Testing-Setup tragen, und wie sich der Test-Prozess in Scrum, Kanban und SAFe konkret unterscheidet. Du bekommst eine Vergleichstabelle, Tool-Empfehlungen und die häufigsten Anti-Patterns, die wir aus über 15 Jahren Beratungs-Praxis kennen.
Für die Praxis-Tiefe „Rolle des Testers und agiles Testmanagement" zweigt der Cluster zu Agiles Testmanagement: Rolle des Testers in Scrum & SAFe ab. Wer Testautomatisierung in die CI/CD-Pipeline einbauen möchte, springt zu Agiles Testmanagement in der CI/CD-Pipeline.
Inhaltsverzeichnis
Was ist agiles Testing?
Agiles Testing bedeutet, dass die Qualitätssicherung Teil jedes Sprints oder Flows ist, nicht eine nachgelagerte Phase. Tester arbeiten als gleichberechtigte Mitglieder im cross-funktionalen Team. Sie schreiben Akzeptanzkriterien gemeinsam mit Product Ownern, automatisieren Tests parallel zur Entwicklung und prüfen jedes Inkrement vor dem Sprint-Review.
Das Konzept geht zurück auf das Agile Manifest von 2001 und die 12 Prinzipien, die Continuous Delivery und kontinuierliche Verbesserung in den Mittelpunkt stellen. Im ISTQB Foundation Level Syllabus wird agiles Testing seit 2018 als eigene Kategorie geführt und in der CTFL-AT-Erweiterung vertieft.
Die wichtigste Abgrenzung zum klassischen Testen: Im Wasserfall war Testen eine Phase am Ende. Im agilen Vorgehen ist Testen eine Aktivität, die in jeder Phase stattfindet. Diese Verschiebung verändert Rollen, Werkzeuge und Metriken grundlegend.
Die 4 Prinzipien des agilen Testens
Vier Prinzipien tragen agiles Testing. Wer eines davon weglässt, baut nur „Wasserfall mit Sprints".
1. Whole-Team-Ansatz: Qualität ist Aufgabe des gesamten Teams. Tester, Entwickler, Product Owner und Stakeholder klären gemeinsam, was „fertig" bedeutet. Die Rolle des Testers verschwindet nicht, sie wandelt sich vom Gatekeeper zum Coach. Mehr dazu in Agiles Testmanagement: Rolle des Testers.
2. Test-First-Mentalität: Tests werden geschrieben, bevor Code entsteht. Test-Driven Development (TDD) und Acceptance-Test-Driven Development (ATDD) machen Tests zum Design-Werkzeug. Specification by Example und Behavior-Driven Development verankern Akzeptanzkriterien als ausführbare Spezifikation.
3. Shift-Left-Testing: Tests starten so früh wie möglich. Static Code Analysis im Pre-Commit-Hook, Unit-Tests im Build, Integrations- und Komponententests im Continuous-Integration-Lauf. Je früher ein Defekt entdeckt wird, desto günstiger die Behebung.
4. Continuous Testing: Jede Code-Änderung läuft durch eine automatisierte Test-Pipeline. Die CI/CD-Pipeline ist das Rückgrat. Manuelle Tests konzentrieren sich auf Exploratives Testen, Usability und Edge-Cases, die Automatisierung nicht abdeckt.
Agiles Testing in Scrum
Scrum gibt agilem Testing einen festen Rhythmus durch zweiwöchige Sprints. Der Tester nimmt an allen fünf Scrum-Events teil und prägt sie mit:
- Sprint Planning: Akzeptanzkriterien pro Story klären, Definition of Done um Test-Anforderungen ergänzen, Test-Aufwand schätzen.
- Daily Scrum: Blocker im Test-Setup, Flakiness-Probleme und offene Defekte werden täglich sichtbar gemacht.
- Sprint Review: Die Inkremente werden vom Tester live demonstriert. Manuelle und automatisierte Tests müssen vor dem Review grün sein.
- Sprint Retrospektive: Test-Metriken (Bug-Backlog, Flaky-Quote, Coverage) fließen in die Team-Verbesserung ein.
- Backlog Refinement: Hier entsteht das eigentliche Test-Design. Specification by Example und Beispiel-Tabellen machen Anforderungen testbar.
Wichtig: Ein Sprint ohne automatisierte Tests skaliert nicht. Nach drei Sprints ist die Regression-Last so groß, dass manuelle Tests den Sprint sprengen. Wer in Scrum agiles Testing einführt, plant Testautomatisierung von Sprint 1 an mit. Tool-Optionen findest du in unserem Testmanagement-Tools-Vergleich 2026.
Agiles Testing in Kanban
Kanban kennt keine Sprints, sondern kontinuierlichen Fluss mit Work-in-Progress-Limits. Agiles Testing in Kanban heißt: Jede Story durchläuft eigene Test-Stages, die als Spalten auf dem Board sichtbar sind.
Typische Test-Spalten: „In Development", „Code Review", „In Test", „Ready for Release". Das WIP-Limit pro Spalte verhindert, dass ungetestete Stories sich anstauen. Wenn die „In Test"-Spalte ihr Limit erreicht, müssen Entwickler beim Testen helfen statt neue Stories zu starten.
Die Test-Pyramide hat in Kanban einen besonders hohen Stellenwert: Da es keinen festen Sprint-End-Punkt gibt, muss jede Story einzeln deploybar sein. Das funktioniert nur mit Unit-Tests an der Basis, Komponententests in der Mitte und einer schlanken End-to-End-Schicht obendrauf. Im Testmanagement-Praxis-Guide 2026 findest du die 10 Praxis-Regeln, die in Kanban-Teams den Unterschied machen.
Agiles Testing in SAFe
SAFe (Scaled Agile Framework) bringt Scrum, Kanban und Lean auf Enterprise-Niveau. Agiles Testing skaliert hier auf mehreren Ebenen.
Auf Team-Ebene arbeitet jedes ART-Team (Agile Release Train) wie ein Scrum- oder Kanban-Team mit eigener Test-Pipeline. Auf Programm-Ebene koordiniert die System-Test-Funktion alle Teams im ART. Auf Solution-Ebene findet System-Demo und Hardening-Sprint statt. Auf Portfolio-Ebene entscheiden Business-Owner über Test-Standards und Compliance.
Die wichtigsten SAFe-Test-Praktiken: Continuous Exploration im Sprint 0, System-Demo am Ende jeder Iteration, Innovation- and Planning-Iteration alle 5 Sprints (PI-Cadence), gemeinsame Test-Standards und Tool-Stacks über alle ARTs hinweg. Wer ein SAFe-Zertifikat als Testmanager oder Tester anstrebt, findet die Optionen in der SAFe-Zertifizierungen-Übersicht.
Vergleich Scrum vs. Kanban vs. SAFe
| Kriterium | Scrum | Kanban | SAFe |
|---|---|---|---|
| Rhythmus | 2-Wochen-Sprint | Kontinuierlicher Fluss | PI alle 8-12 Wochen, Sprints im PI |
| Test-Planung | Sprint Planning | Story-individuell | PI-Planning + Sprint Planning |
| Test-Cadence | Sprint-Ende = Release-fähig | Story-fertig = Release-fähig | System-Demo pro Sprint, Release on Demand |
| Test-Automatisierung | Unverzichtbar ab Sprint 1 | WIP-Limit erzwingt Automatisierung | Standardisiert über alle ARTs |
| Testmanager-Rolle | Ko-aktiv im Team | Flow-Coach + QA-Coach | System-Test-Coordinator auf Programm-Ebene |
| Skalierung | Bis ca. 9 Personen | Bis ca. 12 Personen | 50-1000+ Personen |
| Test-Reporting | Burndown + Done-Quote | Cycle-Time + Defect-Density | ART-Health + Predictability |
Die Wahl des Frameworks ist selten frei. Sie hängt von der Team-Größe, der Release-Frequenz und der bestehenden Org-Struktur ab. Wichtig: Auch im SAFe-Kontext ist die Team-Ebene Scrum oder Kanban. Agiles Testing skaliert nicht durch ein anderes Framework, sondern durch konsequente Test-Automation und gemeinsame Standards.
Tools für agiles Testing
Drei Werkzeug-Kategorien tragen agiles Testing:
- Testmanagement: Xray for Jira, Zephyr Scale, TestRail, Tricentis qTest. Diese Tools verknüpfen Test-Cases mit User-Stories und Akzeptanzkriterien. Detaillierter Vergleich in Testmanagement-Tools 2026.
- Test-Automation: Playwright und Cypress für Web, Selenium für Legacy-Stack, k6 und Gatling für Performance, Postman/Bruno für API-Tests.
- CI/CD-Integration: GitHub Actions, GitLab CI, Jenkins. Test-Suites laufen bei jedem Push, Ergebnisse landen direkt im Story-Ticket.
Ein häufiger Fehler: Teams kaufen ein Testmanagement-Tool, bevor sie die Test-Strategie definiert haben. Das Tool wird dann zur Doku-Last statt zum Beschleuniger. Erst Prozess, dann Tool. Mehr dazu im Konzept-Hub Testkonzept nach ISTQB.
Anti-Patterns im agilen Testing
Diese sechs Anti-Patterns sehen wir in Beratungs-Projekten am häufigsten:
- Mini-Wasserfall im Sprint: Entwickler entwickeln die ersten 7 Tage, Tester testen die letzten 3. Resultat: Tester finden Bugs zu spät, das Inkrement schafft es nicht ins Review.
- Hardening-Sprint als Regel: Wer alle 4 Sprints einen reinen Test-Sprint braucht, hat keine echte Definition of Done. Hardening sollte die Ausnahme bei Major-Releases sein, nicht der Default.
- Manuelle Regression in Scrum: Nach Sprint 3 dauert die manuelle Regression einen ganzen Sprint. Testautomatisierung ist nicht „nice-to-have".
- QA-Silo statt Whole-Team: Tester sitzen in einem eigenen Team, das alle anderen Teams testet. Übergaben kosten Zeit und produzieren Kommunikations-Defekte.
- Tester ohne Code-Skills: Wer in agilen Teams nicht automatisieren kann, bleibt manueller Klick-Tester und wird zum Engpass. Pair-Programming mit Entwicklern ist der schnellste Pfad in die Automatisierung.
- Tooling vor Prozess: Ein Xray-Setup, das keiner pflegt, ist schlimmer als kein Tool. Test-Strategie und Definition of Done müssen stehen, bevor das Tool ausgerollt wird.
Fazit
Agiles Testing ist nicht Wasserfall mit kürzeren Phasen. Es ist eine grundlegend andere Art, Qualität zu sichern: Test-First, im Team, automatisiert und kontinuierlich. Scrum gibt den Rhythmus, Kanban den Fluss, SAFe die Skalierung. Was alle drei brauchen: eine geklärte Tester-Rolle, eine Test-Pyramide und eine CI/CD-Pipeline mit echten Test-Stages.
Wer 2026 in agilen Teams testet, kommt um Testautomatisierung nicht herum. Die Frage ist nicht ob, sondern womit. Starte mit den 10 Praxis-Regeln aus unserem Testmanagement-Guide 2026 und vertiefe die Tester-Rolle in Agiles Testmanagement & Rolle des Testers.
FAQ
Was ist der Unterschied zwischen agilem Testen und klassischem Testen?
Klassisches Testen ist eine Phase nach der Entwicklung. Agiles Testen ist eine Aktivität in jeder Phase. Im klassischen Modell isoliert ein QA-Team die Tests, im agilen Modell ist Qualität Aufgabe des gesamten Teams. Tester sind Mitglieder im Sprint-Team und prägen Sprint Planning, Refinement, Review und Retrospektive aktiv mit.
Brauche ich für agiles Testing zwingend Testautomatisierung?
Spätestens ab Sprint 3 ja. Die Regression-Last wächst pro Sprint, und manuelle Regression skaliert nicht. Starte mit Unit-Tests für Kern-Logik und API-Tests für Service-Grenzen. End-to-End-Tests kommen zuletzt und bleiben schlank. Mehr zur Test-Pyramide in Agiles Testmanagement & Teststrategie.
Welche Rolle hat der Testmanager in Scrum?
Die klassische Rolle „Testmanager als Projekt-Gatekeeper" gibt es in Scrum nicht. Stattdessen wirkt der Testmanager als Coach für Test-Strategie, Tool-Auswahl und Cross-Team-Standards. Die operative Testdurchführung liegt im Sprint-Team. Details in unserem Schwester-Artikel Was macht ein Testmanager?.
Wie funktioniert Test-Driven Development in Scrum?
Der Entwickler schreibt zuerst einen Unit-Test, der fehlschlägt. Dann implementiert er den Code, bis der Test grün ist. Danach folgt Refactoring. TDD ist kein Test-Verfahren, sondern eine Design-Praxis. Sie reduziert Defekte und sorgt für hohe Test-Coverage als Nebenprodukt.
Was ist Shift-Left-Testing?
Shift-Left bedeutet: Tests laufen so früh wie möglich. Static Code Analysis im Pre-Commit, Unit-Tests im Build-Job, Integrations- und Komponententests im Continuous-Integration-Lauf. Ein im Sprint Planning gefundener Anforderungs-Konflikt kostet Minuten. Derselbe Konflikt im Sprint Review kostet einen halben Sprint.
Welche Tools brauche ich für agiles Testing?
Drei Kategorien: Testmanagement (Xray, Zephyr, TestRail), Testautomatisierung (Playwright, Cypress, Selenium, k6) und CI/CD (GitHub Actions, GitLab CI, Jenkins). Vergleich der Testmanagement-Tools im Tools-Hub 2026.
Wie skaliert agiles Testing in SAFe?
Die Team-Ebene bleibt Scrum oder Kanban. Auf Programm-Ebene koordiniert ein System-Test-Coordinator alle Teams im Agile Release Train. PI-Planning klärt Test-Standards alle 8-12 Wochen. System-Demo am Ende jeder Iteration zeigt das integrierte Inkrement. Continuous Exploration in Sprint 0 schafft die Test-Infrastruktur für das kommende PI.