Professionelles Testmanagement

Fallbeispiel: Es muss nicht immer SAP sein …

Die Firma – mein Kunde – hat viele Jahre mit einer selbst entwickelten Software gearbeitet, wohlgemerkt: mehrere Mia CHF Umsatz, ein grosser Mittelständler. Die Einführung der neuen ERP Lösung ist naturgemäss eine grosse Herausforderung, ein solches Projekt wurde noch nie in Angriff genommen wurde. Während fast 2 Jahren erstellen Berater Konzepte, definieren neue Geschäftsprozesse, werden bestehende Prozesse angepasst, Schnittstellen systematisiert und katalogisiert, Programme entworfen, geprüft, bewilligt oder zurückgewiesen: kurz, eine neue Welt, die künftige Systemwelt wird entworfen und aufgebaut!

Allerdings, ob die neue Welt für das bestehende Geschäft passen wird, wie sich manche unvermeidbaren Änderung auf die Prozesse auswirken werden, ob die Mitarbeitenden die neuen Prozesse annehmen und leben werden, ob das neue System der produktiven Datenlast standhalten wird, und viele weitere Fragen bleiben bis zur eigentlichen Systemumstellung unbeantwortet – trotz vieler Studien, endlosen Sitzungen, gründlichen Projekt-Audits. Die Realität der Neueinführung einer Software kann man nicht vorweggenehmen.

Entsprechend wächst der Druck, je näher der Produktivstart-Termin rückt.

Je nach Standpunkt und Blickwinkel liegen die nach dem Produktivstart zu erwartenden Herausforderungen an anderen Stellen: Stammdaten, Preise, Vollständigkeit der Daten, Performance der nächtlichen Batches, das Reporting – die Vergleichbarkeit der Zahlen, die Schnittstellen, die Bewegungsdatenübernahme – oder beim grössten Unsicherheitsfaktor:  dem Menschen, der mit der neuen Systemlandschaft arbeiten muss!

Systematisches Testing leistet einen Beitrag, das Projektrisiko einzuschränken und das Restrisiko berechenbarer zu machen – und hat das Projekt ab Beginn der Realisierungsphase ständig begleitet. Die Tests heissen anfänglich Funktionstests, Beratertests, Entwicklertests und später, wenn die Systeme gemeinsam entlang ihrer Prozessketten getestet werden, Integrationstest oder Regressionstest.

Mein Kunde besass keine nennenswerten Prozessbeschreibungen. Das Know-how war in vielen Köpfen verteilt – und bezog sich in erster Linie auf das Altsystem. Unter hohem Zeitdruck beschrieben wir in einem 2-stufigen Prozess die Prozessketten, welche die Basis für die Testcases bildeten:

• Stufe 1: Mastertestcases: umfassende Beschreibung des Prozess mit allen möglichen Zusatzschritten
  (z.B. Beschaffungsprozess mit lokal, Fernost, Frisch, Fashion, Hartwaren etc.)
• Stufe 2: Prozessvarianten = Untermenge eines Mastertestcases
  spezifische Ausprägung einer bestimmten Beschaffungsart: z.B. Beschaffung von Frische-Artikeln beim Landwirtschaftsbetrieb mit Direktlieferung

Rasch konnte ein Set von Masterprozessen für die wichtigsten Bereiche erstellt werden: Beschaffung, Verkauf ab Kasse, Auslieferung ab Verteilzentrum, Finanzen und Controlling, Business-Intelligence, Produktionsprozesse und einige weitere.

Diese Masterprozesse waren die Basis für hunderte von Varianten, die davon abgeleitet wurden. In rascher Abfolge konnten die Testfälle generiert werden, so dass ein umfassendes Paket von Testcases entstand, dass die zukünftige System- und Prozesslandschaft modellierte.

Systematisches Testing strukturiert das IT-Projekt in Etappen (genannt Testzyklen), die den Reifegrad des Projekts wiederspiegeln. In der Phase der Testvorbereitung müssen Geschäftsprozesse katalogisiert und in Tabellen beschrieben werden, Prozessvarianten werden differenziert, Bereiche abgegrenzt (Einkauf, Verkauf, Nachschub, Logistik-Prozesse, Finanz- und Controlling-Prozesse, Human-Ressources, Produktionsprozesse etc.). Der Testkatalog umfasst die Gesamtmenge der Prozesse (=Testfälle), die in einem Testzyklus durchgetestet werden (Der Testkatalog bleibt während eines Testzyklus‘ – idealerweise – unverändert, um den Fortschritt messbar und vergleichbar zu machen).

Während einer aktiven Testphase wird der Testfortschritt permanent überwacht. Je nach Testintensität kann der Fortschritt 1x pro Tag oder im Stundentakt neu gerechnet werden (Fehler, Testcases, Testschritte). Fehler werden erkannt, dokumentiert und qualifiziert, die Entwickler und Berater erhalten so rasch als möglich detaillierte Fehlerberichte, die zu Korrekturen und zu entsprechenden Nachtests führen.

Effizientes Integrationstesten wird so organisiert sein, dass Wartezeiten vermieden werden – und Gründe für Wartezeiten sind vielfältig: bestimmte Programme sind noch nicht bereit, eine Schnittstelle ist nicht gelaufen oder hat einen Fehler, ein Fremdsystem hat noch nicht geliefert oder die Tester, welche die Vorgänger-Testschritte ausführen müssten sind überlastet oder nicht verfügbar … somit ist die Organisation der Testschritte – respektive die Organisation des Testablaufs entscheidend für die Effizienz der Testarbeit und unterstützt damit die Stimmung der Testmannschaft. Die Testmannschaft soll sich mit den Themen beschäftigen, die funktionieren – und nicht an den Fehler aufhalten. Nach der Behebung der Fehler müssen die Testcases sofort wieder in den Test-Arbeitsvorrat eingespeist werden, damit die Nachtests durchgeführt werden.

Das Ergebnis eines Testzyklus wird quantifiziert: Abdeckungsgrad, Anzahl getesteter Testfälle und Testschritte, Anzahl gefundener Fehler, Intensität der Testarbeitet (z.B. Anzahl Testschritte pro Testtag) und einige mehr. Dieses Ergebnis ist ein wichtiger Input zur Beurteilung des Projektfortschritts und Reifegrads des Endprodukts. Letztlich wird darüber entschieden, ob der nächste Schritte zur Produktivsetzung angegangen werden darf – oder ob nachgearbeitet werden muss.

Systematisches Testing ist aufwändig und generiert Mehr-Arbeit vor allem für die internen Mitarbeitenden, die neben dem normalen Tagesgeschäft (im Altsystem) nun noch Testarbeiten erledigen müssen. Die eigenen Mitarbeitenden erhalten damit die Chance, das neue System in einem frühen Zustand kennenzulernen, und können ihr Tagesgeschäft in einer Modellumgebung (der Testumgebung) nachstellen und reflektieren. Diese Mitarbeiter können später Superuser-Rollen übernehmen, die Kollegen schulen oder nach der Einführung bei Problemen assistieren.

Werden diese Arbeiten an externe Arbeitskräfte delegiert, besteht die Gefahr, dass sich die Mitarbeitenden nicht mit dem System in genügender Tiefe auseinandersetzen, dass sie das neue System nicht genügend kennengelernt haben, dass wichtige aber versteckte Prozesse nicht rechtzeitig kommuniziert wurden. Wenn externe Mitarbeitende notwendig sind aufgrund der hohen Arbeitsbelastung, dann setzen Sie sie für die bestehenden Arbeiten mit den Altsystemen ein! Die eigenen Mitarbeitenden sollen an der Zukunft des Unternehmens arbeiten!

Ganz nebenbei wird auch das Projekt profitieren, da wertvoller Input ins Projekt zurückfliessen kann. und die Mitarbeiter, die an den Tests mitwirken, erhalten frühzeitig tiefgreifendes Know-how in die Funktionsweise der neuen Systemlandschaft.