Noch immer haben viele Entwickler oder gar ganze Teams keine Erfahrung in der Zusammenarbeit mit einem Tester gesammelt. Im Rahmen des agilen Prozesses kommt da schnell die Frage auf: brauchen wir den Tester in Meeting x oder y? Gleichzeitig habe ich Tester erlebt, die dieser Frage Pulver geben – indem sie stillschweigend die Meetings beobachten und sich zurückhalten, als hätten sie dort nichts verloren.
Lasst uns heute einen Blick darauf werfen, was der ein Tester im Refinement leisten kann. Warum seine Perspektive besonders wertvoll ist. Und warum er das Refinement unbedingt für sich nutzen sollte.
Testbarkeit von User Stories
Der Scrum Prozess sieht vor, dass eine User Story so geschnitten ist, dass sie als abgeschlossene Einheit testbar ist. Schneidet ein Projektteam Features so, dass bspw. Frontend- und Backend-Funktionalitäten in eigenständigen Stories behandelt werden, braucht das Team eine Strategie, wie es die jeweiligen Stories dennoch eigenständig testen kann. In solchen Fällen sollte der Tester darauf achten, dass für die jeweiligen Stories die nötigen Tools, Testdaten, Umgebungen und ggf. Mocks bereitstehen, um eine Story auch dann abschließen zu können, wenn der Gegenpart fehlt.
Diese Umstände muss das Team – insbesondere der Tester – bei der Schätzung einpreisen und die Machbarkeit klären. Ist eine Story in der beschriebenen Weise nicht testbar, sollte der Tester intervenieren.
Verständlichkeit und Vollständigkeit der Anforderungen
Fehler entstehen häufig aufgrund von falschen, unvollständigen oder missverständlichen Anforderungen. Ein Fall wurde nicht zu Ende gedacht, Details nicht beschrieben oder Akzeptanzkriterien doppeldeutig formuliert. All dies führt zu Fehlern.
Als Tester frage ich mich deshalb: Verstehen alle Entwickler aus dem Team das gleiche, wenn sie die Anforderungen lesen? Fehlen Informationen, wodurch ein Entwickler während der Implementierung Annahmen treffen wird? Widersprechen sich Anforderungen innerhalb der Story oder passen sie nicht zu dem bisherigen Stand der Software?
Erscheint mir eine dieser Fragen nötig, spreche ich sie laut aus. Die richtigen Fragen zu stellen, ist ein wichtiger Aspekt unserer Rolle!
Testautomatisierung als Teil der User Story
Wie auch der explorative Test, ist die Testautomatisierung Teil der Entwicklungsarbeit. Im Rahmen des Refinements ist es wichtig darüber nachzudenken, wie viele der bereits existierenden Tests von einer Änderung betroffen sind und welche bestehenden Testmethoden du wiederverwenden kannst. Wird eine völlig neue Seite eingeführt, bedeutet das i. d. R. mehr Implementierungsaufwand als bei Änderungen am Design. Andererseits kann eine fundamentale Änderung an der Software bedeuten, dass du tief im Framework verankerte Funktionen anpassen musst – ggf. auf mehreren Teststufen.
Behalte diesen Aufwand im Hinterkopf und schaffe Transparenz während des Refinements. Dein Team sollte sich darüber bewusst sein, wenn ein Haufen versteckter Arbeit auf es zukommt.
Schlusswort
Nimm das Refinement ernst – nur dann wirst auch du als Tester ernstgenommen. Als guter Tester möchtest du Fehler nicht erst finden, wenn die Software deployed ist. Stattdessen trägst du dazu bei, dass diese gar nicht entstehen.
Schreibe einen Kommentar