Illusion fehlerfreie Software
Spezifikationen, die alles enthalten und sich nie ändern. Entwickler, die exakt das programmieren, was verlangt ist – und dies noch fehlerfrei. Tester, die sämtliche Funktionen erfolgreich durchtesten und das noch dazu in kürzester Zeit. Und Benutzer, die das Programm genau so verwenden, wie es vom Erfinder gedacht ist. Aber genau so!
Dann, ja dann, wäre es eventuell sogar möglich, eine fehlerfreie Software zu produzieren. Aber Stopp! Da sind ja auch noch die äusseren Bedingungen, die Abhängigkeiten von Hardware-Komponenten und Elektronik – also kurz gesagt, viel zu viele Einflüsse.
Klar, muss man stark differenzieren. Wenn von Software die Rede ist, meint man ja nicht nur Programme auf dem PC oder Apps auf dem Handy. Software ist ja heute überall drin: Auto, Flugzeug, Waschmaschine, Backofen, Telefon, Uhr und vieles mehr. Das sind unterschiedlichste Systeme und Anforderungen und auch der Umfang der jeweiligen Software ist stark verschieden.
Etwas wird aber bei allen gleich sein und zwar unabhängig der verwendeten Prozesse und Arbeitsmodelle. Zuerst wird mal spezifiziert, was man überhaupt machen will. Und diese Spezifikation wird sich garantiert im Laufe der Entwicklung noch ändern und wachsen. Das ist so sicher, wie das Amen in der Kirche. Und ja, das Release-Datum wird natürlich auch schon definiert und häufig auch bereits kommuniziert. Da ist es egal, ob man schon weiss, was das Produkt alles können muss und wie aufwendig die Umsetzung ist. Also startet die Entwicklung mit einem vorerst definierten, aber sich bestimmt ändernden und wachsenden Anforderungskatalog. Das einzig wirklich fixe ist der Endtermin.
Der Tester fängt dann mal mit Vorabversionen an zu testen. Klar, hat es da noch Fehler drin, die geflickt werden müssen. Für irgendwas soll ja der Tester auch gut sein. Ja und am Ende wird die Software freigegeben. Im Optimalfall ohne bekannte Fehler, im Realfall werden in den Release-Notes oder sonstwo einfach die sogenannten Known Bugs aufgelistet. Man muss ja was zu tun haben für eine neue Version.
Und nun ist es soweit, der schlimmste der anzunehmenden Fälle: der Kunde benutzt die Software! Und eins ist da schon mal im vornherein klar. Er wird das Programm oder Gerät garantiert in irgendeinem Punkt anders bedienen, als dies jemandem der Herstellerfirma auch nur im Traum in den Sinn gekommen wäre. Und natürlich tritt der dümmste Fall ein und das Programm verhält sich in genau diesem Punkt nicht so, wie dies der Benutzer erwartet. Ein Fehler oder einfach nur ein nicht definiertes Feature?
Nun, wenn am PC ein Programm abstürzt oder die App auf dem Handy einfach mal was falsches anzeigt, ist das ja nicht so tragisch. Es nervt zwar, aber man kriegt davon kein blaues Auge ab. Software wird jedoch auch in sicherheitsrelevanten Umgebungen eingesetzt, wie der Fliegerei, in Aufzügen und Seilbahnen oder in der Zutrittskontrolle zu Gebäuden. Einerseits werden hier speziell geprüfte Komponenten eingesetzt, die in ihrem System quasi unveränderbar sind. Oder in Flugzeugen sind wichtige Systeme redundant vorhanden – also auch hier geht man nicht einfach von Fehlerfreiheit aus. In Aufzügen sind zum Beispiel noch softwareunabhängige Sensoren verbaut, die einen nicht in der Türe einklemmen sollten.
Wieso werden nun nicht einfach alle Softwareprodukte genügend getestet und geprüft? Dann würde es ja auch kaum noch Fehlverhalten geben, oder? Naja, wenn man dies so machen würde, wären bestimmt schon viele Firmen pleite gegangen oder manches Produkt wäre nicht auf den Markt gekommen. Kurz gesagt: dafür fehlt ganz einfach das Geld. Oder die Ressourcen und die Zeit, was ja am Ende ebenfalls wieder Geld bedeutet. Viel Geld! Im Zeitalter von Gratis-Apps wollen wir als Endkunden bestimmt nicht dafür bezahlen.
Wie nehmen wir nun aber die Software-Fehler wahr? Wie sind die Auswirkungen? Das ist am Ende das entscheidende. Ist ein Text in einer aufpopenden Dialogbox falsch, die eh keiner liest, so ist das zwar ein Fehler, aber einer den niemand merkt und wenn, dann höchstens zum Lachen bringt. Kann man diese ominöse Dialogbox aber nicht mehr vernünftig schliessen aufgrund eines Fehlers und diese blockiert sogar das Programm im Hintergrund, dann ist das Programm schlichtweg nicht mehr zu benutzen. Man kann noch so unaufmerksam sein, das merkt man einfach. Tritt dieses Fehlverhalten zu häufig und bei oft benutzten Funktionen auf, so wechseln wohl die meisten ziemlich schnell zu einem Alternativprodukt. Der Schaden ist also immens.
Es muss jedoch nicht immer ein Fehler in der Software sein. Wo Software läuft, da steckt immer auch Hardware und Elektronik dahinter und auch diese Komponenten können fehlerhaft sein. Da man als Benutzer aber immer die Software bedient und von der Elektronik normalerweise nichts sieht, ist natürlich immer die Software schuld. Eine Erfahrung, die ich sehr häufig mache. Unsere Software läuft nämlich auf verschiedenen Hardware- und Elektronik-Varianten und da sind Einflüsse auf die Funktionalität der Software quasi vorprogrammiert. Nicht zuletzt, weil aus Kostengründen schlichtweg nicht alle x-beliebigen Kombinationen vollständig getestet werden können. Da ein Update der Software einfacher ist, als ein ganzes Gerät komplett auszutauschen, darf man als Software-Entwickler auch ab und zu mal Hardwareprobleme softwaretechnisch aus der Welt schaffen. Und siehe da! Was lief nun nicht? Was musste man austauschen? Et voila! Die Software!
Weiter kommt bei umfangreichen Softwareprojekten noch dazu, dass diese über Jahre oder gar Jahrzehnte gewachsen sind. Einerseits wird vom Kunden das neuste Look and Feel erwartet, andererseits sollen aber selbstverständlich sämtliche, teils uralten Funktionen nachwievor vorhanden sein. Grossen Wirbel machte da in den letzten Jahren Microsoft mit der Einführung des Ribbon-Menu in den Office-Programmen und der Einführung von Windows 10 mit dem Umweg über Windows 8. Beides finde ich im übrigen mutige, aber sehr gute und sinnvolle Schritte. Aber eben, muss man alten Code weiterhin pflegen und trotzdem neues hinein entwickeln, sind natürlich potenzielle Fehler vorprogrammiert.
Ein Ziel eines jeden Software-Entwicklers ist aber selbstverständlich, die Fehlerrate so tief wie nur möglich zu halten. Code Reviews, Automatisierte Tests und nicht zuletzt eine gute Architektur helfen dabei. Es soll einfach keiner behaupten, er arbeite zu 100% fehlerfrei. Bestimmt hat es in meinen Artikeln ab und zu einen Rechtschreibfehler drin. Nur merkt dies wohl niemand und wenn doch, stört es nicht so gross. Ein Programm wäre jedoch bei einer bestimmten unerwarteten und nicht getesteten Bedienung abgestürzt ab einem Schreibfehler im Quellcode.
Und zum Schluss: Die Grundfunktionen und der von uns so liebevoll Happy Path genannte normale Ablauf, funktionieren wohl praktisch bei jedem Programm korrekt. Nur schon, weil dies bestimmt bereits vom Entwickler getestet wurde.
Was ist eure Erfahrung mit fehlerhaften Programmen, Apps und sonstiger Software? Habt ihr bei bestimmter Bedienung ominöse Meldungen oder komische Verhalten? Die Diskussion darf geführt werden!
