CAFM: Teststrategie und Abnahmekriterien

In Anlehnung an etablierte Vorgehensmodelle (z.B. das V-Modell) gliedert sich das Testen in mehrere Phasen bzw. Teststufen. Jede Phase hat einen spezifischen Fokus und baut auf den vorherigen Ergebnissen auf. Wichtig ist eine sinnvolle zeitliche Abfolge: beginne mit isolierten Komponententests und ende mit dem Gesamtsystem und den Endanwendern.

• Modultests (Komponententests): Prüfung einzelner Module oder Funktionen in Isolation. Hier werden z.B. einzelne CAFM-Module (Flächenmanagement, Instandhaltung, Vertragsmanagement etc.) für sich genommen getestet, um sicherzustellen, dass jede Funktionalität in sich korrekt arbeitet. Diese Komponententests finden typischerweise während der Entwicklungs- oder Konfigurationsphase statt und werden oft von Entwicklern oder dem Implementierungspartner durchgeführt. Sie entsprechen dem untersten Level im V-Modell und können auch Unit-Tests umfassen (automatisierte Tests kleiner Code-Einheiten, sofern Eigenentwicklungen vorliegen).

• Integrationstests: Nachdem die Module einzeln funktionieren, wird getestet, ob die Zusammenspiele zwischen den Modulen reibungslos funktionieren. In einem CAFM heißt das z.B., dass das Zusammenspiel von Stammdaten, Flächen, technischen Anlagen und Instandhaltungsprozessen über Modulgrenzen hinweg geprüft wird. Auch Schnittstellentests fallen in diesen Bereich: Datenaustausch mit externen Systemen wie ERP, HR-Systemen oder IoT-Sensoren wird getestet, um sicherzustellen, dass Import/Export und API-Integrationen korrekt funktionieren. Integrationstests bestätigen die Kompatibilität der verschiedenen Software-Komponenten und Services. Sie werden oft vom technischen Projektteam (Entwickler, Integratoren) durchgeführt, teilweise mit Unterstützung von Key-Usern für fachliche Plausibilitätschecks.

• Systemtests: In dieser Phase wird das gesamte CAFM-System in seiner Gesamtheit auf Herz und Nieren geprüft. Das konfigurierte System wird in einer Testumgebung betrieben, die der späteren Produktivumgebung möglichst nahe kommt. Ziel ist zu validieren, dass das CAFM-Gesamtsystem alle festgelegten Anforderungen erfüllt – funktional und auch nicht-funktional. Im Systemtest werden Geschäftsprozesse end-to-end durchgespielt, alle Module zusammen betrachtet und auch Last- und Performance-Tests durchgeführt (z.B. simulierte gleichzeitige Benutzerzugriffe, um zu prüfen, ob das System unter Last stabil und schnell bleibt). Ebenso können Sicherheitstests stattfinden, etwa Prüfung von Berechtigungen und Datenschutz, um Schwachstellen aufzudecken bevor das System live geht. Systemtests erfolgen meist gegen Ende der Implementierungsphase unmittelbar vor der Benutzerabnahme.

• User Acceptance Tests (UAT / Abnahmetests): Die Abnahmetests durch die Anwender bilden den Abschluss der Testphasen. Hier prüfen Key-User und Fachbereichsverantwortliche das System im Praxisbetrieb: mit realistischen Daten und echten Anwender-Szenarien wird validiert, ob die Software aus Sicht der Endnutzer benutzbar ist und die Geschäftsprozesse unterstützt. Die UAT finden typischerweise in einer Beta- oder Vorproduktionsphase statt, wenn das System weitgehend fertig konfiguriert ist. Ziel ist es, die Nutzbarkeit und fachliche Eignung für den täglichen Einsatz nachzuweisen. Die Endanwender testen z.B. typische Workflows (Störmeldungen erfassen, Wartungsaufträge ausführen, Flächenbuchungen durchführen etc.) selbstständig und geben Rückmeldung zu gefundenen Fehlern oder Unstimmigkeiten. Am Ende der UAT entscheidet der Kunde auf Basis dieser Tests, ob das System abgenommen werden kann.

• Regressionstests: Diese Teststufe begleitet eigentlich alle Phasen iterativ. Regressionstest bedeutet, bereits getestete Funktionen erneut zu prüfen, sobald Änderungen am System vorgenommen wurden, um sicherzustellen, dass neue Änderungen keine bestehenden Funktionen unbeabsichtigt beschädigt haben. In einem CAFM-Projekt kommen Regressionstests z.B. nach Fehlerbehebungen zum Einsatz: Nachdem ein Bug gefixt wurde, wird der entsprechende Anwendungsfall nochmal getestet (Nachtest) und zusätzlich geprüft, ob der Fix keine Seiteneffekte hatte. Auch bei Updates oder während eines agilen Projekts mit mehreren Sprints werden kontinuierlich Regressionstests der Kernfunktionen durchgeführt. Idealerweise werden Regressionstests mit hohem Automatisierungsgrad durchgeführt, um Effizienz zu steigern – z.B. durch Skripte, die kritische End-to-End-Szenarien regelmäßig durchspielen.

Die Testphasen müssen nicht streng sequenziell ablaufen – oft überschneiden sie sich. Ein guter Ansatz ist ein iteratives Vorgehen: Module werden einzeln getestet, früh integriert und im Systemverbund geprüft, während parallel bereits erste Key-User-Tests stattfinden. Wichtig ist, dass zum Projektende hin alle Teststufen durchlaufen wurden und jedes Element des Systems auf jeder relevanten Ebene validiert ist.

Um die genannten Testphasen effektiv umzusetzen, wird zu Projektbeginn ein Testkonzept erstellt.

• Testziele und Testumfang: Zunächst definiert der Testmanager gemeinsam mit dem Projektteam, was genau getestet werden soll. Die Testziele leiten sich aus den Projektanforderungen ab – jede funktionale Anforderung sollte durch mindestens einen Testfall validiert werden, ebenso müssen wichtige nicht-funktionale Anforderungen (z.B. Reaktionszeiten, Sicherheitsauflagen) in den Test aufgenommen werden. Die klare Definition von Abnahmekriterien für jede Anforderung bildet die Grundlage für die gesamte Testplanung. So ist messbar festgelegt, wann ein Test erfolgreich ist und wann nicht.

• Testdesign und Testfälle: Auf Basis der Anforderungen werden konkrete Testfälle entworfen. Ein Testfall beschreibt eine zu prüfende Funktion oder Prozesskette, die Eingabedaten, die auszuführenden Schritte und die erwarteten Ergebnisse. Beim Testdesign ist darauf zu achten, sowohl positives Verhalten (korrekte Eingaben, erwartungsgemäße Abläufe) als auch Negativtests (Fehlerfälle, falsche Eingaben, Ausnahmezustände) abzudecken. Das Testkonzept sollte eine strukturierte Testspezifikation enthalten, in der alle vorgesehenen Testfälle dokumentiert sind – idealerweise ausführlich und Schritt-für-Schritt, damit sie von den Testern einheitlich durchgeführt werden können. Beispiele: „Anlegen eines neuen Gebäudestandorts mit allen Pflichtfeldern“, „Durchführung einer Wartungsanfrage von der Meldung bis zum Abschlussbericht“, „Schnittstellenabgleich: Import eines Personalstamms aus dem HR-System“ etc. Für jeden Testfall wird das erwartete Resultat definiert, um später Soll/Ist vergleichen zu können.

• Testdaten: Von zentraler Bedeutung ist die Bereitstellung geeigneter Testdaten. Die Datenbasis im Test muss repräsentativ für den Echtbetrieb sein. In CAFM-Systemen bedeutet dies z.B. eine ausreichende Menge an Stammdaten (Gebäude, Räume, Anlagen, Verträge, Nutzer etc.), Bewegungsdaten (Aufträge, Tickets) und ggf. historische Daten, um realistische Szenarien abzubilden. Fehlen wichtige Daten oder sind sie unvollständig, können viele Funktionen nicht adäquat geprüft werden – tatsächlich scheitern Tests in der Praxis oft an „schlechter Datenverfügbarkeit und -genauigkeit“. Best Practice ist, frühzeitig einen Datenbestand aufzubauen, sei es durch Migration echter Altdaten in die Testumgebung oder durch Generierung von Testdaten, die typische Nutzungsszenarien widerspiegeln. Oft wird ein Pilot-Datenimport durchgeführt, um die Datenmigration zu testen und sicherzustellen, dass alle benötigten Informationen im neuen System vorhanden und korrekt abgebildet sind.

• Testumgebungen: Das Testkonzept beschreibt die benötigten Testumgebungen. In der Regel wird mindestens eine dedizierte Testinstanz des CAFM-Systems eingerichtet, getrennt von der Entwicklungs- und der späteren Produktionsumgebung. Diese Testumgebung sollte der Produktivumgebung möglichst ähnlich konfiguriert sein (gleiche Versionen, Einstellungen, Schnittstellen aktiviert etc.), um realistische Ergebnisse zu erzielen. Gegebenenfalls gibt es mehrere Stufen: z.B. Dev-System (für Entwickler und Modul-Tests), Test-/QA-System (für Integration/System/UAT) und evtl. ein Staging-System für einen finalen Smoke-Test kurz vor Produktion. Wichtig ist auch ein Konzept für Testnutzer und Berechtigungen: Tester (Key-User) benötigen Accounts mit passenden Rollenrechten in der Testumgebung, um alle relevanten Funktionen prüfen zu können. Zudem muss geklärt sein, wie Schnittstellen in der Testumgebung bedient werden (Simulation externer Systeme oder Kopplung an Testinstanzen der Umsysteme).

• Zeit- und Meilensteinplanung: Das Testkonzept integriert den Testprozess in den Projektplan. Es werden Testphasen zeitlich eingeplant, inkl. Puffer für Fehlerbehebung und Wiederholungstests. Typischerweise werden Meilensteine definiert, z.B.: „Modultests abgeschlossen“, „Integrations-Testlauf 1 durchgeführt“, „UAT Start“, „Abnahme erfolgreich“ etc. Zwischen den Phasen sollte ausreichend Zeit für Korrekturschleifen sein, denn erfahrungsgemäß werden in frühen Tests viele Mängel gefunden, die behoben werden müssen, bevor der nächste Testzyklus sinnvoll ist. Auch externe Abhängigkeiten fließen ein: z.B. Verfügbarkeit von Key-Usern für UAT (meist nur in bestimmten Zeitfenstern möglich) oder notwendige Vorarbeiten (Datenmigration muss vor UAT erfolgt sein). Ein realistischer, abgestimmter Testzeitplan beugt Testzeitdruck vor und stellt sicher, dass der Go-Live-Termin nicht gefährdet wird.

Es verbindet fachliche Sicht (Was soll getestet werden? Mit welchen Szenarien?) mit der technischen Sicht (Welche Umgebung, Daten, Tools?). Alle Beteiligten sollten das Testvorgehen kennen, damit klare Erwartungen herrschen, wann und wie getestet wird.

Die Durchführung der Tests erfordert verschiedene Rollen mit klar definierten Verantwortlichkeiten.

Projektleiter (Verantwortlicher, der auch beim Go/No-Go die Entscheidung mitträgt), QA-Team (bei größeren Projekten ein dediziertes Qualitätssicherungsteam für Tests), Steering Committee (Lenkungsausschuss, entscheidet bei Eskalationen, z.B. Verschiebung Go-Live falls Kriterien nicht erfüllt). Das obige Team-Konzept hat sich jedoch bewährt: ein zentraler Testmanager, engagierte Key-User aus den Fachabteilungen, unterstützende Experten vom Dienstleister.

• Manuelle Tests: Die Mehrheit der fachlichen Tests in einem CAFM-Projekt wird manuell durchgeführt. Das heißt, Tester (Key-User oder QA) führen die Testschritte von Hand in der Software aus und prüfen die Ergebnisse. Manuelles Testen eignet sich besonders für explorative Prüfungen der Benutzeroberfläche, für komplexe Abläufe, die schwer zu skripten sind, und für die Abnahmetests, bei denen echte Nutzer das System bedienen. So werden z.B. im UAT Key-User verschiedene Szenarien eigenhändig durchspielen. Funktionale Tests werden in der Regel manuell durchgeführt und liegen in der Verantwortung sowohl der Systementwickler (für technische Tests) als auch des QS-Teams. Vorteile manueller Tests sind Flexibilität und menschliches Urteilsvermögen (der Tester erkennt, ob das Ergebnis fachlich plausibel ist). Der Nachteil ist der höhere Zeitaufwand und die Fehleranfälligkeit, wenn Tests immer wieder manuell wiederholt werden müssen.

• Automatisierte Tests: Wo immer sinnvoll, sollte man Tests automatisieren, um Effizienz und Wiederholbarkeit zu steigern. Automatisierte Tests bedeuten, dass mit Hilfe von Skripten oder Test-Tools Testfälle maschinell ausgeführt und überprüft werden. In CAFM-Projekten bietet sich Automatisierung vor allem für Regressionstests an: Routine-Testfälle, die nach jedem Update oder Fix erneut ausgeführt werden müssen. Mit der richtigen Testsoftware können beispielsweise alle erstellten Testszenarien auf Knopfdruck erneut durchgespielt werden, was viel Zeit spart. Auch Lasttests (Simulieren von z.B. 100 gleichzeitigen Nutzern) und Sicherheitstests (Penetration-Tests, Schwachstellenscans) werden meist mit speziellen Tools automatisiert durchgeführt, da sie manuell kaum leistbar sind. Automatisierung erfordert anfangs mehr Aufwand (Skripterstellung, Tool-Einrichtung), zahlt sich aber aus, sobald Tests mehrfach laufen. Wichtig ist, automatisierte Tests in die Tool-Landschaft zu integrieren (z.B. Continuous Integration) und Wartung einzuplanen, da sich mit jeder Softwareanpassung auch die Testskripte anpassen müssen.

• Explorative Tests: Ergänzend zu den geplanten Testszenarien sollten explorative Tests durchgeführt werden. Exploratives Testen bedeutet, dass erfahrene Tester die Software ohne festes Drehbuch spontan erkunden, um unerwartete Probleme aufzuspüren. Gerade in komplexen Systemen wie CAFM können so versteckte Fehler und Randfälle entdeckt werden, die mit standardisierten Tests schwer auffindbar wären. Ein Key-User könnte z.B. versuchen, ungewöhnliche Bedienfolgen oder Grenzwerte auszuprobieren, um die Robustheit zu prüfen. Exploratives Testen fördert Kreativität und nutzt die Intuition der Tester. Allerdings ersetzt es keine systematischen Funktions- oder Sicherheitstests, da es unsystematisch ist und Lücken haben kann. Es dient eher als zusätzliche Maßnahme, um die Qualität zu erhöhen. In agilen Projekten wird exploratives Testen oft kontinuierlich parallel zur Entwicklung gemacht; in klassischen Projekten bietet es sich am Ende jeder Testphase an (nachdem alle geplanten Tests erledigt sind, schauen die Tester „frei“ ins System, ob ihnen noch etwas auffällt).

Ein ausgewogener Methodenmix ist ideal. Manuelle Tests bringen fachliches Verständnis ein, automatisierte Tests sorgen für Geschwindigkeit und Wiederholbarkeit, explorative Tests erhöhen die Testabdeckung über die geplanten Fälle hinaus. Je nach Projekt können weitere Methoden relevant sein (z.B. Usability-Tests mit Endanwender-Beobachtung, oder Testgetriebene Entwicklung bei Customizing). Das Testkonzept sollte festhalten, welche Methoden wo zum Einsatz kommen.

Ein erfolgreiches Testmanagement stützt sich auf passende Werkzeuge und gründliche Dokumentation.

• Testfälle und Testkatalog: Alle definierten Testfälle sollten zentral erfasst werden, idealerweise in einem Testmanagement-Tool. Ein solches Tool erlaubt es, Testfälle strukturiert zu dokumentieren (Schrittfolgen, erwartetes Ergebnis) und in Testplänen zu organisieren. Der Testmanager legt einen Testkatalog an, der sämtliche Testfälle pro Modul/Prozess enthält. Moderne Werkzeuge (z.B. Azure DevOps Test Plans, HP ALM, Jira Xray etc.) ermöglichen auch eine Versionierung und Wiederverwendung von Testfällen. So kann man auf bewährte Tests aus früheren Projekten zurückgreifen und sie anpassen, was Aufwand spart. Die Testfälle sollten spätestens in der Vorbereitungsphase erstellt sein, damit in der Ausführungsphase darauf zurückgegriffen werden kann. Während der Testdurchführung dokumentieren die Tester zu jedem Testfall, ob er „bestanden“ oder „durchgefallen“ ist, und können bei Letzterem direkt einen Defect (Fehlermeldung) verknüpfen.

• Fehlerprotokolle (Defect-Tracking): Jeder festgestellte Fehler muss nachvollziehbar protokolliert und nachverfolgt werden. Hierfür kommen Bug-Tracking-Systeme zum Einsatz (z.B. Jira, Mantis, Excel-Liste – je nach Projektgröße). Wichtig ist, dass für jeden Defect festgehalten wird: Beschreibung des Problems, Schritte zur Reproduktion, erwartetes vs. tatsächliches Ergebnis, Einstufung der Kritikalität (Schweregrad) und Verantwortlicher für die Behebung. Ein effizienter Fehlermanagement-Prozess umfasst die Nachverfolgung, Analyse und Priorisierung von Defects sowie die Unterstützung bei deren Behebung. Das Testteam triagiert die gefundenen Fehler: kritische Fehler werden sofort an die Entwickler/Dienstleister zur Korrektur gemeldet, geringere Prioritäten werden gesammelt und ggf. später gebündelt behoben. Das Tool sollte den Status jedes Fehlers abbilden (offen, in Bearbeitung, gelöst, getestet, geschlossen) und erlauben, Kommentare oder Anhänge (Screenshots, Logs) zu dokumentieren. Regelmäßige Fehler-Reports helfen, den Überblick zu behalten.

• Statusverfolgung und Reporting: Während der Testphase ist es entscheidend, jederzeit den Testfortschritt im Blick zu haben. Testmanagement-Tools bieten hierfür Dashboards oder Auswertungen: z.B. Anzahl der durchgeführten vs. geplanten Tests, Prozentsatz bestandener Tests, offene kritische Defects etc. Der Testmanager führt oft tägliche/ wöchentliche Test-Statusmeetings durch, in denen gemeldet wird: Wie viele Tests sind erledigt? Welche schweren Bugs wurden gefunden? Dadurch können Engpässe oder Problemfelder schnell erkannt werden. Alle Tester sollten ihren Fortschritt dokumentieren – sei es im Tool oder zur Not in manuell gepflegten Listen – damit eine konsolidierte Sicht entsteht. Am Ende jeder Testphase wird ein Testabschlussbericht erstellt, der den Umfang der Tests, die Ergebnisse und noch offene Punkte zusammenfasst. Diese Dokumentation fließt später ins Abnahmedokument ein und dient auch der Lessons Learned für zukünftige Projekte.

• Weitere Werkzeuge: Je nach Projekt sind weitere Tools sinnvoll, z.B. Testdaten-Management-Tools (um große Datenmengen bereitzustellen oder anonymisierte Echtdaten zu generieren), Automatisierungs-Frameworks (für UI- oder Schnittstellentests), Performance-Test-Tools (z.B. JMeter, Gatling) und Security-Scanning-Tools. Auch Collaboration-Tools (Wikis, Ticketing-Systeme) können Teil der Test-Werkzeugkette sein, um Knowledge Sharing zu unterstützen. Wichtig ist, dass alle Beteiligten Zugriff auf die relevanten Tools haben und im Umgang geschult sind. Der Einsatz von geeigneter Testsoftware kann verhindern, dass Tests auf verstreute Dokumente in Word/Excel ausgelagert werden – stattdessen wird zentral und versioniert gearbeitet, was langfristig effizienter und revisionssicher ist.

Wann gilt ein CAFM-System als „abnahmereif“? Hier kommen die vorab definierten Abnahmekriterien ins Spiel. Sie legen objektiv fest, unter welchen Bedingungen der Kunde das System abnimmt.

• Volle funktionale Abdeckung: Alle im Lastenheft bzw. Anforderungskatalog definierten Funktionen sind implementiert und im Test erfolgreich nachgewiesen. Sollte es Abweichungen geben (z.B. reduzierte Funktionalität in einigen unwesentlichen Punkten), wurden diese schriftlich festgehalten und vom Auftraggeber akzeptiert. Jede Anforderung muss durch Tests als erfüllt markiert sein (traceability von Anforderungen zu Tests). Nicht erfüllte Anforderungen sind ein Abnahmekiller, es sei denn, beide Seiten einigen sich auf Alternativen oder Nachlieferungen.

• Fehlerfreier (stabiler) Betrieb: Das System soll im Test keine kritischen Fehler mehr aufweisen. Insbesondere dürfen keine Fehler vorhanden sein, die die Nutzung der Software unmöglich oder unzumutbar machen (z.B. Systemabstürze, Datenverlust, gravierende Fehlberechnungen). In vielen Projekten wird eine Mängelklassifikation vereinbart (z.B. Fehlerkategorien P1 kritisch, P2 wesentlich, P3 geringfügig). Ein mögliches Abnahmekriterium: „Zum Zeitpunkt der Abnahme sind keine P1-Fehler offen, höchstens X Fehler der Kategorie P2, welche innerhalb von Y Tagen behoben werden; verbleibende P3 sind tolerierbar.“ Fehlerfreiheit heißt praktisch also frei von Showstoppern. Kleinere bekannte Probleme können ggf. per Abnahme unter Vorbehalt (mit Nachbesserungsverpflichtung) toleriert werden, aber alles Schwere muss behoben sein.

• Erfüllung nicht-funktionaler Anforderungen: Neben den Funktionen müssen auch Leistungs- und Qualitätsanforderungen erfüllt sein. Dazu zählen Performance (Antwortzeiten, Verarbeitungsgeschwindigkeit bei bestimmten Lastszenarien), Stabilität (z.B. keine Speicherlecks über eine Woche Dauerbetrieb), Sicherheit (z.B. Rolle-basiertes Berechtigungsmodell greift, keine unautorisierten Zugriffe möglich, Penetrationstest ohne kritische Befunde) und Usability (Benutzeroberfläche in vereinbarter Sprache, Barrierefreiheit falls gefordert, etc.). Der Testmanager achtet darauf, dass auch diese Kriterien früh definiert und überprüft werden – nicht-funktionale Aspekte wie Performance und Sicherheit müssen von Anfang an berücksichtigt werden. Gegebenenfalls werden dafür separate Messungen durchgeführt (Lasttestprotokolle, Sicherheitsaudit-Berichte). Ein CAFM-System gilt nur dann als abnahmefähig, wenn z.B. Performance-Tests unter Volllast bestanden wurden und Sicherheitsprüfungen keine kritischen Lücken offenbaren.

• Datenqualität und Migration: Gerade bei CAFM ist die Datenbasis Teil der Systemqualität. Ein Abnahmekriterium kann sein, dass 100% der benötigten Stammdaten im System erfasst sind (z.B. alle Gebäude/Flächen, Anlagen, Verträge wurden migriert) und deren Qualität geprüft wurde. Dazu gehört, dass Plausibilitätsprüfungen der Daten erfolgen (z.B. keine Flächen ohne Gebäudezuordnung, keine doppelten Raumnummern, vollständige Zuordnung von Anlagen zu Wartungsplänen etc.). Die Datenmigration sollte verifiziert sein: Alle Daten müssen korrekt und vollständig aus dem Altsystem übernommen worden sein. Dies wird durch Abgleiche (Stichproben oder Vollabgleich) nachgewiesen, etwa indem Datensätze aus Alt und Neu verglichen werden. Automatisierte Tools können helfen sicherzustellen, dass nichts verloren ging. Eine Abnahme ist nur sinnvoll, wenn die Daten so vorhanden sind, dass der Betrieb sofort starten kann – unvollständige Daten würden den Nutzen des Systems stark einschränken.

Zusätzlich zu diesen Hauptkriterien können projektspezifische Abnahmekriterien definiert werden, z.B. Compliance-Anforderungen (Erfüllung gesetzlicher Vorgaben, Prüfungsstandards) oder Schnittstellen voll funktionsfähig (alle angebundenen Systeme tauschen Daten wie erwartet). Alle Kriterien sollten messbar und testbar sein (SMART formuliert), damit es im Abnahmeprozess keine Interpretationsspielräume gibt, ob ein Kriterium erfüllt ist oder nicht.

Damit die Abnahmekriterien praktisch überprüft werden können, müssen realistische Abnahmeszenarien definiert werden. Anstatt nur Einzelfunktionen isoliert zu testen, geht es hier um geschäftsprozessorientierte End-to-End-Tests, die das Zusammenspiel aller Komponenten in einem realitätsnahen Kontext zeigen.

• Realistische Anwendungsfälle: Die Testfälle für die Abnahme sollten echten Anwendungsfällen aus dem Alltag entsprechen. Statt abstrakte Einzeltests durchzuführen („Funktion X liefert korrektes Ergebnis Y“), formuliert man z.B.: „Ein Techniker erstellt eine Störungsmeldung, der Disponent wandelt sie in einen Arbeitsauftrag um, führt ihn aus und meldet zurück – das System durchläuft alle Schritte inklusive Benachrichtigungen und Statuswechsel fehlerfrei.“ Solche Prozessketten zeigen, ob das System die Geschäftsabläufe unterstützt. In der CAFM-Praxis könnten Abnahmeszenarien etwa beinhalten: Buchung eines Raums mit anschließendem Serviceauftrag für Bereitstellung, Durchführung einer Wartung von der Planung bis zum Abschluss inkl. Lagerabgang von Ersatzteilen, Jahresabschluss im Vertragsmanagement mit automatischer Indexierung von Mieten, etc. Wichtig ist, dass alle beteiligten Module und Schnittstellen in einem Szenario zusammenspielen.

• Prozessübergreifende Tests: Ein gutes Abnahmeszenario geht oft über einen einzelnen Prozess hinaus. Beispiel: „Umzug einer Abteilung: Flächenmanagement ändert Raumbuchungen, Inventar wird umgezogen (Lager/Assets angepasst), IT-Leistungen werden umgestellt (Ticketsystem), Mitarbeiterdaten werden aktualisiert (Schnittstelle HR).“ Damit wird geprüft, ob das CAFM-System in einem bereichsübergreifenden Vorgang konsistent arbeitet. Interdisziplinäre Szenarien decken Lücken auf, die modularen Tests entgehen.

• Stammdaten-Validierung: Ein spezielles Augenmerk liegt auf den Stammdaten im System. Ein Abnahmeszenario sollte überprüfen, ob alle migrierten Daten korrekt im System angekommen sind und sinnvoll genutzt werden können. Beispielsweise kann ein Testcase lauten: „Öffne Gebäude X, prüfe ob alle 5 Etagen mit korrekten Flächen vorhanden sind; wähle einen Raum und kontrolliere, ob die ihm zugeordneten Anlagen vollständig und mit allen Attributen angezeigt werden.“ Oder: „Starte einen Wartungsauftrag für Anlage Y, prüfe ob die hinterlegten Wartungsintervalle aus den Stammdaten korrekt berücksichtigt werden.“ So eine Stammdaten-Stichprobe in der Abnahme deckt Inkonsistenzen aus der Migration auf. Es bietet sich auch an, Datenreports laufen zu lassen (z.B. alle Räume ohne Fläche, alle Anlagen ohne Kategorie), um Lücken aufzudecken. Die Abnahme erfolgt nur, wenn die Datenqualität den Vorgaben entspricht (ggf. per Daten-Abnahmeprotokoll bestätigt).

• Benutzer- und Berechtigungstests: Ebenfalls sinnvoll in Abnahmeszenarien sind Tests unterschiedlicher Benutzerrollen. Beispielsweise loggt sich ein Hausmeister ins System ein und sieht nur die für ihn relevanten Module/Aufträge, während ein Administrator alle Funktionen hat. Dieser Test stellt sicher, dass das Berechtigungskonzept im echten Leben funktioniert. Auch Workflows mit mehreren Benutzern (z.B. Antrag → Genehmigung) sollten einmal real durchgespielt werden.

Die Definition der Abnahmeszenarien erfolgt idealerweise gemeinsam mit den Key-Usern und Fachbereichen. Diese wissen, welche Situationen im Alltag besonders kritisch oder häufig sind. Solche realitätsnahen Szenarien dienen nicht nur dem Test – sie erleichtern auch die Akzeptanz bei den Anwendern, da sie sehen, dass „ihr“ Prozess im System funktioniert. Oft wird im UAT-Workshop gemeinsam eine Checkliste der Abnahmeszenarien erstellt. Zum Beispiel wurde in einem Leitfaden empfohlen, im UAT reale Szenarien wie das Abschließen eines Arbeitsauftrags vollständig durchzuspielen und die korrekte Datenmigration zu verifizieren. Diese praxisnahen Tests geben allen Beteiligten Vertrauen in das neue System.

Nach Abschluss aller Tests steht die Go/No-Go-Entscheidung an: Wird das System abgenommen und in den produktiven Betrieb überführt (Go-Live), oder nicht?

• Abnahmereport / Abnahmeprotokoll: Zunächst sammelt der Testmanager alle Ergebnisse in einem Abnahmebericht. Dieses Dokument enthält eine übersichtliche Darstellung aller Abnahmekriterien und ob sie erfüllt wurden. Üblich ist ein Abnahmeprotokoll, das Ablauf und Resultate der Abnahmeprüfung dokumentiert. Darin stehen: Gegenstand der Abnahme (System/Version), Datum, Beteiligte Prüfer, durchgeführte Tests/Szenarien und deren Ergebnisse, Feststellungen von Mängeln, Bezug zu den vereinbarten Abnahmekriterien usw. Es sollte außerdem eine Aussage zur Vollständigkeit, Funktionstauglichkeit und Mängelfreiheit des Werks enthalten. Das Abnahmeprotokoll bildet die Entscheidungsgrundlage für den Abnahmeberechtigten (meist der Auftraggeber oder sein Vertreter), die Abnahme zu erklären oder eben zu verweigern.

• Offene Punkte und Mängelklassifikation: Im Abnahmereport wird speziell auf noch offene Mängel eingegangen. Wenn alle Tests 100% erfolgreich waren, umso besser – dann kann die Abnahme sofort erfolgen. In der Praxis gibt es jedoch häufig Restmängel. Diese werden im Protokoll aufgeführt, inklusive ihrer Klassifizierung (Schweregrad) und einer Bewertung, ob sie abnahmekritisch sind oder nicht. Beispielsweise könnte dort stehen: „Fehler Nr. 47: Bericht XY zeigt falsche Summe (Kategorie P3, geringfügig) – akzeptiert, wird im nächsten Patch behoben“. Kritische Fehler (P1) würden vermerkt mit „Abnahmerelevant: Ja“. Falls solche vorliegen, ist die Abnahme gefährdet. Der Testmanager sorgt dafür, dass für jeden offenen Punkt eine Vereinbarung getroffen wird: entweder wird er vor Go-Live behoben oder es gibt einen Nachbesserungsplan (mit Termin und Verantwortlichen). Diese Transparenz ist wichtig, damit keine strittigen Punkte übersehen werden.

• Entscheidungsgremium: Typischerweise wird am Ende ein Abnahmetermin / Go-Live-Meeting mit dem Projekt-Steering Committee oder den Entscheidern durchgeführt. Der Testmanager präsentiert den Abnahmereport, erläutert den Testverlauf, offene Punkte und seine Empfehlung (z.B. „Systems ist abnahmebereit, keine Showstopper mehr vorhanden“ oder „noch kritisch: empfehlen Go-Live um 2 Wochen zu verschieben“). Die Go/No-Go-Entscheidung wird dann von der dafür befugten Person oder Gruppe getroffen – z.B. vom Auftraggeber, vom Lenkungsausschuss oder der Geschäftsleitung, je nach Projektstruktur. Wichtig: Diese Entscheidung sollte dokumentiert werden (im Abnahmeprotokoll oder separaten Beschluss).

• Go mit Auflagen: Ein möglicher Ausgang ist ein „Go“ unter Auflagen, auch vorbehaltliche Abnahme genannt. Das heißt, man entscheidet sich für den Produktivstart, obwohl noch kleinere Mängel offen sind – verbunden mit der Auflage, dass der Dienstleister diese in der Gewährleistungsphase behebt. In so einem Fall wird im Protokoll exakt festgehalten, welche Punkte dies sind und bis wann sie behoben sein müssen. Die Abnahme gilt dann als erteilt, aber der Vorbehalt sichert das Recht auf Nachbesserung. Dieser Fall tritt ein, wenn keine kritischen Fehler offen sind, aber z.B. kosmetische Dinge oder einzelne Berichte noch optimiert werden müssen.

• No-Go (Abnahme verweigert): Wird beschlossen, dass die Abnahmekriterien nicht erfüllt sind, muss der Go-Live verschoben werden. Die Konsequenzen daraus (Verlängerung des Projekts, ggf. Vertragsstrafen oder Nachforderungen) sind im Projektvertrag geregelt. Hier kommt es auch auf eine definierte Eskalation an: Bei Nicht-Abnahme sollte unmittelbar ein Eskalationsplan greifen. Dies kann bedeuten, dass höhere Managementebenen eingeschaltet werden, um zusätzliche Ressourcen oder Entscheidungen herbeizuführen, damit die Probleme behoben werden. Wichtig ist, dass alle Beteiligten wissen: Keine Abnahme ohne erfüllte Kriterien. Es ist besser, den Start zu verschieben, als mit einem nicht abnahmefähigen System live zu gehen.

Als Best Practice sollte der Testmanager bereits im Vorfeld ein klares Bild vermitteln, wie es um die Abnahme steht, sodass die Entscheidung am Ende wenig Überraschung birgt. Idealerweise liegt am Ende ein Abnahmeprotokoll mit Empfehlung der Prüfer vor, ob die Abnahme erteilt, unter Vorbehalt erteilt oder abgelehnt werden soll. Im Abnahme-Meeting wird dies dann offiziell bestätigt und – bei „Go“ – vom Abnahmeberechtigten unterschrieben (Abnahmeerklärung). Bei Anwesenheit des Abnahmeberechtigten kann auch direkt im Protokoll die Abnahmebestätigung vermerkt und gegengezeichnet werden.

In jedem Testprojekt wird es Abweichungen geben – d.h. gefundene Fehler oder Soll/Ist-Differenzen. Der professionelle Umgang damit entscheidet darüber, ob die Qualität am Ende stimmt.

• Fehlermanagement-Prozess: Wie zuvor beschrieben, sollte ein klarer Prozess zur Fehlerbearbeitung etabliert sein. Jeder Fehler wird erfasst, priorisiert und zur Behebung zugewiesen. Die Entwickler oder Konfiguratoren nehmen dann Korrekturen vor. Wichtig ist eine enge Kommunikation zwischen Testern und Entwicklern, um Missverständnisse zu vermeiden (der Entwickler muss den Fehler nachvollziehen können). Regelmäßige Fehlerrunden (Defect-Meetings) mit allen Parteien helfen, den Status aller wichtigen Bugs zu tracken und Engpässe zu adressieren.

• Nachtest (Re-Test): Nachdem ein Fehler behoben wurde, muss der entsprechende Testfall unbedingt nochmals ausgeführt werden, um zu prüfen, ob die Korrektur erfolgreich war. Dieser Vorgang heißt Nachtest. Im Testplan sollte Zeit für Nachtests eingeplant sein. Der ursprüngliche Tester (z.B. der Key-User, der den Fehler fand) sollte verifizieren, dass das Problem wirklich gelöst ist und das Abnahme**kriterium jetzt erfüllt wird. Das Ergebnis des Nachtests wird im Fehlerprotokoll dokumentiert (z.B. Status auf „behoben und getestet“ setzen).

• Regressionstest: Bei jedem behobenen Fehler besteht das Risiko, dass an anderer Stelle etwas unbeabsichtigt kaputt gegangen ist (Seiteneffekt). Daher folgt auf viele Fehlerbehebungen ein Regressionstest verwandter Funktionen: Wenn z.B. ein Problem in der Raumzuordnung behoben wurde, testet man erneut auch Berichte, die Raumdaten auswerten, um sicherzugehen, dass dort noch alles stimmt. Automatisierte Regressionstests sind hier sehr hilfreich – sie können nach jedem neuen Build angestoßen werden und alarmieren, falls etwas, das früher funktionierte, nun fehlschlägt. Regressionstests wurden oben bereits ausführlich behandelt; im Kontext von Abweichungen sind sie Teil der Korrekturschleife.

• Korrekturschleifen und Testzyklen: Größere Projekte durchlaufen oft mehrere Testzyklen. Ein typisches Vorgehen: Testzyklus 1 (erste vollständige Testdurchführung aller Fälle) deckt zahlreiche Fehler auf. Danach folgt eine Korrekturschleife: Entwickler beheben Fehler, Daten werden bereinigt, Prozesse angepasst. Dann startet Testzyklus 2, in dem erneut getestet wird – nicht nur die Nachtests, sondern oft auch weitere Fälle oder erweiterte Tests. Mit jedem Zyklus sollten weniger neue Fehler auftreten, bis man am Ende nahe an 0 kritischen Bugs ist. Diese Iterationen erfordern Disziplin und sollten im Zeitplan vorgesehen sein. Die Tester müssen eventuell monotone Wiederholungstests durchführen – hier zahlt sich Automatisierung wiederum aus, um menschliche Ermüdung zu reduzieren.

• Change Management bei Abweichungen: Manche Abweichungen entpuppen sich als Änderungswünsche (Change Requests) – also der Test deckt auf, dass ein gewünschtes Verhalten gar nicht spezifiziert war. In solchen Fällen muss das Änderungsmanagement greifen (Bewertung, Auswirkung auf Abnahme?). Kleinere Changes können ggf. noch umgesetzt werden, größere werden meist aus der aktuellen Abnahme ausgeklammert und später nachgezogen. Wichtig ist Transparenz: Alle Beteiligten sollen wissen, welche Abweichungen noch behoben werden und welche akzeptiert oder verschoben wurden.

"Finde den Fehler früh, behebe ihn gründlich, und lerne aus ihm." Jeder gefundene Fehler ist eine Chance, das System robuster zu machen. Durch konsequentes Nachtesten und Regressionstesten stellt man sicher, dass am Ende keine bekannten Mängel übersehen wurden. So wird das System Schritt für Schritt in Richtung Abnahmequalität gebracht.

Gerade in größeren Organisationen und formalisierten Projekten ist die Dokumentation der Abnahme von großer Bedeutung – nicht nur rechtlich, sondern auch um später nachvollziehen zu können, was getestet wurde.

• Abnahmeprotokoll: Wie oben erwähnt, ist dies das zentrale Dokument, das den Abnahmevorgang festhält. Es sollte mindestens eine Checkliste der vereinbarten Abnahmekriterien und deren Erfüllungsstatus enthalten. Außerdem werden empfehlenswerterweise folgende Punkte aufgeführt:

• Identifikation des Systems (Produktname, Version, Modulumfang) und ggf. der Umgebung.

• Prüfer und Beteiligte: Wer hat die Abnahmeprüfung durchgeführt? (Namen, Rollen von Kunden- und Lieferantenseite).

• Datum/Uhrzeit der Abnahmeprüfung (Beginn und Ende).

• Geprüfte Szenarien/Eigenschaften und Zuordnung zu Abnahmekriterien (welche Tests deckten welche Anforderungen ab).

• Art der Prüfungen: z.B. manuelle Tests, Inspektion, Toolgestützte Messungen – zur Nachvollziehbarkeit.

• Ergebnisse der Prüfungen: pro Kriterium/Szenario, bestanden/nicht bestanden, Befund bei Nicht-Bestehen.

• Bewertung der Ergebnisse: Einschätzung der Relevanz der Befunde für die Abnahme (gab es Showstopper? Können wir trotzdem live gehen?).

• Offene Punkte/Nacherfüllung: Liste etwaiger Mängel, die noch behoben werden müssen, inkl. Verantwortlichkeiten und Fristen.

• Nicht geprüfte Kriterien: Falls irgendetwas aus Zeitgründen oder wegen fehlender Voraussetzungen nicht getestet werden konnte, muss das hier vermerkt sein.

• Vereinbarung zu weiteren Prüfungen: Wenn Nachtests geplant sind (z.B. „Performance-Test wird in KW X nachgeholt“), gehört das hier hinein.

Im Idealfall enthält das Abnahmeprotokoll am Ende eine Empfehlung der Prüfer, ob das System abgenommen werden soll, ggf. mit Auflagen. Ist der Abnahmeberechtigte beim Prüftermin anwesend, kann er direkt im Protokoll die Abnahmebestätigung unterschreiben. Andernfalls erfolgt die schriftliche Abnahmebestätigung separat, verweist aber auf das Protokoll.

• Freigabedokumente: Neben dem Protokoll als Prüfungsdokument sollte eine formale Abnahmeerklärung bzw. Freigabeerklärung vorliegen, gerade aus rechtlicher Sicht. Darin erklärt der Auftraggeber, dass er das Werk annimmt (ggf. unter genannten Vorbehalten). Dieses Dokument wird i.d.R. vom Auftraggeber unterschrieben. Es kann Teil des Abnahmeprotokolls sein oder ein separates Schreiben. Bei einer Go/No-Go-Entscheidung im Lenkungsausschuss kann z.B. ein Protokollauszug dienen, in dem die Entscheidung festgehalten ist (inkl. Stimmen, falls abgestimmt wurde).

• Testdokumentation archivieren: Alle während der Tests erstellten Dokumente sollten aufbewahrt werden: Testpläne, die detaillierten Testfälle mit Soll/Ist-Ergebnissen, Fehlerlisten mit Status, Zwischenberichte, E-Mails zu Absprachen etc. Diese Unterlagen bilden den Nachweis der Sorgfalt und können bei späteren Fragen (oder Audits) zeigen, dass die Einführung sauber getestet wurde. Idealerweise wird ein zentrales Ablage-System genutzt (Projektlaufwerk, DMS oder das Testmanagement-Tool selbst). Wichtig ist die Revisionssicherheit: Die Dokumente sollten unveränderbar archiviert oder versioniert sein, sodass im Nachhinein nicht „geschönt“ werden kann. Manche Unternehmen erstellen einen Abnahmeordner (physisch oder digital), der alle relevanten Dokumente zusammenführt.

• Schulungs- und Betriebsdokumentation: Zwar nicht direkt Teil der Testdoku, aber eng verknüpft mit Abnahme: Häufig wird gefordert, dass Benutzerdokumentation und Schulungsnachweise vorliegen, bevor produktiv gegangen wird. In Abnahme-Workflows – insbesondere bei Software für viele Nutzer – kann ein Kriterium sein, dass die Endanwender geschult wurden. Entsprechend sollte auch dokumentiert sein (z.B. in einer Teilnehmerliste), dass die Key-User oder Anwender eine Einweisung erhalten haben. Auch das fließt manchmal ins Abnahmepaket mit ein, da ein gut geschultes Team Voraussetzung für den erfolgreichen Betrieb ist.

• Abnahme der Datenmigration: Bei CAFM-Einführungen ist es zudem üblich, ein separates Daten-Abnahmeprotokoll zu erstellen, in dem die Vollständigkeit der migrierten Bestandsdaten bestätigt wird. Darin könnte stehen: „Alle Flächen nach Gebäudeplan erfasst, Abgleich mit Bauzeichnungen am [Datum] durchgeführt, i.O.“ oder „Anlagenlisten aus Excel importiert, Stichprobe 10% durchgeführt, dabei 2 Fehler korrigiert, jetzt i.O.“. So ein Dokument schafft Vertrauen und ist später Gold wert, falls jemand die Datenqualität anzweifelt.

Bei Teststrategien in CAFM-Projekten treten immer wieder ähnliche Stolpersteine auf.

• Unklare Anforderungen: Wenn Anforderungen vage bleiben oder erst spät präzisiert werden, ist es kaum möglich, gute Tests zu schreiben. Best Practice: Von Anfang an auf Testbarkeit der Anforderungen achten. Der Testmanager sollte früh mit den Fachbereichen zusammenarbeiten, um implizite Erwartungen explizit zu machen – z.B. durch Fragen wie „Wann ist dieser Prozess für Euch erfolgreich abgeschlossen?“. Jedes Requirement braucht messbare Abnahmekriterien. Gegebenenfalls hilft die Methode der Akzeptanzkriterien aus dem Requirements Engineering: Pro User Story wird definiert, wie geprüft wird, dass sie erfüllt ist. Dadurch gibt es Klarheit, was im Test bewiesen werden muss. Unklare Punkte am besten in Workshops klären oder als Risiken eskalieren, bevor die Entwicklung beginnt. Merke: Eindeutige Anforderungen = effiziente Tests = weniger Streit bei Abnahme.

• Unvollständige oder schlechte Testdaten: Oft stellt sich erst im Test heraus, dass wichtige Daten fehlen oder unplausibel sind – dann schlagen Tests fehl, obwohl die Software an sich funktioniert. Lösung: Datenqualität früh sichern. Möglichst bereits zu Testbeginn einen realitätsnahen Datenstand herstellen. Das heißt Altdaten aufbereiten (Duplikate entfernen, Felder bereinigen etc.) und importieren, gegebenenfalls Dummy-Daten ergänzen, wo echte fehlen. Ein Data Audit vor der Migration (Datenqualitätsprüfung) hilft. Zudem sollte man Testdaten generieren, um Grenzfälle abzudecken (z.B. ein Gebäude mit extrem vielen Räumen, um Performance zu testen). Falls Testdaten nicht alle Sonderfälle abdecken, zumindest dokumentieren, was nicht geprüft werden konnte. Tipp: Ein kleiner Pilot-Migrationstest (z.B. 10% der Daten migrieren und prüfen) kann früh Aufschluss über Datenprobleme geben, die man dann vor dem großen UAT behebt.

• Komplexe Testumgebung und Schnittstellen: In CAFM-Projekten hängt vieles an Schnittstellen – doch in der Testumgebung stehen evtl. noch nicht alle Fremdsysteme bereit. Oder die Testumgebung unterscheidet sich von Produktion (falsche Konfiguration, geringere Leistung). Empfehlung: Eine möglichst produktionsnahe Testumgebung aufsetzen und Schnittstellen früh testen, notfalls mit Simulationsdaten. Bei komplexen Integrationen kann es sinnvoll sein, eine separate Schnittstellen-Testphase einzuplanen, in der gezielt nur die Datenaustauschprozesse geprüft werden (z.B. Import von Personaldaten, Export an SAP). Dokumentiere Abweichungen in der Testumgebung (z.B. „Mailversand erfolgt in Test nicht, da kein SMTP – manuell geprüft“), um die Ergebnisse richtig einordnen zu können. Wenn die Testumgebung leistungsschwächer ist, dann Performance-Tests ggf. erst auf Staging/Prod durchführen. Wichtig: Environment-Setup ist Teil des Testkonzepts – investiere genug Zeit, um alle Systeme testfähig zu haben, sonst kostet dich die Fehlersuche (liegt es an der Software oder nur an der Testumgebung?) viel Nerven.

• Testzeitdruck: Ein sehr häufiges Problem ist, dass die Testphase am Ende unter massivem Zeitdruck steht. Vielleicht war die Entwicklung in Verzug, vielleicht wurde der Aufwand unterschätzt – jedenfalls fühlen sich viele Tester gehetzt. Dann droht die Gefahr, dass Tests oberflächlich werden oder Fehler übersehen werden. Best Practices: Realistisch planen – mindestens 20% des Projektaufwands für Tests einplanen. Das Management überzeugen, dass Puffer nötig sind (z.B. wenn möglich flexibles Go-Live-Fenster statt fixem Stichtag). Früh testen statt alles am Schluss: In agilem Kontext ohnehin kontinuierlich, aber auch in Wasserfall-Projekten kann man z.B. nach jedem Modul ein kleines Testintervall einschieben. So verteilt sich die Last. Wenn es eng wird: Priorisieren! Lieber kritischste Abläufe vollständig testen, als alles nur halbherzig. Auch hilfreich: Zusätzliche Tester mobilisieren (z.B. aus Fachbereichen mehr Key-User temporär abstellen) – aber Achtung Einarbeitungszeit. Eine lehrreiche Geschichte aus ERP-Projekten: Wurde Testmanagement vernachlässigt, endete es oft in „16-Stunden-Tagen kurz vor Go-Live, in denen zentrale Fehler in letzter Sekunde gelöst wurden“. Diese Nachtschichten lassen sich vermeiden durch strukturierte, verteilte Tests und ein wenig Mut, bei Bedarf den Zeitplan zu strecken.

• Mängelflut und kein Überblick: Manchmal prasseln in der Testphase so viele Fehlermeldungen herein, dass das Team den Überblick verliert oder die Nerven. Lösung: Strenges Defect-Management und Kommunikation. Also: Fehler klassifizieren (was ist wirklich wichtig?), tägliche Bug-Review-Meetings, geordnetes Abarbeiten nach Priorität. Transparenz im Team schaffen, wer woran arbeitet. Und auch mal Erfolge kommunizieren („Wir haben heute 10 von 12 kritischen Fehlern gelöst!“) zur Motivation. Bewährt hat sich, einen „Defect-Manager“ zu benennen (oft der Testmanager), der nichts anderes tut, als den Fehlerprozess zu koordinieren – so gehen keine Tickets unter. Notfalls Fehlermanagement an ein spezielles Tool koppeln, das automatisiert Erinnerungen schickt etc. Ziel: Am Ende bleiben keine „vergessenen“ Bugs übrig.

• Ändernde Anforderungen / Scope Creep: Gerade längere Projekte erleben es: Während getestet wird, kommen neue Wünsche oder Änderungen vom Fachbereich. Das kann die Abnahme gefährden, wenn plötzlich neue Funktionen gefordert werden. Empfehlung: Klare Scope-Disziplin in der Testphase. Änderungen, die nicht absolut kritisch sind, sollten nach Möglichkeit nach dem Go-Live eingeplant werden (als Phase 2). Alles, was die Abnahme hinauszögert, kritisch hinterfragen: Brauchen wir das jetzt oder kann der Betrieb auch ohne starten? Hier muss das Projektmanagement streng sein. Natürlich sollen schwerwiegende Lücken nicht ignoriert werden, aber oft neigen Anwender dazu, während des UAT „Gold-Plating“-Wünsche zu äußern. Diese muss man managen. Ein formalisiertes Change Request Verfahren hilft, damit die Testphase nicht ausufert.