Antwort.

Im Laufe der Zeit hat sich das manuelle Testen an agile Methoden wie Scrum angepasst. Zunächst arbeiteten Tester „am Ende des Sprints“ und testeten das Ergebnis aller Arbeiten. Dies führte oft zu Zeitdruck und unzureichendem Testen (Problem).

Das Hauptproblem ist der Zeitmangel für Tests, häufige Änderungen der Anforderungen und Aufgaben, die während des Sprints nicht zu den Testern gelangen. Tester stehen unter Druck, was die Qualität mindert (Problem).

Die Lösung besteht darin, Tester von Anfang an in das Team zu integrieren: an Besprechungen teilnehmen, Testfälle planen, während neue Aufgaben entstehen, tägliche Stand-ups und Retrospektiven gemeinsam abhalten und die Transparenz des Status der Testartefakte erhöhen (Lösung).

Wichtige Merkmale:

Ständige Einbindung von QA in allen Phasen des Sprints
Regelmäßige Aktualisierung und Planung von Testfällen „on-the-fly“
Zusammenarbeit mit Entwicklern bei der Festlegung der Testbereitschaft der Aufgaben

Fangfragen.

Kann man mit dem Testen erst nach Abschluss aller Aufgaben des Sprints beginnen?

Nein, der Tester sollte von den ersten Tagen des Sprints an eingebunden sein und, wenn möglich, noch nicht vollständig abgeschlossene Funktionalitäten testen.

Müssen alle Bugs im aktuellen Sprint behoben werden?

Nicht unbedingt, kritische Bugs müssen - nicht kritische können in den externen Backlog verschoben und im nächsten Sprint behoben werden.

Ist manuelles Testen notwendig, wenn Automatisierung in Scrum vorhanden ist?

Ja, manuelles Testen ist entscheidend für die Überprüfung neuer Features und nicht formalisierten Anforderungen sowie für Exploratory Testing.

Typische Fehler und Anti-Patterns

Verspätete Einbindung des Testens
Fehlende Dokumentation neuer Features zu Beginn
Ignorieren der Teamkommunikation und -meetings

Beispiel aus dem Leben

Negativer Fall

Der Tester war nicht an der Planung beteiligt und hatte bis zum Ende des Sprints keinen Zugriff auf neue Aufgaben. Infolgedessen wurden die Tests hastig geschrieben, einige Bugs wurden in die nächsten Sprints verschoben.

Vorteile:

Weniger Meetings für den Tester

Nachteile:

Fehler in der Produktion, Unzufriedenheit der Kunden, geringe Abdeckung

Positiver Fall

Der Tester schloss sich dem Team von den ersten Tagen des Sprints an, nahm an Meetings teil, sah die auftretenden Aufgaben frühzeitig und plante Tests parallel zur Entwicklung.