CAFM: Systemtest/Konfigurationstest

Ein CAFM-Projekt durchläuft mehrere Teststufen; der System-/Konfigurationstest ist darin später angesiedelt und unterscheidet sich deutlich von frühem Komponententest bis hin zum abschließenden Abnahmetest.

Während z. B. Integrationstests sicherstellen, dass einzelne Komponenten und Schnittstellen technisch korrekt zusammenspielen, betrachtet der System-/Konfigurationstest die Gesamtanwendung in einer Umgebung, die der Produktion möglichst ähnlich ist. Hierbei wird geprüft, ob alle Module zusammen das liefern, was die Nutzer benötigen. Im Gegensatz zum nachfolgenden Abnahmetest (UAT), bei dem der Schwerpunkt auf der Geschäftsakzeptanz durch Endnutzer liegt, ist der Systemtest meist durch das Implementierungsteam organisiert. Er dient als interne Qualifikationsprüfung des Systems vor Übergabe an die Fachanwender. Ein weiterer Unterschied zum UAT: Im Systemtest können auch technisch anspruchsvolle Tests (z. B. Lasttests, Sicherheitstests) durchgeführt werden, wohingegen der UAT vor allem die Alltagstauglichkeit und Bedienbarkeit im Fokus hat.

• Systemfunktionalitäten: Alle relevanten Funktionen und Geschäftsprozesse des CAFM/IWMS/CMMS-Systems müssen end-to-end getestet werden. Dies beinhaltet z. B. die Kernmodule wie Flächenmanagement, Instandhaltungsplanung, Helpdesk/Ticketing, Raumbuchung, Vertragsverwaltung usw. Es wird kontrolliert, ob jede Funktion gemäß fachlicher Spezifikation arbeitet und erwartete Ergebnisse liefert (Beispiele: erzeugt die Wartungsplanungs-Funktion die richtigen Wartungsaufträge? Werden Flächen korrekt summiert und ausgewertet?).

• Konfigurationsparameter: CAFM-Systeme bieten meist zahlreiche Konfigurationsmöglichkeiten (z. B. Schwellwerte, Zuständigkeiten, Eskalationszeiten, Systemschalter zur Feature-Aktivierung). Im Test ist zu prüfen, ob diese Konfigurationsparameter wie vorgesehen wirken. Beispielsweise könnte ein Parameter die Eskalationslogik von Tickets steuern – der Test würde verschiedene Einstellungen durchspielen und sicherstellen, dass die Ticket-Workflows entsprechend eskalieren. Alle kundenspezifisch gesetzten Optionen (Customizing) sind zu verifizieren, damit keine Fehleinstellungen in Produktion gelangen.

• Workflows und Prozesse: Moderne CAFM/IWMS-Systeme erlauben das Abbilden von Workflows, etwa für Service-Tickets oder Genehmigungsprozesse. Diese hinterlegten Arbeitsabläufe müssen Schritt für Schritt getestet werden. Ein Testfall kann z. B. ein komplettes Ticket vom Eingang bis zum Abschluss durchlaufen (mit allen Zwischenstatus, Benachrichtigungen und Verantwortlichkeiten), um sicherzustellen, dass der Workflow wie definiert funktioniert – inkl. Abzweigungen für Sonderfälle (Weiterleitung, Eskalation bei Fristüberschreitung etc.). Gleiches gilt für Wartungsprozesse (z. B. Prüfung, ob ein Instandhaltungsauftrag nach dem definierten Zyklus automatisch erzeugt und an den richtigen Bearbeiter zugewiesen wird).

• Benutzeroberfläche (GUI): Die UI-Elemente und Masken des Systems sind ebenfalls Testgegenstand. Hier prüft man z. B., ob Formulareingaben korrekt funktionieren, alle erforderlichen Felder vorhanden sind und Fehlermeldungen bei fehlerhaften Eingaben angezeigt werden (Details zur GUI-Validierung – Responsivität, Usability, Barrierefreiheit – siehe weiter unten). Auch die sprachliche Anpassung (Lokalisierung), Firmenlogos oder Farbschemas der UI, soweit konfiguriert, werden kontrolliert. Insgesamt wird sichergestellt, dass die Oberfläche den Erwartungen der Benutzer entspricht und konsistent ist.

• Rechte und Rollen: CAFM-Systeme haben komplexe Berechtigungskonzepte, um Daten- und Funktionszugriffe je nach Nutzerrolle zu steuern. Im Test wird überprüft, ob diese Rechte korrekt eingerichtet sind. Jeder Benutzer(-rolle) darf nur die Daten sehen und Aktionen ausführen, die ihm laut Konzept erlaubt sind. Beispielsweise sollte ein Sachbearbeiter keine Admin-Funktionen nutzen können; ein externer Dienstleister darf nur ihm zugeordnete Objekte sehen. Testfälle hierzu beinhalten das Anmelden mit unterschiedlichen Rollenprofilen und Prüfen, ob Menüpunkte, Module und Datensätze entsprechend ein- oder ausgeblendet sind. (So müssen bei gesperrten Funktionen die zugehörigen Menüeinträge ausgeblendet oder deaktiviert sein.) Dieser Bereich ist kritisch, um Datenschutz und Datenintegrität sicherzustellen.

• Datenvalidierungen und Geschäftsregeln: Ein weiterer Testgegenstand sind alle hinterlegten Datenprüfungen. CAFM-Systeme verwalten umfangreiche Daten (z. B. Stammdaten von Anlagen, Verträgen, Flächen) – daher sind Validierungsregeln (Pflichtfelder, Wertebereiche, Plausibilitätsprüfungen) essentiell. Im Test werden Eingaben an den Formularen mit gültigen und ungültigen Werten ausprobiert, um sicherzustellen, dass falsche Eingaben abgefangen und die vorgesehenen Fehlermeldungen angezeigt werden. Ebenso werden komplexere Geschäftsregeln geprüft: etwa, ob das System konsistente Beziehungen erzwingt (z. B. kann ein Wartungsauftrag nur abgeschlossen werden, wenn ein Prüfprotokoll hinterlegt wurde – solche Abhängigkeiten müssen im Test auffallen, falls sie nicht greifen). Ziel ist, die Datenqualität und Regelkonformität im System zu gewährleisten.

Jedes CAFM-/IWMS-System wird an die individuellen Bedürfnisse des Unternehmens angepasst. Dennoch gibt es einige typische fachliche Objekte und Module, die in nahezu jedem CAFM-Projekt eine Rolle spielen und daher im Konfigurationstest besonders betrachtet werden sollten:

• Flächenstrukturen: Das Abbilden der Liegenschafts- und Gebäudestruktur (Standorte, Gebäude, Etagen, Räume) ist ein Grundpfeiler von CAFM-Systemen. Hier testet man zum einen die Hierarchie und Verknüpfung dieser Objekte – z. B. ob Flächenzahlen korrekt von Raum- auf Gebäudeebene aggregiert werden, ob Raumlisten einem Gebäude zugeordnet sind usw. –, zum anderen die Umsetzung etwaiger Flächenberechnungsnormen. Ein typischer Testfall könnte prüfen, ob sich Flächenänderungen in einem Raum korrekt auf die Summenflächen des Geschosses und Gebäudes auswirken. Auch Importe von CAD-Plänen mit Flächen müssen validiert werden (kommen alle Räume an, sind die IDs korrekt?). Fehler in der Flächenstruktur wirken sich meist massiv auf Berichte und Auswertungen aus, daher ist hier besondere Sorgfalt geboten.

• Ticket- und Service-Workflows: Die meisten CAFM-Systeme enthalten ein Helpdesk- oder Ticketmodul für Störmeldungen, Service Requests etc. Ein Ticket-Workflow durchläuft oft verschiedene Status (offen, in Bearbeitung, erledigt, geschlossen) und kann automatisierte Benachrichtigungen oder Eskalationen beinhalten. Im Test werden daher typische Tickets simuliert: z. B. meldet ein Nutzer einen Defekt, das System generiert ein Ticket, weist es der zuständigen Stelle zu, verschickt E-Mails an Techniker, eskaliert nach X Stunden an den Vorgesetzten, wenn es nicht bearbeitet wurde, usw. Jeder Schritt wird verifiziert, um sicherzustellen, dass kein Ticket „hängenbleibt“ und die Bearbeitungsfristen gemäß Vereinbarungen (SLAs) eingehalten werden. Darüber hinaus wird geschaut, ob der Endanwender den Bearbeitungsstand in einem Self-Service-Portal verfolgen kann, sofern vorgesehen. Ziel: Das Ticketsystem soll reibungslos funktionieren, damit im Echtbetrieb keine Meldungen verloren gehen oder zu langsam bearbeitet werden.

• Wartungszyklen: CAFM/CMMS-Lösungen dienen häufig der Verwaltung von Wartungs- und Inspektionsplänen für technische Anlagen. Ein zentrales Testobjekt sind daher die hinterlegten Wartungszyklen und -termine. Es wird geprüft, ob das System entsprechend der Konfiguration automatisch Wartungsaufträge generiert (z. B. monatliche Prüfung der Aufzüge, jährliche Wartung der Klimaanlage) und diese den richtigen Teams zuweist. Tests können z. B. den Zeitraum vorspulen (Datum simulieren), um auszulösen, dass ein Wartungsauftrag fällig wird, und dann kontrollieren, ob der Auftrag erscheint und alle Daten (Anlagendetails, Checklisten) korrekt befüllt sind. Auch Ausnahmen werden getestet: Was passiert, wenn eine Wartung verschoben wurde? Berechnet das System das nächste Fälligkeitsdatum richtig? Werden Abhängigkeiten zwischen Wartungs- und Prüfterminen berücksichtigt? Diese Tests stellen sicher, dass im operativen Betrieb keine Wartung vergessen wird und die Betreiberpflichten erfüllt werden.

• Vertragsobjekte: Im Facility Management gibt es zahlreiche Verträge (Mietverträge, Wartungsverträge, Dienstleistungsverträge), die oft im CAFM-System verwaltet und überwacht werden. Typische Vertragsobjekte sind z. B. Mietflächen mit Mietkonditionen, Laufzeiten, Kündigungsfristen oder Wartungsverträge mit Service-Level-Vereinbarungen. Im Test wird überprüft, ob alle relevanten Vertragsdaten korrekt erfasst und ausgewertet werden: z. B. ob das System rechtzeitig Vertragsablaufwarnungen generiert (damit Fristen nicht versäumt werden), ob Kosten automatisch periodisch verbucht werden, oder ob eine Änderung (z. B. Indexmietanpassung) richtig berechnet wird. Ein Beispiel-Testfall: Ein Vertrag hat eine jährliche Verlängerungsklausel – simuliert man das Erreichen des Enddatums, muss das System alarmieren und ggf. den Vertrag als verlängert markieren, falls keine Kündigung erfolgt. Solche Tests verhindern böse Überraschungen, etwa ungewollt verlängerte Verträge oder versäumte Kündigungen.

Diese genannten Objekte sind domänenspezifisch für CAFM/IWMS-Projekte. Natürlich müssen neben ihnen auch alle anderen, ggf. projektspezifischen Komponenten getestet werden – doch gerade bei Flächen, Tickets, Wartung und Verträgen zeigt die Erfahrung, dass hier häufig Konfigurationsfehler passieren (z. B. falsche Zuordnungen, unvollständige Regeln), weshalb sie besondere Aufmerksamkeit im Test verdienen.

Testdurchführung: System- und Konfigurationstests können sowohl manuell als auch automatisiert erfolgen. In der Praxis startet man oft mit manuellen Tests: Ein Tester oder Key-User klickt sich dabei durch die Anwendung, führt definierte Testschritte aus und prüft die Ergebnisse. Manuelle Tests haben den Vorteil der Flexibilität – ein geübter Tester kann ad-hoc auf Auffälligkeiten reagieren –, sind aber zeitaufwendig und fehleranfällig, gerade wenn viele Wiederholungen nötig sind. Zum Beispiel kann ein Testskript 20 Tickets anlegen und prüfen schneller durchführen als ein Mensch dies manuell könnte. Zudem können menschliche Fehler auftreten (Schritte übersehen, falsche Eingaben).

Automatisierte Tests hingegen setzen spezielle Tools oder Skripte ein, um Testfälle ohne manuelles Eingreifen maschinell abzuarbeiten. Die Bandbreite reicht von einfachen Skripten, die z. B. über eine API Funktionen prüfen, bis hin zu kompletten UI-Tests mit Tools wie Selenium, die Benutzeraktionen simulieren. Automatisierung bringt insbesondere bei Regressionstests große Vorteile: Einmal entwickelte automatische Tests können bei jeder neuen Konfigurationsversion oder jedem Software-Update wiederholt ablaufen und so schnell zeigen, ob frühere Funktionen noch einwandfrei arbeiten[1]. Insbesondere in agilem Vorgehen mit häufigen Anpassungen lohnt sich dies, um die Qualität über Releases hinweg zu sichern[2].

In CAFM-Projekten war die Testautomatisierung lange Zeit eher spärlich vertreten – viele Tests wurden klassisch manuell durchgeführt. Mit dem Aufkommen moderner Tools gibt es jedoch heute zahlreiche Möglichkeiten, auch Oberflächentests und End-to-End-Tests zu automatisieren. So können wiederkehrende Abläufe (z. B. das Anlegen eines neuen Mietvertrags und Prüfen der Berichte) skriptgesteuert getestet werden. Toolunterstützung kommt auch im Testmanagement zum Einsatz: Testfallverwaltungs-Werkzeuge (z. B. Jama, Polarion oder im einfachsten Fall Excel) helfen, Tests zu planen und die Ergebnisse zu dokumentieren; Bug-Tracking-Systeme (wie Jira, Bugzilla etc.) unterstützen bei der Erfassung und Nachverfolgung gefundener Fehler (siehe unten). Entscheidend ist, dass das gewählte Vorgehen zum Projektkontext passt: Bei einer einmaligen CAFM-Einführung ohne regelmäßige Releases kann man mit überwiegend manuellen Tests auskommen. Ist jedoch abzusehen, dass das System laufend erweitert wird (neue Module, kontinuierliche Software-Updates vom Hersteller), sollte von Anfang an ein regressionstauglicher Testsatz aufgebaut werden – idealerweise mit Automatisierung – um effizient gegen Neuverschlimmbesserungen gewappnet zu sein.

Manuelle Tests bieten explorative Freiheit und kommen insbesondere bei Usability- und ad-hoc-Tests zum Einsatz, während automatisierte Tests für wiederholbare, umfangreiche und zeitkritische Tests (z. B. nächtliche Batch-Tests aller Kernprozesse) unschätzbar sind. Ein gesundes Mischmodell aus beidem hat sich als Best Practice erwiesen – wichtig ist in jedem Fall eine sorgfältige Planung, welche Tests wie automatisiert werden, da das Erstellen und Pflegen automatischer Tests ebenfalls Aufwand bedeutet.

System- und Konfigurationstests sollten niemals in der produktiven Umgebung stattfinden, sondern in einer abgegrenzten Testumgebung. Üblicherweise wird dafür eine Staging-Umgebung oder ein dedizierter Test-Mandant des CAFM-Systems verwendet, der eine möglichst realistische Kopie der späteren Produktionsumgebung darstellt. Die Testumgebung sollte hinsichtlich Softwareversion, Infrastruktur und Konfiguration identisch oder sehr ähnlich zur Live-Umgebung sein. Nur so sind die Testergebnisse aussagekräftig für das spätere Verhalten des Systems. Gerade für nicht-funktionale Tests (Performance, Last) ist eine vergleichbare Umgebung essenziell – z. B. nützen Performancemessungen auf einem kleinen Testserver wenig, wenn die Produktion in der Cloud auf ganz anderer Hardware läuft.

Ein wichtiger Aspekt ist dabei die Datenbasis in der Testumgebung. Ideal ist eine Mischung aus realistischen Echtdaten und synthetischen Testdaten. Oft wird zu Projektbeginn ein Abzug der Altdaten oder ein Ausschnitt aus dem echten Datenbestand in die Testumgebung importiert, um praxisnahe Bedingungen zu schaffen. Echte Daten (z. B. vorhandene Gebäude- und Vertragsdaten) haben den Vorteil, dass sie komplexe, realitätsnahe Konstellationen mitbringen. Allerdings müssen diese ggf. anonymisiert werden (personenbezogene Daten schützen!) und sie decken nicht jeden Sonderfall ab. Daher ergänzt man sie durch gezielt erzeugte Testdatensätze für spezielle Szenarien (z. B. ein Vertrag mit exotisch kurzem Kündigungsintervall, ein Raum mit maximal zulässiger Flächengröße etc.), um auch Grenzfälle prüfen zu können. Der Grundsatz lautet: So produktnah wie möglich testen, was sowohl für die Technik als auch für die Daten gilt.

In vielen CAFM-Projekten existiert eine mehrstufige Umgebungslandschaft: z. B. eine Entwicklungsumgebung (für Entwickler/Customizer), eine Integrations- oder Testumgebung (für Systemtest durch das Projektteam) und eine Abnahmeumgebung (für den Kunden/UAT), bevor es zur Produktion geht. Wichtig ist hierbei die Mandantentrennung und Datenkonsistenz: Testdaten sollten sauber von Echtdaten getrennt sein, und idealerweise sind die Testmandanten regelmäßig mit realistischen Daten befüllt, aber isoliert, sodass keine Testvorgänge ungewollt in produktive Systeme wirken. In SaaS-CAFM-Lösungen bedeutet Mandantentrennung zudem, dass mehrere Kunden oder Abteilungen auf derselben Instanz völlig abgeschottet voneinander agieren können – auch dies sollte im Test verifiziert werden, falls relevant: Ein Mandant darf auf keinen Fall die Daten eines anderen Mandanten einsehen oder verändern können. Hierfür richtet man ggf. zwei Dummy-Mandanten ein und versucht z. B. mit Nutzer A (Mandant1) auf Daten von Mandant2 zuzugreifen (was fehlschlagen muss).

Zusammengefasst sind die Anforderungen an die Testumgebung: Realitätsnähe, Datenqualität, Isolation und Reproduzierbarkeit. Das heißt, man sollte z. B. auch definieren, wie Testdaten zurückgesetzt oder neu aufgespielt werden (Stichwort Reset der Testumgebung nach einem Durchlauf, um erneut von definierten Bedingungen zu starten). All dies erfordert enge Abstimmung mit der IT-Infrastruktur: Idealerweise wird die Testumgebung im Rahmen des Projektplans früh aufgebaut und getestet, bevor die eigentlichen Systemtests starten.

Ein Testfall beschreibt eine konkrete Prüfsituation mit Eingabewerten, Durchführungsschritten und erwartetem Ergebnis, um eine bestimmte Systemanforderung zu validieren. Die Gestaltung der Testfälle sollte systematisch erfolgen und sich direkt von den Anforderungen ableiten. Als Testbasis dienen die im Lastenheft oder in User Stories festgehaltenen funktionalen und nicht-funktionalen Anforderungen an das CAFM-System. In klassischen Projekten wird hierzu oft eine Traceability-Matrix erstellt: Eine Tabelle, die jeder Anforderung einen oder mehreren Testfällen zuordnet. Dadurch ist sichergestellt, dass keine Forderung ungetestet bleibt und man im Fehlerfall schnell sehen kann, welche Anforderung davon betroffen ist. Moderne Testmanagement-Tools bieten Funktionen, um Anforderungen, Testfälle und Testergebnisse zu verknüpfen und Rückverfolgbarkeit herzustellen.

Bei der Testfallerstellung selbst haben sich zwei Ansätze bewährt: Zum einen ein strukturiertes, systematisches Vorgehen (etwa Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellen), um aus schriftlichen Anforderungen möglichst viele relevante Varianten abzuleiten. Zum anderen der erfahrungsbasierte Ansatz, bei dem Testdesigner auf Basis ihrer Domänenkenntnis zusätzliche Fälle definieren, die in den Anforderungen evtl. nicht explizit stehen (z. B. typische Fehlerfälle oder Benutzeraktionen, die realistisch aber nicht dokumentiert sind). Diese Kombination stellt ein gutes Abdeckungsspektrum sicher: sowohl die normale Nutzung als auch Ausreißer-Szenarien werden bedacht.

• Dokumentation: Jeder Testfall sollte schriftlich oder elektronisch dokumentiert sein – mindestens in Form von Testfallbeschreibungen (Test Case Specifications). Übliche Inhalte sind: eine eindeutige ID, zugeordnete Anforderung(en), Ausgangsbedingungen (Pre-Conditions), Eingabedaten, die durchzuführenden Schritte, das erwartete Ergebnis und ein Feld für das tatsächliche Ergebnis beim Test. Während der Testdurchführung werden diese Unterlagen zu Testprotokollen, indem die Tester die Ist-Ergebnisse und das Bestehen/Nichtbestehen vermerken. In der Praxis nutzt man oft Excel-Listen, Word-Tabellen oder dedizierte Tools, um diese Protokolle zu führen. Eine gründliche Dokumentation erlaubt es, später nachvollziehbar zu machen, welche Tests durchgeführt wurden und wo etwaige Fehlfunktionen entdeckt wurden. Gerade in regulierten Umfeldern (z. B. bei FM in Pharmaunternehmen) ist es wichtig, lückenlos belegen zu können, dass alle kritischen Funktionen getestet wurden.

• Wichtig ist zudem die Versionierung von Testfällen: Wenn sich Anforderungen ändern oder das System erweitert wird, müssen Testfälle angepasst werden. Ein gutes Konfigurationsmanagement bezieht also auch die Artefakte des Testens mit ein (Änderung von Tests bei Änderungen im System). Testprotokolle werden in der Regel versioniert abgelegt oder in einem Ticketsystem referenziert, sodass im Nachgang eine Prüfung (z. B. durch interne Revision oder externe Auditoren) möglich ist.

Nicht zuletzt sollte in den Testdokumenten auch die Abdeckung nicht-funktionaler Anforderungen sichtbar sein: Gibt es z. B. Anforderungen an die Performance („Bericht X muss innerhalb 5 Sekunden laden bei 1000 Datensätzen“), dann braucht es dafür definierte Testfälle (z. B. Lasttest-Skript mit 1000 Dummy-Datensätzen) und Protokolle, die zeigen, ob die Vorgaben eingehalten wurden. Die Nachvollziehbarkeit erstreckt sich also idealerweise auf alle Arten von Anforderungen – funktional, performance, sicherheit, usability etc. – und ihre Überprüfung im Test.

Trotz bester Vorbereitung werden in der Testphase Fehler und Abweichungen auftreten – sei es Software-Bugs, falsch konfigurierte Einstellungen oder unvollständige Umsetzung von Anforderungen. Entscheidend ist ein klarer Prozess zur Fehlererfassung und -verfolgung.

Alle im Systemtest gefundenen Probleme sollten zentral in einem Defect-Tracking-System registriert werden. In einem solchen Tool (oder notfalls einer Excel-Liste) wird für jeden Fehler ein Ticket angelegt, das folgende Informationen enthält: eine eindeutige Kennung, Beschreibung des Symptoms (Was funktioniert nicht? Wie äußert sich der Fehler?), Schritte zu seiner Reproduktion, erwartetes vs. tatsächliches Verhalten, betroffenes Modul/Objekt, Entdecker und Datum, sowie eine Einstufung von Priorität und Schweregrad. Diese Details sind wichtig, damit das Entwicklungsteam oder der Konfigurator den Fehler schnell nachstellen und beheben kann.

jedem Fehler wird ein Verantwortlicher zur Behebung zugewiesen, und sein Status wird vom Testmanagement überwacht (etwa Offen -> In Bearbeitung -> Gelöst -> Retest -> Geschlossen). Es ist ratsam, regelmäßige Fehler-Status-Meetings im Team abzuhalten, um den Fortschritt zu prüfen, insbesondere bei schweren Fehlern, die den Projektplan gefährden könnten. Das Testteam führt nach Meldung eines behobenen Fehlers einen Re-Test durch, um zu bestätigen, dass das Problem tatsächlich behoben ist und keine Seiteneffekte entstanden sind.

Alle diese Schritte – Fund, Behebung, Retest – werden im Fehler-Tool dokumentiert, sodass eine lückenlose Historie entsteht. Dadurch kann man am Ende der Testphase auch auswerten, wie viele Fehler gefunden und gelöst wurden, und welche Bereiche vielleicht besonders anfällig waren. Manchmal werden Fehler in Kategorien eingeteilt (z. B. Konfigurationsfehler, Software-Bug, Bedienfehler), was Lessons Learned ermöglicht. Ein gut geführtes Defect-Log ist auch Teil der Testdokumentation für den Abnahmebericht.

Kleinere Abweichungen oder Change Requests, die nicht vor Go-Live behoben werden (können), sollten ebenfalls erfasst und priorisiert werden. Ggf. entscheidet das Change-Board, dass bestimmte unwesentliche Mängel mit einem Workaround akzeptiert und nach dem Go-Live behoben werden. Auch diese Entscheidungen gilt es nachzuverfolgen, damit nichts unter den Tisch fällt.

Es erhöht ein stringentes Fehlermanagement die Transparenz und Kontrolle im Testprozess: Das Team weiß stets, welche kritischen Bugs noch offen sind und kann sicherstellen, dass vor dem Produktivstart keine showstopper übersehen werden. Zudem trägt die gemeinsame Fehlerdatenbank zur Kommunikation zwischen Testern, Entwicklern und Fachbereich bei – jeder sieht den aktuellen Stand und die Historie der Probleme.

Neben der fachlichen Korrektheit muss im Systemtest auch die Benutzeroberfläche (GUI) gründlich begutachtet werden.

• Responsivität: Viele CAFM/IWMS-Anwendungen werden webbasiert oder mobil bereitgestellt. Daher ist zu testen, ob die UI auf verschiedenen Endgeräten und Bildschirmgrößen optimal dargestellt wird. Beispielsweise soll eine Weboberfläche sich responsiv anpassen: auf dem Desktop ein mehrspaltiges Layout zeigen, auf dem Smartphone als einspaltige Ansicht mit Menüicon. Testfälle hierzu umfassen das Aufrufen der Anwendung mit unterschiedlichen Auflösungen bzw. Geräten (Desktop, Tablet, Smartphone verschiedener Hersteller) und Prüfen, ob alle Bedienelemente sichtbar und nutzbar sind. Ebenfalls wichtig ist die Browser-Kompatibilität: Läuft das System in den gängigen Browsern (Chrome, Firefox, Edge, Safari) ohne Darstellungsfehler? Falls dedizierte mobile Apps im Spiel sind, müssen auch diese auf verschiedenen Betriebssystemversionen getestet werden. Responsivität betrifft aber nicht nur Layout, sondern auch die Performance aus Nutzersicht: Reagiert die Oberfläche flüssig auf Eingaben? Ruckeln z. B. interaktive Raumpläne bei Zooming auf schwächeren Geräten? Solche Beobachtungen fließen in die Bewertung ein.

• Usability (Benutzerfreundlichkeit): Selbst ein funktional korrektes System kann scheitern, wenn es von den Anwendern als unverständlich oder umständlich empfunden wird. Daher wird im Konfigurationstest geprüft, ob das System intuitiv bedienbar ist. Konkrete Prüfpunkte sind etwa: Sind die Menüstrukturen logisch und den FM-Prozessen entsprechend aufgebaut? Finden Benutzer die gesuchten Funktionen mit wenigen Klicks? Sind Begriffe im UI verständlich (lokale Sprache, Branchenjargon vermeiden)? Ein gängiger Ansatz ist hier, Key-User in die GUI-Tests einzubeziehen – also Vertreter der Endanwender, die das System aus ihrer Perspektive bedienen und Feedback geben. Oft entdeckt man so Verbesserungspotenzial bei Eingabemasken, Übersetzungen oder Workflows (z. B. „Warum muss ich hier fünf Felder ausfüllen, um einen einfachen Raum zu buchen?“). Dieses Feedback ist Gold wert[3], um noch vor der Abnahme die Nutzungsfreundlichkeit zu erhöhen. Zudem testet man gängige Use Cases (Szenarien) ohne Vorwissen: Ein neuer Benutzer bekommt eine Aufgabe („Erstelle einen Wartungsauftrag für Raum X“) und man beobachtet, ob er ohne Rückfragen das Ziel erreicht. Schwierigkeiten dabei deuten auf Verbesserungsbedarf in der UX hin. Usability-Testmethoden wie heuristische Evaluation oder kleinere Usability-Testsessions mit repräsentativen Usern können Teil des Konfigurationstests sein. Letztlich fließt das Ergebnis in ggf. Nachbesserungen in der Konfiguration ein – z. B. Felder als Pflichtfeld markieren, Hilfetexte ergänzen, Standardwerte setzen – um das System benutzerfreundlicher zu machen.

• Barrierefreiheit (Accessibility): Gerade im öffentlichen Sektor und zunehmend auch in Unternehmen wird Wert auf barrierefreie Software gelegt. Webbasierte CAFM-Oberflächen sollten idealerweise den WCAG-Richtlinien (Web Content Accessibility Guidelines) entsprechen. Im Test bedeutet dies, verschiedene Zugänglichkeits-Kriterien zu prüfen: Kann die Anwendung ohne Maus nur per Tastatur bedient werden? Werden Screenreader unterstützt (z. B. haben Bilder und Buttons aussagekräftige Alternativtexte)? Sind Farbkontraste ausreichend für sehbehinderte Nutzer? Entspricht der Aufbau den WCAG-Erfolgskriterien der Stufe AA? Zur Überprüfung zieht man sowohl automatisierte Tools als auch manuelle Tests heran. Automatische Scanner (wie WAVE, aXe) finden z. B. fehlende Alt-Texte oder Aria-Label Probleme. Manuelle Tests decken Aspekte ab, die Tools nicht erfassen – z. B. ob die Reihenfolge der Fokus-Steuerung logisch ist oder ob für gehörlose Nutzer alle audio-visuellen Inhalte untertitelt/beschrieben sind. In Deutschland sind die BITV 2.0 (Barrierefreie-IT-Verordnung) und EN 301 549 relevante Standards, die auf WCAG basieren; öffentliche Einrichtungen müssen diese einhalten. Deshalb ist ein WCAG-Compliance-Check ggf. fester Bestandteil der Abnahme. Auch wenn das Unternehmen nicht gesetzlich gebunden ist, sorgt Barrierefreiheit allgemein für eine robustere, besser verständliche Anwendung für alle Nutzer. Im Testbericht wird Barrierefreiheit beispielsweise mit einem Bewertungsbogen dokumentiert (Anzahl der erfüllten/nicht erfüllten Prüfkriterien). Ergibt sich Handlungsbedarf, können noch vor Produktivsetzung UI-Anpassungen erfolgen – etwa größere Schriftarten, Alternativtexte nachpflegen, oder optional ein Hoher-Kontrast-Thema anbieten.

Es zielt die GUI-Validierung darauf ab, dass das System optisch-technisch einwandfrei und für alle Nutzerkreise ergonomisch ist. Responsivität sichert die Nutzung auf verschiedenen Geräten, Usability sorgt für Akzeptanz und effiziente Bedienung, Barrierefreiheit stellt sicher, dass niemand aufgrund von Einschränkungen ausgeschlossen wird. Diese Faktoren beeinflussen maßgeblich den Langzeiterfolg der CAFM-Einführung, da nur ein gern genutztes System letztlich die erhofften Effizienzgewinne bringt.

• Teststrategie früh festlegen: Erfolgreiche Projekte planen die Testphase von Anfang an mit. Es wird ein Testkonzept erstellt, das Teststufen, Verantwortlichkeiten, Umfang und Methoden definiert. Eine klare Strategie und detaillierte Testpläne sorgen dafür, dass in der heißen Phase nichts Wichtiges vergessen wird. Ebenso sollte man ausreichend Zeitpuffer für Tests (und Nachtests nach Fehlerbehebung) im Projektplan einbauen – Testen wird gern unterschätzt.

• Umfassende Testabdeckung sicherstellen: Alle relevanten Funktionen und Prozesse des Systems müssen getestet werden. Konzentrieren Sie sich insbesondere auf die Kernfunktionen: Diese zuerst und gründlich prüfen, da hier Fehler am kritischsten sind. Beispielsweise haben viele Projekte die Lektion gelernt, dass gerade scheinbar einfache Basisfunktionen (Raumsuche, Ticketanlage) absolut zuverlässig funktionieren müssen, da sie täglich genutzt werden. Kernprozesse zuerst – ist ein Leitsatz. Ein gut strukturierter Testprozess hilft, potenzielle Fehlerquellen frühzeitig zu identifizieren und Anpassungen vorzunehmen, bevor die Software live geht.

• Reale Anwendungsfälle durchspielen: Nutzen Sie echte Use Cases und Szenarien im Test, nicht nur theoretische Prüfungen. Testen der Anwendung mit realistischen Abläufen („Day in the Life“-Tests) deckt oft Lücken auf, an die man beim rein anforderungsbasierten Testen nicht dachte. Beispiel: Durchspielen des kompletten Prozesses „Mieter meldet Defekt -> Techniker behebt -> Abrechnung der Kosten“ mit allen Zwischenschritten. So stellt man sicher, dass das System in der Praxis funktioniert, nicht nur auf dem Papier.

• Realistische Testdaten & Umgebung: Wie oben beschrieben, sind realitätsnahe Testbedingungen Gold wert. Projekte berichten als Lesson Learned, dass Tests in künstlichen Mini-Datensätzen oft grüne Haken ergeben, später aber in Produktion mit echten Datenvolumen Probleme sichtbar wurden. Daher möglichst mit echten Mengen und Strukturen testen (z. B. 1000+ Räume, komplexe Gebäudestruktur) – das enthüllt Performanceprobleme und andere Skalierungsfragen vorab.

• Einbindung der Endanwender: Binden Sie Key User und Fachabteilungen aktiv in den Konfigurationstest ein. Deren Feedback ist enorm wertvoll[3]: Sie entdecken Usability-Probleme oder fachliche Inkonsistenzen, die den Testern evtl. entgehen. Außerdem erhöht frühe Einbindung die Akzeptanz – die Nutzer fühlen sich ernst genommen und bauen bereits in der Testphase Vertrauen in das System auf. Eine etablierte Best Practice ist das Beta-Testen mit ausgewählten Endusern in der Testumgebung, um praxisnahes Feedback zu sammeln.

• Gründliche Fehlerdokumentation und -bereinigung: Jeder gefundene Defekt sollte nachvollziehbar dokumentiert und priorisiert werden. „Kleinigkeiten können warten“ – dieser Ansatz hat sich oft gerächt. Besser: Alle Fehler, auch kleinere, notieren und bewerten. Kritische Fehler natürlich sofort beheben und erneut testen. Aber auch scheinbar triviale UI-Bugs oder Übersetzungsfehler möglichst vor dem Go-Live bereinigen, da die Nutzer sonst gestört werden könnten. Eine Testphase gilt erst dann als abgeschlossen, wenn die Anzahl offener kritischer Fehler null ist und nur noch unbedeutende Schönheitsfehler (wenn überhaupt) übrig sind, für die es einen Behebungsplan gibt.

• Nicht-funktionale Anforderungen nicht vergessen: Performance- und Sicherheitstests, etc., sollten fester Bestandteil sein, sofern relevant. Beispiel Lesson Learned: Ein System lief funktional einwandfrei, brach aber unter realer Last ein – weil man Lasttests vernachlässigt hatte. Solche Fehler sind teuer. Also z. B. größere Datenmengen laden, simultane Benutzer simulieren und schauen, ob Antwortzeiten im grünen Bereich liegen. Ebenso Security-Themen prüfen (Zugriffsschutz, Verschlüsselung, Penetrationstest eventuell durch IT-Security-Team). Diese Tests früh einplanen, da Behebungen (z. B. Indexoptimierungen in der DB) dauern können.

• Usability und Change Management beachten: Neben dem technischen Test sollte man immer die Nutzerperspektive mit im Blick haben. Falls möglich, führen Sie nach dem Systemtest eine kurze Pilotphase mit echten Endanwendern in einer kontrollierten Umgebung durch. Dort lernt man oft, welche kleinen Änderungen die Usability verbessern (Beschriftungen, Voreinstellungen etc.). Außerdem sollte die Dokumentation (Bedienungsanleitung, Schulungsunterlagen) parallel geprüft werden – ein oft übersehener Punkt. Ein Best Practice: Während des Tests auch gleich die Anwender-Dokumentation aktualisieren, denn dabei merkt man, ob Abläufe verständlich beschrieben sind und ob evtl. Funktionen fehlen, die die Doku verspricht.

• Traceability und Anforderungsabdeckung im Blick behalten: Halten Sie die Verbindung von Anforderungen und Testfällen aktuell (z. B. in einer Traceability-Matrix). So sieht man jederzeit, wo noch Tests fehlen oder ob neue Anforderungen hinzugekommen sind, für die noch Testfälle zu entwerfen sind. Gerade in agilen Projekten mit Backlog-Änderungen ist das essentiell.

• Iteratives Vorgehen und kontinuierliches Lernen: Nach jedem Testdurchlauf (z. B. Systemtest Zyklus 1, dann Fixes, dann Systemtest Zyklus 2) sollte ein kurzer Review stattfinden: Was lief gut, wo gab es Engpässe? Vielleicht merkt man, dass bestimmte Tests automatisiert werden sollten, weil sie immer wieder viel Zeit kosten. Oder man erkennt, dass die Testdaten erweitert werden müssen. Erfolgreiche Teams passen ihren Testansatz laufend an und verbessern ihn. Lessons Learned aus jedem Testzyklus fließen idealerweise in eine Wissensdatenbank ein, sodass künftige Projekte davon profitieren.

• Abschluss der Testphase sauber gestalten: Zum Ende der Systemtestphase empfiehlt es sich, einen Testabschlussbericht zu verfassen, der zusammenfasst: Umfang der durchgeführten Tests, Anzahl gefundener/behobener Fehler, offene Restpunkte, Entscheidungsempfehlung zur Abnahme. Darin wird formal festgehalten, ob das System aus Testsicht bereit für den UAT bzw. Go-Live ist. Diese Transparenz hilft dem Lenkungsausschuss oder Projektleiter bei der Freigabeentscheidung.

Eine sorgfältig durchgeführte Konfigurationstest-Phase ist wie die Generalprobe vor der Premiere. Hier wird das Zusammenspiel aller Komponenten überprüft und feinjustiert. Je gründlicher diese Generalprobe verläuft, desto reibungsloser wird die eigentliche Aufführung – sprich der Produktivstart – funktionieren. Im Bereich CAFM, wo Software eng mit organisatorischen Prozessen verzahnt ist, zahlen sich strukturierte Tests in doppelter Hinsicht aus: Technisch zuverlässige Software und Akzeptanz bei den Nutzern. Mit den oben skizzierten Methoden und Best Practices lassen sich System- und Konfigurationstests effizient gestalten und der Erfolg des CAFM-Projekts maßgeblich absichern.