Testen tun alle – die einen vor, die anderen nach dem Go Live

Bei ERP Einführungen oder neuen Releases wird vom Anbieter oft verlangt, dass die Benutzer testen. Die User fragen sich dann, weshalb man etwas testen muss: „Es ist doch alles im Standard.“ – Aus Sicht der Anwender wurde weder eine firmenspezifische Entwicklung erstellt noch ein Sonderwunsch geäussert. Alles was man haben möchte ist doch der Standard und mit diesem arbeiten ja alle Firmen.

Ich behaupte jetzt mal, dass jeder der mehr als ein System eingeführt hat weiss, dass dies nicht der Fall ist. ERP Systeme sind flexibel und die Konfigurationen werden an den Kunden angepasst. Bei jedem Kunde etwas anders, da nicht alle gleich arbeiten.

Es geht mir in diesem Beitrag nicht um eine vollständige Aufarbeitung von Softwaretests. Dazu gibt es spezielle Lehrgänge. Es geht mir um die Anwender und den Projektleiter in ERP Projekten. Das sind vielfach nicht die Personen mit einer Spezialausbildung im Testing. Ich möchte hier meine Erfahrungen aus der Praxis weitergeben und den einen oder anderen Tipp platzieren, so dass Ihr es im Alltag einfacher habt.

Bedeutung von Tests
Die Tests der Anwender haben für mich zwei Zwecke. Zum einen wird geprüft ob die Software macht was sie sollte und nicht macht was sie nicht sollte. Zum anderen erhalten die User mit der Durchführung der Testfälle Übung im Umgang mit der neuen Lösung oder der neuen Version. Dies macht den Go Live erheblich einfacher. Zum einen weil man weiss wie es geht und zum anderen weil das System macht was definiert ist. Als schönen Nebeneffekt kann die Anwenderdokumentation gleichzeitig mit den Tests erstellt werden.

Wenn man dies jemandem sagt, so scheint dies eigentlich recht verständlich. Trotzdem wird häufig auf eine intensive Testphase verzichtet.

Hier einige Beispiele aus meinem Arbeitsumfeld weshalb nicht getestet wurde:
– die Konfiguration war noch nicht ganz fertig, der go Live Termin kam näher und diesen wollte man halten. Darum verzichtet man auf einen intensiven Test
– die Mitarbeiter hatten keine Zeit
– die Mitarbeiter wussten nicht was zu testen ist
– die Mitarbeiter wussten nicht wie zu testen ist
– die Mitarbeiter machten ein Klick, es ging nicht wie gewünscht, also hörte man auf

Arten von Tests
Für mich gibt es folgende Testkategorien:

Der Einzeltest
Der User versucht eine bestimmte Transaktion durchzuführen. Zum Beispiel das Erfassen eines neuen Artikels.

Der Integrationstest
In diesem Test wird nicht nur der Einzelschritt angeschaut, sondern der gesamte betroffene Prozess. Wird der erfasste Artikel korrekt gebucht (im Lager, in der Buchhaltung)? Wie erscheint der Artikel auf der Rechnung? Wie entwickelt sich der Einstandspreis, etc.

Der Rückwärts- resp. Seitwärtstest
Was passiert wenn ich etwas Ungewolltes mache? Kommt dann eine Fehlermeldung oder geht der Prozess trotzdem weiter? Was passiert mit den anderen Artikeln? Werden diese weiterhin korrekt gebucht? Welche Querschläger gibt es aus den gemachten Anpassungen?

Um einen kompletten Test durchzuführen, sind immer alle Schritte notwendig. Vor allem, wenn bei einem Test etwas nicht funktioniert hat, es korrigiert wurde und man nochmals testen muss.

Die User
Folgende Testtypen sind mir im Berufsalltag begegnet.

Der Minimalist: „Ich habe ein Fall getestet, es hat alles funktioniert, deshalb hab ich aufgehört.“ – Dies führt dazu, dass im produktiven Betrieb dann halt auch nur der Fall funktioniert der getestet wurde.

Der Ausredensucher: Diese Testperson erhält zehn verschiedene Fälle, hört aber auf, wenn er im ersten Fall nicht das Resultat seiner Wünsche erhält. Die weiteren Fälle werden nicht einmal angeschaut, weil man ja sowieso nochmals testen muss. – Die Durchlaufzeit erhöht sich dadurch massiv, was diese Testperson egal ist, sie sucht nur eine Ausrede, weshalb man NICHT testen kann.

Der „Keine Zeit“ Typ: Diese Person weiss dass sie testen muss, nimmt sich aber die Zeit nicht, weil das Tagesgeschäft den Alltag schon 100% ausfüllt und es irgendwie immer etwas Wichtigeres gibt. – Somit werden die Tests erst nach dem go Live gemacht.

Der Optimist: Diese Person vertraut dem Anbieter, den Consultants, der Software. Es wird schon stimmen. Drum wird einfach nicht getestet. – Murphy lässt grüssen.

Der Gewissenhafte: Diese Person macht alles Test vor- und rückwärts. Das sind diejenigen, welche man im Projekt am liebsten hat.

 

Tipps für den Alltag
Aus meiner Sicht ist es wichtig, dass die Tests genau dokumentiert werden. Und das beginnt bereits beim Auftrag. Der User sollte einen konkreten Auftrag erhalten. Mit allen Elementen eines Auftrages: Wer testet wann was wo und wie meldet er die Ergebnisse und wo meldet man Probleme. Wer steht bei Fragen zur Verfügung?

Am Schluss der Tests sollte es ein Abnahmeprotokoll geben, dass die Person, welche die Tests durchgeführt hat, unterzeichnet.

Idealerweise finden die Tests nicht am eigenen Arbeitsplatz statt, so kann man verhindern, dass die Personen ständig gestört werden. Ein fixes Zeitfenster stellt zudem sicher, dass die Personen sich die Zeit auch reservieren.

Die wichtigsten Tests betreffen das Tagesgeschäft. Testet nicht den Ausnahmefall, der letzte Woche zufällig (und das zum ersten Mal seit 10 Jahren) aufgetreten ist.

Aus Herstellersicht:
Es gibt kein Go Live ohne Testabnahme.

Organisation:
Erstellt eine Testliste mit Testfällen, erweitert diese Testliste mit jedem Release. So hat man mit jedem Update ein Testszenario auf das man zurückgreifen kann. Die User haben einen genauen Leitfaden, an welchen sie sich halten können und die Rückmeldungen sind strukturiert. Versucht dabei auch die User für die Arbeit zu sensibilisieren und setzt wenn möglich die gleichen Personen  ein.

An das Management:
Gebt den Anwendern Zeit für diese Arbeit. Weil alles was während dem Testen nicht entdeckt wird, wird euch im Tagesgeschäft wieder einholen und dort sind die Auswirkungen massiv grösser. Von einfachen Datenkorrekturen bis hin zum Stillstand der Produktion ist vieles möglich.

 

Was sind eure Erfahrungen mit den Tests? Wie habt Ihr die Anwender
sensibilisiert und geschult?

Ein Gedanke zu “Testen tun alle – die einen vor, die anderen nach dem Go Live

  1. Sehr interessanter Artikel !
    Für viele ist dieses Thema einfach eine graue Wolke, die undefinierbar einfach da ist – man weiss, man muss / sollte es tun und schafft es dann aus irgendwelchen Gründen doch nie, gute Vorgehensweisen und Strukturen dazu aufzubauen.
    Aus meiner Sicht ist dies eigentlich eine selbstverständlichkeit 🙂

    Liken

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.