UAT-Test: Leitfaden zum User Acceptance Test + Vorlagen

Ein UAT-Test (User Acceptance Testing, auf Deutsch auch Benutzerakzeptanztest oder Abnahmetest) ist die letzte Testphase vor dem Release. Echte Anwender oder Vertreter des Kunden spielen dabei Geschäftsszenarien in einer produktionsnahen Umgebung durch und bestätigen, dass die Software tut, was das Business braucht. Die QA prüft, ob sie funktioniert. UAT prüft, ob sie das Richtige tut. Am Ende steht eine formelle Abnahme.

Dieser Leitfaden ist für alle, die den Zyklus leiten und deren Fachtester nächste Woche loslegen: QA-Lead, Business Analyst, Product Owner oder Engineering Lead. Du bekommst einen Prozess in 7 Schritten, vier Vorlagen, die du in eine Tabelle oder ein Wiki einfügen kannst, und drei durchgespielte Beispiele mit ausgefüllten Fehlerberichten.

Außerdem bekommst du einen Standard für Fehlermeldungen, der aus „geht nicht“ etwas macht, das ein Entwickler reproduzieren kann, und der direkt in eine klassische Bug-Report-Vorlage passt.

Was ist ein UAT-Test?

UAT steht für User Acceptance Testing, also den Abnahmetest durch die Anwender. Das ISTQB-Glossar beschreibt User Acceptance Testing als eine Art Abnahmetest, mit dem festgestellt wird, ob die vorgesehenen Benutzer das System akzeptieren. Aus Business-Sicht ist die Bedeutung von UAT einfach: Die Leute, die mit der Software leben müssen, sagen „ja, damit können wir arbeiten“, bevor sie live geht.

UAT kommt nach dem Systemtest (der QA-Phase) und vor dem Go-live. Die QA hat den Build schon gegen die Spezifikation geprüft, also stellt UAT eine andere Frage: Passt der Build dazu, wie das Business arbeitet?

Die Leute, die testen, sind nicht die, die den Zyklus leiten. Fachanwender, Fachexperten (SMEs) oder Mitarbeitende des Kunden übernehmen das Testen. Ein UAT-Lead steuert den Zyklus, und der Product Owner oder der Sponsor auf Kundenseite unterschreibt.

UAT vs. QA vs. Usability-Test vs. Betatest

Bei allen nutzt jemand die Software. Der Unterschied liegt darin, wer testet, wogegen getestet wird und was am Ende herauskommt.

Kurz gesagt: Die QA beweist, dass der Build wie spezifiziert funktioniert. UAT beweist, dass es die richtige Spezifikation war. Das eine ersetzt das andere nicht.

Arten von Abnahmetests

UAT ist eine Form des Abnahmetests, den das ISTQB als vollwertige Teststufe führt. Die anderen Arten beantworten andere „Können wir das abnehmen?“-Fragen.

Wer ist für den UAT-Test verantwortlich?

Die Abnahme liegt beim Fachbereich, und die Entscheidung liegt bei einer einzigen Person.

Wenn zwei Leute abnehmen dürfen, kann es keiner. Nenne im Plan genau eine Person, die abnimmt.

Wo UAT im SDLC und in Agile hingehört

Ja, UAT ist Teil des SDLC (Software Development Life Cycle), und zwar als Abnahmetest-Stufe, also als letzte Testphase vor dem Deployment. Im V-Modell steht der UAT der Anforderungsphase gegenüber, denn genau die prüft er.

In Agile passiert die Abnahme auf zwei Ebenen. In jedem Sprint nimmt der Product Owner jede User Story anhand ihrer Akzeptanzkriterien ab. Vor einem Release führst du trotzdem einen UAT auf Release-Ebene durch, denn Stories, die einzeln bestehen, können zusammen einen Geschäftsablauf kaputt machen. Kurze, ungeskriptete explorative Sessions passen ebenfalls gut in dieses Zeitfenster.

So führst du einen UAT-Test in 7 Schritten durch

Die Schritte 1 bis 4 passieren, bevor sich die Tester anmelden. Die Schritte 5 bis 7 sind der eigentliche Zyklus.

1. Umfang und Akzeptanzkriterien festlegen

Entscheide, welche Geschäftsprozesse im Umfang liegen, und schreib Bestehenskriterien, die ein Tester prüfen kann, ohne Code zu lesen. Leite sie aus Anforderungen und User Stories ab. Der Atlassian-Leitfaden zu Akzeptanzkriterien beschreibt sie als die Bedingungen, die ein Produkt erfüllen muss, damit der Nutzer es akzeptiert. Genau diese Messlatte legt UAT an.

Formuliere jedes Kriterium als sichtbares Ergebnis. „Rabatt funktioniert“ ist vage. „Der Code SAVE10 zieht 10 % vom Bestellwert ab, und die Bestätigungsmail zeigt den Rabatt“ kann bestehen oder scheitern.

Lege dann gemeinsam die Eingangskriterien fest. Starte den UAT erst, wenn all das erfüllt ist:

• Der Systemtest ist abgeschlossen und von der QA freigegeben
• Es sind keine kritischen Fehler offen
• Die UAT-Umgebung läuft mit dem Build des Release Candidate
• Testkonten und Testdaten sind eingespielt
• Der Product Owner hat die Szenarien geprüft

2. Einen einseitigen UAT-Plan schreiben

Ein UAT-Plan beantwortet fünf Fragen: Was ist im Umfang, wer testet, wo, wann, und wie wird entschieden? Halte ihn auf einer Seite. Dein vollständiger QA-Testplan deckt Strategie, Risiken und Testabdeckung bereits ab, also braucht der UAT-Plan nur das, was Tester und die abnehmende Person wissen müssen.

Er nennt die Person, die abnimmt, den Testzeitraum, die URL der Umgebung und die Uhrzeit der Triage und sagt, wo Szenarien, Log und Nachweise liegen. Eine Version zum Kopieren findest du unten bei den Vorlagen.

3. Geschäftsszenarien und UAT-Skripte schreiben

Ein Szenario ist eine Geschäftsaufgabe, in der Sprache des Testers geschrieben, mit dem erwarteten Ergebnis in fachlichen Begriffen. Ein UAT-Skript ist die nummerierte Liste der Schritte für dieses Szenario.

Vergleich diese beiden:

• QA-Stil: Prüfe, ob POST /orders 201 mit gesetztem discount_total zurückgibt.
• UAT-Stil: Wende den Code SAVE10 auf eine Bestellung über $80.00 an. Erwartet: Die Summe beträgt $72.00, und die Bestätigungsmail zeigt den Rabatt.

Nummeriere jeden Schritt, denn diese Nummern tauchen später in Screenshots und im Feedback auf. Gib jedem Szenario eigene Testdaten, etwa das Konto und die Bestellung, die verwendet werden sollen. Die vollständige Anatomie eines Testfalls (Priorität, Rückverfolgbarkeit, Automatisierungsstatus) gehört in deine QA-Testfälle, nicht ins fachliche Skript.

4. UAT-Umgebung und Testdaten vorbereiten

Die UAT-Umgebung sollte produktionsnah sein: derselbe Build, dieselben Einstellungen und Integrationen, mit einem Testkonto pro Rolle und maskierten Daten. Wenn Tester ein anderes Verhalten sehen als später die Kunden, ist die Abnahme nichts wert.

• Deploye den Release Candidate, mit Feature Flags so, wie sie zum Launch gesetzt sein werden
• Binde echte Integrationen oder deren Sandboxes an, etwa den Testmodus des Zahlungsanbieters und einen E-Mail-Catcher
• Leg ein Testkonto pro Rolle an: Antragsteller, Genehmiger, Admin und Nur-Lesen
• Spiel maskierte oder synthetische Daten ein und kopier nie rohe Produktionsdaten in die UAT-Umgebung
• Blende ein Banner „UAT-Umgebung“ ein, damit jeder Screenshot leicht zuzuordnen ist
• Friere Deployments während der Testzeiten ein, mit Ausnahme angekündigter Fixes

Kläre auch den Zugriff auf die Tools früh. In Azure Test Plans brauchen Tester mindestens Basic-Zugriff, um Tests auszuführen und Ergebnisse zu markieren. Der Microsoft-Leitfaden zu Benutzerakzeptanztests in Azure Test Plans weist darauf hin, dass Benutzer mit Stakeholder-Zugriff das Webportal von Test Plans nicht nutzen können.

5. Tester mit einem einseitigen visuellen Leitfaden briefen

Gib den Testern eine Seite mit nummerierten Screenshots: wo sie sich anmelden, wo ihre Szenarien liegen, wie sie Bestanden oder Nicht bestanden markieren und wie sie einen Fehler melden. Fachtester lesen selten lange Anleitungen. Sie folgen Bildern.

Beschränk dich auf vier nummerierte Markierungen in der Reihenfolge, in der die Tester arbeiten. Ein Zähler-Werkzeug (nummerierte Schritte) hält die Nummern sauber. Wenn du nichts installieren willst, hat das kostenlose Tool zur Bildannotation Pfeile, Rahmen und Text, sodass du die Nummern als Beschriftung eintippen kannst. Dieser Beitrag zu Schritt-für-Schritt-Anleitungen mit Screenshots behandelt das Layout, und diese Standards für Screenshots in der Dokumentation halten Zuschnitte und Markierungen einheitlich.

Halte dann ein 30-minütiges Kickoff ab, in dem sich jeder Tester anmeldet und ein Szenario live durchspielt. Die meisten Zugriffsprobleme zeigen sich in diesen 30 Minuten statt an Tag drei.

6. Ausführen, Feedback erfassen und täglich triagieren

Die Tester arbeiten ihre Skripte ab und tragen jeden Fehlschlag in ein gemeinsames Feedback-Log ein. Der UAT-Lead triagiert es einmal am Tag. So bleibt der Rückstau klein und die Schleife aus Fix und Retest kurz.

Für jede neue Zeile setzt der UAT-Lead vier Felder:

• Typ: Fehler, Change Request, Frage oder „funktioniert wie vorgesehen“
• Schweregrad: kritisch, schwer, leicht oder kosmetisch
• Blockiert Abnahme: J oder N (die erste Einschätzung des Testers, bestätigt vom Product Owner)
• Owner: wer es behebt oder beantwortet

Change Requests sind die Falle. „Ich hätte hier gern einen Export-Button“ ist eine berechtigte Idee, aber kein Fehler. Sie kommt also ins Backlog, es sei denn, der Product Owner sagt, dass sie den Go-live blockiert.

Fehler gehen als richtige Bug-Tickets an die Entwickler, mit dem Screenshot des Testers im Anhang. Wenn dein Team mit Jira arbeitet, erfährst du hier, wie du Screenshots an Jira-Issues anhängst, damit der Nachweis direkt am Ticket hängt. Wenn ein Fix in UAT landet, testet derselbe Tester dasselbe Szenario erneut und schließt die Zeile.

7. Endekriterien prüfen und die Abnahme einholen

Vergleiche die Ergebnisse mit den Endekriterien aus deinem Plan und halte dann eine von drei Entscheidungen fest.

• Abgenommen: Jedes Szenario im Umfang ist bestanden oder hat einen vereinbarten Workaround.
• Abgenommen mit Auflagen: Das Release geht live, aber jedes aufgeführte Problem bekommt einen Owner und ein Fälligkeitsdatum.
• Abgelehnt: Benenne, was sich ändern muss, und leg einen Termin für den Retest fest.

Halte die Entscheidung mit Name, Rolle und Datum der abnehmenden Person fest und nutze dafür die Vorlage unten. Nach der Abnahme fließt der abgenommene Umfang direkt in deine Release Notes.

UAT-Vorlagen zum Kopieren

Alle vier Vorlagen sind in Markdown geschrieben, also kannst du sie direkt in GitHub, GitLab, Notion und die meisten Wikis einfügen.

Für Google Sheets fügst du eine Tabelle in Zelle A1 ein und wählst Daten > Text in Spalten aufteilen. Stell das Trennzeichen auf Benutzerdefiniert, gib einen senkrechten Strich (Pipe) ein und lösch dann die leere erste Spalte und die zweite Zeile mit den Bindestrichen. In Excel nutzt du Daten > Text in Spalten > Getrennt > Andere mit demselben Pipe-Zeichen.

Ein Testmanagement-Tool (Jira, Azure Test Plans, TestRail) und eine gemeinsame Tabelle funktionieren beide. Die Felder sind wichtiger als das Tool.

Vorlage für den UAT-Testplan (eine Seite)

# UAT-Plan: [Release-Name] [Version]

| Feld | Eintrag |
|---|---|
| Release / Build | 4.2.0-rc3 |
| UAT-Zeitraum | Mo. 5. Okt. bis Fr. 9. Okt. 2026 |
| UAT-Lead | [Name, Rolle] |
| Abnahmeberechtigt | [Ein Name, Rolle] |
| Umgebung | https://uat.example.com (UAT-Banner an) |
| Testkonten | Eins pro Rolle, per E-Mail verschickt, maskierte Daten |

## Im Umfang
- [Geschäftsprozess 1]: Szenarien SCN-01 bis SCN-06
- [Geschäftsprozess 2]: Szenarien SCN-07 bis SCN-11

## Nicht im Umfang
- Performance- und Sicherheitstests
- Features, die sich in diesem Release nicht geändert haben

## Eingangskriterien
- [ ] Systemtest abgeschlossen, keine offenen kritischen Fehler
- [ ] Release Candidate auf UAT deployt
- [ ] Testkonten und maskierte Daten eingespielt
- [ ] Szenarien vom Product Owner geprüft

## Endekriterien
- [ ] Jedes Szenario im Umfang ausgeführt
- [ ] Kein offenes Problem als „blockiert Abnahme“ markiert
- [ ] Jedes offene Problem hat einen Owner, einen Workaround und ein Fälligkeitsdatum

## Zeitplan
- Kickoff und Tester-Briefing: Mo. 10:00 Uhr (30 Min.)
- Tägliche Triage: 16:00 Uhr (15 Min.)
- Fix-Deployments auf UAT: nur um 08:00 Uhr
- Abnahmemeeting: Fr. 15:00 Uhr

## Links
- Szenarien und Skripte: [Link]
- Feedback-Log: [Link]
- Nachweisordner: [Link] (Dateien benannt nach SCN-ID_step_result_date)

Vorlage für UAT-Testskripte

Eine Zeile pro Szenario. Halte die Schritte so kurz, dass sie in eine Zelle passen, und teile jedes Szenario auf, das mehr als etwa acht Schritte braucht.

| Szenario-ID | Geschäftsszenario | Vorbedingungen | Schritte | Erwartetes Ergebnis | Bestanden/Nicht bestanden | Link zum Nachweis | Tester | Datum |
|---|---|---|---|---|---|---|---|---|
| SCN-02 | Rabattcode im Checkout anwenden | Angemeldet als tester.finance@example.com; im Warenkorb liegen eine Tastatur ($50.00) und ein Hub ($30.00) | 1. Checkout öffnen 2. SAVE10 eingeben 3. Auf Apply klicken 4. Summe prüfen | Rabattzeile zeigt $8.00, und die Summe beträgt $72.00 | | | | |

UAT-Feedback-Log für Fachtester

Dieses Log ist absichtlich einfacher als ein Bug Report für Entwickler. Fachtester schreiben auf, was sie erwartet haben und was passiert ist, und der UAT-Lead macht aus jeder Fehlerzeile mit der Bug-Report-Vorlage ein Ticket, mit dem die Entwickler direkt arbeiten können.

| Szenario-ID | Schritt-Nr. | Was ich erwartet habe | Was passiert ist | Screenshot oder Aufnahme | Blockiert Abnahme (J/N) | Status |
|---|---|---|---|---|---|---|
| SCN-02 | 4 | Summe $72.00 nach Code SAVE10 | Summe blieb bei $80.00, Rabattzeile $0.00 | SCN-02_step4_fail_2026-10-05.png | J | Fehler: BUG-2214 |
| SCN-05 | 2 | Button zum Stornieren neben der Bestellsumme | Button ist ganz unten auf einer langen Seite | SCN-05_step2_2026-10-05.png | N | Change Request |

Nutze für den Status eine kurze, feste Liste: Neu, Fehler (mit der Bug-ID), Change Request, Frage, Funktioniert wie vorgesehen, Behoben: Retest und Geschlossen.

Vorlage für die UAT-Abnahme

# UAT-Abnahme: [Release-Name] [Version]

| Feld | Eintrag |
|---|---|
| Release / Build | |
| UAT-Zeitraum | |
| Getesteter Umfang | [Prozesse und Szenario-IDs] |
| Szenarien | Bestanden: 0 · Nicht bestanden: 0 · Blockiert: 0 · Nicht ausgeführt: 0 |
| Offene Fehler | Kritisch: 0 · Schwer: 0 · Leicht: 0 |

## Offene Punkte, die für den Go-live akzeptiert werden
| ID | Problem | Workaround | Owner | Fällig am |
|---|---|---|---|---|
| | | | | |

## Entscheidung
- [ ] Abgenommen
- [ ] Abgenommen mit Auflagen (jede Auflage oben mit Owner und Datum aufgeführt)
- [ ] Abgelehnt (was sich ändern muss, und der Termin für den Retest)

## Freigabe
Erstellt von: [Name des UAT-Leads]

| Name | Rolle | Entscheidung | Datum | Unterschrift oder Ticket-Link |
|---|---|---|---|---|
| | Abnahmeberechtigt (Product Owner oder Sponsor auf Kundenseite) | | | |

Die Unterschrift kann eine echte sein, eine Freigabe in deinem Ticketsystem oder eine E-Mail, auf die du verlinkst. Entscheidend sind eine namentlich genannte Person, eine Rolle, eine Entscheidung und ein Datum.

Beispiele für UAT-Tests

Hier sind drei durchgespielte UAT-Beispiele aus verschiedenen Arten von Software. Jedes hat ein kurzes Skript und einen ausgefüllten Fehlerbericht, denn bei Fehlschlägen verlieren die meisten UAT-Zyklen ihre Zeit.

Beispiel 1: Web-Checkout, Rabattcode wird nicht angewendet

Szenario SCN-02: Rabattcode im Checkout anwenden. Der Tester ist als tester.finance@example.com angemeldet, und im Warenkorb liegen eine Tastatur ($50.00) und ein USB-C-Hub ($30.00).

1. Öffne den Checkout und prüfe, ob die Zwischensumme $80.00 beträgt.
2. Gib den Code SAVE10 ein.
3. Klicke auf Apply.
4. Prüfe die Bestellsumme.

Erwartet: eine Rabattzeile über $8.00 und eine Summe von $72.00.

FB-007 · SCN-02 · Schritt 4 · Blockiert Abnahme: J
Erwartet:    Rabatt $8.00, Summe $72.00
Tatsächlich: Rabatt $0.00, Summe $80.00. "Code SAVE10 applied" wird trotzdem angezeigt.
Umgebung:    uat-shop.example.com, Build 4.2.0-rc3, Chrome unter Windows 11
Konto:       tester.finance@example.com
Nachweis:    SCN-02_step4_fail_2026-10-05.png

Die Zähler passen zu den Skriptschritten, also muss niemand fragen, welcher Schritt fehlgeschlagen ist. Die Kartennummer liegt unter einem deckenden Rechteck, obwohl es Testdaten sind. Tester können Testdaten nicht immer von kopierten Produktionsdaten unterscheiden, also muss das Abdecken zum Automatismus werden.

Beispiel 2: Freigabe in einer B2B-SaaS, Status bleibt auf Pending

Szenario SCN-07: Eine Führungskraft genehmigt eine Spesenabrechnung. Der Tester ist als manager.uat@example.com angemeldet.

1. Öffne EXP-1042 unter Approvals und klicke auf Approve.
2. Prüfe die Bestätigungsmeldung.
3. Lade die Seite neu.
4. Prüfe den Status der Spesenabrechnung.

Erwartet: Nach dem Neuladen steht der Status auf Approved, und der Mitarbeiter bekommt eine E-Mail über die Genehmigung.

FB-008 · SCN-07 · Schritte 1 bis 4 · Blockiert Abnahme: J
Erwartet:    Status ist nach dem Neuladen Approved
Tatsächlich: Meldung "Expense approved" erscheint, aber der Status ist
             nach dem Neuladen immer noch Pending. Das Aktivitätslog zeigt
             "Approved by manager.uat@example.com" um 10:02.
Umgebung:    uat-expenses.example.com, Safari unter macOS
Nachweis:    SCN-07_steps1-4_fail_2026-10-05.gif (9 Sekunden)

Ein einzelner Screenshot kann diesen Bug nicht zeigen, denn jedes Einzelbild sieht für sich genommen gut aus. Der Fehler ist die Abfolge: Klick, Erfolgsmeldung, Neuladen, unveränderter Status. Ein kurzes GIF zeigt das in unter 10 Sekunden. Sieh dir an, wie du GIFs auf dem Mac aufnimmst oder deinen Bildschirm unter Windows als GIF aufnimmst.

Der Tester hat außerdem den Eintrag im Aktivitätslog notiert. Daran sehen die Entwickler, dass die Genehmigung gespeichert wird, die Statusänderung aber nicht.

Beispiel 3: Berichtsexport, Summen stimmen nicht mit der Quelle überein

Szenario SCN-11: Den Quartalsbericht zum Umsatz aus dem Desktop-Client der Finanzsoftware exportieren.

1. Öffne Sales by region für Q3 2026.
2. Notiere die Gesamtsumme auf dem Bildschirm.
3. Klicke auf Export to CSV und öffne die Datei.
4. Vergleiche die Summe in der CSV mit dem Bildschirm.

Erwartet: Jede Region und die Gesamtsumme stimmen auf den Cent überein.

FB-009 · SCN-11 · Schritt 4 · Blockiert Abnahme: J
Erwartet:    CSV-Summe 1,284,310.50 (wie auf dem Bildschirm)
Tatsächlich: CSV-Summe 1,248,310.50. West steht in der CSV mit 198,409.75
             und auf dem Bildschirm mit 234,409.75 (eine Differenz von 36,000.00).
Umgebung:    Desktop-Client Finance Suite, UAT-Build 7.1
Nachweis:    SCN-11_step4_fail_2026-10-05.png

Zahlen wie diese vertippt man leicht, also kopier sie per OCR: Nimm die Summen auf, extrahiere den Text und füg ihn ins Log ein. Das kostenlose Tool zum Extrahieren von Text aus Bildern erledigt das im Browser.

Das hier ist eine Desktop-App, also nimm sie in Bereichen auf: eine Bereichsaufnahme pro Abschnitt eines langen Berichts.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 34 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

So melden Fachtester ein fehlgeschlagenes UAT-Szenario

Ein guter UAT-Fehlerbericht lässt einen Entwickler das Problem ohne Meeting reproduzieren. Dieser Standard mit 6 Punkten verknüpft jeden Screenshot mit den Schrittnummern des Skripts und dem Flag „blockiert Abnahme“, damit Nachweise und Log synchron bleiben.

1. Nimm den Bereich auf, nicht den ganzen Desktop. Schneide auf den Teil des Bildschirms zu, der den Fehler zeigt, plus genug Kontext, um zu sehen, wo er liegt. Ein ganzer Desktop zeigt Chat-Pop-ups und die Daten anderer Leute.
2. Nummeriere die Schritte passend zum Skript. Zähler 4 im Bild bedeutet Schritt 4 im Log, also muss niemand raten.
3. Zeig auf den falschen Wert. Zeichne einen Pfeil und ergänze eine kurze Beschriftung wie „Erwartet $72.00 · erhalten $80.00“.
4. Verbirg sensible Daten richtig. Am besten sind maskierte Testdaten, dann ist nichts Echtes auf dem Bildschirm. Für Kartennummern, Kontonummern, IDs und Passwörter nimmst du ein deckendes, undurchsichtiges Rechteck, denn Weichzeichnen und Verpixeln lassen sich rückgängig machen.
5. Abläufe aufzeichnen, Zustände per Screenshot festhalten. Wenn der Fehler erst nach mehreren Schritten auftritt, nimm statt eines Screenshots ein kurzes GIF oder eine Bildschirmaufnahme auf.
6. Kopier Fehlertexte per OCR. Füg die genaue Fehlermeldung oder die Zahlen ins Log ein, statt sie abzutippen.

Weichzeichnen und Verpixeln haben trotzdem ihren Platz, aber nur für unkritische Details im Hintergrund, etwa Namen in einer Liste oder Avatare. Auf dem Mac zeigt dieser Leitfaden zum Weichzeichnen und Verpixeln beides. Sobald das Bild fertig ist, füllst du die Log-Zeile aus: Szenario-ID, Schrittnummer, erwartet, tatsächlich, Dateiname des Nachweises und das Flag J oder N.

Welche Tools du nutzt. Die eingebauten Tools decken die Grundlagen ab. Unter Windows nimmt das Snipping Tool Bereiche auf, hat Stift und Textmarker, und seine Textaktionen kopieren Text aus einem Screenshot. Auf dem Mac erledigen die eingebauten Screenshot-Tools zusammen mit Markierungen die Aufnahme und die Pfeile, und Live Text kopiert Text aus Bildern.

Eine spezialisierte App spart Zeit, wenn du viele Berichte am Tag einreichst. ScreenSnap Pro zum Beispiel vereint Aufnahme und Annotation in einem Ablauf, mit nummerierten Zählern, deckend gefüllten Rechtecken, Weichzeichnen und Verpixeln, OCR und GIF-Aufnahme. Mit der Pin-Funktion bleibt der Screenshot des erwarteten Ergebnisses aus der Spezifikation im Vordergrund über der App, während du testest. So fällt eine Abweichung sofort auf.

Für lange Webseiten hilft ein Vollseiten-Screenshot, mit einem Haken. Die meisten UAT-Umgebungen liegen hinter einem Login, SSO oder einem VPN, und URL-basierte Tools zur Website-Aufnahme rendern öffentliche Seiten auf einem Server, also kommen sie dort nicht hin. Nutze Bereichsaufnahmen oder den eingebauten Vollseiten-Screenshot deines Browsers, der in deiner angemeldeten Session läuft. Sieh dir dazu die Anleitungen für Mac und Windows an.

Wohin mit den Dateien. Häng die Bilddatei direkt an den Eintrag selbst: im Feedback-Log, in Jira, Azure DevOps oder einem GitHub-Issue. Ein schneller Cloud-Link ist im Triage-Chat in Ordnung. Share-Links sind aber zum schnellen Teilen gedacht, und Uploads werden von Zeit zu Zeit entfernt, also taugen sie nicht als Ablage für Nachweise. Teams, die UAT-Feedback in GitHub sammeln, können die Spalten des Logs in ein Issue-Formular verwandeln. Die GitHub-Doku erklärt, wie du Issue-Vorlagen konfigurierst.

Nachweise, die die Abnahme stressfrei machen

Die meisten UAT-Zyklen brauchen nur Screenshots von Fehlschlägen. Manche brauchen auch Belege für bestandene Szenarien:

• Regulierte Bereiche wie Banken, Versicherungen, Gesundheitswesen oder Validierung in der Pharmabranche
• Kundenverträge, bei denen die Abnahme einen Zahlungsmeilenstein auslöst
• Interne oder externe Audits des Release-Prozesses

Halte in diesen Fällen das erwartete Endergebnis jedes bestandenen Szenarios fest und benenne die Datei jedes Mal gleich, zum Beispiel SCN-04_step3_pass_2026-10-05.png. Leg die Nachweise in einem UAT-Ordner pro Release ab, verlinkt aus dem Abnahmeprotokoll.

Schwärze personenbezogene Daten (PII), bevor eine Datei hineinkommt, denn Nachweisordner werden mit Auditoren und Kunden geteilt. Allgemeine Regeln für QA-Nachweise gehören in deinen vollständigen Testplan. Dieser Ordner braucht nur das, worauf sich die Unterschrift der abnehmenden Person stützt.

Häufige UAT-Fehler (und wie du sie vermeidest)

• Tester, die eigentlich QA sind. Wenn QA Engineers den UAT durchführen, wird die Spezifikation zweimal getestet, und der Fachbereich prüft sie nie. Hol Leute dazu, die den Job jeden Tag machen.
• Vage Akzeptanzkriterien. „Funktioniert korrekt“ kann nicht scheitern. Formuliere jedes Kriterium mit einem Wert oder einem sichtbaren Ergebnis.
• Eine Umgebung, die nicht produktionsnah ist. Fehlende Integrationen oder andere Einstellungen machen jedes Bestanden verdächtig. Bring die Umgebung in Ordnung, bevor die Uhr läuft.
• Echte Kundendaten in Screenshots. Kopierte Produktionsdaten landen in Tickets, Chats und Präsentationen. Maskiere die Daten und deck alles Sensible ab, bevor du teilst.
• Feedback nach dem Motto „geht nicht“. Kein Schritt, kein erwarteter Wert und kein Screenshot bedeuten keinen Fix. Bring den Testern am ersten Tag den Standard mit 6 Punkten bei.
• Feature-Wünsche als Fehler erfasst. Sie blähen die Fehlerzahl auf und bremsen die Abnahme. Triagiere sie jeden Tag als Change Requests.
• Keine namentlich genannte abnahmeberechtigte Person. Ein Gremium kann nicht unterschreiben. Schreib einen Namen in den Plan.
• Start mit offenen kritischen Bugs. Tester stoßen auf bekannte Bugs, verlieren das Vertrauen und hören auf zu testen. Bleib bei den Eingangskriterien hart.

Häufig gestellte Fragen

Was versteht man unter einem UAT-Test?

Ein UAT-Test ist ein User Acceptance Test, also ein Abnahmetest durch die Anwender: die letzte Testphase vor dem Release, in der Fachanwender oder Mitarbeitende des Kunden echte Geschäftsszenarien in einer produktionsnahen Umgebung durchspielen. Er soll bestätigen, dass die Software die Anforderungen des Business erfüllt, nicht nur die Spezifikation. Am Ende steht eine Abnahme: abgenommen, abgenommen mit Auflagen oder abgelehnt.

Wofür steht UAT?

UAT steht für User Acceptance Testing, auf Deutsch Benutzerakzeptanztest oder Abnahmetest. Manchmal heißt er auch End-User-Test oder fachlicher Abnahmetest (Business Acceptance Testing). Das ISTQB führt den Abnahmetest als vollwertige Teststufe, mit UAT als einer Art neben vertraglicher, regulatorischer und betrieblicher Abnahme sowie Alpha- und Betatests.

Was ist der Unterschied zwischen UAT und QA-Tests?

QA-Tests prüfen, ob die Software wie spezifiziert funktioniert. QA Engineers testen gegen die Anforderungen und melden Fehler. UAT prüft, ob die Spezifikation zum Business passt: Fachanwender erledigen echte Aufgaben und entscheiden, ob sie das Release abnehmen. Erst kommt die QA, dann UAT.

Wer ist für den UAT-Test verantwortlich?

Der Fachbereich ist für die Abnahme verantwortlich. Ein UAT-Lead (oft ein QA-Lead oder BA) plant und steuert den Zyklus, Fachtester oder Fachexperten spielen die Szenarien durch, und Entwickler beheben Fehler. Ein namentlich genannter Product Owner oder Sponsor auf Kundenseite nimmt ab.

Ist UAT Teil des SDLC?

Ja. UAT ist die Abnahme-Teststufe und die letzte Testphase im SDLC vor dem Deployment. Im Wasserfallmodell ist der UAT eine eigene Phase nach dem Systemtest. In Agile nimmt der Product Owner Stories in jedem Sprint ab, und vor dem Go-live läuft trotzdem ein UAT auf Release-Ebene, um durchgängige Geschäftsabläufe zu prüfen.

Wie lange dauert ein UAT-Test normalerweise?

Das hängt vom Umfang ab, aber die meisten Teams setzen einen festen Zeitrahmen. Ein bis zwei Wochen sind für ein Release einer geschäftlichen Web-App üblich, während ERP-Einführungen und regulierte Systeme oft mehrere Zyklen über einige Wochen brauchen. Plan mindestens eine Runde aus Fix und Retest ein, denn der erste Durchlauf endet selten fehlerfrei.

Ist UAT dasselbe wie ein Usability-Test?

Nein. Ein Usability-Test fragt, ob Menschen das Produkt leicht bedienen können, und UX Researcher beobachten Nutzer bei Aufgaben, oft an Prototypen. UAT fragt, ob das Business das Release abnimmt, und Fachanwender spielen geskriptete Szenarien auf dem Release Candidate durch. Ein UAT-Tester bemerkt vielleicht Usability-Probleme, doch die werden meist zu Change Requests.

Was ist UAT im Bankwesen?

Im Bankwesen prüfen Mitarbeitende aus Operations, Finanzen und Compliance beim UAT Transaktionen, Kontoauszüge, Gebühren, Zinsen und regulatorische Meldungen in einer produktionsnahen Umgebung mit maskierten Daten. Banken brauchen meist formelle Nachweise für Auditoren, darunter Screenshots bestandener Szenarien. Abnahmeprotokolle und die Benennung der Nachweise zählen deshalb mehr als sonst.

Was ist ein UAT-Skript?

Ein UAT-Skript ist die nummerierte Liste der Schritte, der ein Fachtester für ein Szenario folgt, mit den zugehörigen Testdaten und einem erwarteten Ergebnis in Business-Begriffen. Gute Skripte nutzen die Sprache des Testers, keine technischen Fachbegriffe. Sie nummerieren jeden Schritt, damit Screenshots und Feedback genau auf den fehlgeschlagenen Schritt zeigen können.

Vor deinem nächsten UAT-Zyklus

Kopier die vier Vorlagen, füll den Plan aus und schick den Testern den einseitigen visuellen Leitfaden vor dem Kickoff. Der Zyklus läuft runder, wenn jeder Fehlschlag mit einer Schrittnummer, einem markierten Screenshot und einem klaren Flag „blockiert Abnahme“ ankommt.

Wenn das Aufnehmen und Markieren dieser Screenshots der langsame Teil ist, erledigt ScreenSnap Pro Aufnahme, nummerierte Schritte, Schwärzen mit deckenden Rechtecken, OCR und GIFs in einem Ablauf. Es ist ein einmaliger Kauf für 34 $: 1 Lizenz für 2 Computer (2 Aktivierungen, Mac oder Windows). Zu den Preisen.