Akzeptanzkriterien oder -tests als Anforderungsdokumentation?

Wird in einem agilen Softwareprojekt eine Dokumentation der Anforderungen, die in einer Software realisiert werden (Systemanforderungen), benötigt? Und wenn ja, welche Form und welcher Detailierungsgrad ist dabei sinnvoll?

Bei der ersten Frage kommen mir direkt die Sätze „Lauffähige Software ist wichtiger als ausführliche Dokumentation“ und „Der Quellcode ist die beste Dokumentation (da immer aktuell)“ in den Sinn. Nun schränkt das Agile Manifest direkt ein, dass Dokumentation nicht unwichtig, lauffähige Software eben nur wichtiger ist. Und die Aussage bzgl. des Quellcodes bezieht sich auf die Dokumentation wie und nicht was eine Software macht. Daher spricht nichts gegen eine solche Dokumentation. Im Gegenteil, der Qualitätsanspruch und die damit notwendige Qualitätsicherung machen eine solche Dokumentation sogar zwangsläufig erforderlich.

Eine Prüfung der Umsetzungsqualität erfolgt durch den Vergleich der Anforderungen mit dem Verhalten der realisierten Software. Und dies gilt nicht nur für gerade umgesetzte Anforderungen, sondern auch für alle schon früher umgesetzten Anforderungen (solange sie sich nicht explizit ändern oder wegfallen). Daher wird eine Beschreibung des erwarteten Verhaltens der Software benötigt.

Akzeptanzkriterien und Testfälle

Im agilen Umfeld (mit User Stories) werden Anforderungen meist durch Akzeptanzkriterien genauer beschrieben. Hierbei wird für eine Ausgangssituation (Given) und ein Ereignis (When) ein Verhalten der Software (Then) zugeordnet. Wie offen oder genau die Ausgangssituation, das Ereignis oder das Verhalten dabei beschrieben sind, variiert. Beispiele hierfür können sein:

• „Ein deuscher Benutzer ist angemeldet, wenn er in einem beliebigen Textfeld Text mit deutschen Rechtschreibfehlern eingibt, wird die fehlerhafte Stelle unterstrichen.“
• „Das System befindet sich in einem konsistenten Zustand, wenn ein Benutzer die GUI bedient, bleibt das Sytem immer benutzbar und konsistent.“
• „Es gibt im Sytem ein Kundenunternehmen mit einer Kontaktperson, wenn der Benutzer eine neue Kontaktperson zu diesem Unternehmen mit gleichem Namen und Vornamen erfasst, zeigt das System einen Warnhinweis einer möglichen Doppelerfassung an.“

Dabei sind diese Akzeptanzkriterien nicht von der Umsetzung des Produkts oder eines Testumfelds abhängig. Jede weitere umgesetzt User Story erweitert oder verändert die Menge der Akzeptanzkriterien des Gesamtproduktes. Neben den Akzeptanzkriterien der User Stories gibt es auch „unausgesprochene“ Kriterien, die gar nicht explizit erwähnt werden und meist sehr offen formuliert werden, z.B. „Egal was passiert, keine unbehandelten Fehler/Speicherlecks/Abstürze“ oder „Lesbare und übersichtliche Benutzeroberflächen“.

Um die Qualität der aktuellen Umsetzung zu prüfen, werden für die Akzeptanzkriterien explizite Testfälle erzeugt. Diese berücksichtigen das aktuelle Testumfeld (wie Technologien und Testdaten) in dem die aktuelle Umsetzung getestet wird. Je offener ein Akzeptanzkriterium formuliert ist, desto mehr Testfälle werden benötigt (und um so schwieriger wird es, sinnvolle Testfälle zu formulieren). Um die Qualität zu überprüfen, muss die Menge dieser Akzeptanztests durchgeführt werden. Eine manuelle Ausführung dieser Tests ist schon nach kurzer Projektlaufzeit nicht mehr regelmäßig möglich. Daher werden möglichst viele dieser Tests automatisiert.

Was könnte jetzt als „Dokumentation der Anforderungen“ dienen?

Die Liste der Akzeptanzkriterien ist im Grunde eine gute Dokumentation. Sie erfordert aber ein hohes Maß an Disziplin und Aufwand, um aktuell gehalten zu werden. Dies wird wahrscheinlich gerade im Projektstress als erstes ausgelassen werden. Dadurch kann sie sowohl nicht mehr zur aktuellen Umsetzung, als auch nicht mehr zu den aktuellen Testfällen passen.

Die automatisierten Tests und die Liste der nicht automatisierten Testfälle haben dagegen den Charme, dass sie bei der Qualitätsprüfung zumindest teilweise auf Aktualität geprüft werden. Ein fehlgeschlagener Test kann auf einer fehlerhaften Umsetzung des Produkts oder auf einen fehlerhaften Testfall beruhen. Beides könnte aber auch falsch sein und so zueinander passen, dass der Test erfolgreich ist. Dies kann zu einem systemischen Problem werden, da gerade eine enge Zusammenarbeit von Produktentwicklern und Testentwicklern die Wahrscheinlichkeit für diesen Fall erhöht. Dies ist  natürlich noch stärker der Fall, wenn es sich bei beiden Rollen um dieselbe Person handelt. Gerade im agilen Teamsetup, mit Entwicklern und Testern im selben Team, ist das nicht sonderlich ungewöhnlich. Weiterhin stellt sich die Frage, wie vollständig die Anforderungen durch die Tests beschrieben werden. Schon die Akzeptanzkriterien werden nicht alle Anforderungen vollständig beschreiben und die Testfälle werden nicht die Akzeptanzkriterien vollständig abdecken. Gerade bei sehr offen formulierten Akzeptanzkriterien, sind brauchbare Tests nicht immer einfach zu finden. Ein weiteren Nachteil der Testfälle ist, dass sie eine hohe Abhängigkeit zur Testumgebung haben, was bedeutet das sie ohne diese Umgebung nur begrenzt Sinn ergeben. Damit wird auch die Testumgebung mit Ihren enthalten Testdaten zu einem dauerhaften „Artefakt“ des Projekts, welches persistiert und kontinuierlich gepflegt werden muss. Während der Umsetzungsphase eines Projekts ist dies meist gewährleistet, aber in den folgenden Wartungsphasen wird der dadurch entstehende Aufwand oft vergessen (und nicht betrieben).

Ergebnis

Um die Qualität von Software zu beurteilen, ist eine Dokumentation der umgesetzten Anforderungen erforderlich. Wenn man nicht durch andere externe Bedingungen (z.B. Normen oder Unternehmensrichtlinien) zu einer dokumentenlastigen Form gezwungen wird, kann meiner Meinung nach sowohl die  Menge der Akzeptanzkriterien, als auch die auf diesen basierenden Testfälle ein brauchbares Format darstellen. Dies ist aber nicht ohne Kosten, denn je nachdem, welche Form man für sein Projekt wählt, ist zusätzlicher Aufwand zu betreiben.

Wie beschreibt Ihr was eine von Euch entwickelte Software kann und was nicht?