Praktisches & Grundsätzliches zur Informatik


Knowhow: Diskussion

Absolut falsche Reaktion auf negative Testergebnisse

Leider musste ich mal folgende Situation miterleben:

Ein wichtiger Kunde eines Wirtschaftberatungsunterehmens (jetzt von mir hier WBU genannt, war engagiert worden, ein für seinen Kunden — eine Gruppe von Finanzdienstleistern — wichtiges Qualitätssicherungssystem zu testen.

Der WBU vertretende Projektleiter beauftrage

  • einen Freelancer (der offenbar das notwendige finanttechnische Knowhow mitbrachte), Test Cases zu entwerfen
  • und ein Softwarehaus diesen Test dann auch zu automatisieren.

Die automatisch gut dokumentierten Ergebnisse von Black Box Test haben gezeigt, dass

  • nur für etwa die Hälfte aller (weit über hundert) Test Cases das erwartete Resultat errechnet wurde,
  • für die andere Hälfte aller Test Cases aber der im Test vom System dem Benutzer signalisierte Abweichung vom erwarteten Betrag (der immer genau eine Zahl zu sein hatte) teilweise sehr deutlich abwich.

Statt sich nun in den kritischen Fällen auf die Suche nach der Stelle im System zu machen, welche den unerwarteten Betrag liefert, oder erst mal zu fragen, ob nicht der Test Designer sich verrechnet hat, hat WBU dem Kunden empfohlen, das dem Test unterworfene neue System aufzugeben zu Gunsten von Standardsoftware.

Pikant an dieser Situation war, dass das dem Test unterworfene System einfach nur Hülle (= kunden­spezifisch gestaltete Dialogoberfläche) um ein GUI-loses Standard-Software-Paket herum war. Mit anderen Worten: Man hatte ja bereits, soweit wie irgendwie möglich, auf Standard-Software gesetzt.

Kurz: WBU hat – als für den Test verantwortlicher Dienstleister – gar nicht erst versucht, herauszu­bekommen, wo die Ursache für die festgestellten, teils gravierenden Abweichungen denn eigentlich lag. WBU hat so getan, als müsse der Fehler notwendiger Weise in der um die Standardsoftware herum gebauten GUI des zu testenden Systems liegen.

Wer genau überlegt, dem wird klar sein, dass Rechenfehler abar auch noch verursacht sein könnten

  • vom Test Designer (der nur per EXCEL gerechnet hat, um Sollergebnisse zu identifizieren) oder
  • gar in der ins neue System eingebauten Standardsoftware.

Dass vor allem die erste dieser beiden — hier vom BWU-Vertreter ver­nachlässigten oder bewusst totgeschwiegenen — Möglichkeiten eine recht wahrscheinliche darstellt, hat er seinem Kunden nicht erklärt.

Ob man das eben erst entwickelte Software-Produkt auf den so unsagbar inkompetenten Ratschlag des teuer bezahlten Unternehmensberaters hin tatsächlich aufgegeben hat, habe ich leider nie erfahren.

Diskussion


Dieses Beispiel zeigt sehr deutlich, dass einem Testmanager vor allem klar sein sollte, wo seine Verantwortung beginnt und endet.

Im vorliegenden Fall war ihm zwar klar, wo sie endet, aber nicht, wie früh schon sie beginnt. Genauer: Er hat versäumt, den Test Designer ebenso wie den Testautomatisieren eine richtige Definition des Testlings zu geben und auch, womit die SOLL-Ergebnisse berechnet sein müssen, damit sie wohldefinierte, der Testaugabe angemessene Quaöität haben.

Wer sich, wie er es tat, auf den Standpunkt stellt, dass Standardsoftware ausreichend fehlerfrei rechnet, dem hätte klar sein müssen, dass

  • die vom Testdesigner bereitgestellten Werte für SOLL-Ergebnisse hier unbedingt anhand der Standardsoftware errechnet hätten sein müssen, um die herum die Anwendung implementiert wurde,
  • Mit anderen Worten: Wer – wie in diesem Fall geschehen – den Test als Black-Box-Test der gesamten Anwendung organisiert, dem hätte die Pflicht zukommen müssen, zunächst mal zu beweisen, dass die vom Test-Designer errechnete Sollwerte tatsächlich übereinstimmen mit denen, welche die in der Anwendung verbaute Standardsoftware liefert.
  • Die Pflicht der Entwickler, Anwendungscode zu debuggen kann sich ja schließlich immer nur auf den durch sie implementierten Code beziehen (der in disem Fall ja einfach nur die Aufgabe hatte, korrekt gebaute Aufrufe der Standardsoftware zu veranlassen und dann deren Ergebnis unverändert an die Dialogoberfläche der Anwendung zu transportieren).
  • Ansonsten ist natürlich richtig, dass Test das Aufdecken von Fehlern zur Aufgabe hat, aber nicht notwendig auch Debugging von Code, der falsche Ergebnisse liefert — dann jedenfalls, wenn Black-Box-Test vereinbart war (wie es bei Abnahmetest ja stets der Fall sein wird).

    Dennoch muss vom Tester natürlich verlangt werden, dass, wo Diskrepanzen entdeckt werden zwischen dem Rechenergebnis des Testlings und den Vorstellungen des Testdesigners vom erwarte­ten Sollergebnis, solche erst dann als Fehler des Testlings einstuft werden, wenn nachgeprüft wurde (also insbesondere nachprüfbar ist), dass der Rechenfehler dem Testling, aber keinesfalls dem Testdesigner anzulasten ist. Den Beweis dafür hat geeignete Dokumentation von Testdesign zu erbringen, insbesondere Dokumentation des Verfahrens, mit dem man im Rahmen von Testentwurf zu erwartende Sollergebnisse errechnet hat.

    Erst die Tatsache, dass sie im vorliegenden Fall gefehlt hat — wie ja nicht selten in anderen Testpro­jekten auch — hatte zur Folge, dass der Testmanager sich letztendlich für mit seiner Aufgabe über­fordert sah und so auf die Idee kam, seinem Kunden zu empfehlen, die implementierte Anwendung als unbrauchbar abzuschreiben.

    Es ist deswegen dieser Vorfall auch guter Beweis dafür, dass professionell implementierter Test auf Test-Design-Dokumentation einfach nicht verzichten kann. Jeder, der Tester beauftragt, sollte das wissen.

    Ineressant in diesem Zusammenhang: Durch die Entwickler von Anwendungssoftware erstelltes, schriftlich dokumentiertes Testdesign ist mir während der gesamten 30 Jahre meine Tätigkeit in einem renommierten Softwarehaus, das auch eigene Produkte entwickelt hat, seltsamerweise nie begegnet(!). Das, so denke ich, sagt viel aus über die leider in vielen Fällen immer noch erstaunlich geringe Professionalität von Software-Entwicklern.




stw4504IASCRUMInformatik . Agile . SCRUMNews?

Mehr + B G E + S H A + More