Produkt- oder Prozessqualität?

Spätestens seit der Einführung der ISO-Norm 9126 (Software Engineering, Product Quality) existiert ein allgemein anerkannter Qualitätsbegriff für Software: Softwarequalität ist demnach "die Gesamtheit von Eigenschaften und Merkmalen eines Softwareprodukts oder einer Tätigkeit, die sich auf dessen Eignung zur Erfüllung gegebener Erfordernisse beziehen".

Der Standard und seine DIN-66272-Entsprechung listet sechs Qualitätsmerkmale (Portability, Functionality, Reliability, Maintainability, Efficiency und Usability) auf und sieht eine Quantifizierung über interne und externe Metriken vor. Die Übertragbarkeit (Portability) ist der Grad der Eignung der Software, von einer Umgebung in eine andere übertragen zu werden, die Funktionalität der Abdeckungsgrad in Bezug auf die Anforderungen, die Zuverlässigkeit (Reliability) bestimmt die Fähigkeit der Software, unter bestimmten Bedingungen lauffähig zu sein, während die Änderbarkeit (Maintainability) den Änderungsaufwand spezifiziert. Die Effizienz beschreibt das Verhältnis zwischen Leistungsniveau der Software und den eingesetzten Betriebsmitteln, und die Benutzbarkeit bestimmt den Aufwand zur Nutzung der Software durch die Anwender. Allerdings sind die Metriken leider nicht festgelegt, so dass eine formale oder auch automatisierte Prüfung der Merkmale in der Praxis kaum umgesetzt worden ist.

Eine grundlegende Schwierigkeit ist, dass die Tests dieser Merkmale - wenn überhaupt - nur mit großem Aufwand möglich sind und immer im Gesamtkontext des Systems gesehen werden müssen. Wesentlich einfacher ist es dagegen, Tests im Rahmen der einzelnen Phasen der Softwareentwicklung vorzunehmen. Konkret bedeutet dies, dass im Rahmen der Projektphasen die entsprechenden Tätigkeiten für das Qualitäts-Management eingeführt werden.

Dazu findet in einem pragmatischen Ansatz während der ersten Projektphasen (Analyse und Grobspezifikation) die Qualitätsplanung statt. Sie umfasst die Festlegung der Merkmale und Messwerte sowie die Ausführungsszenarien in Form von Testplänen. Die Qualitätssicherung, also die Maßnahmen zur Abwicklung der Qualitätskontrolle, wird anschließend während der Feinspezifikation definiert. Die Qualitätskontrolle selbst findet während der restlichen Projektphasen statt. Es gibt jedoch auch einen Nachteil dieses Vorgehens: In realen Projekten werden die Testphasen oft als zeitlicher Puffer für die Entwicklung verwendet, so dass Testpläne und Testfälle schnell von der Projektrealität überholt werden und damit zum Papiertiger verkommen. Trotzdem ist dieses Vorgehen einfach und sinnvoll und stellt lediglich eine einfache Erweiterung des normalen Projekt-Management-Prozesses dar.

Das Fehlerproblem

Ein zentraler Ansatz für das Testing könnte sein, dass Fehlerursachen, Auftretenswahrscheinlichkeiten, Häufigkeiten und Ort bekannt wären. Leider existieren nur sehr wenige Fehlerstatistiken. Selbst die viel zitierte "Chaos"-Studie der Standish Group, die zumindest den Erfolg von Softwareprojekten auflistet, ist vom renommierten Honorarprofessor und Autor des "Journal of Systems and Software", Robert L. Glass, vollständig in Frage gestellt worden. Er hat nachgewiesen, dass die Zahlen keinerlei statistischen Wert besitzen. Die Standish-Zahlen sind durch den Bericht "A Replicated Survey of IT Software Project Failures" der Universität Ottawa und Maryland aus dem Jahr 2008 vollständig widerlegt worden. Es gibt allerdings Untersuchungen für einzelne Systeme. So haben die Statistiken der AT&T-Mitarbeiter Perry und Evangelist gezeigt, dass bis zu 66 Prozent aller Fehler in den Schnittstellen auftreten. Meistens handelt es sich dabei um Konstruktionsfehler (13 Prozent), nichtadäquate Funktionalität (13 Prozent), mangelhafte Fehlerbehandlung (15 Prozent) und schlechtes Postprocessing (10 Prozent). Es sind genau die Schnittstellen, die viel zu oft vernachlässigt und in modernen Modellierungsmethoden auch zu wenig detailliert erfasst werden. Allein schon die explizite Modellierung eines Schnittstellenablaufs mit den Schritten Exportieren, Validierung der exportierten Daten, Transformation, Konversion, Validierung der zu importierenden Daten und Import in das Zielsystem hilft, fehlerhafte Schnittstellen zu vermeiden. Eine für die Praxis sehr nützliche Richtlinie hierfür ist die "Top 10 Defect Reduction List" von Barry Boehm.