Scrum still Rocks – Testing still Sucks (kind of)

Vor 2 Jahren dufte ich am Swiss Testing Day 2011 meinen Vortrag „Scrum Rocks, Testing Sucks?!“ präsentieren . Es war zu diesem Zeitpunkt eines der ersten Referate, die sich mit Scrum und Testing auseinander setzten. Es ging im Wesentlichen darum, warum es sich lohnt, eine dedizierte Person fürs Testing, also einen Embedded Tester, im Scrum Team zu haben, was diese Person zu den Scrum Prozessen beiträgt und vor allem, weshalb mir diese Tätigkeit verglichen mit einem Tester-Job im traditionellen Umfeld bedeutend mehr Spass und Erfolg gebracht hat.

Der Vortrag fand grosse Beachtung, und in der Folge erhielt ich die Einladung, das Referat auch an der German Testing Night in Essen im Mai 2011 zu halten und ebenso und an der Lean Agile Scrum Konferenz in Zürich im Herbst darauf.

Als unser Trainingspartner Digicomp diesen Frühling auf uns zukam, ob wir zum Thema Agile Testing im Rahmen einer ihrer Fachreferate-Reihe einen Abend gestalten würden, kam mir die Idee, das Referat wieder „aus der Schublade“ zu holen und mit Erkenntnissen zu ergänzen, die sich in der Zwischenzeit ergeben haben: „Scrum Rocks, Testing Sucks RELOADED“ entstand.

Learnings

Wir alle haben in den vergangenen 2 Jahren viel neues dazu gelernt – immer mehr Kunden sind auf den agilen Zug aufgesprungen und ich durfte spannende Projekte begleiten. Ich war bei einem Kunden in Basel und beim Bundesamt für Informatik in Bern lange Zeit als Embedded Tester tätig und machte interessante Erfahrungen:

• Wie ich mich als Tester am besten in die Scrum-Prozesse einbringe, ist in jedem Projekt wieder ein bisschen verschieden. Manchmal bin ich nur beteiligt, manchmal sogar für die Organisation und/oder Moderation verantwortlich gewesen (Planning, Daily, Demo, Retro usw.).
• Wie eine ganze Organisation von Traditionell auf Agil transformiert wurde.
• Dass ein Embedded Tester je nach Auslastung auch mehrere (kleinere) Projekte mit verschiedenen Teams betreuen kann.
• Die Entwicklung der SET-Methodik (Strukturiert-Exploratives Testing), welche die Vorzüge von Agile mit den Vorschriften und Regulatorien von Hermes in Einklang bringt.
• Wie Coding Standards und Unit Tests helfen, die Qualität merklich zu steigern, bevor ich als Tester die Software in die Hand bekomme.
• Dass Testautomatisierung essentiell ist, um dem Workload von Regressionstests in Grenzen zu halten.
• uvm.

Fazit

Mein Fazit ist nach wie vor: Der Einsatz von Embeddeded Testing lohnt sich, sowohl für das Team, wie auch für den Auftraggeber und Kunden. In der Praxis wird dies aber häufig noch unterschätzt, und die Investition, einen Tester voll- oder auch nur teilzeitlich während des gesamten Entwicklungsprozesses einzusetzen, wird noch zu oft gescheut. Als Folge davon werden Tester immer noch zu spät ins Boot geholt, und uns obliegt dann oft die Aufgabe „Qualität ins Produkt hinein zu testen“, wenn die Entwicklung bereits soweit abgeschlossen ist, dass wir kaum noch Einfluss darauf nehmen konnten, das Produkt nachhaltig zu verbessern oder Fehler frühzeitig zu vermeiden. Gewisse Punkte wie nicht optimale Prozesse, schlechte Usability, oder auch ungenügendes Last- und Performanceverhalten können wir dann nur noch feststellen. Aber ausser dem allernötigsten lässt sich nicht mehr viel verbessern, weil der Zeitpunkt, das Produkt auszuliefern, schon viel zu nah ist.

Zusammenfassung

Meine Erfahrungen und die von meinen Kolleginnen und Kollegen von SwissQ zu Agile Testing sind in unser brandneues Embedded Testing Plakat eingeflossen, welches wir auf unserer Website zur Ansicht, Download und Bestellung zur Verfügung stellen.

Je ein Event zu diesem Thema in Bern und Zürich ist ebenfalls in Vorbereitung. Auf unserer Website gibt es mehr Informationen dazu.

Aufruf

Zu guter Letzt mein Aufruf – wieder frühzeitig ein Tester ins Team zu nehmen! Sie werden es nicht bereuen. Wir können viel mehr, also nur Bugs finden, wir haben immer auch gute Ideen, wie man Abläufe besser gestalten könnte, wie GUIs leichter bedienbar sind, wo allenfalls noch Mängel im Design vorhanden sein könnten. All dies lässt sich aber nur machen, wenn wir früh genug mit von der Partie sind. Ihr zusätzlicher Benefit: Mit Werkzeugen zur Testautomatisierung können wir bereits sehr früh die leidigen Regressionstests vereinfachen und sind bestens darauf vorbereitet, Last- und Performanceprobleme zu erkennen und dazu beitragen, Ihr System zu optimieren, bevor der erste Release zum Kunden geht!

Was ist eure Erfahrung als/mit Embedded Tester? Wo liegen die Schwierigkeiten/Knackpunkte im Testing-Alltag? Wir freuen uns über euer Feedback und eure Kommentare!

<!--[if lte IE 8]>

<![endif]--> hbspt.cta.load(452665, '78a0e289-af83-4525-8e20-7a6adc00e267');