Ein Team liefert einmal ein Kostensystem, das alle technischen Tests besteht. Am ersten Tag stellt das Finanzteam fest, dass es Forderungen in mehreren Währungen nicht bearbeiten kann, die einen großen Teil ihrer Arbeit ausmachen. Nichts war „kaputt“, aber es war nicht verwendbar. Benutzerakzeptanztests gibt es, um genau diese Art von Lücke vor dem Start zu schließen.

In diesem Leitfaden erfahren Sie, wie sich UAT von anderen Tests unterscheidet, wie Sie es Schritt für Schritt ausführen und wie Sie entscheiden, wann Sie für die Veröffentlichung bereit sind. Das obige Szenario und die folgenden Beispiele dienen der Veranschaulichung. Der Prozess sollte an Ihr Projekt angepasst werden.

Was ist UAT?

UAT ist normalerweise die letzte Testphase vor der Veröffentlichung, in der die vorgesehenen Benutzer bestätigen, dass die Software ihre Arbeit unter realistischen Bedingungen erledigen kann. Es wird auch Endbenutzertest oder Akzeptanztest genannt. Es kommt nach der Entwicklung und dem Systemtest, wenn erwartet wird, dass das Produkt stabil ist.

Sein Zweck besteht nicht darin, jeden Fehler zu finden. Zu diesem Zeitpunkt sollten die meisten davon bereits verschwunden sein. Das Ziel ist die Validierung: Haben wir das Richtige gebaut? Tester überprüfen, ob das Produkt der Spezifikation entspricht. UAT validiert, dass die Spezifikation und das Produkt tatsächlich den Bedarf erfüllen.

UAT vs. QA-Tests

UAT ersetzt keine anderen Tests. Wenn Benutzer weiterhin auf grundlegende Fehler stoßen, war der Build noch nicht fertig und Sie verschwenden ihre begrenzte Zeit. Diese Probleme gehören zu früheren Teststufen und Regressionstests.

Wer betreibt UAT?

Wählen Sie heute Tester, die ihre Arbeit wirklich erledigen. Ein erfahrener Schadensbearbeiter wird Probleme erkennen, die ein Manager oder ein Bevollmächtigter niemals erkennen würde. Beziehen Sie eine Reihe von Erfahrungen mit ein, denn ein neuer Mitarbeiter offenbart oft verwirrende Schritte, die ein Experte umgeht, ohne es zu merken. Und stellen Sie sicher, dass ihre Vorgesetzten dafür Zeit haben, denn UAT kann bei voller Arbeitsbelastung nicht erfolgreich sein.

Arten von UAT

Der siebenstufige UAT-Prozess

1. Definieren Sie Umfang und Ziele

Entscheiden Sie, was akzeptiert wird, was außerhalb des Geltungsbereichs liegt und welche Geschäftsergebnisse wichtig sind. Beispiel: „Finanzmitarbeiter können eine Spesenabrechnung in jeder unterstützten Währung einreichen, genehmigen und bezahlen.“

2. Vereinbaren Sie Akzeptanzkriterien

Schreiben Sie im Klartext auf, wie Erfolg aussieht, idealerweise zu Beginn des Projekts und nicht erst eine Woche vor dem Start. Vage Kriterien führen später zu Auseinandersetzungen.

3. Wählen Sie Tester aus und informieren Sie sie

Wählen Sie echte Benutzer aus, erläutern Sie den Zweck, zeigen Sie ihnen, wie sie Feedback aufzeichnen, und machen Sie deutlich, dass sie die Software testen und nicht selbst getestet werden. Viele Menschen haben Angst, etwas falsch zu machen.

4. Bereiten Sie die Umgebung und die Daten vor

Die UAT-Umgebung sollte der Produktion so nahe wie möglich kommen. Nutzen Sie realistische Daten, richten Sie die richtigen Benutzerrollen ein und prüfen Sie Integrationen wie E-Mail. Wenn Sie Produktionsdaten kopieren, maskieren Sie zunächst persönliche Informationen. Führen Sie einen kurzen Rauchtest durch, damit die Tester nicht ankommen, um einen defekten Build zu finden.

5. Schreiben Sie Szenarien

Basieren Sie diese auf realen Arbeitsabläufen und nicht auf einzelnen Schaltflächen. Sie sollten sich wie der Job lesen, nicht wie die Software. Unser Leitfaden zu Testfall vs. Testszenario erklärt, wie viele Details Sie benötigen.

6. Führen Sie die Tests durch und sammeln Sie Feedback

Führen Sie Sitzungen mit jemandem durch, der Ihnen helfen kann. Sammeln Sie Probleme mit Screenshots an einem Ort. Nehmen Sie sich auch etwas Zeit für die freie Erkundung, denn die Leute probieren Dinge aus, die Skripte nie vorhersehen. Exploratives Testen bietet hierfür nützliche Techniken.

7. Korrigieren, erneut testen und abmelden

Sortieren Sie das Feedback, beheben Sie das Wesentliche und lassen Sie die Korrekturen von denselben Benutzern bestätigen. Notieren Sie dann eine formelle Entscheidung.

Ein UAT-Testfall

Ein UAT-Testfall sollte für jemanden ohne technische Kenntnisse leicht zu verstehen sein. Hier ist ein Beispiel für ein Spesensystem:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Beachten Sie, dass es eine reale Aufgabe und keine technischen Details beschreibt und Raum für Kommentare lässt. Diese Kommentare erweisen sich häufig als der wertvollste Teil, wie zum Beispiel „Das funktioniert, aber ich würde diesen Knopf nie finden“.

Ein- und Ausstiegskriterien

Diese passen in den breiteren Lebenszyklus von Softwaretests. Legen Sie die Zahlen im Voraus mit Ihren Stakeholdern fest. „Wir werden entscheiden, wann es sich richtig anfühlt“ führt tendenziell zu einem überstürzten Ja, getrieben von der Frist.

Umgang mit Feedback

UAT-Feedback ist eine Mischung verschiedener Dinge, und nicht alles davon ist ein Fehler. Sortieren Sie es in Kategorien:

Verwenden Sie klare Regeln dafür, was eine Veröffentlichung blockiert, wie unter Schweregrad vs. Priorität beschrieben. Und antworten Sie auf jeden Punkt, auch auf die, die Sie ablehnen. Die Leute hören auf, Feedback zu geben, wenn es scheinbar verschwindet. Unser Leitfaden zum Verfassen eines Fehlerberichts kann Testern dabei helfen, Probleme klar zu beschreiben.

UAT-Checkliste

Vor UAT

• Umfang und Abnahmekriterien werden schriftlich vereinbart
• System- und Regressionstests sind abgeschlossen
• Die Tester werden ausgewählt, eingewiesen und erhalten Zeit
• Umgebung, Abrechnungen und realistische Daten stehen bereit
• Persönliche Daten in Kopien wurden maskiert
• Szenarien werden vom Unternehmen überprüft
• Ein Ort zur Erfassung von Problemen ist eingerichtet
• Der Abzeichnungseigentümer wird benannt

Während UAT

• Ein Support-Kontakt steht zur Verfügung
• Die Probleme werden jeden Tag untersucht
• Der Fortschritt wird mit den Stakeholdern geteilt
• Fixes werden auf kontrollierte Weise bereitgestellt und erneut getestet

Nach UAT

• Ausstiegskriterien wurden geprüft
• Bekannte Probleme werden zusammen mit den Eigentümern dokumentiert
• Die formelle Abnahme wird protokolliert
• Schulungs- und Versionshinweise werden aktualisiert
• Es fand eine kurze Retrospektive statt

UAT in agilen Teams

Die traditionelle UAT stellt am Ende eine große Phase dar, in der eine Überraschung teuer ist. Agile Teams verkürzen diese Schleife. Produktbesitzer überprüfen jede Story während des Sprints anhand ihrer Akzeptanzkriterien, und Benutzer sehen bei Sprint-Reviews funktionierende Software. Viele Teams führen vor einer Hauptversion immer noch ein gezieltes UAT durch, insbesondere wenn mehrere Funktionen in einem Workflow kombiniert werden.

Bei häufigen Veröffentlichungen ermöglichen Techniken wie Feature Flags und Canary-Bereitstellungen echten Benutzern, neue Arbeiten schrittweise auszuprobieren. Beachten Sie, dass diese die Abnahmeprüfung ergänzen, sie jedoch nicht automatisch ersetzen, insbesondere in regulierten Branchen, die eine formelle Aufzeichnung benötigen.

Häufige Fehler

• Behandeln Sie es als eine Formalität. Eine Freigabe ohne wirklichen Nutzen schützt niemanden.
• Verwendung der falschen Tester. Entwickler und Qualitätssicherung haben zu viel Wissen über das System, um Benutzer darzustellen.
• Beginnt mit einem instabilen Build. Tester verlieren schnell das Vertrauen und das Interesse.
• Ich belasse es bis zur letzten Minute. Dann bleibt keine Zeit, das Gelernte zu korrigieren.
• Verwendung unrealistischer Daten. Testdaten weisen selten die chaotischen Fälle auf, die bei echter Arbeit auftreten.
• Den Spielraum wachsen lassen. Behandeln Sie neue Ideen als Änderungswünsche, es sei denn, sie sind echte Blockaden.

Fazit

UAT ist Ihre letzte Chance, vor der Veröffentlichung herauszufinden, ob die Software den Menschen, die sie verwenden werden, wirklich hilft. Planen Sie es von Beginn eines Projekts an, rekrutieren Sie echte Benutzer und vereinbaren Sie, wie der Erfolg aussieht. Versuchen Sie für Ihre nächste Version eine einfache Änderung: Setzen Sie sich während eines realen Szenarios mit einem Benutzer zusammen und sagen Sie nichts, während er arbeitet.

Häufige Fragen

Lerne weiter