Software von den Entwicklern selbst prüfen zu lassen, birgt ein enormes Risiko: Aufgrund ihrer langdauernden Einbindung in das Projekt sind die Mitarbeiter betriebsblind geworden, und konzeptionelle Fehler werden nicht mehr wahrgenommen. Klaus Speicher plädiert für den externen Softwareprüfer, der eine neue Art zu denken ins Spiel bringen soll.
Anhand eines Beispiels wollen wir uns zunächst Klarheit über den Testvorgang von kommerzieller Software verschaffen: Ein neues CASE-Tool, das zur maschinellen Unterstützung bei der Erstellung von Cobol-Programmen unter dem Betriebssystem Unix dient, steht zur Produktfreigabe an; die Planungs- und Programmierungsphase wurde erfolgreich abgeschlossen, was bedeutet, daß der Modultest gerade beendet ist.
Jetzt sollte die Anwendung einem Software-Tool-Spezialisten vorgelegt werden, der zwar die Firmenphilosophie gut kennt, die neue CASE-Anwendung dagegen noch nie gesehen hat. Zur Unterstützung stehen dem Prüfer neben den Funktionen der eigentlichen Anwendung nur die Hilfsmittel zur Verfügung, die auch dem späteren Kunden die Arbeit erleichtern sollen, also beispielsweise Manuale, Produktblätter oder programmierte Unterweisungen.
Betrachtet man die Voraussetzungen gesondert, so läßt sich leicht eine Regel für diese Art des Software-Prüfens ableiten, die dem Hersteller die größtmögliche Absicherung bringt: Der Test muß in allen denkbaren Punkten den späteren Kundenbetrieb simulieren.
Weshalb dieser Punkt so große Bedeutung hat, wird klar, wenn man sich Produktfreigaben früherer Jahre ansieht, bei denen nicht in dieser Art und Weise verfahren wurde, sondern die Programmierer selbst die Freigabeprüfungen durchführten. Diese Produkte waren mit erheblichen Mängeln - unter anderem auch konzeptioneller Art - behaftet.
Die Folgen solcher Produktfreigaben sind einfach zu analysieren: Sie resultieren in einem erheblichen Aufwand der Service-Abteilung sowie in schwindendem Kundenvertrauen etc. Genauso einfach kommt man zum Kernpunkt des Problems, das die fehlerbehaftete Freigabe erst ermöglicht hat: Die eingefahrene Denkweise der zuständigen Programmierer ließ es nicht zu, daß sie von der einmal eingeschlagenen Gedankenrichtung abschwenken und die Fehler erkennen konnten.
Das Problem besteht also dar in, daß Menschen, die ein Produkt entwickeln und in dieser Tätigkeit über einen längeren Zeitraum geistig gefangen sind, das, was sie gefertigt haben, nicht mehr ohne externe Hilfe von einer anderen Warte aus betrachten können. Der Kunde aber kennt die Denkweise des Programmierers nicht; er entwickelt seine eigene Produktphilosophie und stößt so recht schnell an die Grenzen der Anwendung. Schaltet man hingegen einen Software-Tool-Spezialisten als Prüfer in den Entwicklungsvorgang ein, so verlagert sich der Übergang vom Entwickler zum Kunden in die Grenzen des eigenen Unternehmens, und die Fehlerquote nach der eigentlichen Freigabe sinkt erheblich.
Aus diesem Beispiel erwächst eine zweite Regel der Qualitätssicherung: Der Prüfer sollte ein für das Produktgebiet ausgesuchter Spezialist sein, aber mit der zu prüfenden Anwendung bisher nichts zu tun gehabt haben.
Wendet man die beiden Regeln auf den Prüfvorgang in unserem Beispiel an, so erscheint es sinnvoll, bei der Auswahl des Prüfers nach folgenden Kriterien vorzugehen: Er muß über gute Kenntnisse des Betriebssystems Unix verfügen, sollte über die Möglichkeiten, die dieses Betriebssystem bietet, genau Bescheid wissen, außerdem einen fundierten Wissensstand in Cobol haben, die Firmenphilosophie bezüglich des Software-Engineering genau kennen und auch über CASE bestens informiert sein.
Bei der Festlegung des Prüfablaufes sollte man nach folgender Verfahrensweise vorgehen: Der Software-Tool-Spezialist denkt sich ein Modell für eine Produktion aus, die auch ein späterer Kunde entwickeln könnte. Dabei sollten alle beschreibenden Tätigkeiten vom Aufwand her so gering wie möglich angesetzt werden, da auf diese Art und Weise der oft enorm wichtige Faktor Zeit verkleinert wird.
Als Einarbeitungshilfen stehen dem Prüfer genau wie dem späteren Kunden nur das zur Anwendung gehörige Manual sowie ein Mitarbeiter der zuständigen Service-Abteilung zur Verfügung. Idealerweise erarbeitet der Tool-Spezialist das Projekt anhand der zugrundeliegenden Software-Engineering-Methode; daraus läßt er sich automatisch den Cobol-Source Code generieren; dann übersetzt und testet er das generierte Programm; er gibt die Anwendung frei, wenn alle Vorgänge reibungslos abgelaufen sind - was allerdings durchaus nicht immer der Fall ist. In der Regel treten während der Prüftätigkeit etliche Fehler zutage, die das Produkt immer wieder in die Programmierabteilung zurückbefördern.
Die Fehler, die während des Tests auftreten, kann man in zwei Kategorien einteilen: Fehler, deren Auffindung durch Umdenken begünstigt wird, und Fehler, die von der besprochenen Prüfmethode unabhängig - durch reines Testen - ausfindig gemacht werden können. Ein Paradebeispiel für die erste Kategorie wäre in unserem Beispiel eine nicht normengerechte Umsetzung der Software-Engineering-Methode. Werden dagegen Teile des Programmcodes nicht richtig generiert so handelt es sich um einen Fehler der durch die bloße Quantität der probierten Testfälle ausfindig gemacht werden kann.
Weitere Fehler der ersten Kategorie sind beispielsweise falsche Symboltechnik innerhalb des Bildschirmteiles, Bedienungsunfreundlichkeit der Grafikoberfläche, schlecht ausgebildete Schnittstellen zu anderen Produkten, die schon vor der Anwendung bestanden und weiter Bestand haben sollen, sowie mangelhafter Aufbau des Generierungsteiles. Fehler der zweiten Kategorie sind zum Beispiel falsche Masken-Reihenfolge bei wiederholter Anwendung, unrichtige Schreibweise von Maskenfeldern, Programmabstürze bei Abweichung von der normalen Bedienungsrille und andere Fehler, die in Folge des Gewöhnungseffektes in der Programmierabteilung nicht gefunden werden.
Vergleicht man die beiden Kategorien und betrachtet die einzelnen Fälle, so gewinnt man zum einen die Bestätigung für die Existenz zweier unterschiedlicher Gattungen und zum anderen die Einsicht, daß hier auch zwei voneinander abweichende Prüfverfahren erforderlich sind. Es ist leicht ersichtlich, daß ein Prüfvorgang, der durch Umdenken durchgeführt wird, ein großes Maß an logischem Denkvermögen, gepaart mit einer intensiven Kenntnis des zu prüfenden Gebietes, erfordert. Wie sollte ein Fehler im Konzept der Anwendung gefunden werden, wenn der Prüfer nicht exzellente Kenntnisse im Software-Engineering hat und in der Lage ist, diese auch eigenständig anzuwenden?
Ebenfalls leicht ersichtlich ist, daß ein fehlerhafter Generierungsteil nur dadurch erreicht werden kann, daß die großtmögliche Menge aller denkbaren Fälle einmal ausprobiert wird. Eine solche Vielzahl unterschiedlicher Testfälle erfordert von dem zuständigen Prüfer eine intensive Kenntnis der gängigen Prüfmethoden, die ihm die Arbeit entscheidend erleichtern können. Wie sollte er sonst wohl den Sprachumfang von Cobol abdecken, ohne daß dies mehrere Jahre in Anspruch nimmt?
Folgert man nun weiter, so kommt man auch zu den Ursachen dafür, warum Qualitätssicherung durch Umdenken nicht von Menschen ausgeführt werden kann, die vor dem Prüfvorgang schon etwas mit der Anwendung zu tun hatten: Umdenken beginnt immer bei Null ! Es gibt aber keinen Menschen, der sein Hirn auf natürliche Art und Weise von dem reinigen konnte, was er bisher über eine Tätigkeit erfahren hat.
Umdenken heißt also, in einer Betrachtungsweise wieder ganz von vorn zu beginnen. Eine gängige Methode zum Umdenken stellt im wirklichen Leben eine Psychotherapie dar. Welches Projekt könnte aber darauf warten, daß die zuständige Programmierabteilung eine Psychotherapie durchführt? Oder andersherum gefragt: Welcher Programmierer würde für sein Projekt eine Psychotherapie auf sich nehmen? Die Antworten auf beide Fragen erübrigen sich. Was nach dem heutigen Stand der Technik bleibt, ist der oben beschriebene Weg.
Um diesen Weg gehen zu können, müssen DV-Hersteller über die geeigneten Leute verfügen. Softwareprüfer, die in der Lage sind umzudenken, kann aber keine Firma von der Hochschule weg engagieren. Solche Menschen müssen über Jahre hinweg reifen und sind deshalb nur schwer zu finden. Deshalb ist es für Softwarehersteller und -abteilungen enorm wichtig, effiziente Nachwuchsarbeit zu betreiben.
Ist nun aus dem eigenen Nachwuchs ein guter Softwareprüfer herangewachsen, so sollte das Unternehmen darauf achten, daß er auch bleibt, indem es ein gutes und modernes Arbeitsfeld schafft.