“Software zu entwickeln ist ähnlich komplex, wie Autos zu bauen.

Für ihr Auto gibt es Crashtests, wer testet ihre Software?”

» Waidner IT Solutions | Mainz/Wiesbaden | +49 176 10042345
Home » Kundenprojekte » Kundenprojekt: Einführung SAP CRM

Kundenprojekt: Einführung SAP CRM

Eines meiner aktuellen Kundenprojekte ist die weltweite Einführung eines SAP CRM Systems für mehrere hundert User, das die alte Lösung in Lotus Notes ablösen soll. Das Projekt läuft inzwischen ein gutes Jahr, das Konzept wurde mit allen Einheiten des Unternehmens abgestimmt und die Implementierung nähert sich dem Ende.

Mein Anteil am Projekt ist die Migration der Altdaten, die Anbindung von Lotus Notes als Groupware an das CRM sowie die Begleitung der Tests als Berater. Wir befinden uns derzeit mitten in der Testphase und ich will ein paar Einblicke liefern, wie nah wir uns an Standards wie ISTQB halten, und wo wir weit davon weg sind.

Das Team

Für die Organisation der Tests war ein kleines Team von 8 Personen zuständig, das aus einem guten Mix aus Prozesskennern, externen Implementierern und interner IT bestand. Unterschiedliches Wissen konnte so genutzt werden und auch später bei den Tests eingesetzt werden.

Phase 1 – Testkonzeption

Die Tests sind in mehrere Phasen eingeteilt; zuerst natürlich die Konzeption der Tests. Hierzu haben wir in einem kleinen Team die Testfälle für die unterschiedlichen Anwendungsbereiche (Accounts, Aktivitäten, Angebote, …) entwickelt, indem wir uns nah am Konzept entlang gearbeitet haben (also die Doku als Testorakel verwendet haben). Das klappte in vielen Bereichen erstaunlich gut, obwohl wir zu Beginn dieser Phase noch keinen Zugriff auf das System hatten. Sobald dieser möglich war, haben wir die noch sehr theoretischen Tests noch einmal genauer spezifiziert. Größtenteils waren die Testfälle sehr genau vorgegeben, da die meisten der späteren Testuser das System noch überhaupt nicht kennen und auch ohne Dokumentation auskommen müssen (letztere soll erst noch erstellt werden). Die Testfälle wurden ziemlich profan in themenorientierte Excel-Listen unterteilt, um ein paar Auswertungsspalten ergänzt und später ausgedruckt verteilt.

Phase 2 – interne Tests

Als nächsten Schritt haben wir im gleichen kleinen Kreis innerhalb von ca. 2 Wochen die Testfälle komplett durchgetestet, um die gröbsten Fehler direkt intern zu entdecken und eine Chance zu haben, vor den Usertests diese schon zu beheben. Für das Tracking der Bugs wurde ab hier Bugzilla eingesetzt. Meiner Ansicht nach ein brauchbares Programm, dessen Oberfläche und Bedienung aber eher an die Anfangszeiten der Browsertools erinnert. Aber es erfüllt seinen Zweck zuverlässig, war beim Kunden verfügbar und wurde auch schon für andere Projekte genutzt.

Phase 3 – erste Testrunde mit Anwendern

Für die ersten beiden Juniwochen stand die erste Testrunde mit Anwendern an. Für jede Unternehmenseinheit waren 1-3 Tester anwesend, die teilweise schon die Konzeption begleitet hatten, teils auch neu dabei waren. Wir starteten also mit unterschiedlichsten Wissenständen. Die Workshops wurden in 2 Gruppen durchgeführt, die sich unterschiedliche Themengebiete so vornahmen, dass in zwei Wochen je zwei Workshops zu einem Thema durchgeführt wurden und jedes Team jedes Thema einmal bearbeiten konnte.

Die Tage begannen mit einer kurzen Einführung in das System, die Erklärung des Testmodus (über die spezifizierten Testfälle) und einem Intro für ein effektives Fehlerreporting. Nach den üblichen Startschwierigkeiten waren die Tester erstaunlich motiviert bei der Sache, kaum jemand lies sich durch seine Tagesjobs ablenken. Aus meiner Sicht zeigt dies deutlich, dass eine solche frühe Beteiligung Spaß machen kann. Über den Tag kamen reichlich Fehler und Verbesserungsvorschläge zusammen, die Abends kurz im Team besprochen wurden. Es stellte sich beispielsweise sehr schnell heraus, dass die sehr genaue Spezifikation der Testfälle dazu führte, dass sich kein Anwender verloren vorkam, aber dennoch durch die gute Unterstützung jeder die Freiheit bekam, alle Aspekte des Systems ausprobieren zu können.

Phase 4 – Korrekturen und Anpassung

Nach den zwei Wochen Anwendertests waren reichlich Änderungsvorschläge und Fehler aufgelaufen, insgesamt um die 1000 Einträge. Die eingegangenen Punkte wurden von den jeweils zuständigen Teammitgliedern durchgesehen, Duplikate beseitigt, Rückfragen gestellt und ansonsten direkt den Entwicklern zugewiesen. Alle Einträge, für die es Klärungsbedarf gab, wurden in 2 Meetings komplett durchgesprochen und es wurde entschieden, wie und ob umgesetzt wird.

Für die Änderungen im Programm waren nur knappe zwei Wochen vorgesehen, die jetzt dem Ende entgegengehen. Laut Bugzilla ist die Quote der noch offenen Punkte bei unter 10%. Aus meiner Sicht bedeutet dies, dass die Priorisierung der Punkte sehr gut gelaufen ist, man viele Erweiterungspunkte auf eine spätere Version verschieben konnte und viele kleinere Probleme aufgetreten sind, die beseitigt werden konnten.

Phase 5 – zweite Testrunde mit Anwendern

Für die zweite Testrunde mit den Anwendern ist das gleiche Schema wie für Runde 1 vorgesehen, d.h. in zwei Wochen werden wieder in kleineren Gruppen jeweils einzelne Themengebiete durchgearbeitet. Diesmal ist es essentiell, dass die Anwender ihre eingekippten Punkte nachtesten und prüfen, ob diese zur Zufriedenheit beseitigt sind. Ich bin gespannt, wie gut dieses Verfahren klappt.

Phase 6 – letzte Korrekturen

Danach ist nur eine kurze Woche für die hoffentlich letzten Korrekturen vorgesehen, die dann in Phase 7 mündet.

Phase 7 – Abnahmetests

In der letzten Phase werden wir noch einmal gemeinsam alle offenen Punkte durchsehen und dann zusammen mit den Anwendern entscheiden, ob eine Produktivsetzung wie geplant stattfinden kann.

Fazit

Mein bisheriges Fazit fällt recht positiv aus. Für ein Projekt dieser Größenordnung und einer sehr hohen Diversität der Unternehmenseinheiten ist der Test sehr glatt gelaufen. Man hat einiges an offenen Punkten gefunden, aber durch die offene Kommunikation und frühe Einbindung der Anwender ist die Zufriedenheit derzeit sehr hoch.

Obwohl nicht explizit gefordert, konnte mir das ISTQB-Wissen an einige Stellen extrem weiterhelfen. Gerade bei der Konzeption der Tests konnte man gut auf Äquivalenzklassenbildung, Grenzwertanalyse und Zustandstests zurückgreifen. Auch die Zusammenstellung des Testteams hat durch den interdisziplinären Mix sehr viel zum Gelingen beigetragen. Gerade auch bei der Begleitung der User war es wichtig, sowohl IT-Fachleute dabei zuhaben, als auch Mitarbeiter, die im Geschäft des Kunden erfahren waren.

Als Testwerkzeuge für die Anwendertests kamen ausschließlich Bugzilla sowie Microsoft Excel zum Einsatz, wobei die Entwickler natürlich ihre jeweils speziellen Tools wie SOAPUI für Interfaces o.ä. verwendet haben. Hier hätte ich mir allerdings im Vorfeld noch mehr Struktur und Einflussnahme gewünscht, gerade die Statusverwaltung bei Bugzilla war zu kompliziert und vor allem falsch organisiert (bspw. „Resolved“ als Status für Nachtests statt „Verified“). Hier lies sich leider durch zentrale Vorgaben zu wenig ändern.

Ich denke, nach der hoffentlich positiven Abnahme kann ich hier noch einmal mehr schreiben.