© Excellent backgrounds/Shutterstock.com
Akzeptanztestgetriebene Entwicklung in agilen Teams

Wir müssen reden


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 Entwickler hin- und hergeschoben. Gelegentlich entflammen Diskussionen über die Bedeutung der Akzeptanzkriterien. Oder ist vielleicht doch der Analyst oder Product Owner für die Misere verantwortlich? 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 ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang