Die Top-Ten der methodischen Fehler im Software-Testing: Platz 5 – Test-Know-how wird unterschätzt

Test-Know-how wird auch heute noch als geringwertig eingestuft. Betrachten Sie hierzu einmal die Universitätslandschaft und suchen Sie in Deutschland Fakultäten oder wissenschaftliche Institute, welche sich dem Thema Software-Qualität wirklich ernsthaft annehmen. Hier gibt es einige vorbildliche Ausnahmen, mehr jedoch auch nicht. Das ist zu wenig in einem der – für die nächsten zwanzig Jahre – strategisch wichtigsten Bereiche in der Software-Industrie.

Gelegentlich frage ich bei Universitäten an, warum eine derartige wissenschaftliche Einrichtung nicht innerhalb des Campus existiert. Die interessanteste Antwort hierzu war: „Prinzipiell wäre es ein durchaus interessantes Thema. Unterdessen entwickeln wir jedoch in unseren Fakultäten Software auf einem so hohen Niveau, dass Fehler eigentlich gar nicht mehr auftreten. Offensichtlich behandeln wir bereits indirekt das Thema Softwarequalität ausreichend genug.“ Wie ehrlich die Antwort gemeint war, weiß ich nicht.

So mag es auch nicht verwundern, wenn letztlich Unternehmen das Testthema mit einem ähnlich gelagerten Stellenwert behandeln, wie es wissenschaftliche Zentren vorleben. So werden ganze Testprojekte oft an Aushilfskräfte vergeben, oder man betraut Entwickler mit den Testaufgaben. In Teilen mag es sinnvoll sein, jedoch verkümmert das Testen auf diese Weise oft zur Alibi-Veranstaltung. Generell sprechen viele Argumente gegen solche Entscheidungen, wie beispielsweise:

  1. Testen ist nicht trivial.
    Die Basis der oben geschilderten Grundhaltungen liegt oft in der Annahme, dass Testprozesse einfach seien. Ich bezeichne diese – eigentlich nicht existente – Testkategorie kurz als „Dumpfbacken-Testing“. Dieses Paradoxon geht von der Annahme aus, erfolgreiches Testen sei ohne tieferes Verständnis über die Testthematik möglich. Es ist jedoch eine Tatsache, dass Testen im Software-Umfeld profunde Kenntnisse in mindestens drei Domänen benötigt. In den Themen um das Testen (Methodologien, Technologien und Organisationen), um die technischen Detailkenntnisse bezüglich der zu testenden Produkte sowie um die verwendeten Testwerkzeuge.
  2. Entwickler können nicht testen.
    Die zunächst etwas provokativ anmutende Aussage liegt jedoch im Bereich der Psychologie begründet. Entwickler entwickeln bekanntlich ihr Produkt. Das ist deren eigentliche Aufgabe. Psychologisch gesehen ist es deren „Baby“, welches durch sie gehegt und gepflegt wird. Eine der Aufgaben besteht auch darin, alle Widrigkeiten von ihrem Entwicklungsprojekt abzuwenden, damit sich das Produkt bestmöglich entfalten kann. Das ist auch richtig und wichtig, denn wie sonst sollen Entwickler die vielen Hürden nehmen, welche bekanntlich jede Entwicklungsaufgabe in sich birgt?Der Testprozess – betrachtet unter dieser Prämisse – stellt jedoch einen destruktiven Prozess dar, da er potenziell dem Projekt schaden könnte. Das vielleicht schlechte Testergebnis könnte gar die Entscheidung nach sich ziehen, das besagte Projekt einzustellen. Die oben gemachte Aussage zielt also primär nicht darauf ab, die Kompetenz von Entwicklern infrage zu stellen, sondern sie fokussiert auf die Konfliktsituation, in welcher sich ein Entwickler bei der Übertragung qualitätssichernder Aufgaben befindet.Die Gefahr ist zu groß, dass so unbewusst nur die funktionierenden Anwendungspfade getestet werden und nicht alle möglichen. Damit wäre die Qualitätsaussage am Testende unvollständig und wenig aussagekräftig. Sinnvolle Management-Entscheidungen in Bezug auf die Produktfreigabe können so nicht getroffen werden. So verwundert es kaum, dass bei diesem Szenario in der Produktion – trotz guter Testergebnisse – noch überraschend viele Defekte auftreten. Oft hört man in diesem Zusammenhang auch als Schlussfolgerung, dass Testen wohl doch nicht sinnvoll sei. Es sei ja als Instrument ungeeignet, Defekte vorzeitig zu erkennen, bevor die Anwendung produktiv gesetzt wird.

Heute beschränkt sich Testen keineswegs mehr auf explorative Ansätze und Improvisationen. Schon längst hat sich fundamentales Wissen etabliert. Die ISTQB-Zertifikate dokumentieren dies sehr deutlich. Wer nun aber denkt, dass die besagten Zertifikate der drei Skill-Stufen („Foundation“, „Advanced“ und „Expert Level“) das Maß aller Erkenntnisse seien, der irrt.

Dieses Wissen ist als Basis-Know-how also als eine Art Standard (damit meine ich jedoch keinen Industriestandard oder keine Norm im Qualitätssinne) zu verstehen. Also im Sinne eines belastbaren Wissensfundamentes zum Aufbau weiterführender, hoch entwickelter Testtechnologien. Erst mithilfe von Testtechnologien, mit dem damit verbundenen, erweiterten Erfahrungshorizont aus deren Entwicklung wie auch dem Betrieb, entwickelt sich aus dem Testen eine Ingenieursdisziplin, welche entsprechend leistungsfähige und professionelle Testdienstleistungen ermöglicht.

Dies ermöglicht den Sprung vom Facharbeiter auf das Experten-Niveau zum anerkannten Testingenieur. Aus einem Fachgebiet wird dann eine anerkannte Wissenschaft.

Das könnte Sie auch interessieren

Bleiben Sie informiert:

its-people hilft Ihnen...

Weitere Blogthemen: