An welchem ​​Punkt wird eine User Story in einer Iteration getestet?

TL;DR

Wahrscheinlich haben Sie dieses Problem, weil das Testen nicht in Ihrer "Definition of Done" für jede Story enthalten ist. Sie sollten Tests für jede Story in Ihr Sprint-Backlog und als Spalte in Ihr Kanban aufnehmen, falls Sie eines verwenden.

Testen als Story-Anforderung

Im Allgemeinen werden Scrum-Teams Komponententests in die Entwicklungsarbeit und Qualitätssicherung (QA) oder Benutzerakzeptanztests (UAT) als definierten Prozessschritt einbeziehen, bevor eine Story als abgeschlossen betrachtet werden kann.

Beim Zerlegen von Storys für das Sprint Backlog kann es sinnvoll sein, dem Backlog für jede Story eine explizite Aufgabe für QA/UAT hinzuzufügen. Dies macht es zu einem Checklistenpunkt, und jede Story, die diese Aufgabe am Ende des Sprints nicht abgeschlossen hat, wird als unvollständig gezählt.

In vielen Fällen beziehen erfahrene Teams das Testen nicht explizit mit ein, weil es in ihre Schätzungen eingebrannt und Teil der „Definition of Done“ des Teams ist. In solchen Fällen ist das Testen eine implizite Voraussetzung dafür, dass eine Geschichte als vollständig betrachtet wird, aber die gleiche Regel gilt: Wenn die Tests nicht durchgeführt wurden, ist die Geschichte unvollständig.

Darüber hinaus verwenden viele agile Praktiker Kanbans, um Geschichten durch den Arbeitsablauf des Teams zu verfolgen. Das Vorhandensein eindeutiger Spalten zum Testen, die Storys durchlaufen müssen, bevor sie in die Spalte „Fertig“ platziert werden, stellt sicher, dass es eine visuelle Erinnerung gibt, dass das Testen zum Prozess gehört.

Da das Testen Teil der Definition von Done sein sollte, sollten schließlich angemessene Puffer für das Testen in Ihre Story-Schätzungen aufgenommen werden. Wenn Tester nicht an Planungssitzungen teilnehmen oder wenn das Testen nicht Teil der formalen Definition von Done ist, wird diese grundlegende Praxis möglicherweise übersehen.

Wann testen

Das Testen sollte mit Ihrem gesamten Prozess verwoben sein. Tester sollten:

1. Beteiligen Sie sich an der Sprint-Planung und Story-Schätzung.
2. Arbeiten Sie mit Entwicklern zusammen, um Tests während der Funktionsentwicklung zu identifizieren und zu erstellen.
3. Arbeiten Sie mit den technischen Redakteuren zusammen, um Tests zu erstellen, die als Selbstdokumentation für das Produkt dienen.
4. Haben Sie einen eigenen Prozessschritt oder eine eigene Kanban-Spalte, durch die Stories während jeder Iteration fließen.
5. Nehmen Sie aktiv am täglichen Stand-up teil, um sich mit Entwicklern, technischen Redakteuren und anderen Teammitgliedern abzustimmen.
6. Heben Sie blockierte Aufgaben während des täglichen Stand-Ups an.
7. Sprechen Sie Prozessprobleme (z. B. das Warten bis zum Ende des Sprints mit dem Testen) während der Sprint-Retrospektiven an.

Wenn das Testen zu einem integralen Bestandteil des Prozesses Ihres Teams wird, ist es weniger wahrscheinlich, dass Sie am Ende jeder Iteration Last-Minute-Testapaloozas benötigen. Da das Testen eine Teamverantwortung ist , müssen sich außerdem alle Teammitglieder an Testaufgaben beteiligen, die hinter dem Zeitplan liegen, um die Stories bis zum Ende jedes Sprints abzuschließen.

Schaffen Sie einen starken Anreiz für das gesamte Team, sich der Ressourcen- und Zeitanforderungen für Tests bewusst zu sein, sowohl während der Planung als auch während jeder Iteration. Wenn Sie das tun, hört das Testen auf, etwas zu sein, das am Ende für die Tester "über die Wand geworfen" wird.