Was soll getestet werden?

Natürlich sollen allen neuen Funktionalitäten in den Tests enthalten sein.

In der Regel erfolgt dies in zwei Stufen – zuerst die Funktionstests und danach die Integrationstests. Weitere Tests können User-Akzeptanz-Tests und bei Bedarf sog. Stresstests sein.

Gestartet wird mit den „Geradeauslauf“, d.h. alle Prozesse werden unter optimalen Bedingungen prozessiert. Dieser Part ist häufig schnell und mit wenigen Fehlern absolviert.

Das tägliche Leben entlang der logistischen Kette ist aber bunt und voller Überraschungen. Da sind Stammdaten nicht oder falsch gepflegt, Barcodes nicht lesbar oder die geforderte Pickmenge nicht mehr im Lagerfach verfügbar. Nicht zu vergessen sind auch Fehlbedienungen bei MDE-Geräten und/oder irritierende Fehlermeldungen.

In vielen Fällen kann in diesem Segment nicht mehr vollständig getestet werden. Eine sinnvolle Auswahl ist notwendig.

Die Fehleranfälligkeit bei diesen Prozessen ist in der Regel weit höher. Meistens fehlt die Beschreibung dieser Prozesse im Lastenheft, weil von einer Selbstverständlichkeit ausgegangen wird.

„Ist doch klar, was zu passieren hat, wenn der Artikel (das Material) nicht kommissioniert werden kann“ empört sich der Logistikfachmann.  Der Entwickler beherrscht aber in erster Linie seine Datenbanken und Codes und nicht das „daily business“ eines Lagers.

Die  genaue Beschreibung und vorherige Abstimmung (!)  dieser „Seitenstraßen“ der Logistik-Kette schützt vor Überraschungen im Testbetrieb.

Und nun ist alles gut?

Aber laufen die „alten“ Prozesse noch wie geplant?

Funktioniert der Wareneingang richtig, wenn die Kommissionierstrategie verändert wurde?

Können alle Waren richtig in der Finanzbuchhaltung gebucht werden?

Sind alle Segmente in der Datenübertragung richtig befüllt?

Kann der Dienstleister die neuen Barcodes richtig lesen?

Wer soll an den Tests in welchem Umfang beteiligt sein?

Steht der Testumfang, ergibt sich nun die Frage „Wer macht was?“

Es ist nicht schwer, alle Beteiligten vom Sinn und Nutzen der Tests zu überzeugen. Die Aufgabenverteilung innerhalb der Projektteams ist schnell erledigt.

Kritisch ist häufig die Bindung der Ressourcen aus den operativen Bereichen.   Gerade diese Mitarbeiter mit Ihren Erfahrungen sind für den Projekterfolg wichtig.

Störungen im operativen Prozessablauf, Auftragsspitzen, Ausfälle von Personal-Ressourcen oder kurzfristig geänderte Schichtplanungen sind häufig Ursache von Verzögerungen im Testablauf.

Zur Umschiffung dieser Klippe hat sich die Vergabe konkreter Verantwortung an Key-User bewährt.

Die frühe Einbindung dieser Mitarbeiter in den Planungsprozess ist substanziell.  Meist wird aber vergessen, daß die Key-User während des Testbetriebs nur eingeschränkt der Operative zur Verfügung  stehen.

In welchem Zeitrahmen sollen die Tests durchgeführt werden?

Der notwenige Zeitrahmen der Tests läßt sich relativ leicht anhand des Testkonzeptes abschätzen.

Reserven für ausgefallene Ressourcen zu planen, sollte selbstverständlich sein.

Schwer zu bewerten ist allerdings die Anzahl der Wiederholungen der Tests im Fehlerfall.

Welche (erfolgreichen) Tests müssen ebenfalls wiederholt werden, wenn ein Fehler auftritt?

(Es kommt leider nicht selten vor, daß Fehler in einem Prozess beseitigt werden, dafür aber in anderen Bereichen zu unerwünschten Nebeneffekten führen.)

Betrieblichen Erfordernissen ist gleichfalls Rechnung tragen, z.B.:

Betriebsruhezeiten, saisonale Schwankungen im Auftragsvolumen, Wartungsfenster der IT.

Dieser kurze Abriss der Planungsphase des Testmanagements  sollte verdeutlichen, daß diese Aufgaben keineswegs  „on the fly“ erledigt werden können und unter Umständen mehr Zeit beanspruchen, als die Abarbeitung der Tests selbst.

(Dieser Beitrag entstand aufgrund von Erfahrungen aus mehreren Projekten der letzten Jahre, welche durch den Autor Dr. Haka realisiert wurden.)

Fragen oder Anmerkungen sind erwünscht.