Akzeptanztests
Akzeptanztests prüfen, ob eine Software aus Sicht der Nutzer oder des Auftraggebers akzeptabel ist. Sie stehen am Ende des Testprozesses und validieren das Gesamtsystem gegen die Anforderungen. Akzeptanztests können manuell durchgeführt werden, lassen sich aber zunehmend auch automatisieren, beispielsweise durch BDD oder ATDD.
In a Nutshell
- Akzeptanztests prüfen die Software aus Geschäftssicht.
- Sie validieren, ob Anforderungen und Akzeptanzkriterien erfüllt sind.
- User Acceptance Tests werden oft vom Auftraggeber oder Fachbereich durchgeführt.
- ATDD und BDD unterstützen automatisierte Akzeptanztests.
- Klar formulierte Akzeptanzkriterien sind die Grundlage für erfolgreiche Akzeptanztests.
Kompakte Fachbeschreibung
Akzeptanztests sind Testaktivitäten, die bewerten, ob ein System die vereinbarten Anforderungen erfuellt und fuer den Einsatz freigegeben werden kann. Sie stehen im Gegensatz zu technischen Tests, die oft die interne Implementierung pruefen. Akzeptanztests sind typischerweise anwendungsfallbasiert und orientieren sich an den Beduerfnissen der Endnutzer.
Akzeptanztests sind der letzte Schritt im Testprozess. Sie werden durchgefuehrt, wenn System- und Integrationstests abgeschlossen sind. Das Ergebnis eines Akzeptanztests ist die Freigabe oder Abnahme der Software durch den Auftraggeber.
Arten von Akzeptanztests
User Acceptance Tests (UAT)
User Acceptance Tests werden von Endnutzern oder Fachbereichen in einer realistischen Umgebung durchgefuehrt. Sie pruefen, ob die Software die taeglichen Arbeitsablaeufe unterstuetzt und die erwarteten Ergebnisse liefert. UAT ist die haeufigste Form der Akzeptanztests.
Business Acceptance Tests
Business Acceptance Tests werden von Geschaeftsstellen oder Product Ownern durchgefuehrt. Sie pruefen, ob die Software die geschaeftlichen Anforderungen erfuellt und den gewuenschten Mehrwert liefert. Der Fokus liegt auf Geschaeftsprozessen und ROI.
Contract Acceptance Tests
Contract Acceptance Tests pruefen, ob vertraglich vereinbarte Kriterien eingehalten werden. Sie sind besonders bei externen Dienstleistern wichtig. Die Kriterien sind im Vertrag definiert und muessen objektiv messbar sein.
Operational Acceptance Tests
Operational Acceptance Tests pruefen Betriebsaspekte wie Backup, Wiederherstellung, Monitoring, Logging und Skalierbarkeit. Sie werden oft vom Betriebsteam durchgefuehrt und stellen sicher, dass die Software im Produktivbetrieb verwaltbar ist.
Compliance Acceptance Tests
Compliance Acceptance Tests pruefen, ob rechtliche und regulatorische Anforderungen erfuellt sind. Dazu gehoeren Datenschutz, Accessibility und Branchenstandards. Sie sind besonders in regulierten Branchen wie Finanzwesen und Gesundheitswesen wichtig.
Akzeptanzkriterien formulieren
Akzeptanzkriterien sind die Grundlage fuer Akzeptanztests. Sie definieren, wann eine Funktion als fertig und akzeptabel gilt. Gute Akzeptanzkriterien sind:
- Klar: Jeder Beteiligte versteht sie gleich. Keine Mehrdeutigkeiten.
- Testbar: Man kann sie mit Ja oder Nein bewerten. Keine subjektiven Urteile.
- Messbar: Sie enthalten konkrete Werte oder Bedingungen, wie Reaktionszeit unter 200ms.
- Relevant: Sie beschreiben wirklich wichtige Funktionen, nicht Nebensaechlichkeiten.
Given-When-Then-Format
Ein bewaehrtes Format fuer Akzeptanzkriterien ist Given-When-Then. Es beschreibt Vorbedingung (Given), Aktion (When) und erwartetes Ergebnis (Then). Dieses Format ist maschinenlesbar und kann mit BDD-Werkzeugen wie Cucumber automatisiert werden.
ATDD und BDD
Acceptance Test Driven Development (ATDD)
ATDD schreibt Akzeptanztests vor der Implementierung. Das Team bespricht mit dem Fachbereich, welche Kriterien die Funktion erfuellen muss, und formuliert diese als Tests. Erst dann beginnt die Implementierung. Das stellt sicher, dass alle Beteiligten dasselbe Verstaendnis haben.
Behavior Driven Development (BDD)
BDD erweitert ATDD um eine natuerlichsprachliche Beschreibung des Verhaltens. Die Tests werden in der Given-When-Then-Form in Werkzeugen wie Cucumber, SpecFlow oder Behave geschrieben. Diese Beschreibungen sind sowohl fuer Fachbereich als auch fuer Entwickler verstaendlich und koennen automatisiert ausgefuehrt werden.
Praxisbeispiel
Das folgende Beispiel zeigt Akzeptanzkriterien in der Given-When-Then-Form fuer eine Benutzeranmeldung. Dieses Beispiel wurde gewaehlt, weil es ein haeufiges und leicht verstaendliches Feature ist, das alle Aspekte von Akzeptanztests zeigt: positive und negative Szenarien, klare Vorbedingungen und messbare Ergebnisse.
Feature: Benutzeranmeldung
Szenario: Erfolgreiche Anmeldung
Given ein Benutzer mit gueltigem Benutzernamen und Passwort
When er sich anmeldet
Then wird er zur Startseite weitergeleitet
And seine persoenlichen Daten werden angezeigt
Szenario: Fehlgeschlagene Anmeldung
Given ein Benutzer mit ungueltigem Passwort
When er sich anmeldet
Then wird eine Fehlermeldung angezeigt
And der Zugriff wird verweigert
Warum dieses Beispiel?
- Zwei Szenarien: Der positive Fall zeigt die erfolgreiche Anmeldung, der negative Fall zeigt den Fehlerfall. Beide sind fuer die Akzeptanz wichtig.
- Given-When-Then: Die Struktur ist fuer Fachbereich und Entwicklung gleichermassen verstaendlich.
- Messbar: Die Weiterleitung zur Startseite und die Fehlermeldung sind objektiv pruefbar.
- Automatisierbar: Mit Cucumber oder aehnlichen Werkzeugen koennen diese Szenarien direkt als automatisierte Tests ausgefuehrt werden.
Vorteile und Nachteile
| Vorteile | Nachteile |
|---|---|
| Klare Abgrenzung, wann eine Funktion fertig ist | Formulierung guter Akzeptanzkriterien erfordert Erfahrung |
| Bessere Kommunikation zwischen Fachbereich und Entwicklung | Manueller UAT ist zeitaufwendig |
| Reduzierung von Missverstaendnissen vor der Implementierung | Fachbereiche sind nicht immer fuer Tests verfuegbar |
| Nachweis der Anforderungserfuellung | Automatisierung von Akzeptanztests kann aufwendig sein |
| Hoehere Nutzerzufriedenheit | UAT-Umgebung muss produktionsnah sein |
| Fruehes Feedback durch ATDD und BDD | Schulungsaufwand fuer BDD-Werkzeuge |
Wichtige Werkzeuge
- Cucumber: BDD-Framework, das Given-When-Then-Szenarien in natuerlicher Sprache beschreibt und automatisiert.
- SpecFlow: BDD-Framework fuer .NET, aehnlich zu Cucumber.
- Behave: BDD-Framework fuer Python.
- JBehave: BDD-Framework fuer Java.
- FitNesse: Wiki-basiertes Werkzeug fuer Akzeptanztests.
- Postman: Fuer API-Akzeptanztests mit automatisierten Test-Suiten.
Best Practices
- Frueh beginnen: Akzeptanzkriterien vor der Implementierung formulieren.
- Fachbereich einbinden: Akzeptanztests sind nur wertvoll, wenn der Fachbereich beteiligt ist.
- Klein anfangen: Nicht alle Tests automatisieren, sondern mit kritischen Szenarien beginnen.
- Produktionsnahe Umgebung: UAT sollte in einer Umgebung durchgefuehrt werden, die der Produktion aehnelt.
- Dokumentieren: Akzeptanzkriterien und Testergebnisse dokumentieren, um Nachvollziehbarkeit zu gewaehrleisten.
- Regelmaessig wiederholen: Akzeptanztests bei jeder relevanten Aenderung erneut ausfuehren.
Prüfungsrelevante Stichpunkte
- Akzeptanztest: Test, der prueft, ob die Software aus Anwendersicht die Anforderungen erfuellt.
- Arten: UAT, Business Acceptance, Contract Acceptance, Operational Acceptance, Compliance Acceptance.
- UAT: User Acceptance Testing durch Endnutzer oder Fachbereiche.
- Akzeptanzkriterien: Konkrete Bedingungen, die eine Funktion erfuellen muss, um akzeptiert zu werden.
- Eigenschaften guter Akzeptanzkriterien: Klar, testbar, messbar, relevant.
- Given-When-Then: Format fuer Akzeptanzkriterien mit Vorbedingung, Aktion und erwartetem Ergebnis.
- ATDD: Acceptance Test Driven Development schreibt Akzeptanztests vor der Implementierung.
- BDD: Behavior Driven Development beschreibt Verhalten in natuerlicher Sprache als Tests.
- Cucumber: BDD-Werkzeug, das Given-When-Then-Szenarien automatisiert.
- Operational Acceptance Test: Prueft Betriebsaspekte wie Backup, Monitoring und Wiederherstellung.
- Compliance Acceptance Test: Prueft rechtliche und regulatorische Anforderungen.
- UAT-Umgebung: Testumgebung, die der Produktion aehnelt und fuer Akzeptanztests genutzt wird.
Wichtigste Quellen
- https://www.istqb.org
- https://cucumber.io/docs/bdd/
- https://en.wikipedia.org/wiki/Acceptance_testing
Häufig gestellte Fragen
Was ist ein Akzeptanztest?
Ein Akzeptanztest prueft, ob die Software aus Anwendersicht die vereinbarten Anforderungen erfuellt. Er ist der letzte Schritt im Testprozess und entscheidet ueber die Freigabe der Software.
Wer fuehrt UAT durch?
User Acceptance Tests werden von Endnutzern, Fachbereichen oder Product Ownern durchgefuehrt. Sie testen in einer realistischen Umgebung, ob die Software ihre Arbeitsablaeufe unterstuetzt.
Was ist ATDD?
Acceptance Test Driven Development schreibt Akzeptanztests vor der Implementierung. Das Team formuliert mit dem Fachbereich die Kriterien, bevor die Entwicklung beginnt.
Was sind Akzeptanzkriterien?
Akzeptanzkriterien sind konkrete, messbare Bedingungen, die eine Funktion erfuellen muss, um akzeptiert zu werden. Sie sollten klar, testbar, messbar und relevant sein.
Was ist ein UAT-Environment?
Ein UAT-Environment ist eine Testumgebung, die der Produktion moeglichst aehnelt. Sie wird fuer User Acceptance Tests genutzt, um realistische Ergebnisse zu gewaehrleisten.
Kann man Akzeptanztests automatisieren?
Ja, mit BDD-Werkzeugen wie Cucumber, SpecFlow oder Behave koennen Akzeptanztests in Given-When-Then-Form automatisiert werden.
Was ist der Unterschied zwischen UAT und Systemtest?
Der Systemtest prueft technische Anforderungen und wird vom Testteam durchgefuehrt. UAT prueft aus Nutzersicht und wird vom Fachbereich durchgefuehrt.
Was ist ein Operational Acceptance Test?
Ein Operational Acceptance Test prueft Betriebsaspekte wie Backup, Wiederherstellung, Monitoring, Logging und Skalierbarkeit. Er wird vom Betriebsteam durchgefuehrt.
Was ist ein Compliance Acceptance Test?
Ein Compliance Acceptance Test prueft, ob rechtliche und regulatorische Anforderungen wie Datenschutz, Accessibility und Branchenstandards erfuellt sind.
Wie formuliert man gute Akzeptanzkriterien?
Sie sollten klar, testbar, messbar und relevant sein. Das Given-When-Then-Format hat sich bewaehrt, weil es fuer alle Beteiligten verstaendlich und automatisierbar ist.
Was ist BDD?
Behavior Driven Development beschreibt das Verhalten einer Software in natuerlicher Sprache als Tests. Es verwendet das Given-When-Then-Format und ermoeglicht Automatisierung mit Werkzeugen wie Cucumber.
Was ist ein Vorteil von Akzeptanztests?
Sie zeigen, ob die Software wirklich den Nutzerbeduerfnissen entspricht, reduzieren Missverstaendnisse und geben eine klare Definition of Done.
Was ist ein Nachteil manueller Akzeptanztests?
Sie sind zeitaufwendig und abhaengig von der Verfuegbarkeit der Fachbereiche. Ausserdem sind sie schwer wiederholbar und nicht skalierbar.
Wann ist eine Funktion fertig?
Eine Funktion ist fertig, wenn sie alle Akzeptanzkriterien erfuellt und die Akzeptanztests bestanden hat. Das ist die Definition of Done.
Was ist ein Acceptance Test in Scrum?
In Scrum ist ein Acceptance Test ein Test, der das Product Increment gegen die Akzeptanzkriterien eines Backlog Items prueft. Er entscheidet, ob das Item als Done gilt.
Was ist der Unterschied zwischen ATDD und BDD?
ATDD schreibt Akzeptanztests vor der Implementierung. BDD erweitert ATDD um natuerlichsprachliche Beschreibungen im Given-When-Then-Format, die automatisierbar sind.
Was ist ein Business Acceptance Test?
Ein Business Acceptance Test wird von Geschaeftsstellen oder Product Ownern durchgefuehrt und prueft, ob die Software geschaeftliche Anforderungen und den erwarteten Mehrwert liefert.
Was ist ein Contract Acceptance Test?
Ein Contract Acceptance Test prueft, ob vertraglich vereinbarte Kriterien eingehalten werden. Die Kriterien sind im Vertrag definiert und muessen objektiv messbar sein.
Welche Werkzeuge gibt es fuer automatisierte Akzeptanztests?
Cucumber, SpecFlow, Behave und JBehave sind BDD-Frameworks. Postman eignet sich fuer API-Akzeptanztests. FitNesse ist ein wiki-basiertes Werkzeug.
Was ist die Definition of Done?
Die Definition of Done ist eine Vereinbarung, wann eine Funktion als fertig gilt. Sie umfasst erfuellte Akzeptanzkriterien, bestandene Akzeptanztests und abgeschlossene Dokumentation.
Weiter im Software Testing Lernpfad
Der nächste Artikel im Software Testing Lernpfad behandelt Load Testing — wie Load Testing die Performance unter Last prüft.



