Die Bedeutung der Stakeholder beim Softwaretest

Führt man in einem Unternehmen qualitätssichernde Maßnahmen im Bereich Softwaretest ein, so kann man dabei durchaus auf Widerstände treffen. Darüber berichtete Dr. Jan Overbeck bereits in der Dezember-Ausgabe des SQ-Magazins, der Mitgliedszeitschrift des Arbeitskreises Software-Qualität und Fortbildung (ASQF).

Da hat man es mit einem Problem zu tun, das in nahezu allen Changemanagement-Situationen auftreten kann, wenn Neuerungen im Unternehmen etabliert werden sollen. Die davon Betroffenen müssen zu Beteiligten gemacht und eingebunden werden.

Im Falle der Testprozesse und –methoden sind das i.d.R. Entwickler, künftige Anwender, Projektleiter und Steuerungsgremien, Manager und Controller.

Softwaretests finden im Idealfall Fehler. Das werten manche Entwickler nicht als qualitätssichernden Schutz ihrer Arbeit sondern als Bloßstellung und Infragestellung ihrer Kompetenz. Andererseits ist Softwareentwicklung immer auch Teamarbeit. Und das Team  nur dann erfolgreich, wenn es ein qualitativ einwandfreies Produkt termin- und budgetgerecht abliefert. Dabei hilft die Qualitätssicherung.

Aus der Sicht künftiger Anwender bedeuten Tests, Ablenkung von ihren tagesgeschäftlichen Aufgaben. Sie wollen das fertige Produkt einsatzbereit und schlüsselfertig installiert haben. Dessen Zustandekommen ist für sie erst mal nicht so wichtig, zumal dafür ja gut bezahlte Spezialisten engagiert wurden. Andererseits sorgt die frühzeitige Einbindung der Anwender für ein anforderungsgerechtes praxistaugliches Produkt. Sie erhalten so Gelegenheit die Zukunft ihrer eigenen Arbeitsabläufe mitzugestalten.

So mancher Projektleiter sieht in Softwaretests  eher Störfaktoren, die seinen Projekterfolg beeinträchtigen, da i.d.R. als Folge daraus etwas nachgearbeitet oder umgeschrieben werden muss. In komplexeren Projekten mit mehreren Teilprojektleitern kann da der Testleiter schon mal in die Defensive kommen, wenn sein Tester-Team etwas gefunden hat, dessen Korrektur mehrere Teilprojekte in Verzug bringt.

Hinzu kommt die Neigung von Projektleitern, das Testen als disponiblen Kostenfaktor in seine Gesamtplanung zu betrachten, dessen Umfang er von der allgemeinen Termin- und Budgetsituation seines Projektes abhängig macht. Allerdings zeichnen sich ordentlich geplante Projekte auch durch eine definierte Qualität des abzuliefernden Ergebnisses aus. Da gibt es eigentlich keinen Platz für Versuche, daran etwas „wegzuoptimieren“. Idealerweise ergibt sich aus den definierten Qualitätseigenschaften des zu entwickelnden Systems auch ein messbares Testendekriterium, so dass erkannt und beurteilt werden kann, wann das Testen fachlich abgeschlossen ist. Auch wenn solche Testendekriterien im Projekt dann gerne mal aufgeweicht und „flexibilisiert“ werden, um die Testphase abkürzen zu können. Oft genug auf Kosten der abgelieferten Softwareproduktqualität, wie die zahlreichen Patches, Fixes und Bugtrack-Seiten im Internet zeigen.

Und in den Augen vieler General Manager oder Controller ist Testen ohnehin überflüssig, wenn man von Beginn an darauf achtet, alles richtig zu achten. Leider ist die Komplexität moderner Softwareprodukte nicht immer so managertauglich. Der Grundgedanke des Managers hier besteht darin, dass Fehler schlecht sind, weil sie Zeit und Geld kosten.  Dem kann man entgegnen, dass der unbemerkte Verbleib der Mängel im Produkt eher noch teurer kommt und zudem Reputation beim Kunden kostet. Außerdem sind aufgedeckte Fehler stets auch Lernchancen und Möglichkeiten, die Entwicklung des Produktes zu optimieren.

Für Tester, Testmanager und Testprojektleiter sind daher eine gute soziale Kompetenz sowie Konfliktfähigkeit entscheidende Faktoren für den Erfolg ihres Wirkens. Denn sie werden immer wieder einzelne (oder auch alle) der erwähnten Stakeholder von der Notwendigkeit und  dem Sinn ihres Tuns überzeugen müssen. Dabei können sie sich beim „Kampf für Qualität“ durchaus Vorgehensweisen von Qualitätsmanagern in der produzierenden Industrie aneignen, die diese Konflikte bereits vor Jahrzehnen auszufechten hatten. Und deren Tätigkeit heute allgemein akzeptiert und nicht aus den Fabriken wegzudenken ist.

Jeder BWL-Student wird heute mit den Grundlagen kontinuierlicher Verbesserungsprozesse (KVP) und dem Qualitätsmanagement in der Fertigung vertraut gemacht. Aber längst noch nicht jeder Informatiker befasst sich im Verlauf seines Studiums mit Grundfragen der Softwarequalität und der Qualitätssicherung im Entwicklungsprozess.