Sinnvolle Teststrategien für agile Projekte

Im letzten Beitrag ging es darum, warum Testautomatisierung mehr braucht als gute Tools. Ein zentraler Baustein davon ist die richtige Teststrategie im agilen Alltag – also die Frage, wann welche Testaktivität im Projekt eigentlich stattfinden sollte.

Denn eine Testautomatisierung, die technisch sauber gebaut ist, aber zum falschen Zeitpunkt im Sprint ansetzt, bringt Ihnen wenig. Testaktivitäten führen nur dann zu einer sinnvollen Strategie, wenn sie zur richtigen Zeit ausgeführt werden. In diesem Beitrag zeigen wir, wie das in der Praxis aussieht – anhand eines klassischen Scrum-Sprints, wie ihn viele agile Teams leben. Arbeitet Ihr Team nach Kanban, im Spotify-Modell oder einem anderen Framework, unterscheiden sich Zeremonien und Rollen im Detail – die Grundprinzipien lassen sich aber sinngemäß übertragen.

Testen ist kein nachgelagerter Schritt

Testen in der agilen Softwareentwicklung ist ein integraler Bestandteil und wird oft als Shift-Left bezeichnet: Testaktivitäten werden zeitlich nach vorne geschoben, damit Fehler frühzeitig gefunden werden – und damit günstiger zu korrigieren sind, als wenn sie erst kurz vor dem Release auffallen.

Wie das konkret aussieht, zeigt sich am besten entlang eines typischen Sprint-Ablaufs.

Der Test-Ablauf im Sprint

Sprint Planning

Akzeptanzkriterien und Testfälle werden gemeinsam mit Product Owner, Fachbereich bzw. Business Analyse, Entwicklung und Test definiert – nicht erst nachträglich. Akzeptanzkriterien sollten so formuliert sein, dass sie sich in prüfbare, möglichst deterministische Testschritte übersetzen lassen (klare Vorbedingung, Aktion, erwartetes Ergebnis). Lässt sich ein Kriterium nicht automatisiert prüfen, ist das in den meisten Fällen ein Signal, dass die Definition of Ready noch nachgeschärft werden sollte – es gibt aber legitime Ausnahmen, etwa bei Usability-Aspekten.

Implementierungsbeginn einer Story

Sobald die Entwicklung startet, entstehen die ersten Unit-Tests parallel zum Code, idealerweise testgetrieben (TDD). Die für Tests verantwortliche Person ist hier meist nicht aktiv testend beteiligt, sollte aber bei Rückfragen zu Akzeptanzkriterien erreichbar sein. Die Testautomatisierung startet parallel: Grundgerüst anlegen, Page-Objects bzw. API-Clients für neue Endpunkte entwickeln und Testdaten als wiederverwendbare, parametrisierbare Bausteine (Builder/Factory) anlegen – das erspart später Mehrfacharbeit.

Vor dem Merge Request/Code Review

Hier greifen Komponenten- bzw. Modultests sowie statische Codeanalyse, mit dem Ziel, dass fehlerhafter Code den Feature-Branch gar nicht erst verlässt. Ein Merge ohne grüne Unit-Tests sollte im Team die Ausnahme sein, nicht die Regel. In der Testautomatisierung sollte zumindest die API-Ebene abgedeckt sein; UI-Tests folgen, sobald die Oberflächen stabil sind. Auch der Testautomatisierungs-Code gehört reviewt und wird gemeinsam mit dem Produktivcode gemerged.

Nach der Integration in den Haupt-Branch und dem Deployment in die Testumgebung.

Sobald mehrere Komponenten zusammenspielen, sind Integrationstests an der Reihe. Zuerst folgen Smoke-Tests, um das Deployment grundsätzlich zu verifizieren – erst danach die eigentlichen funktionalen Tests entlang der Akzeptanzkriterien. Genau hier zeigt sich, wie wichtig Testdaten sind: Jeder Testlauf braucht einen reproduzierbaren Ausgangszustand (Seed-Daten, Datenbank-Reset bzw. Testcontainer pro Lauf) – geteilte, sich verändernde Testdaten zwischen parallelen Läufen sind eine der häufigsten Ursachen für instabile (flaky) Tests.

Während der restlichen Sprintzeit

Hier ist der richtige Zeitpunkt für exploratives Testen: gezielte Suche nach Randfällen und Szenarien, die in den Akzeptanzkriterien nicht explizit beschrieben wurden. Diese Phase lässt sich kaum automatisieren und hängt stark von Erfahrung ab – jeder hier gefundene, reproduzierbare Fehlerfall ist aber ein Kandidat für einen neuen Regressionstest.

Kurz vor Sprint Review (Definition of Done)

Automatisierte Regressionstests laufen im Idealfall kontinuierlich über die CI-Pipeline. Erst wenn diese grün sind, gilt eine Story als stabil genug für die Demo. Ein grünes Ergebnis der Regressionssuite gehört im Regelfall als festes Kriterium in die Definition of Done – ohne diese Verbindlichkeit verkommt Automatisierung schnell zur Kür statt zur Pflicht. Wichtig ist dabei nicht nur, dass die Suite grün ist, sondern auch, wie stabil sie das über die Zeit bleibt: Laufzeit und die Flaky-Rate – also wie oft Tests ohne echten Fehlerbezug fehlschlagen – sollten sichtbar gemessen werden, etwa über ein Dashboard. Eine Suite, die zu oft grundlos rot wird, verliert im Team das Vertrauen und wird ignoriert – das untergräbt den eigentlichen Zweck der Automatisierung: schnelles, verlässliches Feedback darüber zu liefern, ob eine Änderung etwas kaputt gemacht hat.

Sprint Review

Getestete Funktionalität wird vorgestellt und gemeinsam mit den Stakeholder*innen besprochen – der Review ist mehr als eine reine Demo, es geht auch um Feedback und den Abgleich, ob das Ergebnis den Erwartungen entspricht. Neben der Feature-Demo bietet sich an, kurz auch den Stand der Testautomatisierung zu zeigen – Abdeckung, Anzahl automatisierter Regressionsfälle, Laufzeit – damit Testautomatisierung im Team sichtbar bleibt. Genauso wichtig: offen über unterschiedliche Erwartungshaltungen sprechen. Wird eine Suite instabil oder deckt sie die falschen Dinge ab, sollte das genauso offen angesprochen werden wie fachliche Missverständnisse – nicht erst, wenn sie im Team bereits ignoriert wird.

Diese Reihenfolge ist ein Grundgerüst, kein starres Schema. Je nach Story-Komplexität und Risiko können einzelne Phasen übersprungen, zusammengelegt oder mit mehr Gewicht versehen werden. Entscheidend ist, dass im Team ein gemeinsames Verständnis darüber besteht, welche Testart in welcher Phase erwartet wird – sonst entsteht Testaufwand willkürlich statt strukturiert.

Die Aufgaben von Tester*innen und Testautomatisierer*innen

Die Aufgaben von Testenden und Testautomatisierer*innen sind längst nicht mehr auf reine Testaktivitäten beschränkt. Sie beginnen schon in frühen Projektphasen – etwa bei der Mitwirkung an Definition of Ready und Definition of Done – und reichen bis weit nach der Ausführung der Regressionstests, etwa bei der Planung und Begleitung kritischer Produktions-Releases, wo zusätzliche Testaktivitäten wie Smoke- oder Canary-Tests Sicherheit geben.

Tester*innen (manuell/explorativ):

• Erstellung und Pflege von Testfällen basierend auf Anforderungen und Akzeptanzkriterien

• Exploratives Testen – gezieltes Suchen nach Fehlern außerhalb definierter Testskripte

• Verifikation von Usability, Edge Cases und Szenarien, die schwer automatisierbar sind

• Bewertung von Risiken und Priorisierung von Testaufwand

• Abstimmung mit dem Product Owner zu Akzeptanzkriterien

• Manuelle Regressionstests, wo Automatisierung (noch) nicht wirtschaftlich ist

• Dokumentation und Reporting von Fehlern (Bug-Tracking)

Testautomatisierer*innen (Test Automation Engineer):

• Aufbau und Wartung von Automatisierungs-Frameworks

• Entwicklung automatisierter Testskripte für Regressions-, Integrations- und teilweise End-to-End-Tests

• Integration der Testautomatisierung in die CI/CD-Pipeline

• Pflege von Testdaten und Testumgebungen

• Reduktion von Flakiness und Wartungsaufwand

• Auswahl geeigneter Testebenen (Unit, Integration, E2E) gemäß der Testpyramide

• Reporting und Monitoring der Testergebnisse, etwa über Dashboards und Testabdeckungs-Metriken

Ist im Team nur eine einzige Person für Tests verantwortlich, muss sie diese Aufgaben nach bestem Wissen abdecken und sich bei Bedarf Unterstützung aus dem Team holen – etwa Entwicklungsaufgaben durch die Entwicklung selbst. Beide Rollen verlangen ein hohes Maß an Selbstständigkeit, vorausschauendes Planen und enge Zusammenarbeit mit Kolleg*innen im und über das Team hinaus.

Schätzen und Planen: Testaufwand realistisch mitdenken

Eine sinnvolle Teststrategie in einem agilen Projekt braucht realistische Ausführungszeitpunkte für alle Testaktivitäten – und die Verbindlichkeit, sich auch daran zu halten. Das bedeutet, dass die für Tests verantwortliche Person aktiv im ganzen Sprint-Zyklus eingebunden sein muss. Fällt sie aus, müssen andere Teammitglieder diese Aufgaben übernehmen.

Die Teststrategie ist dabei individuell anzupassen: Je nach Projekt, Software und Teamgröße kann die Positionierung der Testaktivität im Sprint variieren.

Backlog Refinement

Hier ist es wichtig, dass die für Tests verantwortliche Person dabei ist und den Aufwand für alle Testaktivitäten realistisch einbezieht. Die Aktivität „Testen“ allein reicht als Schätzpunkt nicht aus: Vorher müssen Testfälle geschrieben, die Testumgebung konfiguriert und deployt werden. Bei nicht erfolgreichem Test müssen Bugs dokumentiert und teilweise vorab besprochen werden. Bei erfolgreichem Test muss entschieden werden, wie die Story in den nächsten Phasen weitergetestet wird – etwa automatisiert in der Regression oder weiterhin manuell. Eine realistische Schätzung ist anfangs schwierig, mit der Zeit entwickelt ein Team dafür aber ein gutes Gespür.

Empfehlung: Testaufwand vollständig und realistisch mitschätzen, statt ihn implizit unter „Testen“ zu verstecken – das schafft Freiraum für explorative Tests und unerwartete Störfaktoren. Sind Akzeptanzkriterien nicht vollständig oder nicht ausreichend, empfiehlt es sich, eine Schätzung abzulehnen und stattdessen auf die Definition of Ready zu verweisen.

Der Automatisierungsaufwand einer Story sollte zudem als eigener Schätzpunkt mitgeschätzt werden – getrennt vom eigentlichen Testen: Aufbau neuer Testdaten, Anpassung bestehender Testsuiten und ggf. Erweiterung des Frameworks. Wird das nicht separat geschätzt, wird Automatisierung in der Praxis regelmäßig verschoben oder ausgelassen.

Sprint-Planung

Auch hier ist es wichtig, sich Zeit für unerwartete Störungen freizuhalten. Eine offene und ehrliche Kommunikation im Team ist für den Erfolg eines Sprints essenziell. In der Sprint-Planung sollte bewusst entschieden werden, welche neuen Testfälle sofort automatisiert werden und welche zunächst manuell bleiben – etwa, weil sich die Oberfläche noch ändert. Zusätzlich braucht die Wartung bestehender Testsuiten (Anpassen an geänderte Selektoren, Endpunkte oder Testdaten) festen Platz im Sprint, sonst verfällt die Suite schleichend.

Empfehlung: Kurze Absprachen mit Test-Kolleg*innen aus anderen Teams nach der offiziellen Sprint-Planung einplanen. So lassen sich Testaktivitäten teamübergreifend vergleichen, Doppelarbeit vermeiden und kurzfristige Unterstützung vereinbaren.

Testumgebungen und Testdaten: die unterschätzte Grundlage

Ein Sprint ist schnell vorbei, und als für Tests verantwortliche Person hat man viele Aufgaben gleichzeitig. Eine frühzeitige Vorbereitung der Testaktivitäten ist essenziell. Sofern technisch und wirtschaftlich möglich, ist eine Vielzahl an Testumgebungen klar von Vorteil – notfalls kann auch eine lokale Entwicklungsumgebung für Test und Testautomatisierung eine geeignete Lösung sein, um frühzeitig starten zu können.

Die Pflege von Testdaten ist in der Praxis der Punkt, an dem die meiste Automatisierung scheitert oder instabil wird. Bewährt hat sich: containerisierte, on-demand erzeugbare Umgebungen mit versionierten, synthetischen Testdatensätzen statt einer einzigen, dauerhaft geteilten Umgebung. Testdaten pro Testfall isoliert erzeugen (Builder-/Factory-Pattern statt fest verdrahteter Werte), Zustand vor jedem Lauf zurücksetzen und niemals gegen produktive oder von anderen Tests mitgenutzte Daten testen. Testdaten sollten dabei wie Code behandelt werden: versioniert, überprüfbar und nicht manuell von Hand gepflegt.

Neu-Entwicklungen in der Testautomatisierung sollten, wenn möglich, im selben Feature-Branch wie der Produktivcode entstehen und gemeinsam mit ihm gemerged werden – eine einheitliche Tag-Vergabe im Repository unterstützt das zusätzlich.

Fazit

Eine sinnvolle Teststrategie entsteht nicht durch ein einzelnes Tool oder eine einzelne Testart, sondern durch das richtige Timing im Sprint-Zyklus: Wer wann welche Testaktivität übernimmt, wie viel Aufwand das kostet und wie transparent das im Team gemacht wird.

Genau das ist der Unterschied zwischen „wir testen halt auch“ und einer Teststrategie, die ein Projekt wirklich trägt.

Sie möchten wissen, wie eine sinnvolle Teststrategie für Ihr agiles Projekt aussehen könnte – unabhängig davon, ob Sie nach Scrum, Kanban oder einem skalierten Modell arbeiten? In einem unverbindlichen Austausch schauen wir gemeinsam darauf, wo in Ihrem Sprint-Zyklus die größten Stellhebel liegen.

Kontaktieren Sie uns unter: office@gruener-it.at