Automatisches Testen kann nur die Existenz von Fehler aufzeigen, nicht die Fehlerfreiheit
Was bedeutet diese Aussage? Ich will doch wissen, dass meine Software fehlerfrei ist. Dann bringt das doch gar nichts. Warum sollt ich dann meine Zeit mit automatischen Tests vergeuden?
Der Elefant steckt hier im Detail und der eigentliche Nutzen zeigt sich über die Zeit.
Fangen wir mal von vorne an:
Warum testen wir überhaupt? – Ok, die Frage ist einfach zu beantworten: um zu prüfen, dass unsere Software das tut, was sie soll.
Was muss ich tun beim Testen? – Na, das ist natürlich abhängig von der Software, aber kurz gefasst: alle Funktionen mit allen möglichen Eingaben und in jedem möglichen Umfeld ausführen und zu prüfen, ob das richtige Ergebnis erzielt wird.
Jede Möglichkeit? Jede Umgebung? Oh, das kann dauern. Und woher weiß ich, dass ich nichts vergessen habe? – Garnicht. Deine Zeit ist endlich. Aber man kann oft Eingaben in Gruppen unterteilen und muss nur ein Beispiel pro Gruppe testen. Was die Umgebungen angeht, also Einflüsse von außen, wird es schnell haarig. Wie simuliert man das Wegfallen einer Festplatte während des Schreibens einer Datei? Oder den Zusammenbruch des Stromnetzes und dessen Folgen? Tja, so ist das Leben. Wir können nicht alles wissen und nicht alles testen. Aber wir können sehr viel testen, wenn man die Zeit und den Aufwand investiert.
Und wie mache ich das? Starte ich meine Software und klicke wild um her und schaue was passiert? – Ja. Und nein. Bei einem kleinen Hobby-Projekt kann das ausreichen, aber so bald es etwas größer wird sollten Testfälle definiert werden und diese müssen dann einer nach dem anderen ganz genau abgearbeitet werden. Nach jeder Änderung an der Software.
Jedes Mal? – Ja, jedes mal.
Aber das braucht Zeit und je nach Testfall muss man Dinge vorbereiten. Das ist super aufwändig. Wirklich jedes Mal? – Ja, jedes mal. Du musst ja sicherstellen, dass du keinen neuen Fehler eingebaut hast, während du einen anderen behoben hast.
Aber jedes mal alles durch zu testen ist viel zu ineffizient. Gibt es da nicht eine Abkürzung? Zum Beispiel nur die Testfälle durchführen, die irgendwie mit der Änderung zusammen hängen? – Nein, es gibt keine Abkürzungen. Durch eine Änderung an der einen Stelle könnte ein Fehler in einem ganz anderen Teil der Software entstehen. Aber es gibt einen Weg dir langfristig die Arbeit zu erleichtern: die Testautomation.
Aber was bringt es mir Tests zu automatisieren, wenn ich damit nicht sicher stellen kann, dass meine Software fehlerfrei ist? Da mach ich mir ganz viel Aufwand und habe nichts davon. Was soll das bringen? – Nun, in dem Punkt unterscheiden sich manuelle Tests nicht von automatisierten Tests. Ich kann durchs Testen bestehende Fehler nachweisen und zwar auf einer Art die wiederholbar ist. Behebe ich den Fehler, so wird der Test ein anderes Ergebnis ausgeben. Damit habe ich erst nur die Existenz nachgewiesen, aber dann auch das Beheben des Fehlers. Beim manuellen Test würde man so einen Testfall meist nicht mehr betrachten. Automatisierte Testfälle spinnen jedoch ein Netz, das mir immer mehr Sicherheit gibt, dass meine Software annähernd fehlerfrei ist. Mit jedem weiteren Test wird das Netz engmaschiger, weil man automatisierte Tests nicht löscht oder deaktiviert.
Ja, genau. Keine Vorteile. Ich mache also so weiter wie bisher. Macht ja wohl keinen großen Unterschied, oder? – Doch und zwar einen gewaltigen. Für einen Testfall, für den man manuell ein paar Minuten braucht, braucht ein Computer nur Millisekunden. Durch das Automatisieren habe ich Zeit weitere Testfälle zu schreiben und das Netz noch engmaschiger zu machen. Dadurch das ich Software mit Software teste habe ich auch die Möglichkeit auf einer ganz anderen Ebene zu testen. Interne Programmstrukturen, die ich über die Benutzeroberfläche gar nicht erreiche, kann ich isolieren und ausgiebig testen.
Aber wer überwacht den Überwacher? Wenn meine Software Fehler hat und ich mit Software meine Software teste, dann kann ich davon ausgehen, dass auch die Test-Software fehlerhaft, oder? – Ja, das ist richtig. Die automatisierten Tests sind jedoch weit weniger komplex und einfacher zu verstehen als die eigentliche Software. Es können viele kleine Testfälle geschrieben werden, für jede kleine Änderung an der Software, die ineinandergreifen. Die Feedbackloop ist sehr viel kürzer und direkter für den Entwickler. So gesehen überwacht der Überwacher sich selbst. Natürlich kann es immer noch unentdeckte Fehler geben, aber die gibt es auch beim manuellen Testen. Hinzu kommt der Faktor Mensch beim manuellen Testen. Interpretationsspielräume in der Formulierung der Tests können das Ergebnis beeinflussen.
Ok, aber warum machten die Softwareentwickler das nicht einfach? – Je nach dem was das für Software ist, ist das leider nicht so einfach. Software muss so entwickelt werden, dass sie automatisiert testbar ist. Wenn man von Null anfängt ist es nur eine Methodologie, die befolgt werden muss. Das ist recht einfach. Wenn man bestehende Software automatisiert testen möchte, dann wird es sehr kniffelig. Die genutzte Technologie, wie die Programmiersprache, die genutzte Architektur selbst der Programmierstil der einzelnen Entwickler können da im Weg stehen. Dadurch werden die Kosten einer Entwicklung, die durchs automatische Testen eh schon gestiegen sind, um einiges teurer.
Wie bitte? Die Kosten steigen durch automatisierte Tests? – Auch hier wieder: ja, und nein. Es kommt auf den Blickwinkel an. Die eigentliche Entwicklung wird teurer. Es muss nicht nur die Änderung implementiert werden, sondern auch automatisierte Tests. Hinzu kommt, dass zusätzlich zum bestehender Code auch bestehende Tests angepasst werden müssen. Das braucht mehr Zeit und Zeit ist Geld. Aber ab da wird es deutlich günstiger. Die Tests sind innerhalb von Minuten oder Stunden abgeschlossen. Alle Tests. Kein stundenlanges manuelles Testen, kein stundenlanges erneut Testen. Personal, das vorher manuell getestet hat, kann nun wieder an der Wertschöpfungskette mitwirken.
Zusammengefasst ist automatisiertes Testen auf kurze Sicht teurer und bietet kaum Mehrwert. So bald man das Gesamtbild langfristig anschaut ist es günstiger, reduziert die Fehlerquote und beschleunigt die Entwicklung. Es gibt noch weitere Nebeneffekte, die sich langfristig einstellen, aber dazu ein anderes mal.