Dynamics Views
Einblicke, Meinungen und News rund um Microsoft Dynamics 365 Finance und Supply Chain Management sowie Dynamics AX
Cowboys vs. Quality: Testen in der Implementierung
Liebe Blog-Leser,
mit diesem Beitrag eröffnen wir unseren Blog. In „Dynamics Views“ möchten wir Sie an unseren Einblicken, Erkenntnissen und Meinungen rund um Dynamics AX und Dynamics 365 for Operations teilhaben lassen. Außerdem berichten wir über spannende Neuigkeiten. Die Mitglieder unseres Führungsteams sowie weitere kompetente Kollegen werden sich hier in regelmäßigen Abständen zu Wort melden. Unsere Idee ist es, Ihnen über unsere Website hinaus fokussierte Informationen und interessante Impulse zu bieten – und idealerweise mit Ihnen in Dialog zu treten. Wir freuen uns auf Ihre Kommentare!
Für unseren ersten Beitrag haben wir natürlich ein Thema gewählt, das uns besonders am Herzen liegt: Das Testen.
In den vergangenen 12 Jahren habe ich an einem Dutzend Implementierungen von Dynamics AX mitwirken dürfen. Zählt man die meiner Mitarbeiter dazu, waren es sicher an die dreißig. Die besten Projekte waren dabei diejenigen, in denen ein Schwerpunkt auf Dokumentation, Test und Qualität gelegt wurde. Der geneigte Leser könnte jetzt auf die Idee kommen, dass es selbstverständlich ist, Software vor der Implementierung zu testen. Das stellt auch niemand infrage, es gibt jedoch Unterschiede in der Qualität der Tests.
Entscheider und Anwender lassen sich in drei Kategorien einteilen:
1. Der Cowboy
Cowboys lieben das Abenteuer. Testen ist okay, solange es nicht viel Zeit in Anspruch nimmt und wenig kostet. Der Cowboy testet am liebsten auf dem Produktivsystem – da liegen ja auch alle Daten …
2. Der Realo oder der einsame Cowboy mit gewissen Erfahrungen
Irgendwann passiert es einem Cowboy: Die Pferde gehen mit ihm durch und er verliert seine Herde aka eine Vielzahl seiner Daten. Vielleicht sogar eine Menge von dem zuvor eingesparten Geld, da Mitarbeiter, Maschinen und Kunden stillstehen. Ungewollt. Er wird als einsamer Cowboy von der Realität eingeholt, lernt, die Tests doch auf einer isolierten Umgebung durchzuführen und Datenkonstrukte im Vorwege zu testen. Dokumentation ist aber nicht zwingend erforderlich, denkt er.
3. Der Vernünftige oder der Realo mit Erfahrung oder der erfahrene Cowboy
Der Vernünftige denkt, bevor er handelt, und dokumentiert und plant, bevor er testet. Tests leitet er systematisch aus den Anforderungen bzw. Beschreibungen der Anpassungen und Prozessen ab und dokumentiert im Vorhinein sein erwartetes Ergebnis. Realos haben erkannt, dass Tests doch wiederholt durchgeführt werden sollten. Wird an einer genauen Dokumentation der Anforderungen gespart, so wird der Aufwand beim Testen steigen: sowohl durch die Test-Aufgabe an sich als auch durch fehlerhaft erstellte und durchgeführte Tests. Der erfahrene Cowboy reitet sein Pferd erst zu, bevor er es mit zur Herde nimmt. Das Zureiten ist im Dynamics-Projekt das systematische Testen und die Dokumentation des Systems, BEVOR es in Produktion geht.
Ich habe Entscheider und Anwender aller drei Kategorien kennengelernt, daher wundert es mich nicht, dass Testmanagement oder Testunterstützung häufig als dröge Arbeit im Sinne der Testfallerstellung verstanden wird. Zumeist spielen der Faktor Mensch und die Klassifizierung selbsternannter Projektleiter und ERP-Manager eine weitaus wichtigere Rolle. Diese gilt es, so schnell wie möglich zu vernünftigen Test-denkenden zu lenken. Mit Cowboys und Realos zu arbeiten ist zuweilen anstrengend, birgt aber auch große Chancen.
Testen ist kein Selbstzweck, sondern notwendig, um mit den vorhandenen Ressourcen Geld und Zeit schonend umzugehen. Jeder in das Testmanagement investierte Euro verringert die Gefahr, am Ende zu scheitern. Erfahrungsgemäß ist das Aufarbeiten von produktiven Fehlern um ein Vielfaches teurer als die im Vorwege geplanten und durchgeführten Tests. Dabei muss mit dem Testen nicht zwingend erst nach der Entwicklung gestartet werden. Wenn man weiß, was man von einem ERP-System erwartet, kann man sofort seine Anforderungen als Test deklarieren und erwartete Ergebnisse festhalten. Das hat den gravierenden Vorteil, dass die Entwickler neben den Prosa-Beschreibungen auch gleich ordentliche Testfälle haben.
Testen ist weder im Vertrieb noch im Projekt sexy. Die Argumente, warum eine Standardsoftware Tests unterzogen werden sollte, lässt den meisten Vertrieblern das Blut in den Adern gefrieren. Wenn man dann noch davon ausgeht, dass bei großen Anpassungen 30 bis 40 Prozent des Aufwandes für die Entwicklung zusätzlich für das Testen verwendet werden sollte, dann ist der geneigte Geschäftsführer oder Entscheider allzu erbost bzw. gibt eventuell anderen Softwarehäusern den Vorzug.
Entscheidern wird aber oft eine simple Logik nicht deutlich genug aufgezeigt: Das ERP-System funktioniert – mit den vordefinierten Prozessen mit den Demodaten. Jeder Kunde hat aber seine speziellen Daten, mit seinen Datenformaten und er hat besondere Prozesse, sei es nur, weil er schon immer so gearbeitet hat. Deshalb müssen seine Prozesse auf bzw. mit dem neuen System getestet werden. Schließlich kannte weder der Hersteller die Kundenprozesse noch der Kunde die ERP-Prozesse des neuen Systems. Darum ist es wichtig, die eigenen Prozesse kombiniert mit dem neuen System intensiv zu testen, bevor man damit in Produktion geht, wie der Cowboy das neue Pferd erst zureitet.
Schreiben Sie einen Kommentar
Kommentar...