Akzeptanzkriterium vs. Akzeptanztest vs. Testfall

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

So für den Alltag ist wahrscheinlich intutiv klar, was ein Akzeptanzkriterium, ein Akzeptanztest und ein Testfall ist und wie die sich unterscheiden. Bei detaillierterer Beschäftigung damit, beispielsweise wenn man mal versucht, selbst hierfür Definitionen aufzuschreiben, treten durchaus einige Fragen auf - es gibt also etwas zu Lernen. Deswegen schreibe ich so gerne auf. Hier ist mein gedankliches Bild zu den genannten drei Begriffen, erstmal im Überblick und dann im Detail.

Ein Akzeptanzkriterium beschreibt, was (welche Bedingungen) getestet werden soll und wird vom Product Owner geschrieben bzw. bereitgestellt.

Ein Akzeptanztest beschreibt, wie getestet werden soll und wird vom Entwicklungsteam geschrieben. In diesem Sinne ist ein Akzeptanztest die praktische Anwendung der Akzeptanzkriterien, wobei es zu jedem Kriterium gibt es gewöhnlich mehrere Testfälle, davon einige wenige Gutfälle und oft jede Menge Negativfälle.

Beim Akzeptanzkriterium wird die Frage "Wann ist die Anforderung fertig umgesetzt (im Sinne der Definition von Fertig (engl. Definiton of Done))?" beantwortet und ein Akzeptanztest ist die Antwort auf die Frage "Wie teste ich und welches sind die einzelnen Schritte des Tests?". Ein Testfall beantwortet die Frage "Wie und in welchen Schritten teste ich etwas?"

Akzeptanzkriterium

Definition: Ein Akzeptanzkriterium beschreibt, unter welchen Bedingungen (zusätzlich zu denen der Definition von Fertig) ein vom Entwicklungsteam umgesetztes PBL-Element als fertig entwickelt gelten soll. PBL-Elemente werden vor der Realisierung durch Akzeptanzkriterien konkretisiert und am Ende der Iteration an ihnen binär (fertig/nicht fertig) beurteilt.

Beschreibung: Der Zweck eines Akzeptanzkriteriums für Benutzergeschichten ist es, möglichst objektiv und eindeutig zu überprüfen, ob eine Funktionalität genauso beschaffen ist, wie der Benutzer oder Käufer des Systems es erwartet. Ein Akzeptanzkriterium beschreibt eine Geschäftsregeln aus Kundensicht. Akzeptanzkriterien werden vom Product Owner verfaßt oder bereitgestellt, sind schriftlich zu formulieren und repräsentieren eine Anforderung im engeren Sinne, d.h. sie sind eine Vereinbarung (Vertrag) zwischen einem Anforderungsgeber (in Scrum der Product-Owner) und einem Anforderungsumsetzer (in Scrum das Entwicklungsteam).

Akzeptanzkriterien müssen eindeutig und objektiv messbar sein. Akzeptanzkriterien sind festzulegen, bevor mit der Entwicklung eines PBL-Elementes begonnen wird. Spätestens also in der Iterationsplanung. Akzeptanzkriterien sind im laufenden Anforderungsdiskurs idealerweise simultan zu ergänzen und zu aktualisieren und dienen nicht der nachträglichen Dokumentation des Anforderungsdiskurses.

Benutzergeschichten sind der defacto-Standard für PBL-Elemente in Scrum und somit beziehen sich Akzeptanzkriterien gewöhnlich auf Benutzergeschichten. Letztendlich ist dies aber nicht zwingend, so dass Akzeptanzkriterien auch mit beliebigen anderen Arten von PBL-Elementen verwendet werden können, bspw. Iterationsfeatures oder Anwendungsfällen.

Ein Kriterium ist eine Eigenschaften, die eine Lösung beinhalten muss. Zu jedem Kriterium gibt es gewöhnlich mehrere Testfälle, davon einige wenige Gutfälle und oft jede Menge Negativfälle.

Akzeptanztest (in Scrum)

Definition: Ein Akzeptanztest ist eine vom Entwicklungsteam erstellte Beschreibung, wie die Akzeptanzkriterien überprüft werden sollen.

Beschreibung: Grundsätzlich besteht ein Akzeptanztest aus:

- Vorbedingungen (z.B. "Mit Benutzername "Gast" und Kennwort "Gast" einloggt", "Auftrag 4711 ausgewählt")

- Aktionen eines Szenarios ("Im Feld 'Status' den Wert 'bestätigt' auswählen und dann 'Auftrag drucken')

- Nachbedingungen bzw. erwartetes Ergebnis ("Druckvorschau für Auftrag erscheint")

Wie sollte ein Akzeptanztest beschaffen sein?

- Abstrakt: Der Akzeptanztest sollte nicht jede Einzelheit umfassen, sondern sich auf das Wesentliche reduzieren.

- Vertrauenswürdig: Das Verhalten in der Test- und Abnahmeumgebung muss bezogen auf den zu testenden Sachverhalt immer mit dem Verhalten in der tatsächlichen Betriebsumgebung des Kunden identisch sein. Ebenso muss der Test für den Kunden nachvollziehbar reproduzierbar sein.

- Kohärent (zusammenhängend):  Ein Akzeptanztest sollte nur einen (und nicht mehrere) fachlichen Zusammenhang abdecken.

- Entkoppelt (unabhängig): Ein Akzeptanztest muss unabhängig von allen anderen sein und darf nicht durch die Ergebnisse oder Verfügbarkeit anderer Tests im Ergebnis beeinflusst werden.

- Aussagekräftig und verständlich: die Motivation, der Inhalt des Testes und sein erwartetes Ergebnis sollten für Fachleute des Testgebietes (Domänenexperten) gut verständlich sein.

- Redundanzfrei: Ein zu testender Sachverhalt sollte nur durch einen Test und nicht mehrfach abgedeckt werden.