Testen statt sudern 2!

Noch mehr Tests …
… können nie schaden! Darum hat in der letzten Ausgabe der Platz nicht gereicht.

„Egal wie und welche Software Sie auswählen werden, egal ob Sie es mit mir oder ohne mich machen: Stellt jetzt Testgeschäftsfälle zusammen UND dokumentiert auch was das Ergebnis sein soll! Ihr werdet sie brauchen bei der Auswahl, bei der Einführung und bei jedem Releasewechsel!“ sage ich bereits zu meinen Interessenten – nur sehr wenige haben das – außer rudimentär für den Auswahlworkshop – auch gemacht. Ein paar G’schichtln aus der Praxis bei der ERP-Implementierung.


Mitdenken ist erlaubt!
Ein Programmierer, der beim Frühstück immer wieder über Autos redete „Der neuer XYZ gegenüber UVW ist so super!“ reagierte sauer, als ich ihm sagte: „Wenn dein Wagen so userUNfreundlich entwickelt und so schlampig getestet wäre, wie die Software, die DU lieferts, dann wärst DU schon lange tot!“. Zurück kam in patziges „Kann man nicht vergleichen“ und „die User müssten doch nur sagen was sie wollen“ – ich habe das Gespräch irgendwann abgebrochen… nicht aus Überzeugung – sondern wegen der Verdauung und um des Projektfriedens willen. Programmierer müssen sich in die Lage der User versetzen! Sie sind im wirklichen Leben auch User, also sollten sie das können!


„Na, wie soll ich DAS testen?“
Fragt ein Programmierer ziemlich patzig! Optimalerweise mit einem Testcase, den – siehe ganz oben – der Kunde beigestellt hat. Aber auf jeden Fall auch nach der Methode: „Wenn eine Herde Affen auf der Tastatur tanzt, muss die Wahrscheinlichkeit einer Fehleingabe fast Null sein!“. Als ich beim Testen auf dem Mobilgerät in das Feld Menge „asdf“ eingab sowie eine Artikelnummer die es gar nicht gab und sein Programm einfach kommentarlos weiterlief traute ich meinen Ohren nicht als ich hörte: „Na die Artikelnummer wird ja eh gescannt und in die Menge dürfen ja nur Ziffern eingegeben werden!“ HALLO!? „Dann gib’s dem Lagerarbeiter am Display aus, was dein Prog von ihm erwartet! Und wenn der QRCode nicht lesbar ist, MUSS er Artikelnummern auch über Tastatur eingeben können!“

„Das ist aber aufwändig ☹“
… sagte der Programmierer als er den Testcase bekam. JA – so ist es! Testen UND Dokumentation sind formal ein Teil der Softwarelieferung. Kein Mensch sagt, dass das nicht bezahlt wird, denn NICHT Testen und NICHT dokumentieren ist in der Nacharbeit immer exponentiell teurer also „So what!?“. Bitte auch das Testen anbieten und verkaufen liebe ERP-Anbieter!


 „Dafür hatte ich keine Zeit!“
Keyuser ist kein Ehrentitel, sondern Arbeit zusätzlich zur Arbeit! Dessen muss sich das Unternehmen aber auch die Keyuser bewußt sein. Sich auf den Programmierer zu verlassen oder auszureden gilt nicht! Bitte den Keyuser Acceptance Test durchführen – so „affig“ wie oben skizziert! Keinesfalls mit „Wird schon passen“ einfach das Programmierte weiterreichen, weil dann komm das heraus:
 „Wos is’n des fia a Schaas?“
Ist ein leider allzu oft ausgestoßener, typischer Aufschrei der Enduser. Und im blödesten Fall bereits mitten im Echtbetrieb! Gut wenn dieser von den Keyusern, Projektleitern, Programmierern ge- und erhört wird! Aber ich habe auch schon erlebt, dass mein Hinweis auf diesen Aufschrei zu einem Delegieren der Verantwortung an die Enduser führte: „Na dann müssen die User halt spezifizieren was sie anders wollen!“


Die Letzten beißen die Hunde!
Ernsthaft? Die mit dem geringsten Lohn, die nie gefragt wurden, von ihren Keyusern (oft = Vorgesetzten) im Regen stehen gelassen wurden, die sollen nun, wo es mitten im GoLive an allen Ecken brennt zu intellektuellen Höchstleistungen auflaufen und alle Versäumnisse beheben?


Workarounds sind die Lösung!
Enduser behelfen sich dann mit oft „sehr kreativen“ Lösungen wie zB. fotokopierten (!) QR-Codes auf die man erst durch die daraus entstehenden Fehlbuchungen draufkommt 😊. Und die Schuld bekommt „das neue ERP-System“ ab, weiß Ihr

Michael Schober

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert