Suchen

Angemerkt „Softwarequalität muss von Anfang an gelebt werden“

| Redakteur: Franz Graser

John Paliotta, Chief Technology Officer des Testspezialisten Vector Software, warnt davor, Softwarequalität nur als eine Frage des richtigen Testwerkzeugs zu sehen: Tools müssen vielmehr in einen stimmigen Prozess eingebettet sein.

Firmen zum Thema

John Paliotta ist Mitbegründer und Chief Technology Officer des Testlösungs-Spezialisten Vector Software.
John Paliotta ist Mitbegründer und Chief Technology Officer des Testlösungs-Spezialisten Vector Software.
(Bild: Vector Software )

Die Verbesserung der Softwarequalität ist ein Problem mit vielen Facetten. Werkzeuge allein genügen nicht; es ist vielmehr ein Prozess nötig, in den diese Tools eingebettet sind. Und jedes Mitglied des Teams muss Teil der Lösung des Qualitätsproblems sein.

Also nicht nur die Leute in der Qualitätssicherung – was ja eigentlich eine Fehlbezeichnung ist: Der Begriff drückt nämlich das Wunschdenken aus, dass die Qualität irgendwie am Ende in das Produkt hineinkommt. Schon allein die Idee ist Wahnsinn. Qualität muss von Anfang an gelebt werden, sie sollte nicht erst am Ende irgendwie in das Produkt eingefügt werden.

Vielleicht hilft hier eine Analogie: Physikalische Produkte werden heute mit einem sehr hohen Qualitätsgrad gefertigt. Die Fertigungsindustrie hat in den 70er und 80er Jahren eine unbarmherzige Gewissenserforschung betrieben, um herauszufinden, wo im Produktionsprozess Geld verschwendet wurde.

Wenn zum Beispiel in den 60er Jahren bei einem Auto ein Teil kaputtging, dann wurde das Teil in der Werkstatt ausgetauscht, an die Fabrik zurückgesandt und dann eingeschmolzen. Dann aber begann man sich zu fragen: „Warum analysieren wir die betroffenen Teile nicht und dringen zur Wurzel des Problems vor? Und auf diese Weise können wir die Kosten drücken!“

Viele Unternehmen, die sich darauf nicht einstellen konnten, sind gescheitert. Toyota hat auf diese Weise die amerikanischen Autohersteller niedergerungen, denn die Japaner legten als erste den Fokus auf die Qualität in der Fertigung.

Analog dazu kann man sich fragen, was besser ist: Einen Bug in der Software zu haben und gut darin zu sein, ihn zu beseitigen, oder den Bug eben nicht zu haben? Dazu muss man sich nur den Hockeyschläger-Graphen ansehen, die am meisten überbeanspruchte Kurve in der Geschichte der Software.

Daraus geht hervor, dass es vielleicht einen Euro kostet, den Bug früh im Prozess zu beheben – also auf der linken Seite des Graphen – aber 10.000 Euro, den Fehler später zu fixen – auf der rechten Seite der Kurve. Das weiß jeder.

Doch jetzt kommt das große Aber: Es gibt immer den Druck, das Veröffentlichungsdatum weiter nach links zu verschieben, um so schnell wie möglich zu sein. Für mich ist das ein Trugschluss. Der Trugschluss liegt darin, zu glauben, das Veröffentlichungsdatum nach vorne zu verschieben, ohne dass es einen spürbaren Effekt gäbe.

Das ist aber falsch: Entweder erzeugt man dadurch einen Haufen latenter Fehler in der Software oder man belässt einen Haufen latenter Bugs darin.

Aber wie geht man das Qualitätsproblem an? Es gibt verschiedene Strategien: Testen, statische Analyse, Codemodellierung und noch vieles mehr. All diese Dinge sind gut, aber es passiert eben immer wieder, dass die Menschen zu viel Hoffnung darin setzen. Sie denken: „Ich muss nur einen Knopf drücken, und plötzlich habe bessere Softwarequalität.“ So eine Lösung wird nie existieren.

Wenn man sich nun den Hockeyschläger-Graphen ansieht, dann liegt es auf der Hand, dass es billiger ist, Fehler früh aufzuspüren. Viele Firmen gehen bei der Entwicklung so vor, dass die Teammitglieder isoliert arbeiten und ihre Änderungen dann in einen Master-Versionszweig integriert werden. Erst dann werden die meisten Testfälle ausgeführt. Und die Qualitätssicherung muss dann nachvollziehen, welcher Entwickler und welche Code-Änderung einen bereits existierenden Test fehlschlagen ließ.

Aus unserer Sicht sollte jedes Teammitglied bei jeder Änderung jeden Test laufen lassen. Man sollte sicherstellen, dass alle Tests über die ganze Organisation hinweg auf Grün stehen, bevor man die Änderungen an das Integrationsteam weiterleitet. Dann müssen die Qualitätssicherer viel weniger Zeit darauf verwenden, um zu ermitteln, warum Dinge fehlschlagen, die vorher funktioniert haben. Sie können mehr Zeit darauf verwenden, neue Funktionen zu testen.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 43230359)