Testautomatisierung als Product Owner priorisieren (2026)

Inhaltsverzeichnis

1. Warum Du als Product Owner mitentscheiden musst
2. Die 4-Fragen-Filter für Test-Backlog-Priorisierung
3. Akzeptanzkriterien automatisierbar formulieren
4. Definition of Done mit Automatisierungs-Gate
5. Tool-Entscheidung in 5 Fragen
6. Was nicht in Deinen Sprint gehört
7. Fazit
8. FAQ

Als ich vor Jahren in einem Bahn-Projekt als Test Manager mit einem Product Owner zusammengearbeitet habe, der die Testautomatisierung „dem Team überlassen” wollte, ist der Sprint nach drei Iterationen in eine Wartungs-Schleife gerutscht. Niemand hat Tests priorisiert. Niemand hat geprüft, ob die neuen Stories automatisierbar waren. Das Ergebnis: Release verschoben, Vertrauen verloren, ein böses Gespräch mit dem Lenkungskreis.

Seitdem habe ich Tests in den Sprint-Plan gezogen, mit dem Product Owner zusammen, jede Woche. Und ich habe gelernt: Testautomatisierung ist kein technisches Thema, das man delegieren kann. Sie ist Teil der Produkt-Verantwortung.

Dieser Text ist für Dich, wenn Du als Product Owner einen Backlog mit automatisierten Tests führst und nicht raten willst, welche Story automatisierbar ist, welches Tool zum Team passt und wo die Grenze des Sprints liegt.

1. Warum Du als Product Owner mitentscheiden musst

Die häufigste Antwort auf „Wer entscheidet über Testautomatisierung?” ist „Das Test-Team”. Das ist organisatorisch bequem und produktstrategisch falsch.

Drei Gründe, warum die Entscheidung bei Dir liegt:

Coverage ist Wert. Welche User-Journey muss zu 100 Prozent abgedeckt sein? Die Antwort kennst Du, nicht Dein Tester. Du weißt, welche Funktion Umsatz bringt und welche Kosmetik ist.
Wartung ist Backlog-Last. Automatisierte Tests müssen gepflegt werden. Diese Wartung kostet Sprint-Kapazität. Wer entscheidet, dass dieser Aufwand bezahlt wird, wenn nicht der PO?
Akzeptanzkriterien werden zu Test-Spezifikationen. Wenn Du sie schwammig formulierst, sind sie nicht automatisierbar. Du bist Quelle der Wahrheit für das, was getestet werden soll.

Bei wem genau die Verantwortung liegt, hat einen Effekt auf Deine Coaching-Beziehung zum Team. Wenn Du sagst, „ich weiß nichts über Testautomatisierung”, bekommst Du Tests, die zur Tech-Strategie der Engineers passen, nicht zur Produkt-Strategie. Das ist meistens nicht, was Du willst.

2. Die 4-Fragen-Filter für Test-Backlog-Priorisierung

Bei der Frage „Was automatisieren wir als nächstes?” habe ich mir einen einfachen Filter gebaut, der vier Fragen pro Test-Kandidat stellt. Jede Frage mit Ampel-Bewertung: rot, gelb, grün.

Frage	Rot	Gelb	Grün
Critical-Path-Coverage? Liegt der Test auf einer User-Journey, die Umsatz oder Compliance betrifft?	nein	nice-to-have	ja, kernrelevant
Regressions-Häufigkeit? Wie oft ändert sich der Code-Pfad?	selten	gelegentlich	häufig
Manuell-Cost? Wie teuer ist die manuelle Alternative pro Lauf?	wenige Minuten	unter 30 Minuten	mehrere Stunden
Toolchain-Reife? Ist die Toolchain stabil oder im Aufbau?	im Aufbau	teils stabil	etabliert

Faustregel: Drei oder vier grüne Felder = sofort priorisieren. Zwei grüne + zwei gelbe = nächste Sprints. Drei rote = nicht automatisieren, manuell halten.

Das Schöne an dem Filter: er macht die Diskussion mit dem Team kurz. Statt „lass uns alles automatisieren” oder „lass uns nichts automatisieren” hast Du in fünf Minuten pro Story eine begründete Entscheidung. Die Begründung wandert ins Story-Comment und ist Audit-fähig.

Wenn Du tiefer auf die Engineering-Sicht eingehen willst, gibt es bei Qytera den Hub-Artikel mit den sechs goldenen Regeln zur Testautomatisierung. Der ist die Engineering-Pyramide zu dem PO-Frame hier.

3. Akzeptanzkriterien automatisierbar formulieren

Akzeptanzkriterien sind in Story-Form oft so weich, dass kein Test daraus entsteht. „Der Nutzer kann sich anmelden” ist keine Spezifikation. Das ist eine Wunschäußerung.

Was funktioniert, ist die Gherkin-Form. Du kennst sie vermutlich:

Given ich bin ein registrierter Nutzer
And meine Anmeldedaten sind hinterlegt
When ich die Anmelde-Seite aufrufe
And korrekte Anmeldedaten eingebe
And auf Anmelden klicke
Then werde ich auf das Dashboard weitergeleitet
And ich sehe meinen Namen in der Kopfzeile

Drei Eigenschaften, die ein automatisierbares Akzeptanzkriterium hat:

Konkrete Vorbedingung (Given). Welcher Zustand muss da sein, bevor der Test läuft?
Klare Aktion (When). Was tut der Nutzer?
Messbarer Ergebnis-Punkt (Then). Was prüfen wir genau?

Wenn ein Kriterium diese drei Punkte nicht erfüllt, kann Dein Team es nicht automatisieren. Es ist nicht falsch, es ist nur unfertig. Das ist Dein Job als PO, das zu fixen, bevor die Story in den Sprint geht.

In der Praxis nehme ich mir 15 Minuten pro Story, bevor sie ins Refinement geht, und prüfe jedes Akzeptanzkriterium gegen diese drei Punkte. Das ist effizient investierte Zeit.

4. Definition of Done mit Automatisierungs-Gate

Eine Definition of Done ohne Automatisierungs-Gate ist eine Einladung an Wartungs-Schulden. Was bedeutet ein Automatisierungs-Gate?

Ein einfaches Beispiel:

Story ist „done”, wenn:

Akzeptanzkriterien sind erfüllt (manuell verifiziert)

Mindestens ein automatisierter Komponententest (Unit-Test) für den neuen Code besteht

Ende-zu-Ende-Test (End-to-End-Test) für die kritische User-Journey ist erweitert oder neu erstellt

Bestehende Tests sind grün (kein Skip, keine Flakiness eingeführt)

Test-Dokumentation ist aktuell

Das ist kein theoretischer Plan. Das ist die Definition of Done, die ich in mehreren DACH-Projekten eingeführt habe und die funktioniert. Wichtig: Punkt 4 ist hart. Wer Tests auf „skip” setzt, weil sie rot werden, gefährdet den ganzen Sprint. Das ist eine Anti-Pattern, das ich auf der Schwester-Seite testautomatisierung.info ausführlich beschrieben habe, wenn Du den Business-Case dahinter wissen willst.

Die Wartung des Gates ist Deine Aufgabe. Wenn ein Sprint kommt, in dem das Gate nicht haltbar ist, musst Du sehen, ob Du Stories aus dem Sprint nimmst oder die Test-Wartung explizit als Story einplanst. Was Du nicht machen darfst: das Gate stillschweigend reduzieren.

5. Tool-Entscheidung in 5 Fragen

Wenn Du im Refinement plötzlich mitten in einer Tool-Diskussion landest, hilft eine kurze Matrix. Fünf Fragen, die Du als PO Deinem Team stellen kannst, bevor das Gespräch in Tool-Religion abgleitet:

#	Frage	Worauf achten
1	Web, Mobile oder Backend?	Web heißt Playwright oder Cypress. Mobile heißt Appium. Backend heißt Postman oder REST-Assured. Selten beides in einem Tool.
2	Welches Skill-Level hat das Team?	Cypress und Playwright sind moderner und leichter. Selenium ist verbreitet, aber steiler. Robot Framework lohnt nur, wenn das Team Python kennt.
3	Wie ist die CI/CD-Pipeline aufgebaut?	Tool muss in der Pipeline laufen, ohne Schmerz. GitLab-Runner mit Headless-Browser ist Standard. Wenn das Team Docker nutzt: Test-Container vorsehen.
4	Welches Reporting wird gebraucht?	Brauchst Du Allure-Reports, Jira-Integration, Test-Management-System? Das schließt Tool-Optionen ein oder aus.
5	Welches Budget steht für Tool-Lizenzen?	Open-Source-First spart Lizenz-Kosten, aber kostet mehr Engineering-Zeit. Kommerziell ist umgekehrt. Sei ehrlich, was Du bezahlst.

Wenn Du diese Fünf mit Deinem Team durchgegangen bist, hast Du in 20 Minuten eine begründete Tool-Wahl. Ohne sind es meistens 2 Stunden, die in eine emotionale Diskussion mit unklarem Testergebnis führen.

Für die konkreten Tool-Eigenschaften ist der Qytera-Vergleich der 18 wichtigsten Testautomatisierungstools eine gute Referenz. Die meiste Engineering-Arbeit ist die Auswahl von zwei oder drei daraus.

6. Was nicht in Deinen Sprint gehört

Drei Dinge, die ich in PO-Backlogs immer wieder sehe und die nicht in den Sprint gehören:

„Bestehende Tests stabilisieren” als einzelne Story. Das ist Wartungsarbeit, kein Feature-Wert. Plane Wartung als Quote (10 bis 15 Prozent der Sprint-Kapazität), nicht als Story.
„Test-Framework migrieren” als einzelne Story. Das ist eine Mehrsprint-Aktion. Wenn es nötig ist, mach einen separaten Tech-Spike, einen Tech-Debt-Sprint oder einen 90-Tage-Pilot mit klaren Exit-Kriterien.
„Tester für Story X verfügbar machen” als Akzeptanzkriterium. Verfügbarkeit ist kein Test-Kriterium. Wenn der Tester fehlt, fehlt er. Du brauchst keine Story dafür.

Was in den Sprint gehört: das Feature plus den Test plus die Definition of Done plus die Akzeptanzkriterien. Alles andere ist Sprint-Boilerplate, das in die Sprint-Planung gehört, nicht in eine Story.

7. Fazit

Testautomatisierung als Product Owner zu führen ist keine Tool-Frage, sondern eine Backlog-Frage. Die vier Punkte, die in der Praxis funktionieren:

Du entscheidest mit, welche Story automatisierbar ist (4-Fragen-Filter).
Du sorgst dafür, dass Akzeptanzkriterien automatisierbar sind (Gherkin-Form).
Du verankerst Testautomatisierung in der Definition of Done.
Du moderierst die Tool-Wahl in 20 Minuten mit fünf Fragen.

Wenn Du das durchziehst, ist die Testautomatisierung kein parallel laufendes Test-Projekt, sondern Teil Deiner Produkt-Pipeline. Die Wartungs-Schulden, die ich auf testautomatisierung.info als Anti-Pattern beschreibe, treten dann gar nicht erst auf.

Wenn Du das mit Unterstützung machen willst: der QET-Schnellcheck ist 5 Minuten Selbst-Assessment für Dein Test-Setup. Oder wir reden 15 Minuten und schauen gemeinsam, wo Du stehst.

8. FAQ

Welche Tests sollte ein Product Owner zuerst automatisieren lassen?

Tests auf User-Journeys mit Umsatz- oder Compliance-Relevanz, die häufige Code-Änderungen erfahren und manuell viel kosten. Drei grüne Felder im 4-Fragen-Filter sind das Signal. Anti-Beispiel: Einmal-Tests aus Migrationen automatisierst Du nicht.

Wie erkenne ich, dass ein Akzeptanzkriterium nicht automatisierbar ist?

Wenn Du keine konkrete Vorbedingung, keine klare Aktion und keinen messbaren Ergebnis-Punkt formulieren kannst. „Der Nutzer kann sich anmelden” ist eine Wunsch-Äußerung, kein Test. Gherkin-Form Given-When-Then macht den Unterschied sichtbar.

Was kostet die Wartung der Test-Suite im Sprint?

In der Praxis 10 bis 15 Prozent der Engineering-Kapazität, je nach Suite-Größe. Wer das nicht einplant, baut Wartungs-Schulden auf, die spätestens nach 6 Monaten den Sprint blockieren. Lieber als Quote in der Sprint-Planung verankern, nicht als Einzel-Story.

Soll der PO die Tool-Wahl treffen oder das Team?

Beide. Der PO moderiert mit den fünf Fragen (Anwendungstyp, Skill-Level, CI/CD, Reporting, Budget). Das Team trifft die finale Wahl aus zwei oder drei Tools, die nach diesen Fragen übrig bleiben. Die Tool-Religion umgehst Du, indem Du die Diskussion mit den Fragen strukturierst.

Was tun, wenn das Team Testautomatisierung „nebenbei” machen will?

Das ist meistens das schnellste Anti-Pattern in den Wartungs-Schulden. Wenn Du keinen dedizierten Test Automation Engineer hast (mindestens einen pro 5-10 Entwickler), wird die Test-Suite verfallen. Lieber explizit eine Rolle benennen und sichtbar im Sprint-Plan halten.

Wie häufig sollte ich als PO mit dem Test-Team über die Suite sprechen?

Wöchentliches Test-Triage-Meeting, 30 Minuten. Themen: rote Tests, Flakiness-Trends, Wartungs-Budget für nächste Woche, neue Stories, die nicht-automatisierbar formuliert sind. Mit fester Agenda dauert das nicht länger und verhindert die meisten Wartungs-Probleme.

Testautomatisierung für Product Owner: Backlog-Priorisierung + 5-Fragen-Tool-Matrix