User Acceptance Testing ist der Punkt, an dem die Menschen, die die Software später wirklich benutzen, entscheiden, ob sie ihre Arbeit erledigt. Nicht ob sie funktioniert - das ist bereits getestet -, sondern ob sie das tut, worum sie gebeten haben, und zwar auf eine Art, mit der sie leben können.

Es ist die einzige Testphase, deren Zweck eine Entscheidung ist und keine Fehlerliste. UAT endet damit, dass jemand Ja oder Nein zu einem Release sagt.

Was sie von jedem anderen Test unterscheidet

Jede frühere Phase fragt, ob die Software ihrer Spezifikation entspricht. UAT fragt, ob die Spezifikation richtig war.

Diese Unterscheidung klingt akademisch, bis man sie erlebt. Eine Funktion kann jeden fachlichen Test bestehen, jedes Akzeptanzkriterium so erfüllen, wie es geschrieben steht, und im UAT trotzdem abgelehnt werden, weil die Person, die diese Arbeit dreihundertmal pro Woche macht, sieht, dass sie vier Klicks brauchen wird, wo der alte Weg einen brauchte. Nichts ist kaputt. Die Anforderung war falsch, und dies ist der letzte günstige Moment, um das herauszufinden.

QA-Test
Tut die Software, was wir angekündigt haben? Von Testern durchgeführt, gegen die Spezifikation
User Acceptance Testing
Tut sie, was das Geschäft braucht? Von denen durchgeführt, deren Arbeit es ist, gegen die Wirklichkeit

Wer sie durchführt und wer nicht

Die Leute, die sie benutzen werden. Nicht das Entwicklungsteam, nicht die QA und nicht eine Führungskraft, die stellvertretend für sie einspringt.

Das ist schwerer, als es sich liest. Die Leute, die Sie brauchen, sind damit beschäftigt, genau die Arbeit zu tun, für die die Software gedacht ist, und ihre Zeit ist der teuerste Teil der ganzen Übung. Deshalb wird ein UAT, das als nachträglicher Einfall geplant wird, an irgendjemanden delegiert, der gerade frei ist, und ein Release wird dann von jemandem abgenommen, der die Arbeit, die es unterstützt, nie gemacht hat.

Zwei Rollen sind es wert, benannt zu werden: jemand, dem die Entscheidung gehört und der Nein sagen kann, und jemand, der einsammelt, was die Tester finden, und daraus etwas macht, womit ein Entwickler arbeiten kann. Ohne die erste bringt UAT Meinungen hervor und kein Ergebnis. Ohne die zweite bringt es eine Tabelle hervor, mit der niemand arbeiten kann.

Was Tester an die Hand bekommen sollten

Keine Liste von Funktionen. Eine Liste der Dinge, die sie normalerweise tun.

1. Einen neuen Kunden von der Anfrage bis zur ersten Rechnung bringen
2. Eine Erstattung für eine per Karte bezahlte Bestellung bearbeiten
3. Den Monat abschließen, wenn zwei Filialen getrennt berichten
4. Eine Adresse auf einer bereits versendeten Bestellung korrigieren

Das sind Geschäftsprozesse, und jeder einzelne davon durchquert mehrere Funktionen. Ein Tester, dem man “prüfen Sie die Rechnungsmaske” gibt, wird die Rechnungsmaske prüfen; ein Tester, dem man “bringen Sie einen neuen Kunden zu seiner ersten Rechnung” gibt, findet die zwei Stellen, an denen der Prozess zwischen den Masken bricht, und dort leben die echten Probleme.

Geben Sie ihnen echte Daten oder die nächstbeste sichere Kopie davon. Ein UAT auf einer Datenbank mit Testkunde 1 bis 20 findet keines der Probleme, die ein Kunde namens “O’Brien & Sons (früher Smith)” sofort findet.

Wann sie fertig ist

Bevor sie beginnt, einigen Sie sich darauf, was “Ja” bedeutet. Schriftlich und in Begriffen, die jemand nachprüfen kann.

  • Welche Prozesse funktionieren müssen und welche umständlich sein dürfen
  • Was als Blocker zählt und was im nächsten Release behoben wird
  • Wer unterschreibt und wofür er unterschreibt
  • Wie lange es läuft. Ein UAT ohne Enddatum endet nicht; es verblasst

Der häufigste Fehlschlag ist nicht ein schlechter Test, sondern ein unklarer Abschluss. Eine Phase, die läuft, bis die Leute aufhören, Dinge zu melden, endet, wenn ihnen langweilig wird, und ein Release, das auf Langeweile hin ausgeliefert wird, ist ein Release, dem niemand zugestimmt hat.

Die Meldungen, die ein UAT hervorbringt

Das ist der Teil, auf den sich Entwicklungsteams innerlich vorbereiten, und der Grund dafür ist strukturell und nicht jemandes Schuld.

Ihre Tester sind keine Tester. Sie sind Buchhalter, Disponenten, Pflegekräfte, Vertriebsleute - und sie beschreiben, was passiert ist, in der Sprache ihres Berufs statt in der Sprache der Software. “Die Rechnung ging an die falsche Filiale” ist ein völlig klarer Satz, und er ist nicht reproduzierbar. Es fehlen die Rechnung, die Filiale, was auf dem Bildschirm war und was sie stattdessen erwartet hatten.

Zwei Dinge helfen mehr als alles andere:

Fragen Sie nach dem Vorgang, nicht nach der Diagnose. “Was haben Sie gemacht, und was hatten Sie erwartet?” bringt Sie weiter als jedes Formular, denn die Vermutung eines Fachanwenders über die Ursache ist meistens falsch und ersetzt meistens die Fakten.

Nehmen Sie ihnen den technischen Teil ab. Niemand im UAT sollte nach einer Browserversion, einem Konsolenprotokoll oder nach Schritten gefragt werden, die für einen Entwickler geschrieben sind. Das richtig zu machen ist die Aufgabe von Werkzeugen, und je weniger Sie von einem Tester verlangen, desto mehr wird er melden.

Session Replay

Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link, den Sie ins Ticket einfügen können.

Erweiterung holen

Wer die Meldungen einsammelt, muss aus jeder einzelnen immer noch etwas machen, womit ein Entwickler arbeiten kann, und der Leitfaden für Fehlerberichte ist die Form, die das annimmt. Wenn sich ein UAT-Fund nicht reproduzieren lässt, wird er ungelöst geschlossen, so echt er auch war.

Die Kurzfassung

UAT fragt, ob Software die Arbeit erledigt, entschieden von den Leuten, deren Arbeit es ist. Geben Sie ihnen Prozesse statt Masken, echte Daten statt Testzeilen, eine vereinbarte Definition von Ja und so wenig technische Hausaufgaben wie möglich. Was zurückkommt, wird in ihrer Sprache formuliert sein, und daraus etwas Reproduzierbares zu machen ist die Arbeit - kein Zeichen dafür, dass sie falsch getestet haben.