Software-Qualität Weshalb scheitern Firmen bei der Einführung eines Testprozesses?

Der gute Wille, sich mit einem professionellen Testprozess auseinanderzusetzen, ist in vielen großen und kleinen Unternehmen gegeben. In der Umsetzung treffen diese jedoch dann häufig auf handfeste praktische Hindernisse.

Anbieter zum Thema

ET System electronic GmbH

IBR Leiterplatten GmbH & Co. KG

RECOM Power GmbH

Mixed Mode GmbH

Seminare zum systematischen Softwaretest werden bei uns in hohem Maße nachgefragt, im wesentlichen von kleineren und mittelständischen Betrieben, da die großen meist eigene Testabteilungen unterhalten. Die von uns vermittelten Leitlinien und Anforderungen an einen professionellen Testprozeß werden ausnahmslos gut angenommen und akzeptiert.

Eines der zentralen Prinzipien ist: Entwickeln und Testen sollen unabhängig voneinander nach dem Vier-Augenprinzip ablaufen. Wo nicht genügend Personal dafür zur Verfügung steht, ist es denkbar, dafür jeweils eigene Rollen mit unterschiedlicher Zuständigkeit zu definieren. Kernpunkt ist: Kein Entwickler darf seine eigene Arbeit reviewen oder testen. Die Gefahr, in dieselben blinden Flecken zu treten, ist menschlich und einfach zu präsent.

Worauf wir Dozenten aber auch mehrfach deutlich hinweisen: die Umsetzung ist nicht immer ganz einfach und trifft auf handfeste praktische Hindernisse. Spätestens bei der Nachsorge, also einem detaillierten Coaching im Betrieb selbst, treten sie deutlich zutage.

Wer soll das alles testen und wann?

Es ist nicht immer nur das Budget, das Grenzen setzt, obwohl es sehr oft die wesentliche Grenze des Machbaren darstellt. Nicht selten sind in kleineren Betrieben nicht mehr als drei bis fünf Entwickler, teilweise freie Mitarbeiter, für die Software zuständig. Ihre Auslastung ist in der Regel so, daß sie kaum zusätzlich die Rolle des Reviewers oder Testers für einen anderen übernehmen können, so daß doch wieder jeder seine eigene Arbeit testet. Nur in erfreulichen Ausnahmen wird eine personelle Aufstockung oder die temporäre Vergabe von testrelevanten Aufgaben an externe Firmen auch bewilligt.

Eine gewisse Trägheit, nach veränderten Prozessen zu arbeiten, ist trotz der Bereitschaft zur Veränderung bei z.B. Abteilungsleitern und mitunter auch bei den Entwicklern zu beobachten. Wer nie Coding Styles beachten mußte, wessen Arbeit nie von gleichgestellten Kollegen reviewt wurde, wer überhaupt nie zuerst eine Spezifikation des zu erstellenden Codes erstellt hatte, sondern gleich drauflosprogrammiert hat, der entwickelt entsprechenden Änderungen gegenüber bisweilen erstaunlich hartnäckigen Widerstand. Hier ist also weniger Geld, als vielmehr auf Ebene der Verantwortlichen die Fähigkeit zur Mitarbeiterführung gefragt.

Häufig mangelt es an einem wirklich integrierten Prozess

Dabei befinden sich branchenübergreifend die Produktionsprozesse im Umbruch: Software steuert mittlerweile Geräte, in denen sie kaum vermutet würde und sie wird - das ist eine Anforderung des Marktes, also letztlich von uns allen - immer mächtiger und scheinbar intelligenter. Damit wächst aber ihre Komplexität. Dies erfordert nicht selten die Produktionsprozesse anzupassen. Was wir aber vielfach beobachten: Nur die Softwareerstellung wird umgebaut, aber weder die vorbereitende Softwarespezifikation durchgeführt noch darauf aufbauend eine systematische Testmethodik angelegt, die parallel zur Erstellung der Software deren Fehlerhaftigkeit (neben zahlreichen anderen Qualitätskriterien) bestimmte.

Stattdessen wird nach dem althergebrachten Weg verfahren: Hard- und Software werden getrennt erstellt, integriert und anschließend das Gesamtgerät nach einer Handvoll Use Cases ausgetestet. Oft genug unter Zeitdruck, und oft genug befindet sich die Spezifikation zu einem Kernstück eines Produktes nur im Kopf eines einzigen Mitarbeiters. Dabei passiert es nicht selten, daß tiefliegende Webfehler des Codes Freigaben verzögern oder gar Rückrufaktionen erforderlich machen.

(ID:321557)