Ich bin Sebastian Stautz und Software-Tester mit Passion seit 2008. Seit über 10 Jahren arbeite ich in verschiedenen Scrum-Teams und sehe Probleme in der Verwendung einer Test-Spalte auf Boards.
Diesen Artikel habe ich ursprünglich im April 2024 auf englisch auf meinem Blog veröffentlich.
Häufig sehe ich auf Boards nach dem typischen „Open“, dass die nächste Spalte entweder gleich „Dev“ heißt oder selbst als generisches „In Progress“ / „In Arbeit“ Entwicklern bzw. Entwicklungsaufgaben vorbehalten ist. Diese wird wiederum folgt sehr oft „Test“ / „QA“.
In diesem Artikel lege ich dar, warum ich diese Aufteilung als Problem sehe, wird sie erzwungen kann sie Probleme erzeugen, und was mögliche Alternativen sind.
Eine Test-Spalte auf einem Board funktioniert genau dann, wenn …
… man nur eine Aufgabe gleichzeitig an dem Ticket ausgeführt werden kann. Entwicklung XOR Testen.
Wann ist das wirklich mal so ??? Sehr selten.
Das Tester immer nur nach der Entwicklung anfangen können, basiert auf dem Missverständnis, dass Testen auf die reine Interaktion mit dem Produkt reduziert.
Als ob keine Vorarbeiten möglich wären oder auch Interaktion mit dem Produkt nicht parallel zu Entwicklung statt finden könnte (z.B. auf verschiedenen Zwischenständen).
Eine Command & Controll-Mentalität mag ein anderer Ursprung sein. Für konstruktive Zusammenarbeit und schnelles Feedback ist schon allein diese nicht hilfreich.
Einige Modelle der tatsächlichen Arbeitsverteilung
Dies sind ein paar vereinfachte Modelle dessen, wie ich regelmäßig beobachte, dass Tester und Entwickler an einem Ticket arbeiten. Die Realität ist noch komplexer.
Rhetorische Frage: Wann wechselt hier ein Ticket von der In-Progress- in die Testspalte?
=> eine einzige In-Progress-Spalte ist ausreichend
Testen profitiert von der Vorbereitung
Das Sammeln von Informationen, das Erstellen und Besprechen erster Pläne, das Vorbereiten von Test-Daten und -Werkzeugen und vieles mehr sind Aufgaben beim Testen, die ohne ein tatsächliches Produkt durchgeführt bzw. begonnen werden können. Während oder sogar bevor der Code geschrieben wird.
Was sind gute Gründe, dies zu verschieben, bis die Entwicklung der ersten Version abgeschlossen ist? Abgesehen von Zeitmangel.
Es wäre eine Zeitverschwendung und ist ein Risiko, da es die Feedbackzeit für die Entwickler und Projektverantwortlichen verlängert.
=> eine einzige In-Progress-Spalte ist ausreichend
Testen kann in die Entwicklung integriert werden
Anbei zwei Beispiele aus meinem Alltag in denen ich enge mit Entwicklern zusammen gearbeitet habe und wir gar nicht klar sagen könnten in welcher Spalte gerade ein Ticket wäre
- Pair-Testing mit Entwicklern auf deren PC. Sie zeigten mir die Anwendung und ich beriet sie was sie ausprobieren sollen. Die Kollegen haben während dieser Sitzung Codeänderungen gemacht und ggf. die Anwendung neu gebaut um sie sofort wieder testen zu können.
- Ich kann das Produkt selbst lokal bauen und deployen. Vor diesem Hintergrund geben mir Entwickler in kurzen Abständen Code-Änderungen (git push & pull), die ich wiederum innerhalb von Minuten getestet habe. Oft während wir dabei telefonierten.
=> eine einzige In-Progress-Spalte ist ausreichend
Testen kann parallel zur Entwicklung durchgeführt werden
Es kommt häufig vor, dass ich mit dem Produkt interagiere, während die Entwickler parallel dazu noch an grundlegenden Szenarien programmieren:
Sie fangen an, Fehler zu beheben, während ich weiter teste.
Ich beginne mit dem Testen von noch nicht vollständig entwickelten Funktionen, bei denen wir uns darauf einigen, dass ich nur bestimmte Stellen betrachten soll. Frühes Feedback. Ich teste, während die Entwickler programmieren.
=> eine einzige In-Progress-Spalte ist ausreichend
Was ist mit Tickets?
All das oben Gesagte gilt unabhängig davon, wie die Arbeit organisiert ist.
Bug-Tickets – Testen ist hier zuerst (und auch zuletzt)
Bei Bug-Tickets geht es im Allgemeinen darum, dass jemand ein Problem gefunden und dies gemeldet hat. Typischerweise ein Tester. Aber nur das Symptom zu beschreiben ist für Entwickler selten ausreichend.
Ein Tester muss das genau Szenario herausfinden, dann (versuchen) die Entwickler das Problem zu beheben. Und schließlich muss der Fix getestet werden (und vielleicht noch ein paar Runden, weil es neue Probleme gibt).
Würde dieses Ticket in einer Testspalte beginnen und dann zurück in die In-Entwicklung-Spalte wechseln? …
Testen kommt hier zuerst.
=> eine einzige In-Progress-Spalte ist ausreichend
Fehlermeldungen von extern
Oft fehlt es externen Fehlerberichten an Informationen und sie beschreiben das Problem sehr schlecht, was es schwer macht, es zu reproduzieren und zu wissen, was behoben werden muss.
Tester handeln hier oft vor der Entwicklung in dem sie den Fehleranalysieren und versuchen zu reproduzieren.
=> eine einzige In-Progress-Spalte ist ausreichend
Ein einziges Ticket für mehrere Personen
Irgendwie haben Sie nur ein einziges Ticket, aber mehrere Personen arbeiten parallel daran. Sie verwenden keine Sub-Tasks.
Diese Personen können sowohl mehrere Entwickler als auch Tester sein. In welche Spalte würden Sie ein solches Ticket einordnen, vor wenn beide Disziplinen daran arbeiten?
In Jira z.B. kann ein Ticket nur 1 Bearbeiter haben
=> eine einzige In-Progress-Spalte ist ausreichend
Ein Ticket mit Sub-Tasks als Instanzen
Z.B. in Scrum werden oft Stories mit Sub-Tasks verwendet.
Entweder man hat dedizierte Sub-Tasks für Entwicklung und Testing:
=> eine einzige In-Progress-Spalte ist ausreichend
Und/oder mehrere Personen arbeiten an den Teilaufgaben:
=> eine einzige In-Progress-Spalte ist ausreichend, siehe Absatz zuvor.
Zusammenfassung
Testen und Entwickeln sind Aufgaben, die grundsätzlich parallel durchgeführt werden können. Nur weil noch kein Code geschrieben ist, heißt es nicht, dass Tester nichts zu tun haben.
Außerdem bilden beide eine Rückkopplungsschleife:
Das Testen informiert (mindestens) die Entwicklung und die Entwicklung gibt dem Testen etwas, mit dem es interagieren kann.
Im schnellsten Fall kann diese Schleife in wenigen Minuten mehrmals durchlaufen werden.
Feedback bringt man besser früher als später ein. Wenn Entwickler bereits den Kontext gewechselt haben, dauert es für diese länger wieder ins Thema zu kommen.
Jedes Ticket in einem Issue Tracker ist ein (vereinfachtes) Modell einer komplexeren Realität.
Vor allem die Möglichkeit, nur einen Mitarbeiter zuzuweisen, ist oft weit von der Realität der Teamarbeit entfernt.
Alternativen
Hier sind einige Ideen, was man stattdessen tun könnte.
- Personenorientiert:
- Eine Liste alle Personen, die an dem Ticket arbeiten.
- Für jede Person kann man einen Status pflegen ob sie noch daran arbeitet oder schon fertig ist. Z.B. als Wort oder Symbol.
- Eine Liste alle Personen, die an dem Ticket arbeiten.
- Aufgabenorientiert:
- Eine Liste von Aufgaben mit Namen wer an welcher arbeitet. Hier gilt das Gleiche für den Status.
- Subtasks anstatt einer Liste. Die Felder Bearbeiter und Status gibt es hier meistens.
- Welche Aufgaben man fürs Testen haben kann:
- X vorbereiten, Y erforschen, Z überprüfen/besprechen. Für so viele Unterthemen wie nötig.
- Wenn man Session-Based Test Management verwenden, kann man für jede Sitzung einen Subtask erstellen.
- Daten vorbereiten? Ein Werkzeug entwickeln oder verbessern? Die Grundlagen des neuen Features lernen? Was auch immer => ein neuer Subtask