Akzeptanzkriterien

Akzeptanzkriterien sind die spezifischen Bedingungen, die ein Arbeitspaket erfüllen muss, um als abgeschlossen zu gelten. Sie werden einer Anforderung oder User Story zugeordnet, vor Beginn der Arbeit vereinbart und bilden die objektive Grundlage für die Bewertung des Ergebnisses. Ihre Funktion besteht darin, eine allgemeine Absichtsbeschreibung in etwas Überprüfbares statt Diskutierbares umzuwandeln.

Ihr Fehlen führt zu einem vorhersehbaren und kostspieligen Muster. Die Arbeit wird allgemein beschrieben, nach der Interpretation einer Person umgesetzt und von einer anderen Person mit einer anderen Interpretation überprüft. Die daraus resultierenden Meinungsverschiedenheiten führen dann zu Nacharbeiten im ungünstigsten Moment. Werden die Kriterien zuerst formuliert, wird diese Meinungsverschiedenheit so weit verlagert, dass ihre Beilegung ein Gespräch statt einer kompletten Überarbeitung erfordert.

Zwei Formate sind vorherrschend. Eine einfache Checkliste listet alle zu erfüllenden Bedingungen auf, eignet sich für unkomplizierte Anforderungen und lässt sich schnell erstellen. Die aus der verhaltensgetriebenen Entwicklung stammende „Gegeben-Wenn-Dann“-Struktur definiert einen Ausgangskontext, eine Aktion und ein erwartetes Ergebnis. Sie eignet sich für bedingtes Verhalten und lässt sich direkt auf automatisierte Tests übertragen. Keines der beiden Formate ist per se überlegen, und die Konsistenz innerhalb eines Teams ist wichtiger als die Wahl des Formats.

Die wertvollsten Kriterien sind diejenigen, die das abdecken, was die Beschreibung auslässt. Der Normalfall ist meist offensichtlich und selten umstritten; die Streitpunkte betreffen Validierungsregeln, Fehlerzustände, leere und extreme Daten, Berechtigungsgrenzen, das Verhalten bei Ausfall eines externen Dienstes und die Unterschiede im Verhalten auf verschiedenen Geräten. Teams, die Kriterien nur für den erwarteten Fall formulieren, entdecken die übrigen Aspekte während des Testens – und genau dort wird üblicherweise der Zeitplan festgelegt.

Kriterien beschreiben Ergebnisse statt der Implementierung, wodurch dem Team die Möglichkeit bleibt, den Ansatz selbst zu wählen. Die Angabe, dass ein Benutzer innerhalb eines definierten Zeitraums eine Bestätigung erhalten muss, ist ein Kriterium; die Festlegung der Warteschlangentechnologie, die diese Bestätigung senden soll, ist eine Designentscheidung, die nicht in eine Abnahmeerklärung gehört. Kriterien, die die Implementierung vorschreiben, schränken die Entscheidungsfreiheit derjenigen ein, die am besten dafür geeignet sind, und führen häufig zu einer Lösung, die sich im Nachhinein als unnötig erweist.

Die Rückverfolgbarkeit zwischen Kriterien und Tests verhindert, dass sich beide im Laufe der Zeit auseinanderentwickeln. Wenn jedes Kriterium einer Verifizierung zugeordnet ist, sei es automatisiert oder manuell, ist die Abdeckung sichtbar, und eine Änderung der Anforderung führt zu einer Anpassung des Tests. Werden Kriterien und Tests getrennt gepflegt, beschreiben sie zunehmend das tatsächliche Verhalten des Systems anstatt dessen ursprünglich geforderte Funktion. Dadurch verlieren sie ihre Fähigkeit, Abweichungen vom Sollzustand zu erkennen.

Nicht-funktionale Anforderungen gehören in die Kriterien, wenn sie relevant sind, werden aber üblicherweise weggelassen. Leistungsschwellenwerte, Barrierefreiheitsanforderungen, Browser- und Geräteunterstützung sowie Sicherheitsbeschränkungen sind allesamt Akzeptanzbedingungen. Werden sie implizit beibehalten, werden sie entweder uneinheitlich behandelt oder erst bei einem späteren Audit entdeckt. Hat ein Team eine gemeinsame Definition von „Fertig“, die diese Aspekte für alle Arbeiten abdeckt, müssen die einzelnen Kriterien lediglich Abweichungen davon aufzeigen.

Der Nutzen entsteht durch die gemeinsame Erstellung von Kriterien, nicht durch das Dokument selbst. Von einer Person entworfene und übergebene Kriterien stellen eine Spezifikation dar; Kriterien, die zwischen demjenigen, der die Funktionalität wünscht, dem Entwickler und dem Tester diskutiert werden, decken Unklarheiten frühzeitig auf. Die Diskussion führt häufig zu einer Änderung der Anforderungen – und genau das ist der Sinn der Sache.

Da die Kriterien definieren, was geprüft wird, verknüpfen sie die Anforderungsdefinition direkt mit der Qualitätssicherung, anstatt sie als aufeinanderfolgende Schritte zu behandeln. In der Praxis werden sie innerhalb von , als Teil der Optimierung, wobei die Benutzerfreundlichkeits- und Zugänglichkeitsbedingungen durch die festgelegten Standards bestimmt werden UX-Audit Arbeit, sodass das, was als akzeptabel gilt, die Erfahrung widerspiegelt, die das Produkt vermitteln soll, und nicht nur sein funktionales Verhalten.