© 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 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.

Testgetriebene Entwicklung mit Akzeptanztests

Acceptance Test-driven Development (ATDD) ist ein bereits bekannter Ansatz, der die externe Sicht eines Systems und die Kommunikation zwischen Kunden, Entwicklern und Testern in den Fokus rückt. Verwandt damit ist auch der Ansatz des Behaviour-driven Developments (BDD). Das Ziel ist jeweils, die Anforderungen so zu spezifizieren, dass sie später in der Qualitätssicherung genutzt werden können. Darüber hinaus wollen wir den testgetriebenen Entwicklungsansatz nutzen und zuerst die Tests schreiben, bevor wir die Lösung implementieren. Können wir das System während der Umsetzung mit unseren Tests validieren, haben wir eine einfache Metrik, ob die Anforderungen erfüllt werden. Testgetriebene Entwicklung führt dazu, dass die Software stets an die neuen Anforderungen angepasst werden muss. Fehler sind besser lokalisierbar, und es kann ohne viel Zeitaufwand geprüft werden, ob die Software funktioniert. Nicht zuletzt dokumentieren die Tests die Funktionalität der Software. Es lohnt sich deshalb, die testgetriebene Entwicklung auf die Ebene der Akzeptanztests anzuwenden. Obwohl ATDD ein bereits bekannter Ansatz ist, stellt deren Einführung und konsequente Anwendung so manches Team vor Herausforderungen. Wer schreibt die Tests? Wer kümmert sich um deren Pflege? Wie werden sie automatisiert? Welches Tooling verwendet man?

Akzeptanzkriterien formulieren

Der Kunde hat eine Idee für ein Feature und eventuell ein Szenario, wie sich...

Neugierig geworden? Wir haben diese Angebote für dich:

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