User Acceptance Testing läuft fast immer nach demselben Muster ab. Du gibst einer Gruppe von Leuten (eigenen Mitarbeitenden, dem Team der Kundschaft, einer Handvoll Betakundschaft) Zugang zu einem Build und eine Woche Zeit zum Ausprobieren. Am Ende bekommst du eine Tabelle.
Die Tabelle hat sechzig Zeilen. Vielleicht fünfzehn lassen sich sofort bearbeiten. Zwanzig sind dieselben drei Bugs, auf fünf verschiedene Arten beschrieben. Zehn beschreiben gewolltes Verhalten. Zehn brauchen eine Rückfrage, bevor irgendwer anfangen kann. Und fünf sagen so etwas wie „wollte speichern, ging nicht“, ohne Hinweis darauf, welche Seite, welcher Browser oder welcher Tag.
Der erste Reflex ist, der Schulung die Schuld zu geben. Eine bessere Vorlage schreiben, eine Session dazu abhalten, wie man gute Bugs meldet, auf Schritten zur Reproduktion bestehen. Das hilft ein bisschen, und nach zwei Wochen ist es wieder verpufft.
Dass es verpufft, hat strukturelle Gründe. Testpersonen in der UAT sind keine QA-Profis, und wer verlangt, dass sie sich wie QA-Profis verhalten, verlangt etwas, das die Situation nicht hergibt.
Warum Testpersonen zu wenig melden
Drei Einschränkungen, und keine davon hat mit fehlendem Einsatz zu tun.
Sie sehen die Belege nicht. Wer in der UAT testet, hat keine DevTools offen. Dass ein Request eine 500 zurückgegeben hat, bekommt niemand mit. Man sieht einen Spinner, der nie aufhört, und schreibt „hing sich auf“. Die Information, mit der sich der Bug in neunzig Sekunden lösen ließe, war auf dem Bildschirm, hinter einem Tastenkürzel, das niemand gezeigt hat.
Melden kostet mehr, als der Bug wert zu sein scheint. Wer in eine Tabelle wechseln, die richtigen Spalten finden, den Kontext beschreiben und einen Screenshot machen muss, tut das für den Absturz. Beim verrutschten Label und bei der verwirrenden Fehlermeldung bleibt es bei einer gedanklichen Notiz, und es geht weiter. Genau für diese Funde hast du die UAT-Runde aber einberufen.
Sie testen, sie dokumentieren nicht. Wer im Flow ist, erkundet einen Ablauf. Jede Unterbrechung für einen Bericht reißt aus diesem Flow, also werden Berichte gesammelt und ans Ende der Session geschoben. Dann sind die Details am weitesten weg, und zwanzig weitere Aktionen haben den Weg zur Reproduktion längst überschrieben.
Jede dieser Einschränkungen ist eine Eigenschaft des Kanals, nicht der Person. Ändere den Kanal, und das Verhalten ändert sich.
Das Melden gehört in das, was getestet wird
Die wirksamste einzelne Änderung: Das Melden wandert aus einem separaten Tool in die Anwendung, die getestet wird.
Ein Melde-Button auf der Seite hebt alle drei Einschränkungen auf einmal auf. Es gibt keinen Kontextwechsel, also werden Berichte im Moment der Entdeckung geschrieben, statt am Ende gesammelt. Die Kosten sinken auf einen Klick, also werden auch die kleinen Funde gemeldet. Und der Browser ist direkt da, also werden die Belege angehängt, ohne dass die Testperson wissen muss, was Belege sind.
Genau das macht ein Tool, das auf einem Widget aufbaut. BugDump wird mit einem einzigen Script-Tag im Staging-Build installiert:
<script src="https://bugdump.com/sdk/latest.js" data-api-key="your-api-key"></script>Die Testperson klickt, tippt „wollte speichern, ging nicht“ und sendet ab. Bei dir kommt dieser Satz an, zusammen mit dem Console-Log, einschließlich allem, was vor dem Öffnen des Widgets geloggt wurde, mit den Netzwerk-Requests samt Status und Timing, einem Session-Replay, ihren Klicks und Eingaben in der richtigen Reihenfolge sowie Browser, Betriebssystem, Viewport und URL.
Die Testperson ist nicht besser im Melden von Bugs geworden. Der Kanal hat aufgehört, die Belege wegzuwerfen.
Speziell für eine UAT-Runde einrichten
Ein paar Konfigurationsentscheidungen zählen beim Testen mehr als in Produktion.
Identifiziere deine Testpersonen. In Produktion weißt du vielleicht nicht, wer meldet. In der UAT weißt du es immer, und es lohnt sich, das einzubinden: Ruf identify() mit Name und E-Mail der Testperson auf und setContext() mit ihrer zugewiesenen Rolle, dem Testkonto und dem Szenario, das sie bekommen hat. Kommen vier Berichte zu Berechtigungen herein und stammen alle vier von Testpersonen mit Leserolle, ist das schon die Diagnose.
Häng den Build an. Schreib den Commit-Hash oder die Build-Nummer in den Kontext. UAT-Runden ziehen sich meist über mehrere Deploys, und „Ist das nach dem Fix vom Dienstag immer noch kaputt?“ lässt sich ohne diese Angabe nicht beantworten.
Mach den Button unübersehbar. In Produktion ist ein dezenter schwebender Button richtig. In der UAT nicht: Nutze die Hinweisblase mit einem Text, der sagt, was du willst, eher „Etwas gefunden? Sag uns Bescheid“ als ein stummes Icon. Wer vergisst, dass es das Tool gibt, meldet stattdessen per E-Mail.
Schalte Netzwerk-Bodies bewusst ein. Request- und Response-Bodies sind das Nützlichste, was du anhängen kannst, und das Sensibelste. In einer Staging-Umgebung mit synthetischen Daten ist captureNetworkBodies meist ein klares Ja und erspart eine ganze Klasse von Rückfragen. In einer UAT-Runde mit Produktionsdaten und echten Kundendatensätzen nicht: Lass es aus oder filter die Endpoints, die personenbezogene Daten transportieren.
Filter das Rauschen. Staging-Umgebungen sind laut. Ein networkFilter, der Polling-Endpoints verwirft, und ein consoleFilter, der Debug-Geplapper verwirft, machen die Berichte viel lesbarer, und lesbare Berichte werden triagiert statt aufgeschoben.
Frag nach drei Dingen, nicht nach zwölf
Da die Erfassung automatisch läuft, sollte das Formular nur nach dem fragen, was allein die Testperson weiß:
Was schiefging, in eigenen Worten
Was stattdessen erwartet war
Wie oft: zum ersten Mal, manchmal, jedes Mal
Alles andere (Browser, Betriebssystem, URL, Console, Netzwerk, Timing) kommt von selbst.
Die dritte Frage solltest du gegen den Drang verteidigen, sie zu streichen. „Jedes Mal“ oder „manchmal“ ist der Unterschied zwischen einem deterministischen Bug und einer Race Condition, und das ändert, wo das Entwicklungsteam sucht, bevor es überhaupt irgendwo gesucht hat. Außerdem ist die Häufigkeit das Einzige, was keine Instrumentierung liefern kann, denn sie steckt in der Erinnerung der Testperson an die letzten zwanzig Minuten.
Widersteh der Versuchung, ein Dropdown für den Schweregrad hinzuzufügen. Alle wählen „Hoch“, weil aus einem blockierten Testszenario heraus alles hoch ist. Die Häufigkeit plus die Zahl der Leute, die es melden, erfüllt denselben Zweck mit besseren Daten.
Duplikate sind der Sinn der Sache
Der übliche Reflex bei einer UAT-Runde: Doppelte Berichte sind Verschwendung, zwanzig Zeilen für drei Bugs. Das ist verkehrt herum.
Fünf Leute, die denselben kaputten Speichern-Button melden, liefern dir fünf Umgebungen, fünf Abfolgen von Schritten, fünf Netzwerk-Logs. Nutzen vier davon Safari und die fünfte Person Chrome mit schmalem Viewport, hast du die Ursache, bevor irgendwer den Code öffnet. Ein einzelner Bericht zu diesem Bug hätte dir viel weniger verraten.
Du brauchst nicht weniger Duplikate, sondern eine Struktur, in der sie sich stapeln, statt sich zu verstreuen. Genau deshalb trennt BugDump Berichte von Aufgaben: Ein Bericht ist der Beleg einer Person, eine Aufgabe ist das, was du tatsächlich behebst, und viele Berichte hängen an einer Aufgabe. Aus zwanzig Berichten werden sechs Aufgaben, jede mit allen ihren Belegen, und die zwanzig Zeilen sind kein Durcheinander mehr, sondern eine Matrix.
Ist allowTaskAttach aktiviert, hängen Testpersonen ihren Bericht über die öffentliche ID an eine bestehende Aufgabe. „Das hat bestimmt schon jemand gemeldet“ ist dann kein Grund mehr, nichts zu melden, sondern eine Bestätigung mit einem Klick, dass es bei ihnen auch passiert.
Gib Rückmeldung, sonst stirbt die Runde
Am zuverlässigsten tötest du die Beteiligung an einer UAT-Runde mit Schweigen. Wer in Woche eins sechs Berichte schreibt und nichts hört, schreibt in Woche zwei keinen mehr. Nicht aus Trotz: Die Person hat schlicht gelernt, dass Melden nichts bewirkt, und damit hat sie recht.
Zwei Dinge helfen dagegen, und beide sind billig.
Leite Berichte dorthin, wo das Team ohnehin ist. Ein Telegram-, Slack- oder Discord-Channel, der für jeden Bericht eine Nachricht bekommt, lässt die Runde für alle lebendig wirken, auch für die Testpersonen. Sollen Bugs zu Issues werden, sorgt eine Integration mit GitHub Issues oder Jira dafür, dass niemand die Tabelle in einen Tracker abtippt.
Gib Testpersonen eine Statusseite. Ein öffentliches Portal, auf dem die meldende Person sieht, wie ihre Aufgabe von Bestätigt nach Fertig wandert, ist schon der ganze Mechanismus. Wer sieht, dass der eigene Bericht behoben wird, meldet auch den nächsten, und zwar in Woche drei, wenn die interessanten Bugs auftauchen.
Wie das am Ende der Runde aussieht
Statt der Tabelle gibt es ein Board. Sechzig Berichte sind zu etwa zwei Dutzend Aufgaben zusammengeschrumpft, jede mit den Belegen aller, die darauf gestoßen sind. Die unbrauchbaren Zeilen sind weg, weil die Felder, die sie unbrauchbar gemacht haben, vom Browser ausgefüllt wurden statt von einem Menschen, der raten musste, was wichtig ist.
Die Arbeit der Testpersonen ist wieder das, was sie sein sollte: die Software benutzen und sagen, was sich falsch angefühlt hat. Herauszufinden, was das bedeutet, ist Aufgabe des Entwicklungsteams, und das hat jetzt alles, was es dafür braucht.
Der kostenlose Plan umfasst ohne Kreditkarte 500 Berichte pro Monat und Projekt, mehr als die meisten UAT-Runden liefern, also bau BugDump am Tag vor dem Teststart in den Staging-Build ein.
Fehlerberichte im Betatest sammeln, ohne die Hälfte zu verlieren – ein Setup für Feedback im Betatest: Hürden senken, Kontext automatisch erfassen und Testpersonen sagen, was aus ihren Berichten wurde.
Von 40 Berichten zu 6 Bugs: wie Triage funktionieren sollte – warum die Trennung von Berichten und Aufgaben aus Duplikaten das beste Material fürs Debugging macht.
So schreibst du einen guten Fehlerbericht (mit Checkliste) – was ein Bericht braucht, damit der Bug behoben wird, und welche Felder ein Tool statt eines Menschen ausfüllen sollte.