Die harte Wahrheit über fehlerfreie Software
Vor vielen Jahren, an dem Tag, an dem wir beschlossen, ein großes Upgrade unseres Produkts zu veröffentlichen – eine Entscheidung, die selbstverständlich meine Zustimmung als Leiter der Qualitätssicherung erforderte –, ging ich den Flur entlang und der CEO kam mir entgegen.
Er hielt mich an und sagte: „Kann ich also davon ausgehen, dass wir ohne Fehler ausliefern?“
Ohne so viel nachzudenken, wie ich es vermutlich hätte tun sollen, antwortete ich unbekümmert: „Natürlich nicht. Es gibt keine Software ohne Fehler.“
Er war von meiner Antwort schockiert und entsetzt. Er war so verärgert über mich, dass er unser Gespräch abbrach und wütend den Flur entlangstürmte.
Damals schrieb ich das der Tatsache zu, dass er neu in der Softwarebranche und dem Lebenszyklus war, da er aus der Verlagsbranche kam (lange Geschichte – ein andermal). Denn jedem im Entwicklungsteam war klar, dass wir mit Fehlern auslieferten. Aber wir wussten, welche Fehler das waren, und genau das machte den Unterschied bei unserer Risikobewertung.
Mit Sorge stelle ich jedoch fest, dass dieses Missverständnis meines ehemaligen CEOs inzwischen in unserer Branche weit verbreitet ist. Fehlerfreie, „Null-Fehler-Software“ wird immer häufiger als neues Prunkstück oder Mantra präsentiert. Und das nicht nur von ahnungslosen CEOs (was doppelt gemoppelt klingt, ich weiß), sondern von Leuten in der Branche, die es besser wissen sollten. Und die es tatsächlich auch tun. Das beunruhigt mich sehr.
In gewisser Weise ist das „Null-Fehler“-Denken nicht nur verlogener, eigennütziger Unsinn. Im Westen ist es meist nur leeres Gerede und Selbstdarstellung. Aber in Japan hat es tatsächlich Bedeutung. Und das über alle Branchen hinweg.
Ich habe ein Jahr in Japan gearbeitet und das hat mich beeindruckt – allerdings im positiven Sinne. Denn ihre Definition eines „Fehlers“ unterscheidet sich grundlegend von unserer. Zum Beispiel gilt, wenn irgendwo im Werk eine Kaugummiverpackung auf den Boden fällt, das als Fehler – ebenso wie ein Problem mit einer Maschine oder im Ablauf eines Prozesses. Wenn wir wirklich ernsthaft „null Fehler“ anstreben würden, dann würden wir dieses Thema wie die Japaner betrachten. Aber das tun wir nicht, also werden wir es auch nicht tun.
Was ich diesem unglücklichen CEO vielleicht etwas zu unverblümt sagen wollte, ist, dass jegliche moderne kommerzielle Software unendlich komplex ist und deshalb ebenso unendlich viele Wechselwirkungen mit sich selbst oder ihrer Umgebung möglich sind. Es ist nur möglich, jeden Fehler zu finden, wenn man unendlich viel Zeit zum Testen hätte. Aber keiner von uns ist unsterblich.
Selbst wenn man beim ersten Mal jeden einzelnen Fehler finden könnte, hätte man nicht genug Zeit, sie alle zu beheben und noch in diesem Jahrhundert ein Produkt auszuliefern – Time-to-Market ist eine reale Größe. Selbst wenn sie gefunden werden, muss man also damit ausliefern.
Das gesamte Konzept der „Null-Fehler-Software“ ist also von Anfang an eine Illusion.
Woher kommt die Vorstellung von Null-Fehler-Software?
Dem Ursprung dieser Illusion liegt die Annahme zugrunde, die Aufgabe der QS sei es, Qualität zu „sichern“. Das tut sie aber nicht. Das ist die Aufgabe von Produktmanagement und Entwicklung. Die Rolle der Qualitätssicherung ist es, *zu bewerten*, wie erfolgreich diese dabei waren.
Aber es gibt noch eine andere heimtückische Schicht in diesem Problem.
Kürzlich habe ich dieses Thema mit einem Softwareentwickler diskutiert. Er sagte mir, die Bedeutung von „Null-Fehler-Software“ sei ihm genauso erklärt worden wie eben beschrieben. Es bedeutet, dass man mit all den Fehlern shippt, die das Team aus seiner Sicht beheben musste, um ausliefern zu können, und all die nicht behobenen Fehler ebenso ausliefert. Eine Definition, mit der mein Gesprächspartner übrigens nicht einverstanden war.
Das ist ganz klar nichts als begriffliche Augenwischerei. Man liefert tatsächlich mit Fehlern aus, weiß das auch, benutzt aber das Schlagwort „null Fehler“, um sich selbst – und natürlich dem Management – etwas vorzumachen. Denn wir alle wissen, dass sich das Management gerne von leeren Schlagworten beeindrucken lässt.
Es ist schlicht selektive Fehlerreduktion, nicht mehr und nicht weniger.
Wie kommen wir weg vom Null-Fehler-Schwindel?
Die Grundlage dieses Schwindels ist die Sprache selbst, die unser Denken bereits prägt und begrenzt, bevor wir überhaupt konzeptionell darauf reagieren können, was gesagt wird. Es ist diese falsche Sprache, die überhaupt erst dazu führt, dass wir erklären müssen, warum etwas falsch ist. Und so geraten wir durch den Wortschatz eines Schlagworts immer weiter in die Defensive.
Das ist eine weitverbreitete Praxis in der Softwareentwicklung. Leider beschränkt sie sich nicht darauf, uns in Bezug auf „null Fehler“ selbst zu belügen. Sie zieht sich durch alle Ebenen unseres Denkens und Handelns – bei Testern, im Entwicklungsprozess, bei den angewandten Methoden und Metriken.
Schauen wir der Realität doch einmal ins Auge, was wir tun – und was nicht. Der erste Schritt zur Besserung ist, eine Sprache zu verwenden, die ehrlich beschreibt, was wir tun und was wir unterlassen. Denn wenn schon die Sprache, mit der wir über die Realität sprechen, im Kern betrügerisch, unehrlich und wahnhaft ist, dann entstehen keine hochwertigen Softwaresysteme. Wir produzieren Propaganda.
Das andere Problem mit der Rhetorik der „Null-Fehler-Software“ besteht darin, dass selbst wenn dies ein aufrichtig angestrebtes Ziel ist – im Sinne von, dass Menschen ehrlich glauben, es sei möglich und es handele sich nicht nur um eine Übung in Zynismus – ein weiteres, noch schwerwiegenderes Problem den Nutzen dieser Idee einschränkt. Dieses Problem ist folgendes:
Wie könnten Sie überhaupt wissen und beweisen, dass Sie „alle“ Fehler gefunden haben, die es in der zu testenden Software zu finden gibt? Und nicht nur die Anzahl der Fehler, die Sie innerhalb des gegebenen Zeitrahmens gefunden haben? Wie könnten Sie sich selbst beweisen, dass die von Ihnen entdeckte Menge an Bugs tatsächlich die vollständige Menge an Fehlern repräsentiert, die die Software enthält?
Das können Sie nicht. Denn das würde einen Prozess außerhalb der Qualitätssicherung erfordern, um dies festzustellen. Andernfalls ist es lediglich ein Zirkelschluss. Und wie könnte ein solcher externer Prozess aussehen?
Und das gilt unabhängig davon, wie viele Fehler Sie bereits gefunden haben. Sie könnten eine Million gefunden haben. Das beweist jedoch nicht, dass nicht irgendwo im Schatten der Software Fehler Nummer eine Million und eins lauert.
Gibt es überhaupt einen Wert im Null-Fehler-Konzept?
Die offensichtlichen logischen und erkenntnistheoretischen Probleme beim Reden und Denken in Begriffen wie „Null-Fehler-Software“ sind schlicht unüberwindbar. Das Schlagwort selbst ist nicht zu retten, egal wie wir es umformulieren.
Aber wenn wir über die irreführende Parole hinausblicken und uns fragen, was daran attraktiv ist und warum sie für ansonsten klar denkende Menschen einleuchtend erscheint, finden wir tatsächlich etwas Wertvolles, worauf wir uns konzentrieren sollten.
Dieses „Etwas“ ist eine andere Frage, beantwortet aber die praktischen und emotionalen Bedürfnisse, die durch die irreführende Rhetorik der Null-Fehler-Software scheinbar adressiert werden – und zwar auf kohärentere und vertretbarere Weise.
Das Thema, das Menschen in der Softwarebranche hier in Wahrheit durch Selbsttäuschung zu greifen versuchen, ist selbst trügerisch einfach. Nämlich: „Wann wissen wir, dass wir mit dem Testen aufhören können?“
Es ist die einzige Frage, die ich Bewerbern für leitende Positionen in der Qualitätssicherung in meiner Organisation je stelle. Denn das ist wirklich die einzige Frage, auf die QA eine Antwort finden muss. Und wenn sie das nicht kann, ist QA eine komplette Zeitverschwendung. Um diese Frage zu beantworten, müssen wir zuvor eine andere Frage beantworten.
Null Fehler vs % Testabdeckung
Wie wissen wir, ob die Fehler, die wir bereits gefunden haben – wie viele es auch sein mögen – plausibel als repräsentativ für das Risikospektrum betrachtet werden können, das durch die Spezifikation und Entwicklung der zu testenden Software entstanden ist? So dass wir mit Zuversicht sagen können, dass verbleibende, unentdeckte Fehler ein akzeptables Risiko für die Entscheidung darstellen, die Software zu veröffentlichen?
So betrachtet erkennen wir, dass diese Frage gar keine Frage nach Fehlern ist. Es ist eine Frage nach der Testabdeckung. Ihre Analyse der gefundenen Fehler, wie zahlreich sie auch sind, bedeutet nichts, wenn sie nicht mit einem analytischen Verständnis der bereits durch die Qualitätssicherung erreichten sowie noch zu erreichenden Testabdeckung korreliert werden können.
Denn wenn diese Menge bekannter Fehler – egal, wie viel Testaufwand betrieben wurde – nur 30 % tatsächlicher Testabdeckung repräsentiert – und Sie wissen das nicht – dann haben Sie keine rationalen Grundlagen, um die Aussagekraft dieser Fehler in Bezug auf eine Freigabeentscheidung zu bewerten.
Die eigentliche Diskussion und das eigentliche Ziel einer wirklich effektiven Qualitätssicherungsarbeit können nicht „Null Fehler“ sein, sondern vielmehr „100 % Testabdeckung“. Aus dem oben genannten Grund.
Der große Vorteil dieses Ansatzes zur Bewertung von Softwarequalität besteht darin, dass er auf einer Definition ausreichender Testabdeckung basiert, die von der Qualitätssicherung selbst vor dem Testen erstellt wird. Diese Definition kann wiederum mit Spezifikationen, Anforderungen, früheren Kundenproblemen und Kundenbedürfnissen abgeglichen und bei Bedarf angepasst werden.
Nächster Schritt: Lückenlose Testabdeckung
Die Betrachtung dieses Problems in Bezug auf Fehler scheitert gerade daran, dass es sich nicht im Voraus sinnvoll definieren lässt, da Anzahl und Schwere der Probleme erst nach dem Testen festgestellt werden können.
Darüber hinaus wird ein Ziel wie „Null“ nie mit einer vorliegenden (bedeutungsvollen) Definition davon abgeglichen, was „Null“ überhaupt bedeuten könnte. Es ist Zeitverschwendung, Erfolg an einer Variablen zu messen, die selbst undefiniert und undefinierbar ist.
Deshalb ist die einzige Möglichkeit, den Gedanken der Null-Fehler-Software sinnvoll weiterzuführen, diese Denkweise und Planung stattdessen in Richtung lückenlose Testabdeckung zu lenken. Die Motivation hinter dem Null-Fehler-Mantra ist an sich nicht falsch. Sie wurde nur am eigentlichen Ziel vorbeigelenkt. Korrigieren Sie das, werden sinnvolle und messbare Definitionen akzeptabler Softwarequalität möglich.
Wenn Sie bereit sind, mehr zu lernen und direkt von Experten und CEOs zu hören, empfehlen wir Ihnen diesen Podcast: TEAMWORK, KI UND KONTAINERISIERUNG (MIT MICHAEL RITCHSON VON DER NASA)
Lesetipp: 10 BESTE TOOLS ZUR FEHLERVERFOLGUNG FÜR SOFTWARETESTS
