Software-Test: Verifikation und Validation

4 Ein zweiter Ansatz: Black Box Test (S. 81-82)

Prüfe die Brücke, die dich tragen soll. Sprichwort

Neben 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 Testgruppe

Wir 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. Er weiß in der Regel gar nicht, wie eine Funktion implementiert wurde. Selbst wenn für ein Unterprogramm zwei durchaus unterschiedliche Lösungen möglich sind, den Tester interessiert das wenig: Solange die Routine die spezifizierte Funktion erfüllt, ist das Programm für ihn in Ordnung. Gewiss braucht der Tester einen Leitfaden, an dem er sich orientieren kann. Das kann zum einen das detaillierte Lastenheft der Software sein. Besonders gut eignet sich auch das Benutzerhandbuch, falls es zum Zeitpunkt des Tests vorliegt. Grundsätzlich sollte sich ein Mitglied der Testgruppe auf den Standpunkt eines Kunden und Benutzers des Programms stellen. Er darf kein Wissen voraussetzen, das der Entwickler vielleicht hat, der Benutzer aber nicht. Eine gewisse Robustheit und Tauglichkeit für den täglichen Betrieb sollte der Tester von der Software verlangen.