Die Maßnahmen, die bewußt darauf ausgerichtet sind, die für ein Softwareprodukt geforderte Qualität zu erreichen, werden unter dem Begriff "Qualitätssicherung" subsumiert. Während die konstruktiven Maßnahmen insbesondere In der ersten Hälfte der 70er Jahre im Vordergrund der Betrachtung standen, hat sich doch die Einsicht durchgesetzt, daß diese alleine nicht ausreichen, sondern analytische Maßnahmen in jedem Fall erforderlich sind. Während in den Teilen 1 und 2 dieser Serie generell, im Zusammenhang mit der Qualität von Software stehende Aspekte angesprochen wurden, steht in diesem Teil das Testen als eine analytische Maßnahme der Qualitätssicherung Im Vordergrund. Es wird sowohl auf die Durchführung des Testens von Dokumenten und Programmen als auch auf die Planung und Kontrolle eingegangen.
Analytische Maßnahmen der Qualitätssicherung sind - wie vorstehend ausgeführt - solche Maßnahmen, die Ergebnisse (Zwischen-/Endprodukte) im Software-Lebenszyklus analysieren, um einerseits Fehler aufzudecken sowie darüber hinaus Aussagen über die Qualität der vorliegenden Produkte zu machen.
Analytische Maßnahmen sind entgegen der vielfach vertretenen Beschränkung auf die Zuverlässigkeit von Softwareprodukten (Qualitätsmerkmale Richtigkeit, Robustheit und Sicherheit) auf alle Qualitätsmerkmale bezogen, wenn auch die einzelnen analytischen Maßnahmen in unterschiedlichem Maße zur Beurteilung von Softwareprodukten hinsichtlich der einzelnen Qualitätsmerkmale geeignet sind.
Unpraktikable Beweisführung
Folgende Klassen analytischer Maßnahmen sollen unterschieden werden:
- Beweisen
- Symbolische Ausführung
- Testen
Beweisen beinhaltet eine formale Vorgehensweise zur Prüfung der funktionalen Korrektheit eines Programms und bezieht sich ausschließlich auf das Qualitätsmerkmal Richtigkeit. Die symbolische Ausführung ist eine Methode zur Prüfung von Programmen durch interpretative Ausführung und bezieht sich ebenfalls auf das Qualitätsmerkmal Richtigkeit; hierbei werden Pfadprädikate und darauf aufbauend Eingabedatenbereiche bestimmt, die zu verifizieren sind. Testen ist eine informelle Vorgehensweise, durch die zwar das Vorhandensein von Fehlern, nicht aber deren Nichtvorhandensein nachgewiesen werden kann. Testen dient der Prüfung von Zwischen- und Endprodukten im Software-Lebenszyklus in bezug auf sämtliche Qualitätsmerkmale.
Während das Beweisen trotz langjähriger, teilweise intensiver Bemühungen nicht zu einer praktikablen analytischen Maßnahme avancieren konnte, stellt die symbolische Ausführung einen vielversprechenden Ansatz dar, der allerdings im jetzigen Stadium noch teilweise erhebliche Restriktionen aufweist, die einem industriellen Einsatz entgegenstehen.
Durch Testen können bei nicht-trivialen Softwareprodukten zwar nicht alle Fehler garantiert gefunden werden, es handelt sich hierbei jedoch um eine praktikable Vorgehensweise, die insbesondere dann zu zufriedenstellenden Ergebnissen führt, wenn hierbei systematisch; vorgegangen wird.
Auch Dokumente sind Testobjekte
Testen ist eine analytische Maßnahme zur Aufdeckung von Fehlern in Zwischen- und Endprodukten im Softwarelebenszyklus. Fehler sind sämtliche Abweichungen zwischen dem geforderten und dem tatsächlich realisierten Aufbau und Verhalten von Softwareprodukten.
Testen bezieht sich nicht nur auf den Entwicklungsprozeß, sondern auch auf den Betrieb und die Wartung. Neben den unterschiedlichen "Entwicklungsprozeß" (Anforderungstest, Quellprogrammlistentest, Modultest, Integrationstest, Systemtest etc.) sind der "Betriebstest" als Bezeichnung für die Testphase, die kontinuierlich oder sporadisch im Laufe der Nutzung eines Softwaresystems durchzuführen ist und unabhängig von aufgedeckten Fehlern oder durchgeführten Änderungen/ Erweiterungen erfolgt, und der "Wartungstest" als Bezeichnung für die Gesamtheit der Testaktivitäten, die aufgrund der Pflege oder Änderung von Softwareprodukten erforderlich sind, zu nennen.
Gegenstand des Testens (Testobjekte) können sämtliche Zwischen- und Endprodukte sein, die im Rahmen eines Softwareprojekts erstellt werden. Testobjekte sind somit nicht nur Programme, sondern - insbesondere aufgrund der Vielzahl derartiger Produkte - auch Dokumente. Dokumente werden insofern als Testobjekte bezeichnet, als für diese Art von Testobjekten teilweise gleiche Methoden und Verfahren des Testens eingesetzt werden sowie ähnliche Prüfungen erforderlich sind. Für das Testen von Dokumenten werden teilweise andere Bezeichnungen (Inspektion, Review, etc.) verwendet.
Die Bedeutung des Testens von Dokumenten ist dadurch begründet, daß nach empirischen Untersuchungen die Mehrzahl der während des Softwarelebenszyklus gefundenen Fehler schon bei der Erstellung der Anforderungs- oder Entwurfsspezifikation verursacht wird und nur ein geringer Teil aus der Kodierung resultiert. Da der Aufwand zur Erkennung und Behebung eines Fehlers, der in einer frühen Phase des Softwareentwicklungsprozesses gemacht wird, überproportional mit Fortschreiten des Softwareprojekts ansteigt, kommt dem frühzeitigen Testen und damit dem Testen von Dokumenten eine erhebliche Bedeutung zu.
Testen von Dokumenten wird im allgemeinen manuell durchgeführt, sofern keine formalen und damit automatisiert testbaren Zwischen-/ Endprodukte - so etwa Entwurfsspezifikationen in PSL (Programm Statement Language) - vorliegen und entsprechende Werkzeuge zur Verfügung stehen - so etwa PSA (Problem Statement Analyzer).
Die manuelle Vorgehensweise beim Testen von Dokumenten ist leider vielfach gleichzusetzen mit einer unsystematischen Vorgehensweise; so wird ein Entwurf von zwei Systemanalytikern durchgesprochen, oder die geplanten Ausgabelisten eines Softwaresystems werden mit dem zukünftigen Anwender abgesprochen", wobei der Anwender das Protokoll der Absprache vielleicht auch noch gegenzeichnet. Eine derartige Vorgehensweise kann aber keineswegs als systematisches Testen von Dokumenten bezeichnet werden, sondern erfüllt lediglich eine Alibifunktion.
Das systematische Testen von Dokumenten erfordert vielmehr eine formalisierte Vorgehensweise, bei der beispielsweise
- Checklisten verwendet werden,
- die für das Testen heranzuziehenden Personen entsprechend den Anforderungen ausgewählt werden,
- ein bestimmter Ablauf (Information, Vorbereitung, Durchführung) eingehalten wird, oder
- bestimmte Spielregeln befolgt werden.
Von der Gesamtheit der möglichen Aspekte zur Systematisierung des Testens von Dokumenten konnten an dieser Stelle nur einige aufgeführt werden, bei denen jedoch deutlich wird, daß auch beim manuellen Testen sehr zielgerichtet vorgegangen werden kann (muß), indem etwa Checklisten mit möglichen Prüfpunkten vorbereitend erstellt werden und anhand dieser Checklisten während eines strukturierten Gruppengesprächs (Walk Through, Inspection) vorgegangen wird.
Analytisches Testen
Beim Testen von Programmen wird vielfach die Frage gestellt, ob statistisch (Testen mit einer Vielzahl von nach beliebigen Kriterien erstellten Testdaten) oder analytisch (Prüfen eines Programms in bezug auf vorgegebene Prüfpunkte oder Ablauf eines Programms mit systematisch erstellten Testdaten) vorzugehen sei. Diese Frage kann nur unter Berücksichtigung des Testziels, das aus den Qualitätsmerkmalen, hinsichtlich derer ein Programm zu prüfen ist, abgeleitet wird, und der Testphase beantwortet werden.
So kann etwa ein statistischer Test als Bestandteil des Leistungstests im Rahmen des Systemtests durchaus sinnvoll ein, während in den meisten Testphasen die analytische Vorgehensweise im Vordergrund stehen sollte. Diese Forderung ist auch dadurch begründet, daß - um ein Beispiel zu wählen - im Modul- oder Integrationstest nicht die absolute Zahl der Datensätze von Bedeutung ist, sondern mit einer möglichst geringen Anzahl an Testdaten eine möglichst große Anzahl unterschiedlicher Programmelemente und -funktionen zur Ausführung gebracht werden soll.
Dementsprechend sind bei der analytischen Vorgehensweise systematisch Testfälle (mittels aufgaben-, funktions-, und programmorientierter Testfallermittlung) bereitzustellen und konstruierte Testdaten (Normal-, Grenz- und Falschwerte) zu verwenden. Systematisches Testen umfaßt jedoch nicht nur die Testdurchführung, also das Testen von Dokumenten und Programmen, sondern bedingt insbesondere eine umfassen. de Testplanung und darüber hinaus , eine wirksame Testkontrolle.
Planungsgrößen determinieren
Die Testplanung als Grundfunktion zur Festlegung der Ziele und Vorgehensweise bei der Testdurchführung ist eine Management-orientierte Aufgabe (Aufgabe des Projektleiters), die Voraussetzung für eine effiziente Testdurchführung ist. Gegenstand der Testplanung ist beispielsweise die Festlegung der:
- Testphasen,
- Teststrategien,
- Testobjekte,
- Testarten,
- Testziele,
- Testaktivitäten,
- Testträger und
- Testverfahren und -werkzeuge.
Von besonderer Bedeutung ist die Definition der Testziele für die einzelnen Programmbausteine oder Programme, wobei die Zielsetzungen der Testphasen und Testarten etc. berücksichtigt werden. So wird man etwa als Testziel für das programmorientierte Testen im Modultest das Ausführen aller Zweige des Moduls und gegebenenfalls sogar aller Pfade (bei der Begrenzung der Anzahl Schleifendurchläufe auf eins) fordern. Im Systemtest ist dahingegen eine solche Forderung unter wirtschaftlichen Aspekten wenig realistisch; hier würde man das Ausführen aller Moduln eines Programm(system)s fordern.
Unabhängig davon, ob die Festlegung einzelner Programmgrößen langfristig in Form von Konventionen, die für alle Softwareprojekte verbindlich sind, oder individuell unter Berücksichtigung der Gegebenheiten eines speziellen Projekts erfolgt, sind sämtliche Planungsgrößen zu. determinieren, um nach der Testdurchführung anhand dieser Vorgaben eine wirksame Testkontrolle zu ermöglichen.
Objektive Testmaße
Die Testkontrolle dient zur Überwachung und Steuerung des Testprozesses. Sie umfaßt unter anderem folgende Aktivitäten:
- Überwachung der Einhaltung des Testplans
- Aktualisierung des Testplans
- Freigabe/Abnahme von Zwischen-/Endprodukten
Die Bedeutung der Testkontrolle resultiert daraus, daß eine objektive Beurteilung der Vollständigkeit des Testens unbedingt erforderlich ist; denn wer kennt nicht das 90-Prozent-Syndrom, nach dem ein Entwickler auf die Frage, wie weit er mit dem Testen sei, immer wieder die 90prozentige Erledigung des Testens erklärt? Voraussetzung für eine wirkungsvolle Testkontrolle ist das Vorliegen von Testmaßen (etwa das Verhältnis der durchlaufenen Zweige zu den insgesamt vorhandenen Zweigen eines Programms), die objektiv meßbare Größen zur Beurteilung des Umfangs und der Ergebnisse der durchgeführten Testaktivitäten darstellen.
Anhand der quantitativen Angaben über den Grad der Erfüllung der Testmaße (Testmaßzahlen) ist die Überwachung der Testziele möglich. Zur Beurteilung der Vollständigkeit des Testens in bezug auf die definierten Qualitätsanforderungen sind ein oder mehrere Testmaße zu definieren. Anzustreben ist die Definition und Verfügbarkeit von Testmaßen für alle Qualitätsmerkmale, um anhand dessen das Testen beurteilen zu können. Darüber hinaus können die Testmaße auch als Qualitätsmaße verwendet werden.
Es sei darauf hingewiesen, daß diese Kenngrößen nicht zur Mitarbeiterbeurteilung, sondern zur Beurteilung der Vollständigkeit des Testens eines Softwareprodukts herangezogen werden sollen. Die Bedeutung der Testmaße im Rahmen der Testkontrolle zeigt sich auch dadurch, daß eine Vielzahl nachträglicher Änderungen erforderlich wird oder auch Fehler auftreten, da das entsprechende Softwareprodukt nicht umfassend getestet worden ist.
Testmaßzahlen sollen dazu beitragen, den Systemanalytiker oder Programmierer einerseits und den Projektleiter andererseits in die Lage zu versetzen, fundierte Aussagen darüber zu machen, was man getan hat. Diese Notwendigkeit ist sowohl im Entwicklungstest und insbesondere im Wartungstest gegeben, wenn im allgemeinen nicht das Gesamtsoftwareprodukt, sondern nur die von Änderungen betroffenen Teile getestet werden.
Neben dem Systemanalytiker, Programmierer und Projektleiter muß der Anwender ein Interesse an der Verfügbarkeit von Testmaßzahlen haben, um bei der von ihm durchzuführenden Abnahme Aussagen über die Vollständigkeit der von dem Entwickler durchgeführten Tests zu erhalten. Dies ist unabhängig davon, daß der Anwender im Abnahmetest (Pilottest, Paralleltest) selbst weitere Testläufe durchfuhrt.
_AU: Heinz Bons und Rudolf van Megen