Dipl.-Ing. Georg Erwin Thaller war zunächst in der Software-Entwicklung tätig, hat eine Testgruppe aufgebaut und war anschließend im Rahmen eines internationalen Joint Ventures in den USA für die Software-Qualitätssicherung verantwortlich. G. E. Thaller ist Mitglied im Institute of Electrical & Electronical Engineers (IEEE), der Association of Computing Machinery (ACM) und des American Institute of Aeronautics and Astronautics (AIAA). Seine Arbeit wurde 1992 durch Aufnahme seiner Biografie in das "Who s who in the World" gewürdigt. Zu den Themen Software, Qualität und Satellitentechnologie hat er ein Dutzend Fachbücher veröffentlicht. <<

1;Vorwort;62;Acknowledgements;93;Inhaltsverzeichnis;104;1 Die Notwendigkeit zur Verifikation der Software;144.1;1.1 Die stille Revolution;164.2;1.2 Das Risiko;174.3;1.3 Der Zwang zu qualitativem Wachstum;284.4;1.4 Die Testverfahren im Überblick;315;2 Die Softwareentwicklung als Prozess;345.1;2.1 Die Prozessmodelle;345.2;2.2 Die Spezifikation als Grundlage für den Test;425.3;2.3 Die Testplanung;485.4;2.4 Die Notwendigkeit zur frühen Verifikation;515.5;2.5 Die Verifikation ohne Computer;526;3 Die Verifikation der Software;626.1;3.1 Die Rolle des Tests im Lebenszyklus der Entwicklung;626.2;3.2 Die Abhängigkeit von Entwurf und Implementierung;636.3;3.3 Top-down- versus Bottom-up- Strategie beim Test;656.4;3.4 Der Modultest als White Box Test;726.5;3.5 Die Testabdeckung;826.6;3.6 Incremental Testing;876.7;3.7 Die Schwächen des White Box Tests;926.8;3.8 Die geeigneten Werkzeuge;937;4 Ein zweiter Ansatz: Black Box Test;947.1;4.1 Die Motivation der externen Testgruppe;947.2;4.2 Bewährte Grundsätze beim Black Box Test;967.3;4.3 Die Instrumentierung;1117.4;4.4 Vom Modul zum Programm;1187.5;4.5 Die Testabdeckung auf Systemebene;1317.6;4.6 Gray Box Testing;1328;5 Die Ausprägungen von Tests;1348.1;5.1 Der Funktionstest;1358.2;5.2 Volume Test;1378.3;5.3 Stress Test;1418.4;5.4 Speicherverbrauch und Auslastung des Prozessors;1428.5;5.5 Recovery Testing;1428.6;5.6 Der Mutationstest;1438.7;5.7 Benchmarks;1448.8;5.8 Der Test von Prozeduren und Verfahren;1478.9;5.9 Configuration Testing;1488.10;5.10 Compability Testing;1528.11;5.11 Usability Testing;1578.12;5.12 Software für fremde Kulturen und Sprachen;1698.13;5.13 Überprüfung von Dokumenten;1728.14;5.14 Der Systemtest;1759;6 Tests bei spezifischen Applikationen;1789.1;6.1 Objektorientierte Software;1789.2;6.2 Test einer Website;1879.3;6.3 Sicherheitskritische Software;20310;7 Software und System;21210.1;7.1 Unterschiede zwischen Hardware und Software;21310.2;7.2 Analyse;21710.3;7.3 Konstruktive Maßnahmen;22210.4;7.4 Prozessmodelle;23010.5;7.5 Redundanz und Diversity;23210.6;7.6 Normen;23411;8 Test-Automation;23811.1;8.1 Warum automatisieren?;23811.2;8.2 Beschaffung eines Tools;24511.3;8.3 Testen mit automatischen Tools;24811.4;8.4 Erfahrungen mit der Test- Automatisierung;25212;9 Management und Organisation;25812.1;9.1 Test im betrieblichen Rahmen;25812.2;9.2 Organisation;26712.3;9.3 Testplanung;27212.4;9.4 Fremdsoftware;27512.5;9.5 Einsatz von Werkzeugen;27812.6;9.6 Fehlerberichtigungssystem und Behandlung von Änderungen;28112.7;9.7 Debugging und Regression Test;29112.8;9.8 Metriken zum Test;29812.9;9.9 Die Freigabepolitik;30412.10;9.10 Wirksamkeit und Wirtschaftlichkeit;30712.11;9.11 Qualitätssicherung und Test;31212.12;9.12 Das Risiko beherrschen;31313;10 Test und Capability Maturity Model;31613.1;10.1 Capability Maturity Model;31613.2;10.2 Test Maturity Model;33114;11 Ausblick;33615;Anhang;33815.1;A.1 Literaturverzeichnis;33815.2;A.2 Spezifikation: Kernfunktionen der Kalenderroutinen;34215.3;A.3 Akronyme und Abkürzungen;34815.4;A.4 Glossar;35115.5;A.5 Normen und Standards;35815.6;A.6 Produktmuster für den Testplan;36215.7;A.7 Materialien: Fragebögen und Fehlervordruck;36915.8;A.8 Grundriss eines Usability Labs;38715.9;A.9 Ressourcen im Internet;38815.10;A.10 Stichwortregister;390

4 Ein zweiter Ansatz: Black Box Test (S. 81-82)Prüfe die Brücke, die dich tragen soll. SprichwortNeben dem White Box Test, der seit den Anfangstagen der Programmierung bekannt ist, steht gleichwertig der Black Box Test. Sein Ansatz ist verschieden vom White Box Test, und das bezieht sich vor allem auf die Person des Testers.4.1 Die Motivation der externen TestgruppeWir sind bisher wie selbstverständlich immer davon ausgegangen, dass der Entwurf, das Kodieren und der anschließende Test von ein und derselben Person durchgeführt wird. Tatsächlich muss das nicht so sein; es sprechen eine ganze Reihe guter Gründe dafür, die Arbeit anders zu organisieren. Viele Organisationen haben mit wichtigen Projekten Schiffbruch erlitten, weil sie konstruktive und analytische Tätigkeiten nicht sauber voneinander getrennt haben. Lassen Sie mich zu diesem Punkt Tom DeMarco [29] zitieren. Ich könnte es mit meinen eigenen Worten nicht besser sagen."Ganz zu Beginn des Computerzeitalters gab es einmal im Bundesstaat New York eine Firma, die große blaue Computer baute. Sie lieferte auch gleich die passende Software dazu. Die Kunden dieser Firma waren recht nette Leute, aber sie konnten ganz schön böse werden, wenn fehlerhafte Programme ausgeliefert wurden. Eine Weile konzentrierte sich unser Konzern mit den blauen Computern darauf, die Kunden zu mehr Toleranz gegenüber fehlerhaften Programmen zu erziehen. Als das nichts fruchtete, entschloss man sich schließlich, den Fehlern in der Software auf den Leib zu rücken.Der einfachste und offensichtliche Weg bestand darin, die Programmierer dazu zu bringen, vor der Auslieferung des Codes alle Fehler auszumerzen. Das funktionierte allerdings nicht. Aus irgendwelchen Gründen schienen die Programmierer - zumindest damals - daran zu glauben, dass ihre Programme keine Fehler hätten. Sie gaben ihr Möglichstes, aber den wirklich letzten Fehler zu finden war schwierig. Einige Programmierer schienen der gestellten Aufgabe allerdings besser gewachsen zu sein als andere Kollegen. Die Firma fasste diese Gruppe zusammen und stellte ihr die explizite Aufgabe, die Software vor der Auslieferung an die Kunden zu testen. Das Schwarze Team war geboren.Dieses Team bestand ursprünglich aus Leuten, die im Testen von Software etwas besser waren als andere. Sie waren auch besser motiviert: Da sie den Programmcode nicht selber geschrieben hatten, hatten sie keine Angst vor gründlichen Tests." Das Schwarze Team wurde im Lauf der Zeit immer besser. Sie erwarteten Fehler in der Software und waren entschlossen, sie aufzudecken. Sie standen in Opposition zum Schreiber des Programms. Die von ihnen ausgeheckten Tests waren ausgeklügelt, oft zerstörerisch und schwer zu bestehen. Die Mitglieder der Gruppe begannen, sich ganz in Schwarz zu kleiden. Es galt bald als eine Ehre, zum Schwarzen Team zu gehören. Fast unnötig zu sagen, dass die Firmenleitung begeistert war. Jeder gefundene Fehler war ein Defekt, den die Kunden nicht finden konnten. Das sparte viel Geld, das sonst für Wartung und Kundendienst hätte aufgewendet werden müssen. Manche Mitglieder verließen das Schwarze Team, doch sie wurden immer sofort wieder ersetzt. Die externe Testgruppe hatte sich innerhalb der Firma etabliert.Es ist nicht zu leugnen, dass viele Menschen eine Hemmschwelle haben, wenn es um eigene Fehler geht. Den Balken im eigenen Auge sehen wir eben nicht. Warum sollte das bei Programmierern anders sein? Es ist also durchaus sinnvoll, nach dem Test durch den ursprünglichen Entwickler, etwa in der Form eines White Box Tests, den zweiten Schritt zu tun und das Programm einer externen Testgruppe zu übergeben. Das Wort extern bedeutet dabei außerhalb der Gruppe, die innerhalb der Firma für den Entwurf und dessen Implementierung verantwortlich ist. Black Box Test bedeutet, dass der Tester den Programmcode lediglich nach der Funktion beurteilt.