In vielen Scrum-Teams sieht der Sprint auf dem Board agil aus – und verläuft trotzdem wie ein kleiner Wasserfall: Die ersten acht Tage wird entwickelt, in den letzten zwei getestet, und was nicht fertig wird, rutscht in den nächsten Sprint. Agiles Testen bedeutet etwas anderes. Qualität entsteht nicht in einer Testphase am Ende, sondern in jedem Schritt des Sprints – vom Refinement bis zum Review. Dieser Artikel zeigt, wie das in der Praxis funktioniert, welche Rolle Tester im Scrum-Team haben und welche Fehler Sie vermeiden sollten.
Agiles Testen ist kein eigenes Testverfahren, sondern eine Arbeitsweise: Tests begleiten die Entwicklung von Anfang an, Feedback kommt in Stunden statt in Wochen, und das ganze Team trägt Verantwortung für Qualität. Im klassischen Vorgehen gibt es eigene Teststufen und -phasen, die nacheinander ablaufen. In Scrum muss am Ende jedes Sprints ein nutzbares, getestetes Inkrement stehen. Eine separate Testphase hat in diesem Takt keinen Platz.
Daraus ergeben sich drei Grundsätze, die Lisa Crispin und Janet Gregory in ihrem Standardwerk „Agile Testing“ geprägt haben und die bis heute gelten:
Wie sich das Testen grundsätzlich zwischen beiden Welten unterscheidet, beschreibt unser Artikel Agiles vs. klassisches Projektmanagement.
Agiles Testen beginnt, bevor die erste Zeile Code geschrieben ist. Im Backlog Refinement prüfen Tester gemeinsam mit Product Owner und Entwicklung, ob eine User Story verständlich und testbar ist. Bewährt hat sich das Format der „Three Amigos“: Fachlichkeit, Entwicklung und Test besprechen eine Story aus ihrer jeweiligen Sicht und halten konkrete Beispiele fest. Formuliert im Muster Gegeben – Wenn – Dann (Given – When – Then) werden aus diesen Beispielen direkt prüfbare Akzeptanzkriterien. Unklare Formulierungen wie „schnell“ oder „benutzerfreundlich“ fallen dabei sofort auf. Wie man Anforderungen von Anfang an sauber beschreibt, zeigt Saubere Anforderungen in IT-Projekten.
Schätzt das Team eine Story, gehört der Testaufwand dazu: Testdaten vorbereiten, Tests automatisieren, explorativ prüfen, Regressionstests anpassen. Wird nur die Entwicklung geschätzt, plant das Team systematisch zu viel ein – und das Testen wird zum Puffer, der am Sprintende fehlt.
Damit kein Mini-Wasserfall entsteht, arbeitet das Team an wenigen Stories gleichzeitig und bringt sie nacheinander zum Abschluss. Sobald eine Story einen testbaren Stand erreicht, wird sie geprüft – nicht erst, wenn alle Stories entwickelt sind. Gefundene Abweichungen werden möglichst direkt im Gespräch geklärt und behoben, statt sie als Ticket in eine Warteschlange zu stellen.
Die Definition of Done (DoD) legt fest, wann eine Story als fertig gilt. Laut Scrum Guide ist sie eine verbindliche Zusage zum Qualitätsniveau des Inkrements. Für das Testen ist sie das wichtigste Werkzeug, denn sie verhindert, dass „fertig“ heimlich „fertig entwickelt, aber noch nicht getestet“ bedeutet. Eine praxistaugliche DoD enthält zum Beispiel:
Wichtig ist, dass die DoD zum Team und zum Produkt passt und mit wachsender Reife des Teams strenger wird.
Welche Tests braucht ein agiles Team? Eine verbreitete Orientierung bieten die agilen Testquadranten, ursprünglich von Brian Marick beschrieben und durch Crispin und Gregory bekannt geworden. Sie ordnen Tests nach zwei Fragen: Unterstützen sie das Team bei der Entwicklung oder bewerten sie das fertige Produkt? Und sind sie eher technisch oder fachlich ausgerichtet?
Der Nutzen liegt im Gesamtbild: Viele Teams decken die Quadranten 1 und 2 gut ab, vernachlässigen aber explorative Tests oder verschieben Performance-Themen bis kurz vor den Go-live. Wie Sie Letztere rechtzeitig angehen, zeigt unser Artikel über Lasttests.
Mit jedem Sprint wächst die Software – und damit die Menge an Funktionen, die nach einer Änderung erneut geprüft werden müssen. Manuell ist das spätestens nach einigen Sprints nicht mehr in der Sprintlänge zu schaffen. Agiles Testen ist deshalb auf Testautomatisierung angewiesen: Unit-Tests als breite Basis, darüber Schnittstellen- und Integrationstests und nur wenige, gezielt ausgewählte Oberflächentests, wie es die Testpyramide beschreibt. Die automatisierten Tests laufen bei jeder Änderung in der CI/CD-Pipeline und liefern Feedback, solange die Änderung noch frisch ist.
Automatisierung ist dabei Teil der Story, nicht ein separates Projekt, das „irgendwann“ nachgezogen wird. Wie Sie dabei vorgehen, beschreiben Testautomatisierung einführen in 6 Schritten und Regressionstests: So sichern Sie stabile Releases ab.
Automatisierte Tests prüfen, was jemand vorher festgelegt hat. Viele kritische Fehler entstehen aber dort, wo niemand daran gedacht hat: ungewöhnliche Eingaben, unerwartete Reihenfolgen, Zusammenspiel mehrerer Funktionen. Hier setzen explorative Tests an. Eine Testerin oder ein Tester erkundet die Anwendung gezielt mit einer klaren Mission, etwa „Rechnungskorrektur mit Sonderfällen prüfen“, in einem festen Zeitfenster. Diese sitzungsbasierte Form macht exploratives Testen planbar und nachvollziehbar – und passt gut in den Sprintrhythmus.
Der Scrum Guide kennt keine Rolle „Tester“. Alle, die am Inkrement arbeiten, sind Developers – also auch Testspezialisten. Das bedeutet nicht, dass Testkompetenz überflüssig wird. Im Gegenteil: Tester bringen Methodenwissen ein, etwa zu Testentwurfsverfahren wie Äquivalenzklassen oder Grenzwertanalyse, stellen im Refinement die unbequemen Fragen und coachen das Team im Testen. Gleichzeitig testen sie nicht allein: Entwickler übernehmen Unit-Tests und helfen bei der Automatisierung, wenn Stories im Test stauen.
Arbeiten mehrere Teams an einem Produkt, braucht es zusätzlich eine übergreifende Koordination: gemeinsame Testumgebungen, Testdaten, teamübergreifende Integrationstests und eine einheitliche Sicht auf den Qualitätsstand vor einem Release. Diese Aufgaben lassen sich in einem schlanken Testkonzept festhalten, auch im agilen Umfeld.
Agiles Testen funktioniert, wenn Qualität vom ersten Gespräch über eine Story an mitgedacht wird: testbare Akzeptanzkriterien im Refinement, realistisch geplanter Testaufwand, Testen parallel zur Entwicklung, eine verbindliche Definition of Done und eine wachsende Testautomatisierung. Tester bleiben dabei unverzichtbar – als Fachleute für Testmethoden und als Impulsgeber für das ganze Team. Mehr über die Haltung hinter Scrum lesen Sie in Agile Transformation: Was Scrum wirklich bedeutet.
Der Scrum Guide sieht keine eigene Testerrolle vor, aber Testkompetenz im Team ist sehr empfehlenswert. Eine Person mit Testerfahrung sorgt für testbare Akzeptanzkriterien, geeignete Testverfahren und eine sinnvolle Automatisierungsstrategie. Die Verantwortung für Qualität trägt trotzdem das ganze Team.
Fachliche Prüfungen finden laufend statt, etwa durch den Product Owner und im Sprint Review. Wo Verträge oder Vorgaben eine formale Abnahme verlangen, wird sie für ein Release geplant und auf Basis der bereits getesteten Inkremente durchgeführt. So bleibt die Abnahme überschaubar und nachvollziehbar.
Nein. Testautomatisierung ist ein wichtiger Baustein, damit Regressionstests im Sprinttakt möglich bleiben. Agiles Testen umfasst aber auch testbare Anforderungen, explorative Tests, nicht-funktionale Tests und die Zusammenarbeit im Team. Automatisierung ohne diese Grundlagen führt nicht zu besserer Qualität.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihre Teams und zeigen, wie sich Testen wirksam in Ihre Sprints integrieren lässt.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: Software-Qualitätssicherung in Hamburg →
Passend dazu: Scrum Master & Agile Coach in Hamburg →