Ein Testing-Pionier im Gespräch

Systematisches Software-Testen bedeutet, aus einer praktisch unendlichen Zahl möglicher Eingaben gezielt die relevanten auszuwählen: jene mit hohem Risiko und hoher Alltagsbedeutung. Testen macht keine Software kaputt, sondern zeigt auf, wo sie es bereits ist. Ausreichende Testabdeckung entsteht durch Methoden wie Äquivalenzklassen und Grenzwertanalyse, nicht durch blindes Ausprobieren.

Das Wichtigste in Kürze

• Testen ist kein destruktiver Akt: Kein einziger Testfall macht Software kaputt, sondern macht sichtbar, wo sie bereits kaputt ist.
• Vollständiges Austesten ist mathematisch unmöglich: Drei Parameter bei 16 Bit dauern mit 100.000 Tests pro Sekunde rund 89 Jahre, bei 32 Bit sind es 10 hoch 15 Jahre.
• Der Foundation-Level-Abschluss ist ein Führerschein, kein Fahrkönnensnachweis: Er erlaubt das Mitspielen im Straßenverkehr, echtes Testen lernt man erst durch jahrelange Praxis.
• Agilität hat die Mauer zwischen Entwicklung und Test nicht eingerissen, sondern nur ein Stück weit durchlässiger gemacht; im Kopf vieler Beteiligten steht sie noch.
• Entwicklerinnen und Entwickler, die mit Äquivalenzklassen und Grenzwerten klare Abdeckungskriterien erfüllen, wissen wann genug getestet ist; wer 300 automatisierte Testfälle ohne Kriterium durchlaufen lässt, weiß es nicht.

Testen macht keine Software kaputt, es macht Defekte sichtbar

Testen zerstört keine Software. Es zeigt, wo sie bereits defekt ist. Diese Unterscheidung klingt nach Wortklauberei, prägt aber das Selbstverständnis einer ganzen Disziplin.

Kein Testfall beschädigt ein Programm. Ist eine Stelle im Code fehlerhaft, war sie es schon vorher. Der Test bringt diese Stelle nur ans Licht. Wer Testen als destruktive Tätigkeit beschreibt, dreht die Logik um.

Konstruktiv ist Testen, weil es Denkarbeit verlangt. Tester überlegen, mit welchen Testdaten und in welcher Testumgebung sich ein Problem zeigen lässt, an das die Entwicklung nicht gedacht hat. Sie müssen weiterdenken: Wurde der negative Fall berücksichtigt? Wurde an den 29. Februar gedacht? Solche Lücken bleiben Jahrzehnte nach ihrer ersten Beschreibung bestehen.

Testen macht nichts kaputt, sondern zeigt auf, wo die Software kaputt ist. Kein einziger Testfall macht irgendeine Software kaputt.

Andreas Spillner

Warum vollständiges Austesten unmöglich ist

Kein Programm dieser Welt bekommt jemals alle möglichen Abläufe zur Ausführung vorgelegt. Das ist keine Frage der Disziplin, sondern der Mathematik.

Ein Rechenbeispiel macht das greifbar. Ein altes System mit 16 Bit, drei einzugebende Zahlen, eine Testautomatisierung, die 100.000 Tests pro Sekunde schafft: Alle Kombinationen durchzuprobieren würde rund 89 Jahre dauern. Bei 32 Bit landest du bei einer Größenordnung von 10 hoch 15 Jahren.

Daraus folgt nicht, dass Testen sinnlos ist. Daraus folgt, dass du auswählen musst. Welche Abläufe laufen jeden Tag? Wo entsteht ein hohes Risiko, wenn etwas scheitert? Genau dort setzt systematisches Testen an, statt blind irgendwo hineinzugreifen.

Wer diese eine Zahl verinnerlicht hat, hat im Test viel gewonnen: Kein Programm tut jemals alles, was es könnte. Die Frage ist also nicht, ob du auswählst, sondern wie.

Ausreichend statt ausgetestet

Der Begriff “austesten” führt in die Irre. Wer behauptet, etwas sei ausgetestet, müsste alle Möglichkeiten einmal zum Laufen gebracht haben. Das gelingt, wie das Bit-Beispiel zeigt, nie.

Sinnvoll ist ein anderes Ziel: für das konkrete Problem ausreichende Testfälle. Nicht ausgiebig, nicht ausführlich, sondern angemessen zum Risiko. Ein hochkritisches System verlangt viele Methoden und große Testtiefe. Eine Urlaubsplanung für Mitarbeiter braucht das nicht.

Testmethoden helfen bei dieser Auswahl. Mit der Äquivalenzklassenmethode lassen sich viele Eingabeparameter auf wenige Repräsentanten verdichten. Damit hast du ein belastbares Testfallset, ohne in der Kombinatorik zu ertrinken.

Das Bild eines Spinnennetzes trifft den Punkt. Ein gutes Netz ist gleichmäßig geformt, damit etwas hängen bleibt. Es ist nicht an einer Stelle engmaschig und an der anderen großmaschig. Genau diese gleichmäßige Abdeckung leisten Testmethoden.

Klare Endekriterien geben Sicherheit

Endekriterien entscheiden, ob du zufrieden in den Feierabend gehen kannst. Wer weiß, dass Äquivalenzklassen abgedeckt sind, Grenzwerte geprüft und Entscheidungstabellen mit einem grünen Häkchen versehen wurden, hat ein belastbares Signal für ausreichende Abdeckung.

Das Gegenbeispiel ist verbreitet. Eine Automatisierung läuft mit 300 Testfällen durch, und niemand weiß genau, was diese 300 Testfälle eigentlich prüfen. Dann fehlt das Kriterium, das sagt: Du hast genug getestet.

Die strukturierte Methode liefert Entwicklern genau das, was ihnen sonst fehlt: einen Anhaltspunkt, wann sie aufhören dürfen. Ohne dieses Kriterium bleibt das Gefühl, Testen sei eine bodenlose Aufgabe, die sich kaum anzufangen lohnt.

Agilität hat die Mauer zwischen Test und Entwicklung eingerissen

Der größte Umbruch der letzten zwei Jahrzehnte im Test war die Agilität. Das Agile Manifest stammt aus dem Jahr 2000, lange bevor das Thema intensiver in die Lehrpläne und Standardwerke einzog.

Früher stand eine Mauer zwischen Entwicklung und Test. Entwickler warfen das Produkt über die Mauer, Tester warfen die Fehlermeldung zurück, geredet wurde nicht. Agilität hat diese Trennung aufgebrochen, weil sie Teams in den Mittelpunkt stellt statt fester Übergaben.

Die Forderung selbst ist älter als die Agilität. Dass Entwickler und Tester miteinander arbeiten und nicht gegeneinander, wurde schon lange propagiert. Neu ist, dass eine Methode dieses Miteinander zum Prinzip macht.

Eine Restmauer bleibt: die Mauer im Kopf. Sie zeigt sich dort, wo Zusammenarbeit zwar möglich wäre, aber alte Reflexe weiterwirken.

Kommunikation ist Produktivität, auch wenn das Management sie nicht sieht

Miteinander reden ist der Kern agiler Arbeit, und genau das wird in Firmen oft nicht als Arbeit anerkannt. Für Austausch und Kooperation ist häufig keine Zeit vorgesehen, weil scheinbar nichts dabei herauskommt.

Tatsächlich ist es umgekehrt. Aus Kommunikation entsteht oft am meisten, nur sieht man das Ergebnis nicht sofort auf dem Papier. Diese Lücke zwischen Wirkung und Sichtbarkeit ist das eigentliche Verkaufsproblem.

Ein praktischer Weg ist, Kommunikationsräume zu tarnen. Ein Workshop oder eine kurze Coaching-Session schafft einen formalen Rahmen, in dem Austausch stattfinden darf. Sobald die ersten Effekte sichtbar werden, wächst die Toleranz dafür.

Tester und Entwickler profitieren dabei voneinander. Der Entwickler lernt Tester-Know-how, der Tester lernt Entwicklungswissen. Beides brauchst du heute in einem agilen Team, etwa für die Testautomatisierung.

Es gibt keine Lieblingsmethode, nur passende Methoden

Eine universelle Testmethode existiert nicht. Welche Methode oder welche Kombination richtig ist, hängt immer vom System und seinem Umfeld ab.

Die Silver Bullet gibt es nicht, im Test schon gar nicht. Stattdessen gilt: Je kritischer das System, desto intensiver und vielfältiger die Methoden. Je geringer das Risiko, desto weniger Aufwand ist gerechtfertigt.

Diese Haltung entlastet. Wer nicht nach der einen richtigen Methode sucht, sondern nach der passenden für das jeweilige Problem, trifft bessere Entscheidungen. Die Methodenwahl ist eine Frage des Kontexts, nicht der Mode.

Fehlerkultur entscheidet, ob aus Defekten Lernen wird

Eine gute Fehlerkultur bedeutet, zu Fehlern zu stehen und aus ihnen zu lernen. In Deutschland ist diese Kultur oft schwach ausgeprägt, nicht nur in der Softwareentwicklung.

Der Kontrast wird an einem Bild deutlich. Wenn eine Rakete beim Start explodiert und alle jubeln, weil aus dem Fehlgang viel gelernt wurde, ist das eine Haltung, die hierzulande schwer vorstellbar ist. Häufiger wird geduckt, versteckt und unter den Teppich gekehrt.

Feiern ist dabei nicht das Ziel. Lernen ist es. Manche Firmen leben eine Kultur, in der über Fehler offen diskutiert wird, damit sie sich nicht wiederholen. Andere ducken weg. Der Unterschied entscheidet, ob ein Defekt zum Lernanlass oder zum Tabu wird.

Persönliche Offenheit gehört dazu. Wer einen eigenen Fehler öffentlich aufarbeitet, statt sich zu verkrümeln, hilft vor allem sich selbst, auch wenn niemand sonst direkt daraus lernen kann.

Das Foundation Level ist ein Führerschein, kein Meisterbrief

Ein Testzertifikat auf Foundation-Niveau ist mit einem Führerschein vergleichbar. Du darfst ab jetzt mitspielen, du kennst die Regeln und die Zeichen, aber Auto fahren kannst du damit noch nicht.

Das Wissen dahinter ist nicht neu. Viele der Methoden wurden bereits in den 1970er Jahren beschrieben und sind bis heute gültig. Das Verdienst eines guten Grundlagenwerks liegt nicht in Innovation, sondern in klarer Begrifflichkeit und solider Aufbereitung.

Die eigentliche Kompetenz wächst danach. Erst nach Jahren im Umgang mit echten Systemen lernst du zu testen, so wie du erst nach Jahren wirklich Auto fährst. Das Zertifikat ist die Eintrittskarte, nicht das Ziel.

Ein Lehrplan als Orientierung erleichtert auch das Schreiben über das Thema enorm. Wenn der Inhalt vorgegeben ist, entfällt die schwierigste Arbeit: die ständige Frage, was noch hineingehört und was nicht. Embedded-Aspekte oder Realzeit-Themen gehören etwa bewusst nicht ins Grundlagenniveau.

Warum sich Entwickler schwer für systematisches Testen begeistern

Entwickler vom systematischen Testen zu überzeugen, bleibt schwierig. Die Vorstellung vom Austesten sitzt tief: Testen erscheint als unendlich große Aufgabe, mit der anzufangen sich kaum lohnt.

Genau hier liegt der Hebel. Strukturierte Methoden geben Entwicklern Endekriterien an die Hand. Sie verwandeln eine scheinbar grenzenlose Aufgabe in eine, die einen klaren Abschluss kennt.

Der Unterschied lässt sich an zwei Feierabenden festmachen. Mit abgedeckten Äquivalenzklassen, geprüften Grenzwerten und vollständigen Entscheidungstabellen gehst du zufrieden nach Hause. Mit 300 Testfällen ohne Wissen über ihren Zweck bleibt das ungute Gefühl, kein Kriterium für ausreichendes Testen zu haben.

Am Ende braucht es Herzblut für die Sache. Wer mit Überzeugung an ein Thema herangeht, bringt ordentliche Ergebnisse hervor, fast egal in welchem Feld.

Prognosen über die Zukunft des Testens sind selten zuverlässig

Vorhersagen über Technologie treffen oft daneben, und das gilt auch für den Test. Erwartungen wie die starke Modularisierung von Software, bei der Systeme nur noch aus intensiv getesteten Bausteinen mit verifizierten Schnittstellen zusammengesteckt werden, sind in dieser Form nicht eingetreten.

Hype-Wellen verstärken dieses Muster. Die Blockchain galt vor einigen Jahren als Technologie, die Verträge überflüssig machen würde. Eingetroffen ist das nicht in der versprochenen Breite. Solche Technologien landen oft auf einem Plateau realer Nutzung, fern vom ursprünglichen Versprechen.

Künstliche Intelligenz steht aktuell unter ähnlicher Beobachtung. Ob sie ein längerer Hype ist oder eine dauerhafte Veränderung, lässt sich seriös nicht sagen. Sicher ist nur eines: Die Erwartung, eine KI werde das Testen überflüssig machen, weil man ihr nur noch sage, was zu tun ist, wiederholt ein altes Muster. Schon früher hieß es, formale Spezifikation und Codegenerierung machten Testen unnötig. So kam es nicht.

Auch die eigene Fehleinschätzung lehrt Demut. Eine als überflüssig abgetane Technik wie Fernsehbilder auf dem Handy nutzt heute fast jeder selbst. In die Zukunft zu schauen bleibt schwierig.