Continuous Communication und Acceptance Test Driven Development für bedarfsgerechte Softwareentwicklung
„Geliefert wie bestellt, aber nicht wie gewünscht.“ – dieses Zitat aus einem unserer Workshops beschreibt ein häufiges Problem zwischen Kunden und (Software-)Lieferant im Rahmen der Softwareentwicklung. Zwischen dem, was der Kunde beschreibt und dem, was er tatsächlich haben möchte, kann ein großer Unterschied liegen.
Das sogenannte Acceptance Driven Development (ADD, synonym zu Behaviour Driven Development und Specification by Example) ist eine Technik der agilen Softwareentwicklung, die genau dieses Problem adressiert. Hierbei werden die konkreten Anforderungen an die zu entwickelnde Software festgehalten, mit dem Ziel, automatisierte Akzeptanztests zur Verfügung zu stellen und idealerweise auch kontinuierlich auszuführen.
Zur Ableitung der konkreten relevanten Anforderungen muss ein ständiger Austausch zwischen dem Kunden -meist in Form der jeweiligen Fachabteilung-, dem Entwickler und dem Tester etabliert werden. Wir sprechen hierbei von der sogenannten „Continuous Communication“. Nur dann, wenn während des gesamten Entwicklungsprozesses eine solche Continuous Communication in Hinblick auf die konkreten Anforderungen stattfindet, wird die Software entsprechend den aktuellen Bedürfnissen des Kunden entwickelt und geliefert.
Im Folgenden betrachten wir die Vorgehensweise des Acceptance Test Driven Developments und die Continuous Communication als wichtigen Bestandteil dieser genauer.
Praxisprobleme bei der Spezifikation
In der Praxis häufig anzutreffende Antipattern in Bezug auf die Spezifikation einer zu entwickelnde Software sind folgende:
Zunächst wird die Spezifikation oftmals nicht direkt vom Fachbereich in Form von konkreten, messbaren Anforderungen formuliert und festgehalten. Darüber hinaus wird sie während des gesamten Prozesses häufig nicht an neue Anforderungen angepasst und am laufenden Produkt überprüft -Papier ist eben geduldig. In der Konsequenz ist die korrekte Implementierung der Spezifikation dann auch nicht direkt beweisbar. Prinzipiell unterliegt die Spezifikation einem Einwicklungs-und Releasezyklus – genau wie der Quellcode. Sie bilden zwei Entwicklungsstränge, die jedoch ständig gekoppelt werden müssen, damit der aktuelle Stand zu jedem Zeitpunkt bekannt ist (siehe Abbildung 1).
Abbildung 1: Notwendigkeit der Anpassung von Spezifikation und Code.
Mit Acceptance Test Driven Development und Continuous Communication zur ausführbaren Spezifikation
Die zuvor genannten Probleme in Hinblick auf die Spezifikation werden mit dem Lösungsansatz einer ausführbaren Spezifikation, dem Acceptance Test Driven Development, adressiert: Hierbei werden konkrete Testfälle auf Spezifikationslevel definiert und jederzeit, idealerweise kontinuierlich, ausgeführt. Diese Testfälle werden nahe dem Quellcode eingecheckt und mitversioniert. Im Ergebnis ist zum einen dokumentiert, welche Features eine Version der Software enthält. Zum anderen wird über die Ausführbarkeit der Testfälle die Funktionalität bewiesen – oder es wird im Nachhinein deutlich, welche Randbedingungen vergessen wurden. Wenn alle Tests grün sind, gilt die Anwendung als abgenommen.
Allein die Fähigkeit, Features zeitnah in eine Produktion deployen zu können, garantiert jedoch nicht, dass das entsprechende Feature auch den Kundenwünschen entspricht. Neben der technischen Fähigkeit, ein Produkt schnell weiterentwickeln und deployen zu können, ist es daher unerlässlich, die Kundensicht auf das Produkt zu haben. Andernfalls wird möglicherweise ein technisch exzellentes Produkt entwickelt, für das es aber letztlich auf Kundenseite keinen Bedarf gibt (siehe Abbildung 2).
Abbildung 2: Notwendigkeit von technischer und fachlicher Qualität des Produktes.
Für die Vollständigkeit und Qualität der Testfälle muss der Kunde/Fachbereich daher unbedingt eingebunden und verantwortlich gemacht werden. Unterstützt wird er bei der Erstellung der automatischen Abnahmetests von Entwicklung und Quality Assurance, insbesondere in den Aspekten Testabdeckung, Randfälle, Vollständigkeit und technische Umsetzung. Für einen dauerhaften Erfolg des Endprodukts muss über den gesamten Entwicklungsprozess hinweg ein solcher Austausch, Continuous Communication (siehe Abbildung 3) gewährleistet sein.
Abbildung 3: Continuous Communication während des Entwicklungsprozesses.
Insgesamt ermöglicht Acceptance Test Driven Development und Continuous Communication also eine konkrete Spezifizierung und Anpassung der Anforderungen des Kunden/Fachbereichs in Form von automatisierbaren Akzeptanztests. Diese können bereits während des Entwicklungsprozesses durchlaufen werden, so dass die Implementierung der Spezifikation nachgewiesen werden kann sowie Probleme und Fehler frühzeitig erkannt und behoben werden.
Acceptance Test Driven Development arbeitet dabei mit Tools (z.B. Robot, Cucumber oder FitNesse), die eine Trennung zwischen fachlichem und technischem Teil der Tests erlauben. Dies versetzt die fachlichen Tester in die Lage, gemäß neuer Anforderungen selbst neue Tests formulieren zu können. Continuous Communication als Bestandteil wird durch ATDD Tools mit verschiedenen Layern unterstützt: Fachlicher Test (Given/When/Then), Code zur Lauffähigkeit (Entwickler), Zuordnung von Business Case auf die Anwendung.
Erfahrungsbericht Aus der Praxis
Neben einer bedarfsgerechteren Entwicklung und damit einer Erhöhung der Qualität und der Akzeptanz beim Fachbereich ergeben sich durch den Einsatz automatisierter Akzeptanztests durchaus noch weitere Vorteile. Diese sollen im Folgenden anhand eines konkreten Projektes erläutert werden.
Ausgangssituation:
Eine fachlich komplexe Anwendung auf Webtechnologie (Clients laufen im Browser) hat einen Releasezyklus von 3 Monaten. Dieser Zyklus kann schwer verkürzt werden, da die Fachabteilung sämtliche neuen und alten Funktionen auf Korrektheit testen muss. Die durchzuführenden Tests (~500) sind in einer Excel-Liste gepflegt und werden ggf. angepasst und erweitert. Im Fachbereich gibt es ein bis zwei Personen, die, in der Lage sind, zuverlässig alle fachübergreifenden Tests durchzuführen. In der Praxis erledigt dies immer dieselbe Person. Dies bedeutet, dass eine der fähigsten Personen des Fachbereichs für zwei bis drei Wochen gebunden ist (Test durchführen, Rücksprache halten bei unerwarteten Ergebnissen, Klärung von Problemen und Missverständnissen usw.). Die Tests finden Prinzip bedingt immer sehr spät im Releasezyklus statt, da hierfür die gesamte zu testende Funktionalität vorhanden sein muss. Als Folge werden Fehler und Missverständnisse erst sehr spät erkannt. Im Ergebnis ist eine Gefährdung des Releasetermins wahrscheinlich. Darüber hinaus ist die Wahrscheinlichkeit groß, dass der Aufwand für die Beseitigung der Fehler in diesem fortgeschrittenen Stadium bereits relativ hoch ist.
Lösung:
Der Lösungsansatz für dieses ineffiziente Szenario besteht darin, die bereits vorhandenen Tests automatisiert laufen zu lassen (via Selenium + Robot). Hieraus ergeben sich verschiedene Nutzenaspekte: Zum einen wird die Fachseite entlastet, da nur noch die Ergebnisse der Tests kontrolliert werden müssen und diverse Varianten (Firefox, IE, Chrome) einfach automatisiert mitgetestet werden können. Zum anderen können die automatisierten Tests während der gesamten Entwicklung kontinuierlich laufen, sodass Probleme und Fehler direkt sichtbar werden und in einem frühen Stadium beglichen werden können.
Bei der Automatisierung der Tests wurde außerdem deutlich, dass viele Testbeschreibungen bis dato nicht eindeutig definiert waren. Als Beispiel steckten hinter der Formulierung ‚Feld xy darf nicht mehr als 10 Stellen haben‘ ganz unterschiedliche Erwartungen. In einem Fall durften im Webformular gar nicht mehr Stellen eingegeben werden, in einem anderen Fall wurde (via JavaScript) bei der 11. Stelle eine Meldung eingeblendet und in einem weiteren Fall kam erst nach Absenden des Formulars eine Fehlermeldung vom Server zurück. Durch die Automatisierung ist nun die genaue Erwartungshaltung klar ersichtlich, da sie ja im Code (oder direkt lesbar) hinterlegt ist.
Um dieses Beispiel korrekt zu überprüfen, mussten QA, DEV und Fachbereich eng zusammenarbeiten. So konnte sichergestellt werden, dass die unterschiedlichen Prüfungen so tatsächlich korrekt (DEV) und gewollt (Fachbereich) sind. Dieses Praxisbeispiel zeigt somit auf, wie wichtig Continuous Communication für die korrekte Implementierung der Akzeptanztests ist. Im Zuge dieses Acceptance Test Driven Developments konnte durch die Implementierung der Akzeptanztestfälle der Releasezyklus deutlich verkürzt werden. Eine einmalige manuelle Überprüfung gegen Ende der Entwicklung wurde durch eine ständige automatisierte Überprüfung ersetzt. Diese diente als Indikator für die Releasefähigkeit des aktuellen Entwicklungsstandes.