Benutzerakzeptanztests (UAT)
Ende-zu-Ende UAT-Framework, das die Planerstellung, Durchführung, Abnahme durch Stakeholder und Go/No-Go-Entscheidungen für Releases abdeckt. UAT ist das letzte Qualitätsgate vor der Produktion – behandeln Sie es auch so. Kein Feature wird ohne explizite Abnahme der Stakeholder gegen die Akzeptanzkriterien ausgeliefert.
Vorverarbeitung (Auto-Kontext)
Bevor Sie beginnen, sammeln Sie den Projektkontext im Hintergrund:
- Lesen Sie
PORTFOLIO.md, falls es im Projektstamm oder in übergeordneten Verzeichnissen existiert, um Produkt-/Teamkontext zu erhalten - Führen Sie aus:
cat package.json 2>/dev/null || cat build.gradle.kts 2>/dev/null || cat Podfile 2>/dev/null, um den Stack zu erkennen - Führen Sie aus:
git log --oneline -5 2>/dev/nullfür die letzten Änderungen - Führen Sie aus:
ls src/ app/ lib/ functions/ 2>/dev/null, um die Projektstruktur zu verstehen - Verwenden Sie diesen Kontext, um alle Ausgaben auf das tatsächliche Projekt abzustimmen
Schritt 1: Klassifizieren des UAT-Bedarfs
Bestimmen Sie den UAT-Typ, bevor Sie den Plan erstellen. Der Typ bestimmt Umfang, Tiefe, Einbeziehung der Stakeholder und Zeitplan.
| UAT-Typ | Auslöser | Umfang | Typische Dauer |
|---|---|---|---|
| Neues Feature UAT | Feature-Entwicklung abgeschlossen, in Staging gemerged | Alle Akzeptanzkriterien aus PRD/Stories, vollständiger Happy Path + Randfälle | 2-5 Werktage |
| Regressions-UAT | Großer Refaktor, Abhängigkeits-Upgrade oder Plattformmigration | Kritische Benutzerpfade erneut geprüft, keine Verhaltensregressionen | 1-3 Werktage |
| Release-Kandidaten UAT | Release-Branch erstellt, alle Features integriert | Vollständiger Release-Umfang – jedes Feature, jeder Integrationspunkt, jedes plattformübergreifende Verhalten | 3-5 Werktage |
| Hotfix-Validierung | Produktionsfehler behoben, Patch in Staging deployed | Enger Umfang – Fehlerbehebung prüfen, keine Nebeneffekte auf angrenzende Abläufe bestätigen | 2-4 Stunden |
Wenn der UAT-Typ unklar ist, fragen Sie nach, bevor Sie fortfahren. Ein Hotfix-Validierung und ein Release-Kandidaten UAT erfordern grundlegend unterschiedliche Pläne.
Automatische Kontexterfassung
Vor der Erstellung des UAT-Plans:
- Durchsuchen Sie das Projekt global nach vorhandenen Testspezifikationen, PRD-Dateien, Dokumenten mit Akzeptanzkriterien
- Lesen Sie alle gefundenen Spezifikationen, um testbare Anforderungen zu extrahieren
- Durchsuchen Sie den Code mit grep nach Feature-Flags, die die zu testenden Features steuern
Generierung von Artefakten (Erforderlich)
Erzeugen Sie folgende Dateien mit dem Write-Tool:
- UAT-Plan:
docs/uat/uat-plan.md– im Stil einer Testplan-Ausgabe - Testfälle:
docs/uat/test-cases.md– detaillierte Testfälle mit Schritten und erwarteten Ergebnissen - Freigabeformular:
docs/uat/sign-off.md– Vorlage für die Stakeholder-Abnahme - Bug-Triage-Vorlage:
docs/uat/bug-triage.md– Leitfaden zur Schweregradklassifizierung
Schritt 2: Kontext sammeln
Erfassen Sie alle Eingaben, bevor Sie den UAT-Plan schreiben. Fehlender Kontext führt zu unvollständigen Plänen.
| Eingabe | Erforderlich | Quelle | Hinweise |
|---|---|---|---|
| Feature-Name / Release-Version | Ja | PM/Tech Lead | Kurzer Identifikator zur Nachverfolgung |
| Akzeptanzkriterien | Ja | PRD, User Stories, Jira/Linear-Tickets | Verwenden Sie das /sdlc-Skill-Ergebnis, falls verfügbar |
| Stakeholder-Liste | Ja | PM/Product Owner | Wer testet, wer gibt frei, wer hat Vetorecht? |
| Zielumgebung | Ja | Engineering | Staging-URL, Build-Nummer, Feature-Flags |
| Plattform(en) | Ja | Engineering | Android, iOS, Web oder Kombination |
| Compliance-Anforderungen | Optional | Recht / Sicherheit | HIPAA, SOC 2, PCI-DSS, GDPR-Einschränkungen für Testdaten |
| Bekannte Risiken oder Einschränkungen | Optional | Engineering | Technische Schulden, bekannte Probleme, unvollständige Integrationen |
| Vorherige UAT-Ergebnisse | Optional | QA/PM | Baseline für Regressionsvergleich |
| Release-Termin | Ja | PM | Festes Datum vs. flexibel – bestimmt den Go/No-Go-Druck |
Wenn keine Akzeptanzkriterien existieren, stoppen Sie und erstellen Sie diese zuerst mit dem /sdlc-Skill. UAT ohne Akzeptanzkriterien ist meinungsbasiertes Testen – es beweist nichts.
Schritt 3: UAT-Planerstellung
3.1 Extraktion der Akzeptanzkriterien
Akzeptanzkriterien aus allen Quellen extrahieren und in testbare Aussagen normalisieren.
Format: Gegeben [Vorbedingung], Wenn [Aktion], Dann [Erwartetes Ergebnis]
Quellpriorität:
1. PRD-Akzeptanzkriterien (maßgeblich)
2. User-Story-Akzeptanzkriterien (detailliert)
3. Design-Spezifikationen / Prototypen (visuelles und Interaktionsverhalten)
4. API-Verträge (Antwortstrukturen, Fehlercodes)
5. Randfälle, die während des Code-Reviews oder /feature-audit identifiziert wurden
Jedes Akzeptanzkriterium wird zu einem oder mehreren Testszenarien. Wenn ein Kriterium nicht manuell getestet werden kann, markieren Sie es und geben Sie die automatisierte Überprüfungsmethode an.
3.2 Testszenario-Matrix
Erstellen Sie die vollständige Szenariomatrix. Jedes Szenario hat genau ein erwartetes Ergebnis.
| ID | Kategorie | Szenario | Vorbedingung | Schritte | Erwartetes Ergebnis | Plattform | Priorität |
|---|---|---|---|---|---|---|---|
| UAT-001 | Happy Path | [Primärer Erfolgspfad] | [Einrichtungszustand] | [1. 2. 3.] | [Erwartetes Ergebnis] | Alle | P0 |
| UAT-002 | Happy Path | [Sekundärer Erfolgspfad] | [Einrichtungszustand] | [1. 2. 3.] | [Erwartetes Ergebnis] | Alle | P0 |
| UAT-003 | Randfall | [Grenzbedingung] | [Einrichtungszustand] | [1. 2. 3.] | [Erwartetes Ergebnis] | Alle | P1 |
| UAT-004 | Fehlerzustand | [Ungültige Eingabe / Fehler] | [Einrichtungszustand] | [1. 2. 3.] | [Fehlerbehandlung] | Alle | P1 |
| UAT-005 | Plattformübergreifend | [Plattformspezifisches Verhalten] | [Einrichtungszustand] | [1. 2. 3.] | [Plattformerwartung] | Spezifisch | P1 |
| UAT-006 | Barrierefreiheit | [Screenreader / Tastaturnavigation] | [AT aktiviert] | [1. 2. 3.] | [Barrierefreies Ergebnis] | Alle | P1 |
| UAT-007 | Leistung | [Ladezeit / Reaktionsfähigkeit] | [Standardbedingungen] | [1. 2. 3.] | [Innerhalb des Budgets] | Alle | P2 |
| UAT-008 | Offline/Eingeschränkt | [Keine Konnektivität / Schlechtes Signal] | [Flugmodus / gedrosselt] | [1. 2. 3.] | [Korrekte Handhabung] | Mobil | P1 |
Prioritätsdefinitionen:
- P0 – Kernfunktionalität. Wenn dies fehlschlägt, funktioniert das Feature nicht. Blockiert das Release.
- P1 – Wichtiges Verhalten. Wenn dies fehlschlägt, funktioniert das Feature, aber mit erheblichen Lücken. Muss vor dem Release behoben werden.
- P2 – Nettes Extra zur Überprüfung. Wenn dies fehlschlägt, kann das Release mit dokumentiertem bekanntem Problem ausgeliefert werden.
3.3 Umgebungscheckliste
Überprüfen Sie die Testumgebung, bevor die UAT beginnt. Eine defekte Umgebung verschwendet die Zeit der Stakeholder und untergräbt das Vertrauen.
CHECKLISTE VOR UAT-UMGEBUNG
[ ] Staging-Umgebung mit korrektem Build/Version bereitgestellt
[ ] Build-Version dokumentiert: _______________
[ ] Feature-Flags für den UAT-Umfang aktiviert:
[ ] Flag: _____________ = AN/AUS
[ ] Flag: _____________ = AN/AUS
[ ] Testdaten angelegt (Konten, Inhalte, Transaktionen)
[ ] Testkonten mit erforderlichen Rollen/Berechtigungen erstellt
(siehe /test-accounts-Skill zur Kontobereitstellung)
[ ] Integrationen von Drittanbietern im Test/Sandbox-Modus:
[ ] Stripe: Testmodus mit Test-API-Schlüsseln
[ ] Zahlungsabwickler: Sandbox-Umgebung
[ ] E-Mail/SMS: abgefangen oder mit Testempfängern
[ ] Analysen: dev/staging-Eigenschaft (nicht Produktion)
[ ] Backend/API zeigt auf Staging (nicht Produktion)
[ ] Datenbank mit repräsentativer Datenmenge befüllt
[ ] Push-Benachrichtigungen für Staging konfiguriert
[ ] Deep Links / Universal Links für die Staging-Domain konfiguriert
[ ] SSL-Zertifikate auf Staging gültig
[ ] VPN/Netzwerkzugriff für alle Tester konfiguriert
3.4 Tabelle der Stakeholder-Rollen
Definieren Sie, wer was tut. Unklarheit bei den Rollen bedeutet Lücken in der Abdeckung.
| Rolle | Person | Verantwortlichkeiten | Freigabebefugnis |
|---|---|---|---|
| UAT-Leitung | [Name] | Besitzt den UAT-Plan, koordiniert Sitzungen, triagiert Fehler, erstellt Bericht | Endgültige Go/No-Go-Empfehlung |
| Produktverantwortlicher | [Name] | Validiert, dass Akzeptanzkriterien erfüllt sind, testet Geschäftslogik-Szenarien | Ja – Geschäftsfreigabe |
| Design-Leitung | [Name] | Validiert visuelle Wiedergabetreue, Interaktionsmuster, Markenkonsistenz | Ja – Designfreigabe |
| Engineering-Leitung | [Name] | Für Fehleruntersuchung, Umgebungsbehebungen, Erklärung technischer Einschränkungen verfügbar | Ja – Technische Freigabe |
| QA-Tester | [Name] | Führt Testszenarien systematisch aus, dokumentiert Ergebnisse mit Nachweisen | Nein – berichtet an UAT-Leitung |
| Domänenexperte | [Name] | Testet domänenspezifische Workflows (Finanzen, Gesundheitswesen, Recht) | Ja – Domänenfreigabe |
| Barrierefreiheitstester | [Name] | Screenreader-Test, Tastaturnavigation, WCAG-AA-Überprüfung | Beratend – eskaliert an UAT-Leitung |
Mindestanforderung für die Freigabe: Produktverantwortlicher + Engineering-Leitung. Alle anderen Freigaben sind empfohlen, aber umfangsabhängig.
Schritt 4: UAT-Durchführungsrahmen
Siehe reference/details.md (Abschnitt „Schritt 4: UAT-Durchführungsrahmen“) für vollständige Details.
Schritt 5: Freigabe und Go/No-Go-Entscheidung
5.1 Entscheidungsmatrix für Go/No-Go
Die Go/No-Go-Entscheidung ist datengesteuert, nicht meinungsgesteuert. Bewerten Sie jedes Kriterium und berechnen Sie das gewichtete Ergebnis.
GO / NO-GO-ENTSCHEIDUNGSMATRIX
Feature/Release: _______________
Datum: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────────────┬────────┬────────┬───────┬───────┐
│ Kriterium │ Gewicht│ Status │ Punkt │ Notizen│
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ Alle P0-Szenarien bestanden │ 30% │ GO/NOGO│ X/30 │ │
│ Alle P1-Szenarien bestanden │ 25% │ GO/NOGO│ X/25 │ │
│ Keine offenen P0-Fehler │ 20% │ GO/NOGO│ X/20 │ │
│ Keine offenen P1-Fehler (oder Risiko akzeptiert)│ 10% │ GO/NOGO│ X/10 │ │
│ Barrierefreiheit bestanden (WCAG AA) │ 5% │ GO/NOGO│ X/5 │ │
│ Leistung innerhalb des Budgets │ 5% │ GO/NOGO│ X/5 │ │
│ Plattformübergreifende Parität geprüft │ 5% │ GO/NOGO│ X/5 │ │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ GESAMT │ 100% │ │ X/100 │ │
└──────────────────────────────────┴────────┴────────┴───────┴───────┘
Entscheidungsschwellen:
GO >= 90/100 Alle P0-Kriterien müssen GO sein.
BEDINGT 70-89/100 Mit dokumentierten Bedingungen und Zeitplan für die Lösung ausliefern.
NO-GO < 70/100 Nicht veröffentlichen. Beheben und erneut testen.
Harte Blocker (automatisches NO-GO unabhängig von der Punktzahl):
- Jeder offene P0-Fehler
- Datenverlust- oder -beschädigungsszenario
- Sicherheitslücke (Authentifizierungsumgehung, Datenoffenlegung)
- Absturz auf einem kritischen Benutzerpfad
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 Freigabevorlage
FREIGABE DURCH STAKEHOLDER
Feature/Release: _______________
Build/Version: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────┬──────────────┬──────────┬────────────┬─────────┐
│ Stakeholder │ Rolle │ Entscheidung│ Bedingungen│ Datum │
├──────────────────┼──────────────┼──────────┼────────────┼─────────┤
│ [Name] │ Produktverantwortlicher│ GO/NOGO │ [ggf.] │ [Datum] │
│ [Name] │ Engineering-Leitung │ GO/NOGO │ [ggf.] │ [Datum] │
│ [Name] │ Design-Leitung │ GO/NOGO │ [ggf.] │ [Datum] │
│ [Name] │ Domänenexperte │ GO/NOGO │ [ggf.] │ [Datum] │
│ [Name] │ UAT-Leitung │ GO/NOGO │ [ggf.] │ [Datum] │
└──────────────────┴──────────────┴──────────┴────────────┴─────────┘
Bedingte Freigabe bedeutet: „GO, vorausgesetzt, die folgenden Punkte werden bis zum [Datum] gelöst:"
1. [Bedingung]
2. [Bedingung]
Wenn IRGENDEIN Stakeholder mit NO-GO unterschreibt, wird das Release blockiert, bis sein Anliegen gelöst ist.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.3 Rollback-Plan
Jedes Release muss einen dokumentierten Rollback-Plan haben, bevor die Go/No-Go-Entscheidung getroffen wird. Kein Rollback-Plan = automatisches NO-GO.
ROLLBACK-PLAN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Auslöser: [Bedingungen, die einen Rollback auslösen – z. B. Absturzrate > 2 %, P0-Fehler in Produktion]
Verantwortlich: [Wer initiiert den Rollback]
Schritte:
1. [Feature-Flag deaktivieren / Deployment rückgängig machen]
2. [Erfolg des Rollbacks überprüfen]
3. [Stakeholder benachrichtigen]
4. [30 Minuten nach dem Rollback überwachen]
Daten: [Ist ein Datenmigrations-Rollback erforderlich? Firestore-Dokumentversionierung?]
Kommunikation: [Wer kommuniziert bei Bedarf mit den Benutzern – Support-Team, Statusseite]
Post-Mortem: [Innerhalb von 48 Stunden nach dem Rollback planen]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 Entwurf der Versionshinweise
Generieren Sie Versionshinweise aus den UAT-Ergebnissen. UAT-Tester kennen das Feature zu diesem Zeitpunkt besser als jeder andere.
VERSIONSHINWEISE (aus UAT-Ergebnissen)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Version: _______________
Datum: _______________
NEU
- [Hinzugefügtes Feature/Fähigkeit – in benutzerverständlicher Sprache]
VERBESSERT
- [Verbesserung eines bestehenden Features – was ist besser für den Benutzer]
BEHOBEN
- [Während der UAT behobener Fehler – was war defekt und ist jetzt gelöst]
BEKANNTE PROBLEME
- [P2-Fehler, die mit diesem Release ausgeliefert werden – Workaround falls verfügbar]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Schritt 6: UAT-Bericht
Erstellen Sie den vollständigen UAT-Bericht, nachdem alle Sitzungen abgeschlossen und die Freigaben gesammelt wurden.
═══════════════════════════════════════════════════════════════
UAT-BERICHT
Feature/Release: [NAME]
Version/Build: [VERSION]
Datum: [HEUTE]
UAT-Leitung: [NAME]
═══════════════════════════════════════════════════════════════
ZUSAMMENFASSUNG
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Entscheidung: GO / BEDINGT / NO-GO
Szenarien gesamt: [N]
Bestanden: [N] ([X]%)
Fehlgeschlagen: [N] ([X]%)
Blockiert: [N] ([X]%)
Nicht ausgeführt: [N] ([X]%)
Offene Blocker: [N] P0 / [N] P1 / [N] P2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
BESTANDENSRATE NACH KATEGORIE
┌──────────────────────┬──────────┬────────┬─────────┬────────┐
│ Kategorie │ Gesamt │ Bestanden│ Fehlgeschlagen│ Rate │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
│ Happy Path │ [N] │ [N] │ [N] │ [X]% │
│ Randfälle │ [N] │ [N] │ [N] │ [X]% │
│ Fehlerzustände │ [N] │ [N] │ [N] │ [X]% │
│ Plattformübergreifend│ [N] │ [N] │ [N] │ [X]% │
│ Barrierefreiheit │ [N] │ [N] │ [N] │ [X]% │
│ Leistung │ [N] │ [N] │ [N] │ [X]% │
│ Offline/Konnektivität│ [N] │ [N] │ [N] │ [X]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
...
[gekürzt für Übersetzung]