"Jede Software hat Fehler"

Software hat Fehler. Das ist ganz normal.

Ein Softwarefehler häufig auch Bug (englisch) genannt, bezeichnet im Allgemeinen ein Fehlverhalten von Computerprogrammen. Dies tritt auf, wenn der Programmierer eine bestimmte Festlegung der Spezifikation nicht oder falsch umgesetzt hat. Weiterhin können auch Unvollständigkeit, Ungenauigkeit oder Mehrdeutigkeiten in der Spezifikation des Programms zu „Fehlern“ führen. Zur möglichst vollständigen Erkennung und Behebung von Programmfehlern wird üblicherweise in den Prozessen der Softwareentwicklung, d. h. vor dem tatsächlichen, 'produktiven' Einsatz von Software, die Projektphase Softwaretest durchlaufen, wobei eine Validierung durchgeführt wird. Dabei auftretende Fehler sind üblich und sie zu finden ist Ziel des Testens, während Fehler im laufenden Betrieb je nach Fehlerwirkung u. U. kritische Anomalien/Störungen darstellen. In der Praxis treten Computerprogramme ohne Programmfehler selten auf. Programme mit einer Fehlerdichte von weniger als 0,5 Fehlern pro 1000 Zeilen Code gelten als stabile Programme. Als spezielle Instrumente zur Suche nach den Ursachen für Fehler in Programmen sind sogenannte Debugger hilfreich, mit denen ein Programm Schritt für Schritt ausgeführt und kontrolliert werden kann. Bei besonders kritischer Software (z. B. Flugzeugsteuerung) wird mitunter eine formale Verifikation durchgeführt. Zur Erfassung und Dokumentation werden sogenannte Bugtracker (z.B. JIRA) eingesetzt. Diese nehmen sowohl Fehlerberichte, als auch Verbesserungsvorschläge und Wünsche der Nutzer oder allgemeine Vorgänge auf. Der Vorgang des Beseitigens eines Programmfehlverhaltens wird bugfixing genannt, das Ergebnis der Verbesserung wird als Bugfix bezeichnet."
Unser Projekt Management im technischen Sinn richtet sich an der sogenannten „Agilen Softwareentwicklung“ aus. Dabei sind wir bestrebt, mit geringem bürokratischen Aufwand, wenigen Regeln und meist einem iterativen Vorgehen effizient und pragmatisch das Projekt zu leiten und im kleinen Team umzusetzen.
Enttäuschung entsteht, wenn die Erwartungen nicht der Realität entsprechen. Und unsere Erwartungen an die Softwarequalität sind oft unrealistisch. So werden viele Anwender immer wieder von Softwarefehlern enttäuscht, ja sogar wütend gemacht. Das sollten sie nicht sein. Der einzige zuverlässige, weit verbreitete Weg, um eine einwandfreie Softwarequalität zu gewährleisten, ist, weniger Software zu schreiben, die weniger Dinge tut. Ein solcher Ansatz ist jedoch sehr selten mit kommerziellem Erfolg oder gar mit der Motivation von Entwicklern vereinbar. Während Anwender sich für das Konzept "Halte den Zug an, wir müssen die Gleise reparieren" Richtlinien für die Software-Entwicklung begeistern, ist es nicht das, was sie kaufen würden. Nun, aber dann ist da noch der Glaube: Apple ist so reich, können sie nicht einfach mehr Entwickler und Tester einstellen, um alle Fehler zu beheben? Um Frederick Brooks zu paraphrasieren: Nein. So funktioniert die Softwareentwicklung nicht. Immer größere Teams auf Probleme anzusetzen, macht die Probleme meist nur noch größer. Fehler sind ein unvermeidliches Nebenprodukt beim Schreiben von Software. Sobald wir diese einfache Tatsache akzeptieren, dass Software = Fehler, können wir Fortschritte machen, um zu verstehen, warum die Behebung dieser Fehler vielleicht nicht einmal so wichtig ist.
Das Fehlen von Fehlern ist nur ein Erfolgsparameter in der Software, aber nicht einmal annähernd der wichtigste (mit einigen Ausnahmen für lebenskritische Systeme). Nutzlose Software kann völlig fehlerfrei sein und dennoch völlig nutzlos bleiben. Nützliche Software kann mit fehlerhaft sein, bleibt aber trotzdem sehr wertvoll. Oder, der Wert von Software hängt viel mehr von dem Problem ab, das sie löst, als von der Qualität, mit der sie dies tut. Sie könnten zwei Programme haben, die das gleiche Problem lösen, und es ist vernünftig zu denken, dass die mit weniger Fehlern besser wäre. Doch selbst diese einfache Aussage wird vom Markt oft widerlegt. Faktoren wie bestehende Akzeptanz, Integration, Marke und Spaß übertrumpfen oft die Qualität. Angesichts der Tatsache, dass es so viele Faktoren gibt, die für die Zukunftsaussichten einer Softwarelösung und seiner Hersteller wichtiger sind, ist es wirklich so überraschend, dass nicht jeder Fehler "alles fallen lassen, wir müssen das beheben" Priorität hat? Natürlich nicht. Anwender, die einen Fehler gefunden haben, tun immer noch so, als ob es so wäre.
Der Wert eines jeden Fehlers kann anhand der Anzahl der betroffenen Benutzer und der Kritikalität des Problems bewertet werden. Viele Benutzer verlieren durch diesen Fehler alle ihre Daten? Okay, dann ist es sehr wichtig! Reparieren Sie es JETZT! Viele Benutzer sind ein wenig verärgert oder verwirrt darüber? Wahrscheinlich sollte es bald repariert werden. Ein paar Benutzer müssen weitere 30 Sekunden für eine Arbeit um sich herum aufwenden? Es ist unwahrscheinlich, dass es bald repariert wird! Software-Organisationen, die im Geschäft bleiben, priorisieren ihren Nachholbedarf an solchen Fehlern. Sie lassen nicht alles fallen, um mit irgendeinem Fehler fertig zu werden. Mit den Skaleneffekten steigt auch das Ausmaß der Folgen einer solchen Priorisierung. Große Softwarepakete haben oft Hunderte, wenn nicht Tausende offener "Bugs" unterschiedlicher Kritikalität. DAS IST NORMAL. DAS WIRD ERWARTET. Dies ist keine Aufforderung, auf Softwarequalität zu verzichten, ganz im Gegenteil.
Also, wenn Sie das nächste Mal einen lästigen Fehler entdecken, haben Sie Respekt dafür, dass so etwas Komplexes wie eine moderne Software so "einwandfrei" funktioniert! Denken Sie kurz an die enorme Rechenleistung die Ihr Computer erbringt, damit Sie die Funktionalitäten voll nutzen können. Haben Sie etwas Verständnis für Mensch und Maschine.