Zehn Tage vor dem Go-Live eines ERP-Rollouts sitzen Projektleitung, IT und Fachbereich in einem österreichischen Maschinenbauunternehmen vor einer unangenehmen Liste. 47 offene UAT-Tickets sind noch nicht geschlossen, und die Key-User aus dem Werk Linz melden plötzlich abweichende Buchungsergebnisse. Technisch laufen die Kernfunktionen. Fachlich ist trotzdem unklar, ob die Lösung den Produktionsalltag korrekt abbildet. Der Projektleiter muss entscheiden, ob der Abnahmetest gerade zur Hürde oder zum Schutznetz wird.
Genau dort scheitert User Acceptance Testing in der Praxis oft. Nicht an fehlender Funktionalität, sondern an unklaren Akzeptanzkriterien, unvollständigen Testdaten und fehlenden Eskalationswegen. Bei AI-Agenten und MCP-gestützten Workflows kommt eine weitere Schwierigkeit hinzu: Eine Antwort kann plausibel wirken, ohne bei jedem Lauf identisch zu sein. Deshalb müssen Teams nicht nur prüfen, ob ein Prozess funktioniert, sondern auch, ob ein nicht-deterministischer Bestandteil innerhalb klarer fachlicher und technischer Grenzen bleibt.
Dieser Leitfaden zeigt, wie sich UAT in Enterprise-Umgebungen planen, durchführen und formal abschließen lässt. Im Mittelpunkt stehen wiederverwendbare Akzeptanzkriterien, realistische Testdaten, Rollen, Testumgebungen, Defect-Triage und Governance für AI-Agenten. Die Beispiele lassen sich direkt in den nächsten ERP-, CRM- oder Automatisierungs-Release übertragen.
Inhaltsverzeichnis
- Wenn der Abnahmetest zur Hürde wird
- So läuft ein UAT-Zyklus Schritt für Schritt
- Checkliste für Planung, Rollen und Testumgebung
- Beispiel-Testfälle für ERP, CRM und AI-Agent-Workflows
- Manuell, skriptbasiert oder AI-gestützt im Vergleich
- Abnahme, Protokoll und Go-Live-Entscheidung
- Die fünf häufigsten UAT-Fehler und wie sie zu vermeiden sind
Wenn der Abnahmetest zur Hürde wird
User Acceptance Testing ist die letzte fachliche Prüfung vor der Produktivsetzung. Spätere Anwender oder repräsentative Fachanwender prüfen reale Geschäftsprozesse gegen vorher festgelegte Anforderungen und entscheiden, ob die Lösung für den Betrieb geeignet ist. In Österreich wird der Abnahmetest als formaler Schritt verstanden, der nach den Einzeltests ein Abnahmeprotokoll mit Ergebnissen, Abweichungen und Freigabeentscheidung verlangt. Diese schriftliche Dokumentation macht nachvollziehbar, warum ein System produktiv gehen darf oder welche Einschränkungen akzeptiert wurden. Das beschreibt auch die österreichische Fachpraxis zur Abnahme von Individualsoftware.
UAT beantwortet eine andere Frage als technische Teststufen. Unit-Tests prüfen einzelne Codeeinheiten, Integrationstests prüfen das Zusammenspiel von Schnittstellen, und Systemtests betrachten das technische Gesamtsystem. UAT fragt: Kann der Fachbereich den vollständigen Prozess korrekt, verständlich und kontrolliert ausführen?
| Teststufe | Ziel | Verantwortung | Typische Werkzeuge |
|---|---|---|---|
| UAT | Geschäftsanforderungen, Akzeptanzkriterien und Bedienbarkeit bestätigen | Fachbereich, Key-User, Product Owner | Jira, Azure DevOps, Testmanagement-Plattform, Abnahmeprotokoll |
| Systemtest | Verhalten des vollständigen Systems gegen technische und funktionale Anforderungen prüfen | Testmanager, QA, Fachspezialisten | Testautomatisierung, Logs, Monitoring, Testframeworks |
| Integrationstest | Datenfluss und Zusammenspiel verbundener Systeme validieren | Integrationsteam, Entwickler, Betrieb | API-Tests, Contract-Tests, Schnittstellenmonitoring |
| Smoke-Test | Prüfen, ob ein Build grundsätzlich testbar ist | QA, Betrieb, Release-Verantwortliche | Deployment-Pipeline, Health Checks, kurze Kernprozess-Skripte |
UAT ersetzt keine Performance-, Sicherheits- oder Lasttests. Ein Key-User kann bestätigen, dass eine Bestellung fachlich richtig verarbeitet wird. Daraus folgt noch nicht, dass das System unter hoher Last stabil bleibt oder eine Sicherheitsfunktion korrekt konfiguriert ist. Für Pharma, Banken und andere regulierte Bereiche kommen zusätzlich Compliance-Nachweise, Berechtigungsprüfungen, Audit-Trails und dokumentierte Freigaben hinzu. Eine österreichisch geprägte Beschreibung von UAT hebt neben der Nutzerfreigabe auch die Prüfung sicherheitsrelevanter Einstellungen, des verbleibenden Risikos sowie von Versionen, Programmen und abgezeichneten Testergebnissen hervor. Diese Anforderungen sind im Glossar zum UAT-Abnahmetest konkret eingeordnet.
Der eigentliche Engpass
Im Linzer ERP-Beispiel ist die Frage nicht bloß, ob das Buchungsprogramm funktioniert. Das Team muss klären, ob die verwendeten Stammdaten vollständig sind, ob die lokale Prozessvariante berücksichtigt wurde und ob die Key-User dieselbe Erwartung an das Ergebnis haben. Ein Testfall wie „Rechnung buchen“ ist dafür zu grob. Er muss beschreiben, welcher Lieferant, welcher Steuercode, welche Genehmigung und welches erwartete Ergebnis gelten.
Bei einem AI-Agenten verschiebt sich die Prüfung weiter. Der Agent kann einen Beleg klassifizieren, eine ERP-Abfrage über MCP ausführen oder einen nächsten Prozessschritt vorschlagen. Die fachliche Akzeptanz darf deshalb nicht nur an einer exakten Textantwort hängen. Sie braucht Grenzen für erlaubte Entscheidungen, Pflichtbegründungen, nicht zulässige Aktionen, Eskalationen und den Umgang mit fehlenden Daten.
Praktische Regel: Wenn ein Fachanwender nicht in wenigen Sätzen sagen kann, wann ein Test bestanden ist, ist das Akzeptanzkriterium noch nicht fertig.
Ein sauberer UAT schützt den Go-Live, weil er fachliche Risiken sichtbar macht. Ein schlecht vorbereiteter UAT verlängert dagegen den Systemtest, produziert unklare Tickets und zwingt die Projektleitung zu Bauchentscheidungen. Die folgenden Schritte schaffen eine belastbare Grundlage, ohne die Verantwortung des Fachbereichs an ein Tool oder einen Agenten abzugeben.
So läuft ein UAT-Zyklus Schritt für Schritt
Ein UAT-Zyklus funktioniert am besten, wenn jede Phase ein klares Ergebnis liefert. Für einen Order-to-Cash-Prozess eines bayerischen Automotive-Zulieferers könnte der Ablauf so aussehen:
Planung: Der UAT-Plan definiert Scope, Zeitfenster, Key-User, Verantwortliche und Eintrittskriterien. Im Beispiel gehören Auftragserfassung, Verfügbarkeitsprüfung, Lieferung, Faktura und Gutschrift in den Scope. Der Product Owner bestätigt, welche Varianten geschäftskritisch sind.
Vorbereitung: Das Team richtet eine getrennte UAT-Umgebung ein und lädt anonymisierte, produktionsnahe Stammdaten. Kunden, Materialien, Preise und Lieferbedingungen müssen zusammenpassen, sonst testet der Fachbereich Datenfehler statt Prozessverhalten. Für AI-Agenten werden eigene API-Schlüssel und nachvollziehbare Logs verwendet.
Testdesign: Akzeptanzkriterien werden als Given-When-Then-Sätze formuliert. Beispiel: Given ein gültiger Kundenauftrag mit bestätigtem Materialbestand, When der Auftrag freigegeben wird, Then entstehen Lieferung und Preisfindung gemäß den fachlichen Regeln.
Testdurchführung: Key-User führen die Szenarien aus, dokumentieren Ergebnis und Beleg und erfassen Abweichungen zentral. IT und Fachbereich führen täglich eine Triage durch. Behobene Fehler gehen in den Re-Test, nicht direkt in den Status „geschlossen“.
Abschluss: Der UAT-Koordinator erstellt einen Report mit ausgeführten Fällen, Ergebnissen, offenen Defects, Restrisiken und Empfehlungen. AI-Agenten können Logfiles vorsortieren oder fehlende Nachweise markieren. Die Bewertung bleibt beim zuständigen Fachanwender.
Abnahme: Der Fachbereich entscheidet formal über Freigabe, bedingte Freigabe oder Ablehnung. Das Ergebnis wird im Abnahmeprotokoll mit Build, Teilnehmern, Testzeitraum und Restpunkteliste festgehalten.
Checkliste für Planung, Rollen und Testumgebung
Eine UAT-Checkliste muss kopierbar sein und Verantwortlichkeiten sichtbar machen. Die folgenden Blöcke eignen sich als Ausgangspunkt für ein Planungsdokument oder ein Arbeitspaket im Program Management Office.
Rollen und Verantwortlichkeiten
Der Product Owner ist Abnahme-Sponsor und entscheidet nicht allein über fachliche Details. Jeder Fachbereich benennt einen Business Lead, der Anforderungen priorisiert und die Freigabe vorbereitet. Der UAT-Koordinator steuert Termine, Testfortschritt und Nachweise. Der Testmanager verantwortet die Verbindung zu System- und Regressionstests.
Fach-Key-User führen die Szenarien aus und bewerten die Ergebnisse. Für Agent-Komponenten braucht es zusätzlich einen AI-Owner, der Modellversion, Prompts, Tools, Berechtigungen und Ausweichverhalten dokumentiert. IT-Betrieb betreut Schnittstellen, Logs und Reset-Routinen. Datenschutzverantwortliche klären Rollen nach österreichischem Datenschutzrecht und prüfen, ob Testdaten und Protokolle zulässig verarbeitet werden.
Testumgebung und Planungsdokumente
Die UAT-Stage bleibt von Entwicklung und Systemtest getrennt. Ihre Konfiguration soll produktionsnah sein, inklusive Berechtigungen, Schnittstellen und relevanter Batch-Läufe. Stammdaten werden anonymisiert oder synthetisch erzeugt. AI-Agenten erhalten separierte API-Keys, Trace-Level-Logging und klar begrenzte MCP-Tools. Eine dokumentierte Reset-Routine stellt den Ausgangszustand zwischen Testtagen wieder her.
Der UAT-Plan enthält Scope, Rollenmatrix, Zeitfenster, Kommunikationsweg, Defect-Schema, Datenschutzfreigabe und Go-Live-Fenster. Das Wartungsfenster muss mit IT-Betrieb und Fachbereich abgestimmt sein, besonders wenn Schnittstellen oder produktionsnahe Daten betroffen sind.
Testdaten und Entscheidungskriterien
Testdaten brauchen realistische Volumen und konsistente Zeitstempel über drei Quartale, damit Periodenwechsel, Nachbuchungen und Rückstellungen sichtbar werden. Edge-Cases umfassen Nullbuchungen, Doppelbuchungen, Massenbuchungen, fehlende Pflichtfelder und widersprüchliche Stammdaten. Für AI-Outputs werden vorberechnete Sollergebnisse oder zulässige Ergebnisbereiche hinterlegt.
Eintrittskriterien sind Build-Freeze, grüner Smoke-Test, gesetzte Berechtigungen, eingespielte Testdaten und abgeschlossene Schulung. Abbruchkriterien sind defekte Kernprozesse, fehlende Zugriffe, ein AI-Agent mit reproduzierbar unbrauchbaren Antworten oder ein Datenschutzvorfall. Diese Kriterien verhindern, dass Teams wertvolle Fachbereichszeit in eine Umgebung investieren, die noch nicht testbereit ist.
Beispiel-Testfälle für ERP, CRM und AI-Agent-Workflows
Gute Testfälle beschreiben keine Bildschirmtour. Sie bilden eine fachliche Entscheidung ab, nennen die Vorbereitung und definieren, wann das Team abbrechen muss.
ERP-Buchhaltung
Vorbereitung: Ein österreichischer Lieferant, eine Eingangsrechnung mit Skonto, ein 3-Wege-Abgleich zwischen Bestellung, Wareneingang und Rechnung sowie ein Reverse-Charge-Fall werden vorbereitet. Die UID-Prüfung und der Zahllauf-Vorschlag gehören ausdrücklich in den Scope.
Given Bestellung, Wareneingang und Rechnung stimmen fachlich überein, When die Rechnung gebucht wird, Then entstehen die erwarteten Buchungsbeträge, der richtige Steuerfall und ein korrekter Zahllauf-Vorschlag. Ein Abbruch erfolgt bei falschen Beträgen, fehlender UID-Prüfung oder einer nicht erklärbaren Abweichung im Reverse-Charge-Fall.
CRM-Sales-Prozess
Vorbereitung: Eine Opportunity wird einem Account Executive zugewiesen und durchläuft Qualifizierung, Stage-Gates und Forecast-Commit. Die Testdaten enthalten Aktivitäten, Abschlussdatum, Wert und Forecast-Kategorie.
Given alle Pflichtinformationen einer Stage sind vorhanden, When der AE die Opportunity weiterführt, Then wird der nächste Stage-Gate-Status gesetzt, die Aktivität protokolliert und der Forecast-Roll-up korrekt aktualisiert. Der Test bricht ab, wenn der Verantwortliche keinen Trigger erhält, die Aktivität fehlt oder der Roll-up nicht mit dem erwarteten Ergebnis übereinstimmt. Das kann in Dynamics 365 oder Salesforce geprüft werden.
AI-Agent mit MCP-Anbindung
Vorbereitung: Ein Reisekosten-Agent greift über MCP auf ERP, Kalender und Spesenrichtlinie zu. Testdaten umfassen lesbare und unlesbare Belege, zulässige und nicht zulässige Ausgaben, doppelte Einreichungen sowie fehlende Projektinformationen.
Given ein Beleg ist verfügbar und die Richtlinie enthält eine passende Regel, When der Agent den Antrag prüft, Then liefert er ein deterministisches JSON-Schema mit Entscheidung, Begründung, verwendeten Quellen und Eskalationsstatus. Für die AI-Komponente werden eine erlaubte Latenz, eine Halluzinations-Quote kleiner zwei Prozent und eine Pflichtbegründung pro Entscheidung als Akzeptanzkriterien festgelegt. Die Werte müssen im Testplan definiert und anhand einer dokumentierten Stichprobe bewertet werden. Ein Abbruch erfolgt, wenn der Agent unzulässige ERP-Aktionen ausführt, Quellen erfindet, das Schema verletzt oder doppelte Einreichungen nicht erkennt.
| Ebene | Beispielprozess | Schlüssel-Akzeptanzkriterien | Abbruch bei |
|---|---|---|---|
| ERP | Eingangsrechnung und 3-Wege-Abgleich | Beträge, UID-Prüfung, Steuerfall und Zahllauf stimmen | Falsche Buchung oder unklarer Steuerstatus |
| CRM | Opportunity bis Forecast-Commit | Stage-Gates, AE-Trigger, Aktivitätslog und Roll-up stimmen | Fehlende Aktivität oder falscher Forecast |
| AI-Agent | Reisekostenprüfung über MCP | JSON-Schema, Quellen, Begründung, Toleranzbereich und sichere Tool-Nutzung | Halluzination, Schemafehler oder unzulässige Aktion |
Für Teams, die AI in ERP-Prozesse integrieren, ist die Trennung von fachlichem Ergebnis und Modellantwort entscheidend. Ein Agent darf intern variieren, solange die Geschäftsentscheidung, die Begründung und die erlaubten Aktionen innerhalb der vereinbarten Grenzen bleiben. Mehr Kontext zur Einbettung von KI in ERP-Prozesse bietet der Beitrag KI in ERP-Systemen.
Manuell, skriptbasiert oder AI-gestützt im Vergleich
Die passende UAT-Methode richtet sich nach dem Prozessrisiko, der Änderungsrate und der benötigten Beweiskette. Manuelle Tests sind fachlich fundiert, weil Key-User Abweichungen im Arbeitsablauf erkennen, die kein Skript vorsieht. Bei vielen Varianten, wiederholten Releases und grossen Datenmengen werden sie jedoch schnell aufwändig und schwer konsistent zu protokollieren.
Keyword-Driven Frameworks wie Robot Framework oder Tosca bilden wiederverwendbare Bausteine. Dafür braucht es klare Zuständigkeiten: Jemand pflegt die Keyword-Bibliothek, kontrolliert Änderungen an Schnittstellen und Oberflächen und integriert die Ausführung in die CI-Pipeline. Die Methode skaliert besser als Excel-Skripte, verlangt aber dauerhaftes technisches Eigentum und versionierte Testartefakte.
AI-gestützte Testassistenz kann Testschritte aus Anforderungen ableiten, Logfiles zusammenfassen oder bei UI-Änderungen alternative Locatoren vorschlagen. Selbstheilende Locatoren senken den Pflegeaufwand, können jedoch einen falschen Pfad unbemerkt akzeptieren. Automatische Anpassungen dürfen deshalb nur mit sichtbarem Audit-Trail in einen Abnahmenachweis einfliessen. Bei MCP-gestützten Workflows gehört zusätzlich die verwendete Tool-Auswahl und die tatsächlich ausgeführte Aktion in die Evidenz.
| Dimension | Manuell | Skriptbasiert | AI-gestützt |
|---|---|---|---|
| Aufwand für Erstellung und Wartung | Niedriger Einstieg, hoher Aufwand bei Wiederholung | Höherer Aufbau, planbare Wiederverwendung | Geringere Erstellung möglich, laufende Kontrolle nötig |
| Stabilität bei UI-Änderungen | Fachlich fundiert, operativ aufwändig | Stabil bei guter Abstraktion, abhängig von Bibliotheken | Anpassungsfähig, aber mit Risiko falscher Selbstheilung |
| Nachvollziehbarkeit für Audit und DSGVO | Direkt nachvollziehbar, wenn sauber dokumentiert | Sehr gut bei versionierten Artefakten und Logs | Nur belastbar mit Prompt-, Modell-, Tool- und Ergebnisprotokoll |
| Eignung für AI-Agent-Workflows | Gut für fachliche Review und Grenzfälle | Gut für Schema-, Tool- und Regressionstests | Gut für Variantenanalyse, Logauswertung und volatile Oberflächen |
Der praktikable Ansatz ist hybrid. Eine manuelle Erstdurchführung prüft, ob der Prozess fachlich verständlich und die erwartete Entscheidung eindeutig ist. Danach übernimmt ein skriptbasierter Lauf die stabile Regression. AI-Assistenz eignet sich für wechselnde Oberflächen, viele Testdatenvarianten und die Prüfung nicht-deterministischer Antworten innerhalb definierter Toleranzbereiche.
Lizenzkosten und Vendor-Lock-in gehören ebenso in die Entscheidung wie DSGVO-Auskunftspflichten. Für AI-Agenten muss zusätzlich feststehen, welche Modell-, Prompt- und Tooldaten archiviert werden und wer Abweichungen bewertet. Ein Test ohne dokumentierte Beweiskette bietet für kritische Prozesse keinen Mehrwert.
Abnahme, Protokoll und Go-Live-Entscheidung
Am letzten UAT-Tag sollte nicht noch einmal über den Scope verhandelt werden. Der UAT-Koordinator prüft, ob alle vereinbarten Szenarien ausgeführt wurden, der Fachbereich die Ergebnisse bewertet hat und offene Defects einer Severity zugeordnet sind.
Das Abnahmeprotokoll enthält mindestens:
- getesteten Scope und explizit ausgeschlossene Bereiche
- Version oder Build
- Testzeitraum und Teilnehmer
- ausgeführte Testfälle und Ergebnisse
- offene und geschlossene Defects
- Severity-Klassifizierung und Restrisiken
- Anlagen wie Testbericht, Evidenz und Defect-Liste
- formale Freigabeentscheidung
Die Defect-Triage findet in einer kurzen Runde mit Fachbereich, IT und Product Owner statt. Jeder offene Punkt wird als Show-Stopper, Major, Minor oder Known Limitation eingeordnet. Ein Show-Stopper blockiert die Go-Live-Entscheidung oder löst eine formale Eskalation an das Steering Committee innerhalb von 24 Stunden aus. Major- und Minor-Punkte werden gegen Geschäftsrisiko, Workaround und Wartungsfenster bewertet.
Die Go/No-Go-Sitzung braucht vorher festgelegte Stimmrechte, ein Quorum und Entscheidungskriterien. Eine bedingte Freigabe ist möglich, wenn Restpunkte, Verantwortliche, Zieltermine und akzeptierte Risiken schriftlich feststehen. Das Protokoll wird erst verbindlich, wenn Fachbereich und Product Owner unterzeichnet haben. Eine klare Übersicht zu den Voraussetzungen vor Produktionsstart bietet Production Readiness.
Die fünf häufigsten UAT-Fehler und wie sie zu vermeiden sind
1. UAT wird zum verlängerten Integrationstest. Wenn Schnittstellen und technische Basisfunktionen erst im UAT entdeckt werden, fehlt dem Fachbereich die Zeit für echte Geschäftsprüfung. Harte Eintrittskriterien, ein grüner Smoke-Test und ein klar abgegrenzter Scope verhindern diese Verschiebung.
2. Testfälle entstehen erst während der Abnahme. Dann diskutieren Key-User gleichzeitig über Anforderungen, Daten und Ergebnisse. Ein Backlog aus Fachbereichsworkshops sollte bereits in der Designphase entstehen und mit Anforderungen verknüpft werden.
3. Produktionsdaten werden ungeprüft kopiert. Das vermischt Datenschutzrisiko mit fehlender Reproduzierbarkeit. Maskierte oder synthetische Daten bilden die benötigten Geschäftsvarianten ab, ohne unnötig reale Personen- oder Kundendaten in die UAT-Stage zu übertragen.
4. Defects erhalten keine Severity. Eine offene Liste ohne Geschäftsauswirkung hilft weder Entwicklerinnen und Entwicklern noch dem Steering Committee. Das Klassifikationsschema muss direkt mit Eskalation und Go/No-Go verbunden sein.
5. AI-Agent-Outputs werden wie deterministische Funktionen behandelt. Ein exakter Stringvergleich passt nicht zu einem Agenten, der Sprache verarbeitet oder mehrere zulässige Formulierungen erzeugt. Akzeptanzkriterien brauchen ein Toleranzband, eine Stichprobenregel und eine Review-Pflicht pro Lauf. Zusätzlich müssen Quellen, Tool-Aufrufe, JSON-Schema, Begründung und verbotene Aktionen geprüft werden.
Die gemeinsame Ursache dieser Fehler ist fehlende Vorabklärung. Auch bei AI-Komponenten funktioniert UAT nur, wenn Erwartung, Messlatte und Verantwortlichkeit vor dem ersten Lauf schriftlich fixiert sind.
Specialty Tokens unterstützt Unternehmen dabei, AI-Agenten direkt in ERP-, CRM- und Finanzprozesse einzubetten, MCP-gestützte Integrationen sicher zu betreiben und UAT für nicht-deterministische Workflows auditierbar aufzusetzen. Besuchen Sie Specialty Tokens, wenn Sie aus Ihren Akzeptanzkriterien einen produktionsreifen Agenten und einen belastbaren Go-Live-Prozess machen wollen.