User Acceptance Test und Fachabnahme

Im UAT werden End-to-End-Geschäftsprozesse getestet – von der Anmeldung im System bis zur Erstellung von Berichten oder dem Abschluss von Workflows.

• Prozessdurchläufe und Use Cases: Vollständige Abläufe (z. B. Anlegen und Schließen eines Wartungsauftrags) werden anhand realer Beispieldaten geprüft. Dabei werden sowohl Standardfälle als auch kritische Randfälle und Fehlerpfade berücksichtigt.

• Bedienbarkeit (GUI/Usability): Fachanwender bewerten die Benutzeroberfläche auf Verständlichkeit, Ergonomie und Effizienz. Sie geben Feedback zu Navigation, Fehlermeldungen und Gestaltung, um letzte Optimierungen zu ermöglichen.

• Performanceempfinden: Obwohl formale Lasttests oft gesondert stattfinden, fließt hier das subjektive Empfinden über Systemperformance (Ladezeiten, Reaktionsgeschwindigkeit) ein. Ein träges System würde die Akzeptanz mindern.

• Regelwerke und Compliance: Vertrags- oder gesetzlich vorgegebene Kriterien werden überprüft. Beispiele sind Daten- und Sicherheitsrichtlinien (z. B. DSGVO) oder branchenspezifische Standards. Dafür können separate Tests (betrieblich, vertraglich) eingesetzt werden.

• Nicht-funktionale Anforderungen: Aspekte wie Backups, Rollbacks und Systemstabilität im Produktivbetrieb werden oft im Rahmen eines betrieblichen Abnahmetests (Operational Acceptance Test) validiert.

Es empfiehlt sich, eine strukturierte Testfall-Matrix zu erstellen, die Prozesse, Zielkriterien und Abhängigkeiten abbildet.

• Umfangreiches Domänenwissen mitbringen und die abzubildenden Prozesse im Detail kennen. Häufig treten Key-User oder erfahrene Mitarbeiter mehrerer Fachabteilungen als Tester auf.

• Repräsentativ sein: Verschiedene Benutzergruppen (z. B. Servicedesk, Instandhaltung, Verwaltung) sollten vertreten sein, um alle Anwendungsszenarien abzudecken.

• Verantwortung übernehmen: Der Fachbereich definiert die Abnahmekriterien und entscheidet über eventuelle Abnahmeverweigerungen (siehe nächstes Kapitel). In der Regel fungiert ein Projekt-Sponsor oder Facheigentümer als Entscheidungsträger für die UAT-Abnahme.

• In die Testkoordination einbezogen sein: Neben der Ausführung der Tests wirken Fachanwender oft bei der Testfallauswahl mit und bewerten Fehlerfolgen. So kann z. B. der Fachbereich in Absprache mit Testmanagement kritische Testszenarien festlegen].

Das Projektteam unterstützt dabei organisatorisch (z. B. Bereitstellung der Testumgebung, Planung) und stellt sicher, dass die Tester Zugriff auf Anleitungen oder Schulungsunterlagen erhalten. Ein häufiges Problem ist eine unzureichende Endanwender-Einbindung: Fehlen die richtigen Fachtester, können Fehlfunktionen erst spät auffallen und umfangreiche Nacharbeiten erfordern. Eine gute Praxis ist daher, die Tests frühzeitig mit möglichst echten Nutzern anzusetzen und klar definierte Rollen (Fachtestende, Testleitung, technische Ansprechpartner) zu verankern.

• Testplan und Abnahmekonzept: Im Testplan werden Umfang, Ziele, Testumgebung sowie Ein- und Ausstiegskriterien festgehalten. Das Abnahmekonzept definiert, welche Akzeptanzkriterien (fachliche Anforderungen, Erfolgsmetriken) erfüllt sein müssen, damit der Test als bestanden gilt. Dazu werden alle relevanten Anforderungen (Lastenheft, User Stories) analysiert und Testkriterien daraus abgeleitet. Ein früher „Shift-Left“-Ansatz empfiehlt, diese Kriterien schon in der Anforderungsphase nutzerseitig präzise zu formulieren.

• Testfall-Design: Für jeden Geschäftsprozess werden konkrete Testszenarien entwickelt. Dabei helfen Methoden wie Äquivalenzklassentests oder Entscheidungstabellen, um Abdeckung sicherzustellen. Die Fachabteilung und der Testkoordinator wählen gemeinsam die Schlüssel-Use-Cases aus. Aus den Szenarien leitet man einzelne Testfälle ab: Schritt-für-Schritt-Beschreibungen mit Eingaben und erwarteten Ergebnissen. Wesentlich ist, auch kritische oder randständige Abläufe zu berücksichtigen (z. B. Störmeldungen bei Instandhaltung).

• Testdaten und Umgebung: Die Tests sollten in einer produktionsähnlichen Umgebung erfolgen – möglichst dieselben Systeme, Integrationen und Datenformate wie später live. Die Testdaten sollten realistische Betriebsdaten abbilden (z. B. Adressen, Inventardaten, Aufträge). Gegebenenfalls werden Teilmengen aus dem Produktivsystem anonymisiert übernommen. Nur so lassen sich last- und bereichsspezifische Effekte (Performance, Schnittstellenverhalten) wirklich verifizieren.

• Schulung der Tester: Da Fachanwender oft wenig Erfahrung mit formellem Testen haben, lohnt sich eine Einweisung in die UAT-Methodik. Ein kurzes Training zu Testprotokollierung, Fehlerdokumentation oder genutzten Tools erhöht die Effizienz und Qualität der Tests deutlich. Zusätzlich sollte vorab sichergestellt sein, dass alle Tester die neuen Funktionen zumindest überblicksweise kennengelernt haben, etwa im Rahmen von Demo-Workshops.

• Ressourcen und Terminplanung: Im Zeitplan des Projekts muss der UAT mit ausreichendem Puffer eingeplant werden. Üblicherweise werden Phasen für Testausführung, Fehlerbehebung und Retesting separat ausgewiesen. Die Testkoordination legt Deadlines für Teilbereiche fest und stellt sicher, dass technische Ansprechpartner (Entwickler, Administratoren) verfügbar sind.

Eine sorgfältige Dokumentation (versionierter Testplan, Testfälle, Protokolle) ist essenziell. So wird transparent nachvollziehbar, welche Anforderungen bereits überprüft sind und wo eventuell Lücken bestehen. Diese Unterlagen sind später auch wichtige Referenzen für den Live-Betrieb und mögliche Audits.

• Testausführung: Die ausgewählten Tester führen die Testfälle manuell aus – das System verhält sich dabei wie später im Livebetrieb. Sie protokollieren jedes Testergebnis: Ist/Soll-Vergleich, aufgetretene Fehler und Unklarheiten. Moderne Tools (Testmanagement- oder Issue-Tracking-Systeme) unterstützen dabei oft mit vordefinierten Testschritten und -reports. Bei jeder Abweichung wird ein Fehler (Anomalie) erfasst, idealerweise mit Reproduktionsschritten, Screenshots und Kontext\. Dies hilft den Entwicklern bei der schnellen Analyse.

• Fehlerdokumentation und -klassifizierung: Jedes gefundene Problem wird nach Schwere (kritisch, mittel, gering) bewertet. Prioritäten werden vergeben: Blockierende Fehler (z. B. Systemabsturz, Datenverlust) müssen vor Abnahme behoben werden; kleinere Mängel (z. B. UI-Texte) können als „Restfehler“ ins Protokoll und nach der Auslieferung angegangen werden. Ein klassisches Vorgehen ist das fortlaufende Defect-Management: Entwicklerbehebung und anschließender Retest aller behobenen Fehler.

• Kommunikation und Daily-Review: Idealerweise gibt es regelmäßige Koordinationsmeetings (z. B. tägliche Kurz-Meetings) zwischen Testern, Testkoordination und Entwicklerteam. Dort werden die wichtigsten gefundenen Fehler besprochen, Prioritäten gegeben und Eskalationen geklärt. Diese engmaschige Abstimmung beschleunigt die Fehlerbehebung und verhindert Dopplungen. Jeder Fix wird erneut geprüft, bis die Tester das Ergebnis als korrekt bestätigen (Retest). Ein formaler Abschluss der Testphase erfolgt erst, wenn alle definierten Abnahmekriterien erfüllt sind oder verbleibende Restmängel akzeptiert wurden.

• Dokumentation: Parallel zur Fehlererfassung werden alle Testergebnisse in Testberichten dokumentiert. Dabei hält man fest, welche Testfälle erfolgreich waren, welche kritischen Fehler auftraten und welche nach Korrektur neu getestet wurden. Diese Berichte können als Grundlage für das offizielle Abnahmeprotokoll dienen.

Am Ende der Durchführung stehen üblicherweise ein Abschluss-Workshop oder eine Review, in dem das Testergebnis zusammengefasst wird: Stimmen die Geschäftsanforderungen mit dem bisherigen Ergebnis überein? Welche offenen Punkte sind noch relevant? Erst nach dieser finalen Bewertung entscheidet der Fachbereich über die Annahme.

Für die Abnahmeentscheidung müssen klare, messbare Kriterien definiert sein. Diese Abnahmekriterien können aus dem Lastenheft, den User Stories oder einem gesonderten Abnahmekonzept stammen. Sie umfassen funktionale Anforderungen (z. B. „Alle definierten Prozesse können vollständig ausgeführt werden“) sowie nicht-funktionale Vorgaben (z. B. „System ist in 90 % der Tests innerhalb von 2 Sekunden reagierend“ oder „Bedienfehler führen zu klaren Fehlermeldungen“). Die Fachabnahme erfolgt erst, wenn alle Akzeptanzkriterien erfüllt sind.

Wird bei der Prüfung eine kritische Lücke oder ein fehlendes zugesichertes Merkmal festgestellt, kann der Fachbereich die Abnahme verweigern. Beispielsweise darf das System bei Fehlern höchster Klassifikation nicht abgenommen werden. Oft wird definiert, dass nur eine bestimmte Anzahl kleinerer Mängel akzeptabel ist. In der Praxis halten die Tester diese Kriterien in einem Abnahmeprotokoll fest: Dieses Dokument listet alle geprüften Punkte, die Testresultate und sämtliche beanstandeten Mängel auf. Das Protokoll wird von den beteiligten Parteien (Fachbereich, Projektleitung, ggf. Anbieter) unterzeichnet.

In vielen Projekten bildet das erfolgreiche Durchlaufen des UAT einen Meilenstein („Abnahme bestanden“) – es löst vertragliche oder finanzielle Folgeaktivitäten aus. Nach Erfüllung der Kriterien gilt das System als „abnahme­reif“. Erst dann fließen üblicherweise Schulungen, endgültige Datenimporte und der Go-Live-Plan aus.

Fehler, die im UAT entdeckt werden, müssen konsequent behandelt werden. Wichtig ist: Priorisierung und Transparenz. Blocker-Fehler werden sofort der Entwicklung gemeldet und fixiert – solange diese nicht behoben sind, sollte der Abnahmeprozess nicht weiter fortschreiten. Kleinere Fehler werden klassifiziert und im Abnahmeprotokoll als Restmängel dokumentiert. In Abstimmung mit dem Auftraggeber wird entschieden, welche Fehler noch in dieser Phase beseitigt werden müssen und welche nach dem Go-Live umgesetzt werden können.

Abnahmehemmnisse können auch organisatorischer Natur sein (z. B. fehlende Tester, zeitliche Engpässe, instabile Testumgebung). Best Practice ist es, solche Risiken schon in der Planung zu mindern: Bauen Sie einen stabilen Teststand auf und reservieren Sie ausreichend Zeit sowie qualifiziertes Personal für UAT-Aktivitäten. Liegen Widerstände vor (etwa weil Endanwender den Test vermeiden), sollte das Projektleitung klar kommunizieren, dass ohne erfolgreiche Abnahme eine Inbetriebnahme nicht erfolgen kann. Oft hilft es, Testfortschritte sichtbar zu machen (z. B. mit Dashboards oder regelmäßigen Reports), um allen Beteiligten den Nutzen des Prozesses aufzuzeigen.

Ist ein kritischer Fehler nicht kurzfristig behebbar, muss in der Abnahmebesprechung entschieden werden: Entweder wartet man auf eine Korrektur, oder man akzeptiert das Projekt mit einem sogenannten Restfehlereintrag und einem festgelegten Nachbesserungsplan. Letzteres sollte jedoch die Ausnahme sein, da ungelöste Mängel zu großen Betriebsrisiken führen können. Eine saubere Dokumentation aller Abweichungen (Abnahmeprotokoll) ist hier unerlässlich, um später das weitere Vorgehen (Patchen, Wartungssupport) zu strukturieren.

• Klassisches (Wasserfall) Projekt: Hier wird der UAT typischerweise als gesonderte Abschlussphase nach allen technischen Tests (Unit-, Integrations-, Systemtest) durchgeführt. Die Fachtester folgen einem festen Plan und arbeiten lineare Testzyklen ab: Abarbeitung aller Testfälle, Fehlerprotokollierung, Workshops zur Ergebnisauswertung. Die Dokumentation ist formell – inklusive Testbericht und Testabdeckungsmatrix . Dieser Ansatz ermöglicht eine umfassende Transparenz über die abgedeckten Anforderungen, erfordert aber eine sorgfältige Planung und langfristige Verfügbarkeit der Fachanwender. Änderungen in dieser Phase sind aufwändig, daher ist es wichtig, dass das System vor dem UAT möglichst stabil ist.

• Agiles Projekt: Im Gegensatz dazu läuft UAT hier iterativ parallel zu den Sprints. Nach jedem Sprint werden die neu entwickelten Funktionalitäten durch die Fachtester überprüft. Oft findet das UAT in Form von Sprint-Reviews oder Demos statt, ergänzt durch kontinuierlich angepasste Testszenarien. Die Fachtester (z. B. Product Owner, Key-User) arbeiten eng mit Entwicklern zusammen, integrieren ihre Rückmeldungen sofort und erweitern sukzessive den Pool an Testfällen. Dieser agile Ablauf beschleunigt die Fehlerbehebung und minimiert funktionale Abweichungen, erfordert aber eine flexible Organisation (stetige Tester-Verfügbarkeit, häufige Releases). Automatisierungstools für Regressionstests spielen in agilen Projekten eine größere Rolle, um den Aufwand zwischen den UAT-Zyklen zu reduzieren.

In beiden Vorgehensmodellen bleibt die sorgfältige Planung des UAT entscheidend. Moderne Testmanagement- und Kollaborationstools (z. B. JIRA, TestRail) unterstützen unabhängig von der Methodik dabei, Testfälle zu verwalten und Testergebnisse zu tracken.

• Frühzeitige Planung: Definieren Sie Akzeptanzkriterien bereits in der Anforderungsphase und binden Sie UAT-Ressourcen rechtzeitig ein. Vergessen Sie nicht, realistische Zeitfenster und Puffer für Retests einzuplanen.

• Repräsentative Tester: Wählen Sie Fachanwender aus verschiedenen Bereichen mit entsprechendem Know-how als Tester aus. Ihre Praxiserfahrung liefert relevantes Feedback und beschleunigt die Fehlerbehebung.

• Stabile Testumgebung und -daten: Richten Sie für den UAT eine dedizierte, produktionsnahe Umgebung ein. Nutzen Sie reale oder realistische Testdaten, um die tatsächliche Systemperformance und Datenintegrität zu prüfen.

• Strukturierter Testprozess: Nutzen Sie einen detaillierten Testplan mit klaren Szenarien, Testfällen und Erfolgskriterien. Dokumentieren Sie alle Testschritte und -ergebnisse lückenlos, damit auch später nachvollzogen werden kann, was genau geprüft wurde. Ein Testmanagement-Tool kann hier helfen.

• Effektives Fehlermanagement: Priorisieren Sie Fehler nach ihrer Kritikalität] und führen Sie nach jeder Korrektur einen Retest durch. Ein Score- oder Statussystem (Blocker, Major, Minor) stellt sicher, dass vor der Abnahme keine Showstopper übersehen werden.

• Kommunikation und Rollen: Stellen Sie klar definierte Rollen sicher: Ein Test-Lead oder Koordinator steuert den Ablauf, Fachtester führen aus, Entwickler/QA unterstützen bei Unklarheiten. Halten Sie regelmäßige Abstimmungen, um alle Stakeholder auf dem Laufenden zu halten.

• Lessons Learned einbeziehen: Führen Sie am Ende des UATs eine Retro durch: Was lief gut, wo gab es Lücken? Passen Sie Prozesse bei Bedarf an und aktualisieren Sie Testfälle oder Abnahmekriterien für Folgeprojekte.

Mit diesen Best Practices lässt sich der UAT-Prozess in CAFM-Projekten effizient und wirkungsvoll gestalten – so wird sichergestellt, dass das neue System optimal auf die Bedürfnisse der Fachbereiche abgestimmt ist und der Rollout reibungslos gelingt.