Die um sich greifende Regulierung des Entwicklungsprozesses und des IT-Betriebs führen dazu, dass sich Unternehmen zunehmend mit den Themen Testing und Qualitätssicherung auseinandersetzen. Doch die Qualitätsansprüche an Softwaresysteme fallen aufgrund der individuellen Sichtweise der Beteiligten sehr unterschiedlich aus. Die Anwender wollen ein intuitiv zu bedienendes GUI und möglichst kurze Antwortzeiten. Der Auftraggeber erwartet möglichst niedrige Kosten und eine rechtzeitige Inbetriebnahme. Für den Support ist eine weitgehend fehlerfreie Anwendung wichtig. Der Sicherheitsbeauftragte, das Controlling und andere Regelgremien wollen Anwendungen, die prüfbar und normenkonform sind. In der Theorie ist alles einfach. Man nehme die Qualitätsnormen nach ISO oder DIN, wie beispielsweise den Qualitätsbegriff nach ISO 8420, suche sich das entsprechende Qualitäts-Management-System (ISO-9000-Reihe, TQM, EFQM, IQM oder IMS) aus den über 30 verfügbaren Qualitätsmodellen aus und appliziere es auf den Software-Entwicklungsprozess.
In der Praxis sieht die Sache jedoch ganz anders aus, insbesondere in der Individualentwicklung oder der unternehmensspezifischen Erweiterung von Standardprodukten. Allein das Testen und die Verifizierung von Software kennt eine Unzahl von Standards, Methoden und Tools, die in der Praxis der Entwicklungsprojekte kaum oder nur sehr beschränkt anzuwenden sind. In der Individualentwicklung kommt hinzu, dass die Kosten, die mit der Qualitätssicherung einhergehen, nicht zu tragen sind. Es findet sich kein Kunde, der einen Aufpreis von bis zu 50 Prozent, wie beispielsweise Ian Sommerville in seinem Buch "Software Engineering" schätzt, zu zahlen bereit ist.
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.
Foto: Trivadis
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.
Was wirklich gut funktioniert
Jedes Testhandbuch und jeder Leitfaden für das Testen von Software enthalten den Satz: Es kann gar nicht genug getestet werden. Leider ist dies ein schlechter Ratgeber in einer Situation, in der Kosten und Zeit die zentrale Rolle bei der Erstellung und beim Unterhalt von Softwaresystemen spielen. Deshalb empfiehlt sich ein pragmatisches Vorgehen, das sechs wichtige Instrumente beinhaltet: Entwicklungsrichtlinien zur Fehlervermeidung, die unterschätzten Reviews, eine Änderung der Unit-Test-Praxis, der kluge Einsatz automatisierter Test-Tools, der Ausbau von Tracing und Logging und die vollständig getrennte Prüfung der Datenqualität.
-
Richtlinien zur Fehlervermeidung: Jede Individualentwicklung sollte auf Richtlinien zur Vermeidung von Softwarefehlern beruhen. Eine wesentliche Voraussetzung ist das Vorhandensein und die Anwendung so genannter Code-Conventions. Dabei schadet es überhaupt nicht, diese Richtlinien für ein Unternehmen in Zusammenarbeit mit dem Fachpersonal festzulegen. Der Aufwand hält sich in Grenzen, die disziplinierte Umsetzung ist dann jedoch wesentlich einfacher. "Design for Performance" und "Defensive Programming" sind Prinzipien, die in solche Unternehmensrichtlinien gehören.
-
Reviews: Reviews und im Speziellen Peer Reviews und formale Reviews sind das beste Mittel, um Fehler zu finden. In Kombination mit einer klugen Auswahl kritischer Module, Klassen, Komponenten oder Services sind sie ein wirkungsvolles Mittel, um die Qualität eines Systems zu verbessern. Allerdings setzen sie ein bestimmtes Betriebsklima voraus, welches gegenseitige Anschuldigungen und Besserwisserei vermeidet, dafür die gegenseitige Akzeptanz fördert.
-
Unit-Tests: Die heutige Praxis des Unit-Tests dient lediglich dazu, den Normalfall zu testen. Dieselbe Person, die den Code produziert, erzeugt auch die Unit-Tests. Dieser Zustand muss verändert werden. Die Unit-Tests einer Klasse sollten gerade nicht von derjenigen Person entwickelt werden, die die Klasse realisiert. Denn wer testet sich schon gern selbst? Zudem sind Unit-Tests dann sinnvoll, wenn sie so aufgebaut sind, dass sie im Rahmen der nachfolgenden System- und Integrationstests weiterverwendet werden können. Sie sollten also auf jeden Fall von außen ansteuerbar sein.
-
Automatisierte Test-Tools: Der Einsatz automatisierter Test-Tools, die über die reine Testverwaltung hinausgehen, ist in der Individualentwicklung nur bei großen Systemen zu evaluieren. Die Verwendung von GUI-Testern ist selten für Unternehmensanwendungen sinnvoll, da die Erstellung guter Testskripts genauso komplex ist wie die Entwicklung des GUI. Gute systemübergreifende End-to-End-Test-Suiten sind noch in den Kinderschuhen und werden sich erst im Laufe der nächsten Jahre in der Individualentwicklung durchsetzen. Auch unterschätzen nach wie vor viele Unternehmen die Problematik der Bereitstellung und Reproduktion realitätsnaher Testdaten.
-
Tracing und Logging: Die durchschnittliche Lebenszeit einer Anwendung in einem Unternehmen liegt bei zwölf bis 15 Jahren. Während dieser Zeit verändert sich das Umfeld der Anwendung stark. Der Betrieb und Unterhalt von Programmen und im Speziellen die Fehlersuche werden kräftig vereinfacht, wenn Tracing- und Logging-Fähigkeiten zur Verfügung stehen und die Software diese Mechanismen auch zulässt. So sollten beispielsweise Tracing- und Logging-Levels zur Laufzeit geändert werden können. Davon sind die meisten Individualsysteme weit entfernt. Der zusätzliche Aufwand zur Entwicklungszeit hält sich jedoch in Grenzen, sofern ein unternehmensweites Konzept zur Verfügung steht.
-
Getrennte Prüfung: Die durchschnittliche Lebenszeit von Daten in einem Unternehmen beträgt 20 bis 30 Jahre. Daten leben also im Schnitt bedeutend länger als Anwendungen. Schon allein aus diesem Grunde sollte die Qualität von Daten getrennt von der Qualität der Anwendungen geprüft werden. Mehr und mehr Unternehmen realisieren im Rahmen von IT-Governance-Projekten nicht nur Sicherheits- und Projekt-Management-Richtlinien, sondern auch Policies zur Umsetzung von Data-Quality-Management (DQM).
Testmethoden auf einen Blick
Architecture & Design Inspections: Inspektionen werden auch Reviews, Walkthroughs oder Audits genannt. Dabei werden die zu testenden Artefakte (Dokumente oder Code) durch Fachpersonal geprüft. Die Prüfung kann mittels formeller Methoden, wie beispielsweise nach Fagan, oder in freien Verfahren erfolgen.
Unit-Test: Mittels Unit-Test (auch Modul- oder Komponententest genannt) werden einzelne Komponenten einer Anwendung geprüft. Unit-Tests werden oft im Rahmen der Softwareentwicklung vorgenommen.
Systemtest: Mit einem Systemtest werden alle Komponenten einer Anwendung, die neu, geändert oder von einer Änderung betroffen sind, geprüft. Ein Systemtest erfordert meist mehrere Durchläufe und ist daher ein wichtiger Kandidat für automatisierte Testläufe. Systemtests fallen oft in den Bereich dedizierter Testabteilungen.
Integrationstest: Der Integrationstest prüft das System mit allen notwendigen Komponenten und umgebenden Systemen. Begleitet werden sie häufig von speziellen Tests wie Compatibility-, Performance-, Stress- und Load-Tests. Integrationstests sind die Aufgabe von dediziertem Testpersonal oder der Administration. Ihre Abnahme wird oft "Operational Acceptance" genannt.
User-Acceptance-Test: Diese Tests werden oft auch Betatests, Anwendungstests oder auch End-User-Tests genannt. Sie erfolgen durch die Anwender.
Product Verification: Diese Art von Test wird auch Abnahmetest genannt. Grundlegende Eigenschaft der Product Verification ist die Tatsache, dass unter produktiven Bedingungen mit den entsprechenden Mengengerüsten (Daten, Benutzer, Konfiguration etc.) getestet wird.
Übersicht: Was lässt sich wie und womit testen
|
Eigenschaft |
Erklärung |
Testbarkeit |
Testmittel |
|
Performance (Reaktionszeit/Durchsatz) |
Garantie der geforderten Antwortzeiten. |
Schwierig, nur im Betrieb möglich. |
Performance-Test im Rahmen von Integrationstests. |
|
Sicherheit |
Schutz vor nicht autorisiertem Zugriff und mutwilliger Zerstörung. |
Sehr schwierig, nur punktuell möglich. |
Security-Audits und Reviews. |
|
Verfügbarkeit |
Ein System muss zur Verfügung stehen und dabei definierte Mindestanforderungen erfüllen. |
Schwierig, mittels Statistiken (Uptime, MTBF, RTO, RPO) im Betrieb. |
Betriebsstatistik, Messung nur im laufenden Betrieb über die Zeit möglich. |
|
Usability |
Einsetzbarkeit für den vorgesehenen Zweck. |
Schwierig, erfordert sehr gute Anforderungsdefinitionen. |
User-Acceptance-Test (UAT). |
|
Stabilität |
Die Anwendung muss stabil laufen und darf auch unter großer Belastung ihren Dienst nicht teilweise oder ganz einstellen. |
Sehr schwierig, Fehlersituationen treten oft nur punktuell auf. |
Lasttests. |
|
Skalierbarkeit |
Die Anwendung muss ausgebaut werden können. |
Sehr schwierig, Simulation sehr komplex. |
Keine. |
|
Integrierbarkeit |
Ein System muss sich nahtlos in eine existierende Umgebung einfügen lassen. |
Machbar, jedoch erst in späten Projektphasen. |
Integrationstest. |
|
Portabilität |
Unterstützung verschiedener Plattformen. |
Machbar, oft durch separate Entwicklungssysteme gewährleistet. |
Systemtest auf verschiedenen Plattformen. |
|
Wartbarkeit |
Nachweis definierter Wartungsschnittstellen und klare Struktur. |
Machbar unter Einbezug des Betriebspersonals. |
Reviews. |
|
Wiederverwendbarkeit |
Systemteile müssen sich für andere Systeme wiederverwenden lassen. |
Schwierig: Gefahr der falschen Generizität. |
Keine. |
Barry Boehms Richtlinien zur Fehlervermeidung
-
Auffinden und Beheben von Fehlern ist nach der Auslieferung oft hundertmal teurer, als in der Anforderungsanalyse oder im Design.
-
Die meisten Softwareprojekte verschwenden 40 bis 50 Prozent der Zeit mit vermeidbaren Nacharbeiten.
-
80 Prozent der vermeidbaren Nacharbeiten werden durch 20 Prozent der Fehler verursacht.
-
80 Prozent der Fehler kommen von 20 Prozent der Module, etwa die Hälfte aller Module sind fehlerfrei.
-
90 Prozent der Ausfallzeit eines Systems werden durch zehn Prozent der Fehler verursacht.
-
Mit Peer Reviews werden 60 Prozent der Fehler gefunden.
-
Mit formalen Review-Techniken werden 35 Prozent mehr Fehler gefunden als mit informellen Reviews.
-
Personal, welches diszipliniert mit Richtlinien arbeiten kann, vermindert das Aufkommen von Fehlern um 75 Prozent.
-
Es kostet 50 Prozent mehr pro Codezeile, wenn Code nahe an der Zielumgebung produziert wird. Dadurch sinken aber die Betriebskosten - der Aufwand lohnt sich oft.
-
Zwischen 40 bis 50 Prozent der benutzten Software enthalten nicht triviale Fehler.
Ausblick
In Zukunft wird die Qualitätssicherung von Software und Systemen integraler Bestandteil der IT-Governance eines Unternehmens werden. IT-Governance wird heute in vielen Unternehmen mit dem Ziel formuliert, den Wildwuchs, die Heterogenität und die Kosten der betrieblichen Informationssysteme in den Griff zu bekommen. Größere Unternehmen und Verwaltungen definieren Richtlinien, etablieren IT-Governance-Boards und Kennzahlen (Key-Performance-Indikatoren) zur Steuerung, Messung, Kontrolle und Überwachung der IT-Prozesse. Die Integration des Qualitäts-Managements wird dann zum Instrument der Messung und Kontrolle. Das Software-Artefakt der Zukunft wird der Service sein, der auf Unternehmensebene auch die qualitätsrelevante Größe darstellt. Bis dahin sind eine pragmatische Umsetzung von Qualitätsnormen auf Prozessebene und der Einsatz einer klugen Sammlung aus Fehlervermeidungs- und Testvorgehen die besten Mittel, um die durchschnittliche Qualität einer Anwendung zu vertretbaren Kosten zu erhöhen.
Und bei der ganzen Testerei sollte eine grundlegende Tatsache niemals vergessen werden: "Tests können nur die Anwesenheit von Fehlern aufzeigen, nicht ihre Abwesenheit" (Dijkstra). (ue)