Systematische Softwareentwicklung

8.4Systematische Tests

"Der Fehler liegt in der Eile."
(Aus China)

Worum geht es beim systematischen Testen? Die Software wirklich fertig zu bekommen und die geforderte Qualität zu erreichen; oder anders gesagt: "Make it fly!" Dies ist ein zäher Prozess, der extrem an den Nerven zerrt, weil man mit jedem neu entdeckten Fehler das Gefühl bekommt, wieder ein Stück schlechter gewesen zu sein, als erwartet. Versuchen Sie es, anders herum zu sehen. Der Projektleiter eines Projekts, in dem ich 1985 teilnahm, sagte immer: "Kaum macht man's richtig, schon geht's." Mit dieser Einstellung ist es jedes Mal ein tolles Gefühl, wenn ein weiterer Fehler vernichtet ist!

Systematisch zu testen, bedeutet vor allem, zu wissen, was man testet und wie man es testet. Ein zentraler Aspekt sind sicherlich "Testfälle", die möglichst schon gemeinsam mit den Anwendungsfällen geschrieben werden sollten. Wenn Sie nämlich die Anwendungsfälle schreiben, fallen Ihnen oft schon die Bedingungen auf, die erfüllt sein müssen, damit der Anwendungsfall erfolgreich verläuft. Diese Annahmen sind sehr gut als Ansätze für Testfälle geeignet. Wenn es in einem Anwendungsfall heißt "Der Name der gespeicherten Datei wird der Liste hinzugefügt.", so frage ich mich sofort, wie sich die Software wohl verhält, wenn die Datei nicht gespeichert werden konnte? Was kann dazu führen? Beispielsweise eine volle Festplatte (war bei Testern schon immer beliebt, weil dabei immer was passiert; gleiches gilt natürlich für Quoten) oder mangelnde Berechtigungen des Anwenders in dem gewählten Ordner oder ein doppelter Dateiname oder, oder, oder. Mit etwas Erfahrung findet man schnell Ansätze zum Testen, die man direkt in einem zugehörigen Testfall festhalten sollte. Darin sollte auch beschrieben werden, wie sich das Softwaresystem verhalten sollte. Es ist schließlich ein Unterschied, ob der Anwender eine Fehlermeldung erhält (natürlich immer zusammen mit einem Hinweis, wie er sich weiter verhalten sollte) oder das System beispielsweise bei mangelnden Berechtigungen automatisch und still das Homeverzeichnis des Anwenders wählt.

Tester verwenden diese Testfälle, um die Situationen zu provozieren und das Verhalten der Software zu prüfen. An dieser Stelle eine Bitte an alle Tester: seid mal nicht zu systematisch und fangt nicht immer mit den einfachsten Tests an; langt ruhig mal in der ersten Testphase sofort richtig in die schwierigen Töpfe, damit die Entwickler erst einmal beschäftigt sind und ihnen viel Zeit zur Behebung zur Verfügung steht. Dann habt ihr auch genug Luft, in Ruhe systematisch vorne anzufangen und habt auch gleich ein Gefühl für die Komplexitätsschwelle, ab wo die Software "buggy" (dt. "fehlerhaft") wird. Einige Testfälle sind auch gar nicht gut für professionelle Tester geeignet. Ich habe gute Erfahrungen damit gemacht, in einer Art Feldversuch einige Anwender zu einer Testmannschaft zusammen zu stellen und mit diesen dann bestimmte Anwendertests durchzuführen. Denn oft wissen Tester auch nicht besser als die Entwickler, wie Artikel- oder Vertragsnummern korrekt aufgebaut werden und wann eine Sammelrechnung inhaltlich verhunzt ist und wann nicht. Bei den Anwendertests "im Feld" gewinnt man oft noch entscheidende Testfälle hinzu. Natürlich sind aber auch mindestens 2/3 der Anmerkungen dieser Anwender Optimierungs- oder Erweiterungswünsche.

Es gibt aber natürlich noch mehr Möglichkeiten, systematisch zu testen, als nur die Testfälle durchzugehen. Den ersten Test wird der Entwickler selbst durchführen, denn ein Entwickler, der seinen Code ungetestet zu einem offiziellen systematischen Test in die Testabteilung gibt, wird garantiert ausgepeitscht, wenn das Ding dort überhaupt nicht läuft! Beim "Developer Test" schaut der Entwickler zuerst, ob seine Funktionalität für die Anwender überhaupt erreichbar ist und durchläuft, ohne "Bumm" zu machen. Ferner wird er einige Randbedingungen sofort durchprüfen, weil es ihm irgendwann einfach zu peinlich ist, wenn die Tester bei ihm immer wieder sofort auf bestimmte einfache Situationen treffen. Dazu gehört beispielsweise, ob die Prüfung auf die Pflichtfelder funktioniert, ob leere Felder auch leer gewertet werden, wenn ein Leerzeichen drin steht, ob bei Summierungen auch richtig gerechnet wird, ob die Formatierung und Rundung von Zahlen stimmt, ob Tippfehler in den Texten auf dem Bildschirm sind, ob bei langsamen Passagen die Sanduhr angezeigt wird, etc.

Weitere Tests sind "Schnittstellentests", die auch von Prüfständen durchgeführt werden. Dabei wird das Verhalten der Programmschnittstellen geprüft. Wenn beispielsweise eine Funktion als Parameter einen Provisionssatz bekommt (ein Argument ist übrigens etwas, was an eine Funktion gegeben wird, ein Parameter ist etwas, was eine Funktion bekommt; die unterschiedliche Begrifflichkeit stammt also von der unterschiedlichen Sicht), so kann man ja mal testen, wie sich die Funktion bei einem negativen Provisionssatz verhält, oder bei einem, der größer ist als 100%. Schließlich kann es ja schon morgen passieren, dass ein Entwickler des Teams diese Funktion falsch versorgt. Einem Fehler vorzubeugen ist besser, als einen Fehler tagelang zu suchen.

Mit diesem Gedanken macht es auch Sinn, die Quellen einem zweiten Entwickler zu zeigen, damit er sich die einfach mal durchliest - vielleicht fällt ihm ja was auf. So etwas nennt man "Code Review". Dies führte beim Extreme Programming [L2] zum Ansatz des "Pair Programming": der eine Entwickler schreibt die Funktion und der andere parallel den Schnittstellentest dazu; dann tauschen die beiden ihre Quellen und sichten sie. Erst danach wird der Test auf der Funktion durchgeführt. Ich denke gerne an ein Softwaremodul zurück, dass ich Anfang 2002 entwickelt habe. Durch eine ordentliche Zeitabschätzung hatte ich genug Luft für meine Developer Tests und konnte sogar noch meine Teamkollegen eine Code Review durchführen lassen und die Quellen nachträglich mit noch ausführlicheren Kommentaren versehen, wobei mir auch noch die eine oder andere Gelegenheit zur Plausibilitätsprüfung aufgefallen war. Das eingeflogene Testteam war nach fünf Tagen so verzweifelt, weil sie keinen einzigen Fehler fanden, dass sie selbst einen Code Review durchführen wollten. Es kommt sicherlich nicht oft vor, dass ein Testteam so viel Entwicklungserfahrung mitbringt und dass man als Entwickler dem Tester auch noch dabei über die Schulter blicken darf. Die Tester hatten zwar beim Code Review auch nicht mehr viel gefunden, konnten sich aber nun auch vergewissern, warum dies so war ;-)

Die oben beschriebenen Schnittstellentests können auch als "Prüfstand" automatisiert werden. Prüfstände testen aber noch mehr, nämlich auch, ob ein Geschäftsprozess oder eine komplexe Softwarefunktionalität durch eine Aneinanderreihung von Einzelfunktionen sauber abläuft (Test ganzer Anwendungsfälle). So kann man beispielsweise die ganze Serienbrieffunktion eines Textverarbeitungsprogramms automatisiert testen, oder das Erstellen von Sammelrechnungen aus einzelnen Lieferscheinen bei einem Warenwirtschaftssystem. Ich habe mal mit einem Kollegen in den 80ern in Assembler die Software für eine elektronische Speicherschreibmaschine mit Display entwickelt (übrigens ein Projekt von ca. sechs Mannjahren Aufwand), bei dem die Testmannschaft unter anderem die fertigen Schreibmaschinen in eine Apparatur gespannt hat, die mit Hydrostößeln über jeder Taste die Finger des Anwenders simulieren konnte. Diese Apparatur konnte nun ihrerseits mit einfachen Makros programmiert werden. Darin wurde nur festgehalten, welche Taste mit welcher anschließenden Pause gedrückt werden sollte. Dadurch wurde ein echtes Verhalten eines Anwenders für eine Vielzahl von Bedienfunktionen (Display- und Delay-Modus, Tabulationen, Löschfunktionen auf dem Papier, Totzeichen, etc.) simuliert - und zwar ganze Nächte hindurch! Vor diesem Prüfstandtest habe ich immer viel Respekt gehabt, weil auf ganz natürliche Art und Weise der Speicher gefüllt wurde, seitenweise Text in verschiedensten Modi generiert wurde und vor allem, weil uns morgens ein dickes Protokoll auf den Tisch geknallt wurde, in dem alle Fehler markiert waren! Wir konnten auch davon ausgehen, dass es kein Fehler in der Apparatur war, weil diese Makros äußerst einfach und sicher zu erstellen waren. Anders ist es bei Softwareprüfständen, die automatisiert Testfälle testen. Ich frage mich da immer, warum diese Software eigentlich fehlerfreier sein soll als die, die sie testet. Wird Prüfstandsoftware von Göttern programmiert?

Ein Test führt also zu einem positiven oder negativen Ergebnis. Ein positives Ergebnis ist ein Fehler, der bewertet und festgehalten werden muss. Insbesondere der Weg zum Fehler ist wichtig, denn nur ein reproduzierbarer Fehler ist ein guter Fehler! Daher sollte ein Bug-Reporting-System zum Melden von Fehlern eingesetzt werden. Dies kann eine professionelle webbasierende Software sein, bei kleinen Projekten aber beispielsweise auch eine Access-Datenbank oder gar nur ein Textdokument. Fehler sollten dort eingetragen, gewichtet (priorisiert) und Bearbeitern zugeordnet werden. Die Behebung des Fehlers sollte exakt beschrieben werden und der Fehler zum Nachtest freigegeben werden. Fehler sollten immer zeitnah behoben und nicht aufgeschoben werden. Dabei spielt natürlich die Dringlichkeit und Wichtigkeit des Fehlers eine große Rolle. Der Projektleiter muss ggf. den Projektplan anpassen und eine Statistik der Fehler und Behebungen führen. Solange noch 1er Prios oder Class-A-Bugs drin sind, kann die Software nicht guten Gewissens freigegeben werden. Bei Individualsoftware sollte der Kunde in die Statistik eingeweiht werden. Vor allem sollten die Prioritäten der Fehler mit dem Kunden diskutiert werden, damit klar ist, ob es sich wirklich um einen Fehler oder einen Wunsch handelt und ob ein Fehler die Abnahme der Software behindert oder nicht. Anhand eines Bug-Reporting-Systems können Kennzahlen aus den Projekten ermittelt werden, die zu einer besseren Messbarkeit der nächsten Projekte führt. Denn wenn sehr viele Fehler gefunden werden, ist dies genauso verdächtig als wenn sehr wenige Fehler gefunden werden. Aber dazu muss man erst einmal wissen, was "sehr viele" und "sehr wenige" bedeutet, und dies hängt vom Team, vom Zeitrahmen, von der Komplexität der Aufgabenstellung, von der Erfahrung mit der technischen Plattform und vielen weiteren Faktoren ab.

Führen Sie regelmäßig "Regressionstests" durch, d.h. testen Sie regelmäßig alte Fehler, die vor scheinbaren Ewigkeiten behoben wurden, denn nicht selten tauchen diese wieder auf. Es gibt in jeder Software Fehler, die wie Tischtennisbälle immer oben schwimmen, egal, wie oft Sie sie wieder unter Wasser drücken. Die iterativ inkrementelle Vorgehensweise im Projekt sorgt automatisch für häufige Tests der Basisfunktionalität, weil diese ja nach jeder Iterationsstufe wieder mitgetestet wird. Diese Arbeitsweise stellt auch sicher, dass Sie immer nur auf geprüftem Code weiter entwickeln. Dies erspart Ihnen viele unangenehme Überraschungen am Ende des Projekts.

"Zero Defects" ist eine Methode, bei der die Regressionstests auf die Spitze getrieben werden, denn dabei wird durch tägliche (!) "Quick Tests" über die ganze Projektlaufzeit hinweg sichergestellt, dass dicke Hunde erst gar nicht auftauchen. Alle Fehler aus den Quick Tests werden sofort (wirklich sofort) gesucht und behoben - vorher wird nicht weiter entwickelt! Anhand von Checklisten kann ermittelt werden, welcher Umfang von den Quick Tests abgedeckt wird, denn bei halbwegs komplexer Software in halbwegs großen Projekten ist es nicht mehr möglich, an einem Tag alles zu testen. Sämtliche Testfälle, andere systematische Tests und auch Situationen aus weichen Tests und vor allem sämtliche Situationen, die schon einmal zu einem Fehler geführt haben, sollte man dann in einer fetten Checkliste führen, in der die Tests priorisiert und die Zeit für deren Durchführung gestoppt und notiert wird. Dann kann die Zeitsumme für die einzelnen Prioritäten gebildet werden. So ist eine zuverlässige Aussage möglich, innerhalb welcher Zeit welche Qualität geprüft werden kann. Ich habe dies mal bei der Entwicklung eines graphischen Textverarbeitungssystems mit der Testabteilung, den Vertrieblern sowie dem Entwicklungsteam durchgezogen. Vor Präsentationen einer neuen Version bei Key-Kunden konnten wir den Vertrieblern genau sagen, welche Qualität wir bei der verbleibenden Testzeit noch gewährleisten können, und die Vertriebler konnten anhand der Checklisten auch genau prüfen, was das bedeutet. Gleiches galt für Messen: auf der CeBIT wollten wir im Kino natürlich nur Gutes zeigen und wussten genau, dass wir acht Tage vor der Messe die Entwicklung stoppen mussten, wenn wir wissen wollten, was bei einer 2er-Qualität nicht vorgeführt werden durfte. Der Aufwand für solche Verfahren sollte genauso wenig unterschätzt werden wie die Schwierigkeit der Projektsteuerung mit solchen Verfahren!

Bei kritischer Software sollte natürlich auch das Ausfallverhalten getestet werden: wenn die Software oder das von der Software gesteuerte System versagt, muss ein möglichst harmloser oder neutraler Zustand erreicht werden. Wie der aussieht, sollte natürlich nach gründlicher Absprache mit dem Auftraggeber in der Spezifikation festgehalten sein. Wenn beispielsweise an einer Kreuzung die Ampeln die Verbindung zur Steuerzentrale verlieren, könnten sich alle Ampeln der Kreuzung auf rot stellen. Wenn die Verbindung nicht innerhalb einer Minute wieder hergestellt werden kann, sollten vielleicht besser alle Ampeln gelb blinken. Wenn hingegen nur eine einzige Fahrtrichtung an einer Kreuzung total ausfällt, sollten sich vielleicht alle anderen Ampeln ebenfalls ganz ausschalten und die Regelung des Verkehrs den Schildern überlassen. All diese Situationen müssen definiert sein und gründlich - am besten vollautomatisch - getestet werden können.

Alle Einzelfehler zu Testen ist schon schwer, aber wie sieht es mit Mehrfachfehlern aus, vor allem, wenn sich diese gegenseitig aufheben? Hat schon mal jemand die Zeit gehabt, die extrem aufwendigen Mehrfachfehlertests bei einem Softwaresystem durchzuführen? Es gibt da das berühmte Beispiel des Atomkraftwerks, bei dem die Software eine Störung melden und sich danach "möglichst neutral" verhalten sollte. Es kam, wie es kommen musste: Ein Ventil verursachte eine völlig harmlose Störung, die Software meldete diese und danach verhielt sich die Software so, wie die Entwickler "neutral" verstanden: sie ignorierte weitere Fehler. Dummerweise trat direkt nach dem harmlosen Ventilfehler eine ernsthafte Störung auf, die beinahe einen GAU verursacht hätte, weil sie nicht gemeldet wurde.

Ich möchte hier noch einen Aspekt erwähnen, der beim Testen sehr oft vergessen oder extrem unterschätzt wird: Die "Datenversionierung". Wenn Sie einen Fehler feststellen und die Entwickler diesen zur Behebung reproduzieren können sollen und die Tester später testen können sollen, ob er wirklich behoben ist, müssen Sie nicht nur exakt beschreiben können, was getan werden muss, um diesen Fehler zu provozieren, sondern Sie müssen genauso exakt beschreiben können, wie die Daten aussehen, die bei diesen Schritten verwendet werden. Sie werden also oft die Daten "einfrieren" können müssen und diesen Eisblock mit einer bestimmten Fehlernummer oder Versionsnummer kennzeichnen können müssen. Dafür sind ggf. Tools oder Zusatzprogrammierungen (beispielsweise umfangreiche Protokollmechanismen) erforderlich. Noch schwieriger wird es, wenn Sie zur Durchführung eines Tests eine ganz bestimmte Datensituation benötigen. Wenn beispielsweise bei einer Verwaltungssoftware die Übertragung von Restmitteln aus Budgets ins neue Wirtschaftsjahr getestet werden soll, so müssen Sie wahrscheinlich für alle Monate eines Jahres plausible Daten vorliegen haben, zum Ausführen des Tests müssen alle Rechneruhren des Neztes ein Datum vom Ende eines Wirtschaftsjahres haben und dann müssen auch noch alle anderen Abhängigkeiten für den Wechsel in ein neues Wirtschaftsjahr korrekt eingestellt sein. Dies zeigt, dass die Schaffung der Ausgangssituation eines Tests oft das Aufwändigste am ganzen Test ist. Aber die Bestimmung des genauen Aufwands zur Festlegung der Testprozesse im Projektplan ist in einem frühen Stadium des Projekts sicherlich auch sehr aufwändig.

Diese Seite verdeutlicht, wie unglaublich groß der Gesamtaufwand beim systematischen Testen werden kann. Es ist stets mehr Zeit erforderlich, als man vorher glaubte und der erste Fehler, den man dabei macht, ist vielleicht der, der durch den Spruch oben auf dieser Seite beschrieben wird. Denn die Software (bzw. die Iterationsstufe) ist ja "eigentlich" fertig und man möchte den Rest jetzt nur noch möglichst schnell hinter sich bringen.