Für Unternehmen ist die Einführung eines neuen ERP-Systems ein kritischer Prozess. Funktioniert die Software nicht einwandfrei, kann das zu erheblichen Problemen im Tagesgeschäft führen, bis zum Stillstand des Versandes oder der Produktion. Fehlende Abläufe und fehlerhafte Funktionen können durch Softwaretests sehr stark eingedämmt werden. Doch in meiner täglichen Arbeit stelle ich immer wieder fest, dass nur unzureichend getestet wird, bevor es in den produktiven Betrieb geht. Wie sieht also „richtiges Testen“ überhaupt aus?
Die zentrale Rolle der Key User bei Softwaretests
In meinem Blogartikel „Tests in ERP Projekten“ bin ich schon ausführlich auf die verschiedenen Arten von Tests eingegangen, z.B. Funktionstest, Integrationstest, Massentest:
In diesem Artikel steht das richtige Testen an sich im Fokus.
Da die Key User diejenigen Mitarbeiter eines Unternehmens sind, die die Prozesse und Arbeitsabläufe besonders gut kennen, macht es sie zu den idealen Testern. Optimalerweise kennen sie nicht nur die Standardabläufe, sondern auch die Besonderheiten und Herausforderungen ihres jeweiligen Fachbereichs. Ihre Aufgaben im Testprozess umfassen grob:
- Die Überprüfung, ob die neuen oder angepassten Funktionen den tatsächlichen Anforderungen entsprechen.
- Die Sicherstellung, dass alle relevanten Geschäftsprozesse abgebildet werden können.
- Die Identifikation von Usability-Problemen, die in einer technischen Prüfung möglicherweise übersehen würden.
- Aktives „kaputt spielen“ der Software
Doch was bedeutet eigentlich der Satz „aktives kaputt spielen“ und warum sollte man das tun?
Warum „Kaputtmachen“ der beste Softwaretest ist
Mit fällt eigentlich bei jedem Kunden gleich zu Beginn der Softwaretests auf, dass sich jeder Key User an einem vorgegebenen Testschema orientiert, sei es von jemand anderem vorgegeben oder selbst überlegt. Das ist erst einmal auch eine gute Einstiegsmöglichkeit, um sich mit dem System vertraut zu machen:
Sie möchten zwei neue Felder im Debitor testen, die Angaben zur Tourenplanung für den späteren Versand beinhalten. Die Felder stehen in Abhängigkeit zueinander und sollen auch im Auftrag vorhanden sein. Der Auftrag darf nur mit den beiden Feldern freigegeben werden. Sie füllen beide Felder im Debitor, erstellen einen neuen Auftrag und liefern und fakturieren diesen. Die gewünschten Felder sind überall gefüllt.
Sie haben die Grundfunktionalität getestet: Debitor bearbeiten und Aufträge abwickeln funktioniert. Aber denken Sie noch ein wenig weiter:
- Was passiert, wenn ich die Felder im Debitor leer lasse und einen Auftrag erstelle?
- Kann ich die Felder nachträglich im Auftrag füllen und bestehen dann die gleichen Abhängigkeiten wie im Debitor?
- Kann ich die Felder im Auftrag einfach verändern und erhalte andere Konstellationen wie im Debitor?
- Kann ich den Auftrag freigeben, ohne dass die Felder gefüllt sind?
- Funktioniert das Ganze auch mit Genehmigungsprozess, statt der direkten Freigabe?
- Sind die Felder schon im Angebot zu sehen oder nur im Auftrag, wie gewünscht? Und wenn ich aus einem Angebot einen Auftrag erstelle, werden die Felder dann aus dem Debitor übernommen?
Stellen Sie sich vor, welche ungünstigen Konstellationen möglicherweise auftreten könnten, beispielsweise leere Felder und trotzdem die Möglichkeit der Lieferung und Faktura. Dann versuchen Sie diese ungünstigen Konstellationen im System hinzubekommen. Funktioniert das absolut nicht, dann haben Sie eine Funktion erfolgreich auf Herz und Nieren geprüft. Ob Sie damit alle möglichen Schwachstellen eliminiert haben? Wahrscheinlich nicht. Aber das Risiko haben Sie um einiges verringert, als wenn Sie nur den Grundtest absolvieren, wie zu Beginn des Beispiels.
Das richtige Testen
Ein effektiver Softwaretest beschränkt sich nicht auf das bloße Durchspielen von Standardprozessen. Ein gutes System muss auch mit unerwarteten Eingaben und untypischen Nutzeraktionen umgehen können. Deshalb sollten Key User nicht nur prüfen, ob das ERP-System wie gewünscht funktioniert, sondern gezielt versuchen, Fehler zu provozieren. Dabei sollte man allerdings auch realistisch bleiben und immer die genauen Anforderungen vor Augen haben.
Mögliche Testmethoden sind:
- Eingabe von ungültigen oder unerwarteten Werten: Was passiert, wenn ein Nutzer eine negative Menge in einen Auftrag oder Bestellung eingibt oder ein Datum aus der Vergangenheit verwendet? Können die Daten auch in einer anderen Reihenfolge eingegeben werden?
- Nutzung verschiedener Testszenarien: Funktioniert der Prozess nur für den Standard-Artikel und dem Standard-Debitor/Kreditor oder auch für sämtliche andere Konstellationen? Bedenken Sie hierbei z.B. verschiedene Artikelverfolgungen (Chargen, Seriennummern), mögliche Varianten oder Beschaffungsmethoden eines Artikels. Fertigungsartikel werden oft komplett anders gehandelt wie Lagerartikel.
- Arbeiten mit falschen Benutzerrechten: Kann ein Mitarbeiter ohne die entsprechenden Berechtigungen trotzdem sensible Daten einsehen oder ändern? Kann jeder Benutzer die individuell programmierten Funktionen ausführen, oder fehlen ggf. wichtige Berechtigungen?
- Tests durch Kollegen: Ein Kollege erklärt die grobe Funktionalität und lässt den anderen anschließend den Prozess selbst testen. Dabei sollte man ihn in Ruhe ausprobieren lassen, da er so oft ganz neue Konstellationen und Denkmuster entwickelt, an die zuvor niemand gedacht hat.
Je mehr solcher Tests durchgeführt werden, desto robuster wird das System. Ziel ist es, potenzielle Schwachstellen frühzeitig zu erkennen und zu beheben, bevor sie im Echtbetrieb zu ernsthaften Problemen führen.
Testbeispiele teilen
Um die Tests im Projekt noch effektiver zu gestalten, können nachfolgende Abteilungen die erstellten Testbeispiele nach vorheriger Absprache weiternutzen. So könnten beispielsweise Aufträge, die im Rahmen der Verkaufs-Tests angelegt wurden, als Grundlage für weiterführende Tests in der Logistik oder Produktion dienen. Dies ist jedoch nur sinnvoll, wenn die Prozesse fehlerfrei und funktionsfähig sind. Daher ist ein enger Austausch zwischen den beteiligten Abteilungen wichtig, um sicherzustellen, dass die Testdaten den jeweiligen Anforderungen entsprechen. Zudem können Kollegen gezielt Beispiele für nachfolgende Abteilungen erstellen, die optimal auf die Anforderungen der weiteren Testszenarien abgestimmt sind. Dadurch sparen die Key User Zeit, da sie sich auf die Tests ihrer Aufgaben konzentrieren können und sie nicht mit unbekannten Prozessen auseinander setzen müssen.
Fazit: Ein stabiles ERP-System durch praxisnahe Softwaretests
Softwaretests sind dann erfolgreich, wenn sie nicht nur technische, sondern auch praxisbezogene Herausforderungen abbilden. Key User sind die besten Tester, da sie mit dem System im Alltag arbeiten und daher realistische, aber auch untypische Szenarien durchspielen können. Wer das ERP-System erfolgreich „kaputt spielt“, hilft dabei, es für den späteren Einsatz noch stabiler zu gestalten. Ermutigen Sie die Mitarbeiter, auch einmal andersherum zu denken und fordern Sie das System heraus!
