Systematische Softwareentwicklung

8.3Weiche Tests

"Eine dicke Haut ist ein Geschenk Gottes."
(Konrad Adenauer)

Als "weiche Tests" bezeichne ich gerne die unsystematischen Tests, obwohl ja durch eine Klassifizierung und gezielte Anwendung dieser Tests schon wieder eine gewisse Systematik aufkommt. Der wesentliche Charakter dieser Tests ist die Intuition, mit der vorgegangen wird. Entsprechend benötigt man dafür Leute, die einfach ein gewisses Gespür oder "Händchen" haben und manchmal auch mit einer gewissen Respektlosigkeit an dieses eigentlich phantastische Produkt herangehen. Ganz wichtig ist dabei also, dass diese Leute völlig unvoreingenommen und frei vorgehen können, weshalb diese Tests auch niemals von den Entwicklern des Produkts vorgenommen werden können. Da hier nicht systematisch getestet wird, ist es manchmal extrem schwer, die Fehler zu reproduzieren. Ich habe bei solchen Tests schon Video-Kameras benutzt, um genau festhalten zu können, wann der Tester welche Tasten gedrückt hat, wann er wo geklickt hat und was er ansonsten gemacht hat. Gleichzeitig können diese Aufnahmen dazu dienen, das Produkt in der Bedienung (Ergonomie) zu verbessern, denn wenn jeder Anwender an den gleichen Stellen stolpert, sollte man da was dran ändern.

Ich habe schon erlebt, dass es für einen Fehler entscheidend war, dass der Anwender zwischen zwei bestimmten Funktionen mehrere Minuten gar nichts gemacht hatte, weil in der Zeit eine Variable in einer Schleife so hoch gezählt wurde, dass sie überlief und dann erst in der folgenden Funktion einen Fehler verursachte. Das Programm musste Proben analysieren, die eine bestimmte Mindestabkühlzeit benötigten, bevor die nächste Untersuchung stattfinden konnte. Jeder dachte, dass die Untersuchungen so schnell wie möglich hintereinander erfolgen würden, weil die Wartezeit nervig war und jeder auf das Ergebnis der Untersuchung gespannt war. Die Entwickler hatten bei ihren Tests immer ungedulig gewartet und so schnell wie möglich fortgesetzt, weil sie wissen wollten, ob es funktioniert. Bei den systematischen Tests wurde getestet, was passiert, wenn man nicht lange genug wartet und was, wenn man exakt die Zeit wartet und was, wenn man etwas länger wartet. Aber der unbedarfte Anwender, der für einen weichen Test eingeladen wurde, interessierte sich überhaupt nicht für den Sachverhalt oder das Ergebnis der Untersuchung und war für mehrere Minuten aus dem Kamerabild verschwunden. Er hat nämlich einfach die Zeit genutzt, um zwischendurch aufs Klo zu gehen. Dadurch hat er als einziger die zweite Funktion erheblich später nach der ersten ausgeführt.

Voraussetzung für so einen Test ist, dass der Tester nicht die geringste Ahnung davon hat, was eigentlich in der Software vorgeht - er muss das Produkt als "Black Box" betrachten. Kein anderer würde sonst wahrscheinlich auf die Idee kommen, in das Postleitzahlfeld "unbekannt" reinzuschreiben, eine Datei auf der Diskette zu eröffnen und dann einfach die Diskette rauszunehmen, die erste Filialadresse zehnmal zu kopieren und dann erst die Kopien anzupassen (statt sie jedesmal sofort nach dem Kopieren anzupassen) oder sich auch ansonsten wie ein DAU (Dümmster Anzunehmender User) zu verhalten (die Abkürzung ist vom GAU = Größter Anzunehmender Unfall eines Atomkraftwerks abgeleitet). Ein früherer Projektleiter von mir sagte mal: "Ich setze mich mit dem Arsch auf die Tastatur - und wehe, ich höre auch nur einen Piep von der Kiste!" Es gibt auch Software-Hersteller, die sich für den Black-Box-Test in der Stadt oder an einer Uni Anwender von der Straße einkaufen, um zu testen, wie die Erstkäufer des Produkts wohl damit umgehen werden. Bei einer Individualsoftware, die für ein Unternehmen entwickelt wird, kann man sich gut in der Kantine bedienen - viele Mitarbeiter haben super viel Spaß an solchen Tests und erzählen hinterher rum, wie sie das Programm "aufs Kreuz gelegt" haben. Ein positiver Nebeneffekt davon ist, dass sich rumspricht, dass es bald eine neue Software gibt.

Damit sich dabei nicht allzu viel Schlechtes rumspricht, sollte man jede Version, die man in einen Black-Box-Test gibt, natürlich gründlich - vor allem auch systematisch - vortesten. Den ersten Test macht natürlich immer der Entwickler, der schaut, ob das, was er gerade programmiert hat, auch das macht, was es soll. Danach sollte ein anderer Entwickler einfach mal provokant und brutal mit dem Programm umgehen und schauen, ob es raucht und wie stark es raucht. Deshalb wird so ein Test gerne "Smoke-Test" genannt. Sie werden feststellen, dass viele Entwickler ganz jeck darauf sind, die Funktionen der Kollegen abrauchen zu lassen. Ich habe da schon regelrechte Turniere und Wettlisten gesehen. Ein positiver Nebeneffekt davon ist, dass die Entwickler auch mal den Rest des Produktes kennen lernen und spätestens dann genau wissen, wer was programmiert hat. Wenn das Produkt dann hinterher in den Black-Box-Test geht und die Fehlermeldungen der DAUs auf den Tischen der Entwickler landen, explodieren diese meistens, weil sie dann die Respektlosigkeit, Nüchternheit, Objektivität und natürlich teilweise auch Blödheit der echten Anwender zu spüren bekommen. Ich kannte mal einen Entwickler, der dann jedes mal voller Wut in den Testtrakt stürmte und dort einen riesigen Aufstand veranstaltete. Damit ist auch klar, warum ich obigen Spruch für diese Seite gewählt habe.

Wenn Sie ein Altsystem mit modernen Technologien neu programmieren oder eine andere Software nachprogrammieren, sollten Sie mit verschiedenen Leuten einen "Pepsi-Test" durchführen. Dies ist eine Art Geschmacksvergleich, bei dem ganz subjektiv beurteilt wird, ob das Produkt besser oder mindestens genauso gut schmeckt. Hier kann verglichen werden, ob Funktionen schneller, komfortabler oder sicherer ablaufen, besser zu finden sind, der längst veränderten Fachlichkeit näher kommen und vielleicht auch einfach mehr Spaß machen. Dieser letzte Aspekt ist natürlich gerade bei Spiele-Software sehr entscheidend. Ich konnte mal mit den führenden deutschen Spieleentwicklern über Systematiken der Softwareentwicklung diskutieren und das entscheidende Argument für eine iterativ inkrementelle Entwicklung war, dass man möglichst früh die Performance messen, die Realitätsnähe beurteilen und vor allem den Spielspaß prüfen kann. Macht es keinen Spaß oder läßt der Spaß schnell nach, kann man die Entwicklung (oder die betroffenen Teile oder Charaktere) direkt in die Tonne hauen.

Der Black-Box-Test eignet sich also gut, um die Praktikabilität zu testen, der Smoke-Test prüft im Wesentlichen, ob Fehlermeldungen hochkommen oder etwas kaputt geht und der Pepsi-Test zeigt einfach, wie es gefällt. Natürlich ist nicht jede Art von Test für jedes Produkt oder jede Phase geeignet. Sie werden keinen Smoke-Test mit einer Software für Herzschrittmacher durchführen und Sie werden auch keinen Black-Box-Test mit Software für Mittelstreckenraketen durchführen. Aber Sie können bei einer individuellen Verwaltungssoftware sehr wohl bereits in der Analysephase (also sehr früh) einen Pepsi-Test anhand des Prototypen durchführen; deshalb auch im Inhaltsverzeichnis bei "Prototyp" der Spruch: "Etwas zum Spielen braucht der Mensch". Sie können beim Schreiben der Anwendungsfälle auch sehr gut gedanklich einen Black-Box-Test durchlaufen, denn die Implementierungswege sind ja zu dieser Zeit noch unbekannt. So können Sie bereits dann die ersten Testfälle für die systematischen Tests finden. Einen Smoke-Test sollten Sie bei "harmloser" Software nach jeder Iterationsstufe durchführen, vielleicht auch einen Black-Box-Test mit ausgewählten Pilotanwendern.

Systematisch sollte man bei weichen Tests bei der Auswertung vorgehen. Die Fehler sollten genauso aufgenommen, priorisiert, weitergeleitet und behoben werden, wie die Fehler von systematischen Tests auch. Ferner sollten gute Ideen der Tester zu neuen Testfällen führen, damit diese bei späteren Tests nach Korrekturphasen, weiteren Iterationsstufen oder neuen Produktversionen erneut angewendet werden können. Die systematischen Tester sollten diese Testfälle einsehen können, damit sie daraus vielleicht Ideen für neue systematische Tests entwickeln können.