Michael Thiele Saxonia Systems AG

Gute Akzeptanzkriterien sind die Voraussetzung für gute Software, die Kundenwünsche erfüllt.

Dr. Vincent Tietz Otto Group

Akzeptanztestgetriebene Entwicklung bringt eine deutlich höhere Testabdeckung mit sich.

Martin Uhlig Saxonia Systems AG

Tester und Entwickler sitzen nicht nur zusammen, sie werden zusammengebracht, wie es in einem agilen Team der Fall sein sollte.

Agile Teams wollen regelmäßig hochwertige und für den Kunden wertvolle Software liefern. Sie brauchen kurze Entwicklungszyklen, um frühzeitig Feedback zu bekommen, und sie müssen sicher sein, dass Änderungen die bisherige Funktionalität nicht beeinträchtigen. Testgetriebene Entwicklung und Testautomatisierung sind hier die Mittel der Wahl.
Scrum bietet uns ein Rahmenwerk zur schnellen und fokussierten Umsetzung von wertstiftenden Anforderungen in selbstorganisierten Teams. Schauen wir uns ein Team näher an, bestehend aus Entwicklern und einem Tester. Die Entwickler gehen mit Begeisterung ans Werk. Sie implementieren Unit-Tests, achten auf Clean Code, bestehen das Code Review, integrieren den Code und gehen motiviert zur nächsten User Story. Die Entwickler fühlen sich produktiv und sind gut gelaunt. Doch dann kommt gegen Ende des Sprints der Spielverderber. Der Tester hat einen Fehler entdeckt. Ein Akzeptanzkriterium wurde gebrochen. Und so muss ein Entwickler die Arbeit an einer anderen User Story unterbrechen, den Fehler beheben und eine weitere Review durchführen. Währenddessen findet der Tester weitere Fehler. Beeinflussen sich die Implementierungen gegenseitig, gibt es Fehlermaskierungen, und es kommt die Frage auf: Funktionieren die anderen Teilbereiche der Software noch? Der Schwarze Peter wird zwischen Tester und Entwicklern hin- und hergeschoben. Gelegentlich entflammen Diskussionen über die Bedeutung der Akzeptanzkriterien. Oder ist vielleicht doch der Analyst oder Product Owner verantwortlich für die Misere? Am Ende ist die Frage nebensächlich, denn das Sprintziel des gesamten Teams ist in Gefahr.

Gleichzeitig ist das Team überzeugt davon, dass ihr Vorgehen gut sei. Tests werden ernster genommen als in vielen Projekten zuvor, Testfälle vor der Testausführung vom Tester in ein Testtool geschrieben. Entwickler schauen sich die Testszenarien an und implementieren die User Story nach bestem Wissen und Gewissen. Die technischen Schulden sind minimal, die Abdeckung durch automatisierte Unit-Tests könnte nicht besser sein. Der Tester testet die Akzeptanzkriterien, hat die Fehler im Blick und pflegt die Testfallsammlung. Er kann beurteilen, welche Teile regressiv nachgetestet werden müssen und wo explorative Tests notwendig sind. Das Team harmoniert.

Schauen wir jedoch genauer hin, machen wir eine nüchterne Feststellung: Wartezeiten, Reibungsverluste, Verschwendung. Alles, was wir durch Scrum vermeiden wollen, stellt das Team durch einen gut gemeinten Qualitätssicherungsprozess zur Disposition. Tests werden eher nach klassischer Vorgehensweise unabhängig vom zu testenden System geschrieben. Der Zeitpunkt ist dabei offen: zu Beginn des Sprints, während der Entwicklung oder danach. Die Entwickler schauen, wenn überhaupt, nur sporadisch auf die Testfälle. So setzt das Team die User Stories wasserfallartig um und prüft erst am Ende, ob auch die Tests bestanden werden. Gleichzeitig sind unterschiedliche Personen mit unterschiedlichem Fokus und unterschiedlichen Artefakten beteiligt. Die Verantwortung für die Umsetzung und die Qualitätssicherung ist immer noch getrennt. Der Tester hat besonders am Anfang und am Ende des Sprints viel zu tun und ist schnell ein unbeliebter Zeitgenosse. User Stories werden über einen langen Zeitraum hinweg nicht fertig. Schuldzuweisungen können die Folge sein.

Wir stehen hier eigentlich vor zwei Problemen. Einerseits handelt es sich um ein Kommunikations- und Verständnisproblem: Nicht alle Beteiligten haben die gleiche Vorstellung von den Akzeptanzkriterien, da es oft einen Spielraum für Interpretationen gibt. Völlig natürlich vertiefen sich Entwickler in die Implementierung und setzen sich nur oberflächlich mit den Akzeptanzkriterien auseinander. Testbeschreibung und Testausführung finden unabhängig von der Umsetzung statt. Anderseits haben wir ein technisches Problem: Da die Akzeptanztests erst nach der Implementierung ausgeführt werden können, vergeht viel Zeit, bis die User Story getestet und somit wirklich fertig ist. Eine Antwort darauf kann die akzeptanztestgetriebene Entwicklung sein. Sie gibt uns die Möglichkeit, die Tugenden der testgetriebenen Entwicklung, die heute für jeden Entwickler selbstverständlich sein sollten, auch auf die fachliche Ebene der Akzeptanzkriterien zu übertragen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 6.17 - "Continuous Delivery"

Alle Infos zum Heft
579796481Scrum und die Probleme des TDD
X
- Gib Deinen Standort ein -
- or -