Agiles Testen in Scrum: Der vollstaendige Leitfaden 2026

Von Abhay Talreja

17.2.2026

Mein neuester Artikel - Empirical Process Control - The Key to Agile Success

Agiles Testen ist keine Phase, die nach der Entwicklung stattfindet - es ist eine kontinuierliche Disziplin, die in jeden Sprint, jedes Standup und jede Codezeile eingewoben ist. In Scrum-Teams ist Qualitaet eine gemeinsame Verantwortung: Entwickler schreiben Tests vor dem Code, das gesamte Team definiert Akzeptanzkriterien, und Tests stauen sich nie am Ende einer Iteration an.

Dieser Leitfaden deckt alles ab, was Sie fuer eine effektive Umsetzung von agilen Testen benoetigen: die Testpyramide, Agile Testing Quadranten, TDD/BDD/ATDD-Praktiken, Shift-Left-Strategien, branchenspezifische Checklisten, ein Reifegradmodell und die haeufigsten Anti-Patterns, die die Qualitaet untergraben.

Was Sie lernen werden

• Wie sich agiles Testen von traditioneller QA unterscheidet und warum es bessere Ergebnisse liefert
• Die Testpyramide und das richtige Verhaeltnis von Unit-, Integrations- und End-to-End-Tests
• Die vier Agile Testing Quadranten und wann welcher Typ anzuwenden ist
• Wie TDD, BDD und ATDD innerhalb von Scrum zusammenpassen
• Shift-Left-Testing und wie Qualitaet von Anfang an integriert wird
• Wie Testing auf Sprint Planning, Daily Scrum, Sprint Review und Retrospektive abgestimmt wird
• Branchenspezifische Test-Checklisten fuer Healthcare, Fintech, E-Commerce und mehr
• Ein dreistufiges Reifegradmodell fuer agiles Testen
• Acht haeufige Test-Anti-Patterns und wie man sie behebt

Schnellantwort: Agiles Testen auf einen Blick

Was ist agiles Testen?

Agiles Testen ist ein Ansatz zur Softwarequalitaetssicherung, der mit agilen Werten uebereinstimmt: Zusammenarbeit, kontinuierliches Feedback, Kundenfokus und Reaktionsfaehigkeit auf Veraenderungen. Anstatt Tests als einen Uebergabeschritt am Ende eines Sprints oder Releases zu behandeln, integriert agiles Testen Qualitaetspruefungen direkt in den Entwicklungsworkflow.

Der wesentliche Unterschied zum traditionellen Testen liegt im Timing und in der Eigenverantwortung:

• Traditionelle QA: Entwickler beenden das Codieren, uebergeben dann an ein separates QA-Team, das testet und eine Fehlerliste zuruecksendet, die Entwickler vor dem naechsten Uebergabe bearbeiten muessen.
• Agiles Testen: Das Testen beginnt bevor Code geschrieben wird (durch TDD und ATDD), laeuft parallel zur Entwicklung und bezieht das gesamte Scrum-Team ein.

Diese Verlagerung reduziert die Kosten fuer die Fehlerbehebung dramatisch. Forschungen des Systems Sciences Institute bei IBM zeigen, dass Fehler, die nach dem Release gefunden werden, 6-mal mehr kosten als Fehler, die waehrend des Designs gefunden werden, und 15-mal mehr als Fehler, die waehrend des Codierens gefunden werden.

Prinzipien des agilen Testens

Sechs Kernprinzipien fuer agiles Testen in jedem Scrum-Team:

1. Qualitaetsverantwortung des gesamten Teams Testen ist keine QA-Abteilungsfunktion. Jedes Teammitglied - Entwickler, Designer, Tester und Product Owner - teilt die Verantwortung fuer die Produktqualitaet.

2. Kontinuierliches Testen, kein phasenbasiertes Testen Tests werden waehrend jedes Sprints staendig geschrieben und ausgefuehrt. Das Warten mit dem Testen bis die Entwicklung abgeschlossen ist, schafft Engpaesse und verzoegert Feedback.

3. Kundenorientierte Akzeptanzkriterien Der Product Owner arbeitet mit dem Team zusammen, um klare Akzeptanzkriterien zu schreiben, bevor die Sprint-Arbeit beginnt.

4. Schnelle Feedback-Schleifen Tests muessen schnell ausgefuehrt werden. Unit-Test-Suiten sollten in unter 5 Minuten abgeschlossen sein, und vollstaendige CI-Pipeline-Laeufe in unter 20 Minuten.

5. Testautomatisierung als erstklassige Aktivitaet Automatisierung ist eine Investition in nachhaltige Geschwindigkeit. Teams, die Regressionstests automatisieren, verbringen weniger Zeit mit sich wiederholender Verifizierung.

6. Anpassungsfaehige Teststrategien Testansaetze entwickeln sich Sprint fuer Sprint weiter. Die Retrospektive ist der richtige Ort, um Teststrategien zu inspizieren und anzupassen.

Die Testpyramide

Die Testpyramide bietet ein Modell zum Ausbalancieren von Testtypen nach Geschwindigkeit, Kosten und Abdeckung. Agile Teams verwenden sie, um das "Eistuetenm-Anti-Pattern zu vermeiden (zu viele langsame, teure End-to-End-Tests und zu wenige schnelle Unit-Tests).

         /\
        /  \
       / E2E\     ~10% der Tests
      /------\
     /        \
    /Integration\  ~20% der Tests
   /------------\
  /              \
 /   Unit-Tests   \  ~70% der Tests
/------------------\

Unit-Tests (Basisschicht)

Unit-Tests verifizieren einzelne Funktionen, Methoden oder Klassen in vollstaendiger Isolation von externen Abhaengigkeiten. Sie sind:

• Schnell: Laufen in Millisekunden, gesamte Suite in unter 2 Minuten
• Guenstig: Einfach zu schreiben, leicht zu warten
• Praezise: Pinpointieren genau, welche Funktion fehlgeschlagen ist
• Hochvolumig: Anstreben von 70% Ihrer gesamten Testanzahl

Abdeckungsziel: Anstreben von >80% Code-Coverage auf Unit-Ebene.

Integrationstests (Mittelschicht)

Integrationstests verifizieren, dass zwei oder mehr Komponenten korrekt zusammenarbeiten. Sie testen echte Interaktionen zwischen Diensten, Datenbanken oder APIs:

• Mittlere Geschwindigkeit: Laufen in Sekunden bis wenigen Minuten
• Mittlere Kosten: Mehr Einrichtung erforderlich
• Kritische Abdeckung: Datenbankabfragen, API-Vertraege, Nachrichtenwarteschlangen-Interaktionen

Abdeckungsziel: 20% Ihrer Testanzahl, fokussiert auf kritische Integrationspunkte.

End-to-End-Tests (Spitze)

End-to-End-Tests simulieren vollstaendige Benutzerreisen durch das gesamte System, von der UI bis zur Datenbank:

• Langsam: Laufen in Minuten bis Zehnten von Minuten
• Teuer: Erfordern vollstaendige Umgebung, anfaellig fuer UI-Aenderungen
• Hohes Vertrauen: Beweisen, dass kritische Benutzerreisen funktionieren
• Niedriges Volumen: Auf 10% der gesamten Tests oder weniger beschraenken

Agile Testing Quadranten

Brian Maricks Agile Testing Quadranten bieten eine Karte fuer das Nachdenken ueber verschiedene Testkategorien, wer sie leitet und wann sie verwendet werden.

Die Quadranten sind auf zwei Achsen organisiert:

• Horizontal: Technologieorientiert vs. Geschaeftsorientiert
• Vertikal: Tests, die das Team unterstuetzen vs. Tests, die das Produkt kritisieren

Quadrant 1 - Technologieorientierte Tests

Zweck: Entwickler beim Schreiben von sauberem, korrektem Code leiten.

Testtypen: Unit-Tests, Komponenten-Tests, Integrationstests

Wer leitet: Entwickler

Tools: JUnit, Jest, pytest, Vitest, Testcontainers

Quadrant 2 - Geschaeftsorientierte unterstuetzende Tests

Zweck: Bestaetigen, dass das System das tut, was das Geschaeft benoetigt.

Testtypen: Funktionstests, Beispiele und Prototypen, Story-Tests aus Akzeptanzkriterien

Wer leitet: Das gesamte Team - Product Owner schreibt Kriterien, Entwickler und Tester automatisieren sie

Tools: Cucumber, SpecFlow, FitNesse, Robot Framework

Quadrant 3 - Geschaeftsorientierte kritisierende Tests

Zweck: Fehler und Luecken finden, die das Team nicht erwartet hat.

Testtypen: Exploratives Testen, Usability-Tests, User Acceptance Testing (UAT), Alpha/Beta-Tests

Wer leitet: Tester, UX-Spezialisten, echte Benutzer, Product Owner

Quadrant 4 - Technologieorientierte kritisierende Tests

Zweck: Nicht-funktionale Qualitaeten des Systems unter realistischen Bedingungen evaluieren.

Testtypen: Performance- und Lasttests, Security Penetrationstests, Zugaenglichkeitstests, Stress-Tests

Tools: k6, JMeter, Gatling (Performance); OWASP ZAP, Burp Suite (Security); axe, Lighthouse (Zugaenglichkeit)

TDD, BDD und ATDD

Diese drei Praktiken repraesentieren verschiedene Ebenen des test-first-Denkens. Sie ergaenzen sich gegenseitig.

Test-Driven Development (TDD)

TDD ist eine Entwicklerpraktik, die einem engen Rot-Gruen-Refaktorisieren-Zyklus folgt:

1. Rot: Einen fehlschlagenden Unit-Test schreiben, der das gewuenschte Verhalten beschreibt
2. Gruen: Den minimalen Produktionscode schreiben, der notig ist, um diesen Test zu bestehen
3. Refaktorisieren: Den Code bereinigen, waehrend alle Tests grueen bleiben

Vorteile von TDD:

• Zwingt Entwickler, ueber das Design nachzudenken, bevor Code geschrieben wird
• Erstellt als natuerliches Nebenprodukt eine umfassende Unit-Test-Suite
• Reduziert Debugging-Zeit, da Fehler sofort abgefangen werden

Behavior-Driven Development (BDD)

BDD erweitert TDD nach oben: Anstatt einzelne Funktionen zu testen, testet es Verhaltensweisen, die fuer das Geschaeft wichtig sind. BDD verwendet ein strukturiertes Gegeben-Wenn-Dann-Format.

BDD-Beispiel (Gherkin-Syntax):

Feature: Warenkorb-Rabatt
  Szenario: Kunde erhaelt Rabatt auf grosse Bestellung
    Gegeben ein Kunde hat Artikel im Wert von 150 EUR im Warenkorb
    Wenn er zur Kasse geht
    Dann soll ein Rabatt von 10% (15 EUR) angewendet werden
    Und die Gesamtsumme soll 135 EUR betragen

Acceptance Test-Driven Development (ATDD)

ATDD ist BDD auf Story-Ebene angewendet. Das gesamte Scrum-Team (Product Owner, Entwickler und Tester) arbeitet zusammen, um Akzeptanztests bevor die Entwicklung beginnt zu definieren.

Shift-Left-Testing

Shift-Left-Testing bedeutet, Testaktivitaeten frueher in den Entwicklungsprozess zu verlagern.

Kontinuierliches Testen im Scrum-Sprint

Testen geschieht nicht "waehrend des Sprints" als einzelne Aktivitaet. Es ist in jedes Scrum-Event und jeden Arbeitstag eingebettet.

Sprint Planning

• Akzeptanzkriterien fuer Sprint-Backlog-Elemente ueberpruefen und verfeinern
• Testansatz (Unit, Integration, E2E) pro Story identifizieren
• Die Definition of Done umfasst Testkriterien bestaetigen

Daily Scrum

• Test-Blocker aufdecken
• Testergebnisse vom Vortag teilen
• Aufkommende Fehler identifizieren, bevor sie sich vervielfachen

Waehrend der Entwicklung (Jeden Tag)

• Entwickler schreiben Unit-Tests vor oder neben dem Code (TDD)
• Tester schreiben automatisierte Akzeptanztests fuer laufende Stories (ATDD)
• CI-Pipeline laeuft bei jedem Commit: Linting, Unit-Tests, Integrationstests

Sprint Review

• Funktionalitaet gegen die zu Beginn des Sprints vereinbarten Akzeptanzkriterien demonstrieren
• Stakeholder fuehren exploratives Testen waehrend der Review durch

Sprint-Retrospektive

• Test-Metriken aus dem Sprint ueberpruefen (Abdeckung, Defekt-Escape-Rate, Testausfuehrungszeit)
• Testengpaesse oder langsame Tests identifizieren
• Verbesserungen an der Teststrategie planen

Testen-Rollen in Scrum

Entwickler

• Unit-Tests schreiben (TDD-Disziplin)
• Integrationstests fuer ihren Code schreiben
• Eigene Fehler am selben Tag beheben, an dem sie gefunden werden

Tester (QA-Ingenieure)

• Akzeptanztestdesign vorantreiben (ATDD-Facilitation)
• Die automatisierte Testsuite aufbauen und warten
• Exploratives und sitzungsbasiertes Testen durchfuehren

Product Owner

• Klare, testbare Akzeptanzkriterien fuer jede Story definieren
• Am "Drei Freunde"-Meeting teilnehmen
• Implementierung gegen Akzeptanzkriterien in Sprint Review validieren

Automatisierungsstrategie fuer agile Teams

Was automatisieren:

• Regressionstests: Jeder Test, der mehr als zweimal manuell ausgefuehrt wurde
• Smoke-Tests: Grundlegende Funktionspruefungen bei jedem CI-Build
• API-Tests: Vertraege zwischen Diensten validieren
• Datenbankgesteuerte Tests: Tests, die dieselbe Logik mit verschiedenen Eingaben wiederholen
• Akzeptanztests: BDD/Cucumber-Szenarien aus Akzeptanzkriterien

Was manuell behalten:

• Exploratives Testen: Kreative Erkundung nach unerwartetem Verhalten
• Usability-Tests: Auswerten, ob echte Benutzer Aufgaben intuitiv ausfuehren koennen
• Einmalige Tests: Tests fuer Features, die sich nach dem Release nicht aendern werden

Branchenspezifische Test-Checklisten

SaaS / Cloud-Dienste

• Unit-Tests bestehen mit >80% Code-Coverage
• API-Vertragstests bestehen fuer alle Service-Versionen
• Lasttests verifizieren Antwortzeit <200ms beim 95. Perzentil unter 1.000 gleichzeitigen Benutzern
• Multi-Tenant-Datenisolation verifiziert (Mandant A kann nicht auf Mandant B-Daten zugreifen)
• Rollback-Verfahren getestet und dokumentiert

Gesundheitssoftware (HIPAA/FDA)

• Alle PHI-Felder (Geschuetzte Gesundheitsinformationen) bei Ruhe und Uebertragung verschluesselt
• Audit-Protokollierung getestet: jeder PHI-Zugriff und jede Aenderung erzeugt einen unveraenderlichen Protokolleintrag
• Rollenbasierte Zugriffskontrolle verifiziert
• MFA-Durchsetzung fuer alle Benutzerrollen getestet

Finanzdienstleistungen (PCI-DSS / SOC 2)

• PCI-DSS-Umfangsgrenzen getestet: Karteninhaberdaten lecken nicht ausserhalb definierter Zonen
• Tokenisierung von Zahlungskartennummern verifiziert
• Betrugserkennungsregeln gegen bekannte Betrugsszenarien getestet
• Transaktionsatomizitaet verifiziert

E-Commerce / Einzelhandel

• Warenkorbberechnungsgenauigkeit fuer alle Rabatt-, Gutschein- und Steuerszenarien getestet
• Zahlungsgateway-Integration im Sandbox-Modus getestet
• Checkout-Fluss-Lasttest bei Spitzenverkehrsszenarien
• Produktbestandsminderung als atomar verifiziert

Mobile Anwendungen

• UI auf minimaler unterstuetzter OS-Version und aktueller OS-Version getestet
• Offline-Modus-Funktionalitaet getestet
• App-Startzeit gemessen: <2 Sekunden Kaltstart auf Zielgeraeten
• Barrierefreiheit mit VoiceOver (iOS) und TalkBack (Android) getestet

DevOps / Unternehmensinfrastruktur

• Infrastructure-as-Code-Vorlagen mit Policy-as-Code-Tools validiert
• Blue/Green- und Canary-Deployment-Strategien getestet
• Circuit-Breaker-Verhalten unter Downstream-Service-Ausfall getestet
• Auto-Scaling-Trigger bei definierten CPU/Speicherschwellenwerten getestet

Reifegradmodell fuer agiles Testen

Stufe 1: Grundlegend (Sprints 1-6)

Merkmale:

• Testen ist groesstenteils manuell, am Ende des Sprints durchgefuehrt
• Unit-Tests existieren, aber die Abdeckung ist inkonsistent (20-40%)
• Keine CI-Pipeline oder eine minimale

Agile Testpraktiken auf dieser Stufe:

• Akzeptanzkriterien fuer jede Story vor Sprint-Beginn schreiben
• Grundlegende CI-Pipeline aufbauen
• TDD fuer neue Features beginnen

Ziel bis Ende Stufe 1: Jede Story hat schriftliche Akzeptanzkriterien; CI-Pipeline laeuft bei jedem Merge; Unit-Test-Abdeckung >40% fuer neuen Code.

Stufe 2: Fortgeschritten (Sprints 7-15)

Merkmale:

• Unit-Test-Abdeckung waechst auf 60-75%
• CI-Pipeline umfasst automatisierte Unit- und Integrationstests
• BDD-Szenarien fuer kritische Benutzerreisen geschrieben

Agile Testpraktiken auf dieser Stufe:

• "Drei Freunde"-Session als Standardpraktik implementieren
• Regressionstest-Suite aufbauen, die bei jedem PR laeuft
• Performance-Benchmarks in CI einfuehren

Ziel bis Ende Stufe 2: Unit-Test-Abdeckung >70%; Defekt-Escape-Rate unter 15%.

Stufe 3: Hochentwickelt (Sprint 16 und darueber hinaus)

Merkmale:

• Unit-Test-Abdeckung >80%
• Vollstaendige CI/CD-Pipeline mit automatisierter Bereitstellung fuer Staging
• Shift-Left-Security: SAST-Scanning bei jedem Commit

Ziel fuer Stufe 3: Unit-Test-Abdeckung >80%; Defekt-Escape-Rate unter 5%; CI-Pipeline in unter 20 Minuten abgeschlossen.

8 Haeufige Anti-Patterns beim agilen Testen

Anti-Pattern 1: Testen nach "fertigem" Entwickeln

Problem: Entwickler erklaeren eine Story fuer "fertig" und dann beginnen Tester erst mit dem Testen.

Warum es problematisch ist: Schafft einen Test-Engpass am Ende des Sprints. Spaet gefundene Fehler erfordern Kontextwechsel fuer Entwickler.

Loesung: Definition of Done so neu definieren, dass Tests bestehen muessen. ATDD anwenden, damit Tester Tests schreiben, waehrend Entwickler Code schreiben.

Anti-Pattern 2: Die Eistueten-Testsuite

Problem: Das Team hat 5 Unit-Tests, 20 Integrationstests und 200 Selenium-E2E-Tests. Die CI-Pipeline dauert 2 Stunden.

Loesung: Die Pyramide umkehren. Fuer jeden E2E-Test 10 Unit-Tests schreiben.

Anti-Pattern 3: Tests unter Sprint-Druck ueberspringen

Problem: Mit 2 Tagen bis zum Sprint-Ende ueberspringt das Team das Schreiben von Tests.

Loesung: Definition of Done ohne Ausnahmen durchsetzen. Eine unvollstaendige Story ist weniger gefaehrlich als eine falsch "fertige".

Anti-Pattern 4: Tester nur als Fehler-Reporter

Problem: Testern werden fertige Features uebergeben, sie finden Fehler und protokollieren sie. Sie sind nicht in Design oder Akzeptanzkriterien eingebunden.

Loesung: Tester in Backlog-Refinement, Sprint-Planung und Drei-Freunde-Sessions einbeziehen.

Anti-Pattern 5: Fragile und Flaky Tests

Problem: Tests bestehen manchmal und schlagen manchmal aus Gruenden fehl, die nichts mit dem Code zu tun haben.

Loesung: Flaky Tests als kritische Bugs behandeln. Sofort unter Quarantaene stellen und Grundursachen beheben.

Anti-Pattern 6: Kein exploratives Testen

Problem: Das Team verlasst sich ausschliesslich auf geskriptete, automatisierte Tests.

Loesung: Formelle explorative Test-Sessions jeden Sprint planen. SBTM-Ansatz verwenden: Charter definieren, Time-Box setzen, erkunden, Ergebnisse berichten.

Anti-Pattern 7: Nicht-funktionale Tests ignorieren

Problem: Jeder Sprint produziert Features mit Funktionstests, aber Performance, Sicherheit und Zugaenglichkeit werden nie getestet.

Loesung: Nicht-funktionale Kriterien zur Definition of Done hinzufuegen und automatisierte Tools in CI integrieren.

Anti-Pattern 8: Testumgebungen stimmen nicht mit Produktion ueberein

Problem: Tests bestehen in der Entwicklungsumgebung, aber Fehler treten in Produktion auf, weil Umgebungen unterschiedlich sind.

Loesung: Containerisierung (Docker) verwenden, um Umgebungskonsistenz sicherzustellen. Infrastructure-as-Code verwenden.

Wichtige Testmetriken

Fazit

Agiles Testen ist keine Technik - es ist eine Denkweise, die Qualitaet als kontinuierliche, gemeinsame Verantwortung behandelt. Die wirkungsvollsten Aenderungen, die ein Scrum-Team vornehmen kann:

1. Akzeptanzkriterien schreiben, bevor Code beginnt (ATDD-Disziplin)
2. Die Testpyramide durchsetzen: schnelle, zuverlaessige Unit-Test-Grundlage aufbauen
3. Testen in CI integrieren, damit jeder Commit sofortiges Feedback erhaelt
4. Tester in jede Planungs- und Refinement-Diskussion einbeziehen
5. Defekt-Escape-Rate verfolgen und Sprint fuer Sprint verbessern

Fuer tieferen Kontext zu den Qualitaetsstandards, die agiles Testen unterstuetzen, lesen Sie die Leitfaeden zur Definition of Done und Continuous Integration.

Weiterlesen

Häufig gestellte Fragen (FAQs)