Mithilfe von Akzeptanztests wird im Rahmen der Software-Entwicklung geprüft, ob die Software die funktionalen Erwartungen und Anforderungen im Gebrauch erfüllt. In Scrum-Projekten heißt das, dass der Kunde bzw. der Product Owner testet, ob ein Release aus seiner Sicht auslieferbar ist. In diesem Artikel werden die theoretischen Grundlagen von Akzeptanztests beschrieben und Möglichkeiten der Automatisierung diskutiert.

Theoretische Grundlagen

Akzeptanztests - oder auch Abnahmetests, engl. User Acceptance Tests (UAT) - gehören organisatorisch zu den User-Stories und den in ihnen definierten Akzeptanzkriterien. Ein Akzeptanzkriterium beantwortet die Frage nach der Fertigkeit der Story aus Kunden- oder Anwendersicht. Der Akzeptanztest beschreibt die durchzuführenden Schritte, um festzustellen, ob die Funktionalität im Sinne des Akzeptanzkriteriums als korrekt betrachtet werden kann. Da Akzeptanztests eigentlich vom Kunden (oder zumindest in dessen Anwesenheit) durchgeführt werden sollen, stehen sie also sowohl am Anfang (Definition) als auch am Ende (Durchführung) der Entwicklung einer User-Story. In der Regel sieht der Prozess wie folgt aus:

1. Die Story wird entworfen.
2. Akzeptanzkriterien werden vom Product Owner definiert (und ggf. im Laufe der Zeit erweitert).
3. Das Entwicklerteam oder ein separates Qualitätssicherungsteam erstellt Akzeptanztests.
4. Die Story wird umgesetzt.
5. Der Kunde, der Product Owner und/oder die Qualitätssicherung führen die Akzeptanztests durch, die Story wird abgenommen.
6. Die Story wird veröffentlicht.

Im Entwicklungsprozess steht die Durchführung von Akzeptanztests also ganz am Ende unmittelbar vor der Inbetriebnahme. Daher haben Akzeptanztests eine besonders große Bedeutung.

Ein Akzeptanztest ist eine vom Entwicklerteam verfasste Beschreibung der Überprüfung der in der Story definierten Akzeptanzkriterien. Er soll dabei helfen, jedem einzelnen Teammitglied ein Verständnis davon zu vermitteln, was der Kunde eigentlich wirklich möchte. Hierfür ist eine intensive Beschäftigung mit den Akzeptanzkriterien und -tests von großer Bedeutung.

Wie das Team einen solchen Test schreibt, ist ihm selbst überlassen. Sofern man die Akzeptanztests nicht automatisieren möchte, kann so ein Test durchaus einfach auf Pappkärtchen geschrieben werden. Wichtig ist dabei nur, dass der Tester weiß, was zu tun ist.

Akzeptanztests sind sog. Black-Box-Tests. Dass heißt, dass der programmierte Code und die interne Logik dem Tester nicht zur Verfügung stehen, es geht um die reine Funktionalität an der Oberfläche.

Ein Akzeptanztest setzt sich aus folgenden Bestandteilen zusammen:

• Vorbedingungen (z.B. aufzurufende URL)
• Aktionen des Szenarios (z.B. Beschreibung des notwendigen Klickverhaltens auf einer Website)
• Nachbedingungen bzw. erwartetes Ergebnis (z.B. Fehler-/Erfolgsmeldungen)

Ein Akzeptanztest sollte folgendermaßen beschaffen sein:

• abstrakt
• vertrauenswürdig (Verhalten muss mit dem im Live-Betrieb identisch und für den Kunden nachvollziehbar sein)
• kohärent (nur einen fachlichen Zusammenhang abdecken)
• entkoppelt/unabhängig
• aussagekräftig und verständlich
• redundanzfrei

In der Praxis treten folgende Probleme bei Akzeptanztests relativ häufig auf:

• Es werden nur „Gut-Fälle“ getestet, also keine Fälle, in denen die Anwendung mit Fehlern reagiert, z.B. weil es sich um falsche Eingaben handelt. (Hier ist jedoch die Notwendigkeit weiterführender Tests im Einzelfall zu prüfen: Pauschal kann man nicht sagen, dass nicht ausschließlich Gut-Fälle getestet werden sollen.)
• Die Abnahmeumgebung entspricht nicht der Produktivumgebung.
• Im Rahmen unbegleiteter Tests durch den Kunden kommt es zu Reports von Fehlern, die tatsächlich auf Bedienfehler zurückzuführen sind. Dies ist sicherlich ein besonders häufig auftretendes Problem. Einerseits muss zwar auch der „unbedarfte“ Endanwender ohne Anleitung mit der Applikation arbeiten können, die Vermeidung von Bedienfehlern ist aber nicht unbedingt Bestandteil der Story.
• Es sind keine Abnahmekriterien/Fehlerklassen definiert.
• Es kommt zu Personalproblemen während der Abnahmephase: Wenn niemand eine Story testen kann, kann dies die Auslieferung verzögern oder gar dazu führen, dass ohne Abnahme ausgeliefert wird. Hier bietet sich die Automatisierung von Akzeptanztests als sinnvoll an.
• Wichtige Tests sind zu ungünstigen Zeitpunkten eingeplant, z.B. am Ende der Abnahmephase.

Automatisierung von Akzeptanztests

Die Automatisierung von Akzeptanztests ist ein logischer Schritt hin zu einer kontinuierlichen Qualitätssicherung. Warum sollten Entwicklungsteams automatisiert testen? Durch die iterative Arbeitsweise im Scrum-Prozess hat der Kunde stets die Möglichkeit, seine Prioritäten zu verlagern bzw. neue Wünsche ins Produkt aufzunehmen. Von Sprint zu Sprint kann sich die Code-Basis daher enorm verändern, ein manuell ausgeführter und erfolgreicher Akzeptanztest wird jedoch in der Regel nicht ein zweites Mal durchgeführt, erst recht nicht, wenn die Kapazitäten knapp und der Zeitplan sportlich sind.

Davon abgesehen wird eine Funktionalität (Epic) oft erst nach mehreren Sprints vollständig abgeschlossen. Mit der kontinuierlichen Integration (Continous Integration) von automatisierten Akzeptanztests kann sichergestellt werden, dass alle bisher entwickelten Funktionen nach wie vor den Wünschen des Kunden entsprechen.

Bei der Automatisierung von Akzeptanztests arbeiten Product Owner und Entwickler eng zusammen, denn der Entwickler programmiert den Test und benötigt dazu die vom Product Owner definierten Akzeptanzkriterien.

Vorweg: Ein Königsweg und eine wirklich richtige Lösung zur Automatisierung von Akzeptanztests existiert bislang nicht. Einen gangbaren Weg in diese Richtung beschreitet das BDD-Paradigma (Behaviour Driven Development). Eine ausführliche Einführung in BDD soll  an dieser Stelle nicht erfolgen, nur so viel: BDD erweitert die Testgetriebene Entwicklung (TDD) um die Betrachtung des Verhaltens statt der Funktionalität. Dazu schreibt man das geforderte Verhalten in Textform auf und übergibt diesen Text dem System.

In der Regel weist die Code-Basis von BDD starke Ähnlichkeit mit den Umgebungen für Unit-Tests auf, ein testender Entwickler wird sich darin also gut zurechtfinden können. Allerdings werden nun die programmierten Tests um zwei Schichten ergänzt: Am Anfang steht eine Testbeschreibung (auch Szenario genannt) in natürlicher, wenngleich stark formalisierter Sprache (Stichwort: Domain Specific Language/DSL). Diese Testbeschreibung bringt an dieser Stelle den Akzeptanztest und die Akzeptanzkriterien ins Spiel, denn beides liegt im Idealfall ja bereits in Textform vor.

Unterhalb der Testbeschreibung liegt ein Parser, der diese Testbeschreibung analysiert und die tatsächliche Ausführung des Tests anstößt. Jeder Schritt des Szenarios muss an eine Implementierung gekoppelt sein, was zum Beispiel mit regulären Ausdrücken, Mapping-Tabellen u. ä. geschehen kann.

Bekannte Frameworks sind z.B. folgende:

• FIT (defacto Standard) (umfangreiche Anleitung dazu)
• JBehave (Java)
• Cucumber (Ruby)
• RSpec (Ruby)
• Test::Cukes (Perl)
• Jasmine (Javascript)

Oberflächentests

Da Akzeptanztests selbst oft an der Anwendungsoberfläche durchgeführt werden, bieten sich insbesondere bei Webapplikationen Tools wie Selenium, sahi oder watir als Testbasis an.

Gerade mit solchen Tools lassen sich einfache und etwas “abgespeckte” automatisierte Akzeptanztests leicht erstellen. Da Selenium ein Aktions-Recorder ist, muss hier mindestens ein Akzeptanztest per Hand erstellt und ausgeführt werden, erst dann ist dieser regelmäßig immer wieder aufrufbar. Das Testen der User-Story würde hier also durch eine Aufzeichnung ergänzt. Automatisiert abgespielte aufgezeichnete Test-Sessions bieten einen guten Einstieg und können eine wertvolle Hilfe bei der Entwicklung sein.

Die Risiken sollte man jedoch im Blickfeld haben: Selenium basiert auf der DOM-Struktur des HTML-Dokuments. Harmlose Änderungen im DOM-Baum (z.B. nach der Integration eines Banners oder neuer Inhalte irgendwo im Dokument) können zur Folge haben, dass der Test fehlschlägt, obwohl sich an der Funktion gar nichts geändert hat. Der Wartungsaufwand kann also hier sehr hoch werden, insbesondere bei dynamischen Projekten mit häufigen Änderungen. Systeme mit flexiblen Techniken zum Parsen von HTML sind also sinnvoll.

Vor- und Nachteile automatisierter Akzeptanztests

Folgende Vorteile bieten automatisierte Akzeptanztests:

• Es findet eine aktive Arbeit mit der Dokumentation statt, die Aktualität und Korrektheit kann sichergestellt werden. (In der Realität hat sich jedoch auch gezeigt, dass Tests so gut wie nie vom Kunden geschrieben werden, obwohl die DSL die Möglichkeit bietet.)
• Automatisierte Akzeptanztests unterstützen die aktive Kommunikation und die Einbindung der Fachdomäne bzw. des Kunden.
• Die Funktionalität wird auch über lange Zeiträume hinweg und bei vielen Änderungen sichergestellt.

Der sicherlich am schwersten wiegende Nachteil von automatisierten Akzeptanztests besteht wohl in dem nicht unerheblichen Aufwand für die Implementierung. Hier bestehen Parallelen zwischen Unit- und Akzeptanztests, denn beide sind in der Praxis insbesondere bei den Entwicklern nicht immer beliebt. Ihren wahren Nutzen können sie erst entfalten, wenn sie existieren, gut implementiert sind und regelmäßig ausgeführt und gewartet werden.

Ein weiterer Nachteil kann gegebenenfalls das fehlende Erlebnis auf Seiten des Testers sein. Beim klassischen Akzeptanztest interagiert der Tester direkt mit dem Produkt und erhält ein direktes und unmissverständliches Feedback über das Testergebnis. Er kann zudem spontan agieren und auch einfach mal mit der zu testenden Funktion "spielen" und herumprobieren (exploratives Testen).

Bei der Automatisierung hingegen werden lediglich die Testschritte als Text geschrieben/gelesen, das Testergebnis steht kaum mit dem Produkt in Verbindung, der Tester bekommt es womöglich nicht einmal zu sehen. Für ihn oder den Product Owner dürfte es schwierig sein, auf diese Art Vertrauen in das Produkt und besonders in die Tests zu gewinnen. Hier sind also vertrauensbildende Maßnahmen nötig, etwa ein paralleles manuelles Testen und automatische Tests.

Leider existiert meines Wissens zurzeit keine wirklich brauchbare "fertige" Lösung zur Automatisierung von Akzeptanztests. Frameworks für das Testen von Oberflächen sind ein erster Ansatz, können unter Umständen aber auch schnell lästig werden, wenn der Wartungsaufwand steigt und steigt. Eine flexible und gut durchdachte Testplanung ist hier wichtig. BDD-Frameworks sind ebenfalls ein guter Ansatz, denn sie bieten die textbasierte Testbeschreibung. Allerdings sind Akzeptanztests und BDD meines Erachtens nicht gleichzusetzen: Hier steht Prozess gegen Paradigma. Akzeptanztests lassen sich mithilfe von BDD-Frameworks möglicherweise durchführen – es würde sich lohnen, die technischen Details gelegentlich gründlich zu durchdenken –, BDD-Frameworks sind jedoch nicht dazu gedacht, Akzeptanztests zu automatisieren.

Die Kombination von textbasierter Testbeschreibung (BDD-Frameworks) und automatisierten Oberflächentests ist hier augenscheinlich eine vielversprechende Lösung, die in der Praxis auch bereits eingesetzt wird.

Grundsätzlich kommt es natürlich immer auf die Art der Tests, die User-Story, die zu entwickelnde Software usw. an. Ich denke jedoch, dass in der Regel ein oberflächenbasierter Ansatz die Anforderungen abdecken dürfte. Man stößt also zwangsweise immer wieder auf Frameworks für Oberflächentests. Hier müsste man allerdings möglicherweise zunächst ein individuell passendes Framework entwickeln, das auch auf die eigenen Anforderungen zugeschnitten ist und sich gut in die Entwicklungsarbeit integriert.

Dieser Tage ist eine Debatte zu beobachten, die James Shore, ein bekannter Vordenker und Aktivist der "agilen Szene" angestoßen hat. Es geht um die Frage, ob automatisierte Akzeptanztests ein guter Weg sind und ob es nicht auch bessere Alternativen gibt. Interessanten Lesestoff dazu gibt es unter:

• James Shore: Alternatives to Acceptance Testing
• InfoQ: Jim Shore Suggests Automated Acceptance Tests Are Not The Right Move

Fazit

Akzeptanztests sind ein wichtiges Mittel zur Sicherstellung der Funktionsfähigkeit einer Software. Sie fördern (wenn man sie "nach Handbuch" durchführt) die Kommunikation und das Verständnis von Team und Product Owner mit- und untereinander.

Die Automatisierung sehe ich momentan allerdings überwiegend kritisch aus folgenden Gründen:

• Hoher Aufwand der Implementierung
• Technische Herausforderungen
• Mögliche Akzeptanzprobleme bspw. bei Testern aufgrund des fehlenden Test-Erlebnisses

Eine gute Automatisierungsmöglichkeit wäre allerdings wünschenswert, denn nur so kann die Qualität auch über eine lange Zeit hinweg sichergestellt werden. Dazu fehlen meiner Erfahrung nach jedoch die Lösungen. Möglicherweise bieten die verlinkten weiterführenden Diskussionen zum Thema ja gute und vor allem brauchbare Alternativen an. Oder haben Sie Erfahrungen gesammelt und Lösungswege gefunden? Nutzen Sie doch das Kommentarfeld unter diesem Artikel für Ihre interessanten Vorschläge. 🙂

Literatur, Referenzen und weiterführende Infos

Wikipedia: Abnahmetest
oose.team: Akzeptanzkriterium vs. Akzeptanztest vs. Testfall
Jens Coldeweys Blog: Automatisierte Akzeptanztests
Testoptimierung.de: Abnahmetest - Akzeptanztest - UAT (User acceptance Test)

Software-Tests: Notwendigkeit und Arten des Testens
Unsere spezielle Seite zum Thema agile Software-Entwicklung
Java-Projekte mit //SEIBERT/MEDIA

Mehr über die Creative-Commons-Lizenz erfahren