Ein Programmfehler oder Softwarefehler, häufig auch als Bug (bʌg) benannt, bezeichnet im Allgemeinen ein Fehlverhalten von Computerprogrammen. Dies tritt auf, wenn der Programmierer eine bestimmte Festlegung der Spezifikation nicht oder falsch umgesetzt hat, oder wenn die Laufzeitumgebung fehlerhaft bzw. anders als erwartet arbeitet. 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. Dabei auftretende Fehler sind üblich, und sie zu finden ist Ziel des Testens^[1] 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. Statistische Erhebungen in der Softwaretechnik weisen im Mittel etwa zwei bis drei Fehler je 1000 Zeilen Code aus.

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.

Zur Erfassung und Dokumentation werden sogenannte Bug-Tracker (wie Bugzilla oder Mantis) eingesetzt. Diese nehmen sowohl Fehlerberichte, als auch Verbesserungsvorschläge und Wünsche der Nutzer oder allgemeine Vorgänge auf. Siehe auch Fehlermanagement.

Der Vorgang des Beseitigens eines Programmfehlverhaltens wird umgangssprachlich bugfixing genannt. Das Ergebnis der Verbesserung wird in der Fachsprache als Bugfix, Patch oder Softwarepatch bezeichnet.

Ein Programm- oder Softwarefehler ist, angelehnt an die allgemeine Definition für 'Fehler'^[2]

„Die Nichterfüllung einer festgelegten Forderung (DIN ISO 8402)“.

Konkret definiert sich der Fehler danach als

„Abweichung des IST (beobachtete, ermittelte, berechnete Zustände oder Vorgänge) vom SOLL (festgelegte, korrekte Zustände und Vorgänge), wenn sie die vordefinierte Toleranzgrenze [die auch 0 sein kann] überschreitet.“

Nach ISTQB^[3] bildet sich der Begriff 'Fehler' aus den folgenden Zusammenhängen:

• eine Fehlhandlung (engl. Error)

„die menschliche Handlung, die zu einem Fehlerzustand führt [nach IEEE 610])“

• ... führt zu einem Fehlerzustand (engl. Defect)

„Defekt (innerer Fehlerzustand) in einer Komponente oder einem System, der eine geforderte Funktion des Produktes beeinträchtigen kann ...“

• der eine Fehlerwirkung (engl. Failure) nach sich ziehen kann

„Die Manifestierung eines inneren Fehlers bei der Ausführung des [ Programms ] als ein inkorrektes Verhalten oder Resultat bzw. als Versagen des Systems.“

Als Synonym für 'Fehler' oder ergänzend dazu sind auch Ausdrücke wie Problem, Defect, Abweichung, Mangel gebräuchlich. Damit kann die 'Fehlerschwere' auch begrifflich unterschieden werden, z. B. die Verletzung von Vorschriften zum Programmierstil von der Lieferung falscher Ergebnisse oder einem Programmabbruch.

Das Wort „Bug“ wurde schon im 19. Jahrhundert für kleine Fehler in mechanischen und elektrischen Teilen verwendet. Knistern und Rauschen in der Telefonleitung würden daher rühren, dass kleine Tiere („Bugs“: engl: Wanze) an der Leitung knabbern. Edison schrieb an seinen Freund Tivadar Puskás, den Erfinder der Telefonzentrale und Gründer einer Telefonzeitung einen Brief über die Entwicklung seiner Erfindungen, in dem er kleine Störungen und Schwierigkeiten als „Bugs“ bezeichnete. Vorlage:"-en Edison ist zwar nicht Erfinder, aber immerhin Kronzeuge für eine schon damals kursierende Neuschöpfung.

Die Verknüpfung des Begriffs mit Computern geht möglicherweise auf die Computerpionierin Grace Hopper zurück.^[4] Sie verbreitete die Geschichte, dass am 9. September 1945 eine Motte in einem Relais des Computers Mark II Aiken Relay Calculator zu einer Fehlfunktion führte. Die Motte wurde entfernt und in das Logbuch geklebt mit den Worten Vorlage:"-en. Die Legende von der Begriffsfindung hält sich hartnäckig, obwohl die Logbuch-Eintragung gerade auf die frühere Verwendung des Begriffs hinweist. Zudem irrte Grace Hopper sich hinsichtlich des Jahres: Der Vorfall ereignete sich tatsächlich am 9. September 1947. Die entsprechende Seite des Logbuchs wurde bis Anfang der 1990er Jahre am Naval Surface Warfare Center Computer Museum der US-Marine in Dahlgren, Virginia, aufbewahrt. Zurzeit befindet sich diese Logbuchseite mit der Motte am Smithsonian Institute.

In der Softwaretechnik wird zwischen folgenden Typen von Fehlern in Programmen unterschieden:

• Syntaxfehler sind Verstöße gegen die grammatischen Regeln der benutzten Programmiersprache. Ein Syntaxfehler verhindert die Kompilierung des fehlerhaften Programms. Bei Programmiersprachen, die sequentiell interpretiert werden, bricht das Programm an der syntaktisch fehlerhaften Stelle undefiniert ab.

• Laufzeitfehler sind alle Arten von Fehlern, die auftreten, während das Programm abgearbeitet wird. Da diese Fehler die Programmlogik und damit die Bedeutung des Programmcodes betreffen, spricht man hier auch von semantischen Fehlern. Ihre Ursache liegt in den meisten Fällen in einer inkorrekten Implementierung der gewünschten Funktionalität im Programm. Gelegentlich tritt als Ursache auch eine ungeeignete Laufzeitumgebung auf (z. B. eine falsche Betriebssystem-Version). Laufzeitfehler können sich auf die unterschiedlichsten Arten zeigen. Oftmals zeigt das Programm ungewünschtes Verhalten, im Extremfall wird die Ausführung des Programms abgebrochen („Absturz“), oder das Programm geht in einen Zustand über, in dem es keine Benutzereingaben mehr akzeptiert („Einfrieren“, „Hängen“). Wird in Programmiersprachen ohne automatische Speicherbereinigung (etwa C oder C++) Speicher nach der Verwendung nicht mehr freigegeben, so wird durch das Programm auf Dauer immer mehr Speicher belegt. Diese Situation wird Speicherleck genannt. Aber auch in Programmiersprachen mit automatischer Speicherbereinigung (etwa Java oder C#) können ähnliche Probleme auftreten, wenn zum Beispiel Objekte durch systemnahe Programmierung unkontrolliert angesammelt werden. Noch kritischer sind versehentlich vom Programmierer freigegebene Speicherbereiche, die oft trotzdem noch durch hängende Zeiger referenziert werden, da dies zu völlig unkontrolliertem Verhalten der Software führen kann. Manche Laufzeitumgebungen erlauben daher solche programmierbaren Speicherfreigaben grundsätzlich nicht. Des Weiteren gibt es auch Bugs im Zusammenhang mit Multithreading, etwa Race Conditions, welche Konstellationen bezeichnen, in denen das Ergebnis einer Operation vom zeitlichen Verhalten bestimmter Einzeloperationen abhängt, oder Deadlocks.

• Fehler im Compiler, der Laufzeitumgebung oder sonstigen Bibliotheken. Solche Fehler sind meist besonders schwer nachzuvollziehen, da das Verhalten des Programms in solchen Fällen nicht seiner Semantik entspricht. Insbesondere von Compiler und Laufzeitumgebung wird daher besondere Zuverlässigkeit erwartet, welche jedoch gerade bei kleineren Projekten nicht immer gegeben ist.

• Logische Fehler und semantische Fehler bestehen in einem falschen Problemlösungsansatz, beispielsweise auf Grund eines Fehlschlusses oder eines fehlerhaften oder falsch interpretierten Algorithmus. Die Toleranz gegenüber solchen Fehlern und die diese einschränken sollende Attributgrammatik von Programmiersprachen, wie etwa bei der Zuweisungskompatibilität von Datentypen, sind je nach verwendeter Programmiersprache sehr unterschiedlich ausgeprägt.

• Designfehler sind Fehler im Grundkonzept, entweder bei der Definition der Anforderungen an die Software, oder bei der Entwicklung des Softwaredesigns, auf dessen Grundlage das Programm entwickelt wird. Fehler bei der Anforderungsdefinition beruhen oft auf mangelnder Kenntnis des Fachgebietes, für das die Software geschrieben wird oder auf Missverständnissen zwischen Nutzern und Entwicklern. Fehler direkt im Softwaredesign hingegen sind oft auf mangelnde Erfahrung der Softwareentwickler, unstrukturierte Programmierung oder auf Folgefehler durch Fehler in der Anforderungsspezifikation zurückzuführen. In anderen Fällen ist das Design historisch gewachsen und wird mit der Zeit unübersichtlich, was wiederum zu Designfehlern bei Weiterentwicklungen des Programms führen kann. Vielen Programmierern ist das Softwaredesign auch lästig, sodass oftmals ohne richtiges Konzept direkt entwickelt wird, was dann insbesondere bei steigendem Komplexitätsgrad der Software unweigerlich zu Designfehlern führt. Sowohl für Fehler in der Anforderungsdefinition als auch im Softwaredesign kommen darüber hinaus vielfach Kosten- oder Zeitdruck in Frage. Ein typischer Designfehler ist die Codewiederholung, die zwar nicht unmittelbar zu Programmfehlern führt, aber bei der Softwarewartung, der Modifikation oder der Erweiterung von Programmcode sehr leicht übersehen werden kann und dann unweigerlich zu unerwünschten Effekten führt.

• Ein Regressionsbug ist ein Fehler, der in einer früheren Programmversion bereits behoben wurde, der aber in einer späteren Programmversion wieder auftaucht.

• Fehler im Bedienkonzept. Das Programm verhält sich anders als es einzelne oder viele Anwender erwarten, obwohl es technisch an sich fehlerfrei arbeitet.

• Fehler durch inkompatible Systemteile. Wenn zum Beispiel eine neu installierte Version einer Software an ihren Schnittstellen zu den sie nutzenden Programmen nicht exakt identisch arbeitet wie bisher, kann es beim Ablauf dieser unveränderten Programme zu Problemen kommen.

• Fehler als Folge physikalischer Betriebsbedingungen. Verschiedenste Begebenheiten wie elektromagnetische Felder, Strahlen, Temperaturschwankungen, Erschütterungen, usw., können auch bei sonst einwandfrei konfigurierten und innerhalb der Spezifikationen betriebenen Systemen zu Fehlern führen. Fehler dieses Typs sind sehr unwahrscheinlich, können nur sehr schwer festgestellt werden und haben bei Echtzeitanwendungen unter Umständen fatale Folgen. Sie dürfen aber aus statistischen Gründen nicht ausgeschlossen werden. Das berühmte „Umfallen eines Bits“ im Speicher oder auf der Festplatte auf Grund der beschriebenen Einflüsse stellt zum Beispiel solch einen Fehler dar. Da die Auswirkungen eines solchen Fehlers (z. B. Absturz des Systems oder Boot-Unfähigkeit, weil eine Systemdatei beschädigt wurde) von denen anderer Programmfehler meist nur sehr schwer unterschieden werden können, vermutet man oft eine andere Ursache, zumal ein solcher Fehler häufig nicht reproduzierbar ist.

Bei manchen Projekten wird nicht der Begriff Bug verwendet, sondern man spricht zum Beispiel von Metabugs, bei denen ein Bug ein Element einer Aufgabenliste darstellt. Bei einigen Projekten spricht man stattdessen auch von „Issues“ (Angelegenheiten), da sich dieser Ausdruck nicht auf Programmfehler beschränkt.

Konkrete Beispiele von Fehlern mit medial besonderer Wirkung finden sich in dieser Liste.

Softwarefehler sind weit mehr als nur ärgerliche Begleitumstände für Softwareentwickler, sondern sie verursachen aus betriebswirtschaftlicher und ökonomischer Sicht erhebliche Kosten. Die IX-Studie 1/2006^[5] zeigt z. B. folgende für Deutschland ermittelte Werte:

• Ca. 84,4 Mrd Euro betragen die jährlichen Verluste durch Softwarefehler in Mittelstands- und Großunternehmen
• Ca. 14,4 Mrd Euro jährlich (35,9% des IT-Budgets) werden für die Beseitigung von Programmfehlern verwendet;
• Ca. 70 Mrd Euro betragen die Produktivitätsverluste durch Computerausfälle aufgrund fehlerhafter Software

In derselben Studie wird auch die Entwicklung der Softwarequalität für die Zeit von 2002 bis 2004 untersucht - mit dem Ergebnis:

• die Rate gescheiterter Projekte stieg von 15% auf 18%
• die Rate erfolgreicher Projekte sank von 34% auf 29%
• die Rate der Projekte mit Kostenüberschreitung stieg von 43% auf 56%
• die Rate der Projekte mit Terminüberschreitung stieg von 82% auf 84%
• die Rate der Projekte mit passender Funktionalität sank von 67% auf 64%

Besonders viele Misserfolge zeigt ein Bericht des obersten Rechnungshofs für neue Projekte (1985) bei der US-Bundesverwaltung,^[6] wonach

• 27 % der bezahlten Software nie geliefert wurden,
• 52 % nie funktionierten,
• 18 % erst nach einer aufwändigen Sanierung zum Einsatz kamen.
• Lediglich 3 % der in Auftrag gegebenen Software erfüllten die vereinbarten Vertragsbedingungen

Die Standish Group International stellte fest:^[7] Durchschnittlich überschreiten Projekte

• die ursprünglich geplanten Projektkosten um 89 %
• die geplanten Termine um 222 %

Als Gründe für Projektabbrüche aufgrund schlechter Softwarequalität ermittelte Ewusi-Menach folgende Faktoren:^[6]

• Unklare Zielsetzung; falsche Projektteambesetzung; unzulängliche Qualitätssicherung; fehlendes technisches Know-how; unzureichende Berücksichtigung der Ausgangssituation; mangelnde Beteiligung der Anwender

Generell gilt:^[8] Je früher im Entwicklungsprozess der Fehler auftritt und je später er entdeckt wird, umso aufwändiger wird es, den Fehler zu beheben.

Am wichtigsten ist eine gute und geeignete Planung des Entwicklungsprozesses. Hierfür gibt es bereits etliche Vorgehensmodelle, aus denen ein geeignetes ausgewählt werden kann.

Ein Problem ist, dass die Korrektheit eines Programms nur gegen eine entsprechend formalisierte Spezifikation bewiesen werden kann. Eine solche Spezifikation zu erstellen kann jedoch im Einzelfall ähnlich kompliziert und fehlerträchtig sein, wie die Programmierung des Programms selbst.

Auch die Entwicklung immer abstrakterer Programmierparadigmen und Programmierstile wie die funktionale Programmierung, objektorientierte Programmierung, Design By Contract und die aspektorientierte Programmierung dienen unter anderem der Fehlervermeidung und Vereinfachung der Fehlersuche. Aus den zur Verfügung stehenden Techniken für das Problem ist eine geeignete auszuwählen. Ein wichtiger Punkt hierbei ist aber auch, dass für das jeweilige Paradigma erfahrene Programmierer zur Verfügung stehen müssen, sonst entsteht oft der gegenteilige Effekt.

Ferner ist es sehr nützlich, von den Entwicklungswerkzeugen möglichst viele Aufgaben der Fehlervermeidung zuverlässig und automatisch erledigen zu lassen, was z. B. mit Hilfe von strukturierter Programmierung erleichtert wird. Dies betrifft zum einen bereits Kontrollen wie Sichtbarkeitsregeln und Typsicherheit, sowie die Vermeidung von Zirkelbezügen, die bereits vor der Übersetzung von Programmen vom Compiler übernommen werden können, aber auch Kontrollen, die erst zur Laufzeit durchgeführt werden können, wie zum Beispiel Indexprüfung bei Datenfeldern oder Typprüfung bei Objekten der objektorientierten Programmierung.

Softwareexperten sind sich darüber einig, dass praktisch jedes nicht-triviale Programm Fehler enthält. Deshalb wurden Techniken entwickelt, mit Fehlern innerhalb von Programmen tolerant umzugehen. Zu diesen Techniken gehören defensives Programmieren, Ausnahmebehandlung, Redundanz und die Überwachung von Programmen (z. B. durch Watchdog-timer) sowie die Plausibilisierung des Programmes während der Entwicklung und der Daten während des Programmablaufs.

Darüber hinaus wird eine Reihe fortgeschrittener Anwendungen angeboten, die entweder den Quellcode oder den Binärcode analysieren und versuchen, häufig gemachte Fehler automatisiert zu finden. In diese Kategorie fallen etwa Programme zur Ausführungsüberwachung, die üblicherweise fehlerhafte Speicherzugriffe und Speicherlecks zuverlässig aufspüren. Beispiele sind das frei erhältliche Tool Valgrind und das kommerzielle Purify. Eine weitere Kategorie von Prüfprogrammen umfasst Anwendungen, die Quell- oder Binärcode statisch analysieren und etwa nicht geschlossene Ressourcen und andere Probleme auffinden und melden können. Darunter fallen etwa Findbugs, Lint und Splint.

Es ist durchaus sinnvoll, dass der Test vor dem eigentlichen Programm entwickelt wird. Damit wird erreicht, dass nicht ein Test geschrieben wird, der zu dem bereits geschriebenen Programm passt. Dies kann durch Ermittlung von Testfällen anhand der Spezifikation bereits während der Analyse- bzw. Designphase erfolgen. Die Ermittlung von Testfällen in diesem frühen Stadium der Softwareentwicklung ermöglicht zudem die Prüfung der Anforderungen an das Programm auf Testbarkeit und Vollständigkeit. Die anhand der Spezifikation ermittelten Testfälle stellen die Basis für die Abnahmetests und können kontinuierlich über den gesamten Entwicklungsprozess verfeinert werden.

Manche Softwareanbieter führen Testphasen teilweise öffentlich durch und geben Betaversionen heraus, um die unvorhersehbar vielfältigen Nutzungsbedingungen verschiedener Anwender durch diese selbst testen und kommentieren zu lassen.

Tritt ein Fehler während des Betriebs auf, so muss versucht werden, seine Auswirkungen möglichst gering zu halten und seinen Wirkungskreis durch Schaffung von „Schutzwällen“ oder „Sicherungen“ einzudämmen. Dies erfordert zum einen Möglichkeiten der Fehlererkennung und zum anderen, adäquat auf einen Fehler reagieren zu können.

Ein Beispiel zur Fehlererkennung zur Laufzeit eines Computerprogrammes sind Assertions, mit deren Hilfe Bedingungen abgefragt werden, die gemäß Programmdesign immer erfüllt sind. Weitere Mechanismen sind Ausnahmebehandlungen wie Trap und Exception.

Durch die Implementierung von Proof-Carrying Code kann die Software zur Laufzeit ihre Zuverlässigkeit in gewissem Rahmen gewährleisten und sicherstellen.

Völlige Fehlerfreiheit für Software, die eine gewisse Komplexitätsgrenze überschreitet, ist weder erreichbar noch nachweisbar. Mit steigender Komplexität sinkt die Überblickbarkeit, insbesondere auch, wenn mehrere Personen an der Programmierung beteiligt sind. Selbst teure oder vielfach getestete Software enthält unweigerlich Programmierfehler. Man spricht dann bei gut brauchbaren Programmen nicht von Fehlerfreiheit, sondern von Stabilität und Robustheit. Eine Software gilt dann als stabil bzw. robust, wenn Fehler nur sehr selten auftreten und diese dann nur kleinere Unannehmlichkeiten mit sich bringen und keine größeren Schäden oder Verluste verursachen.

In Spezialfällen ist ein Beweis der Fehlerfreiheit eines Programms möglich. Insbesondere in Bereichen, in denen der Einsatz von Software mit hohen finanziellen, wirtschaftlichen oder menschlichen Risiken verbunden ist, wie z. B. bei militärisch oder medizinisch genutzter Software oder in der Luft- und Raumfahrt, verwendet man zudem eine (formale) Verifizierung genannte Methode, bei der die Korrektheit einer Software formal-mathematisch nachgewiesen wird. Dieser Methode sind allerdings wegen des enormen Aufwands enge Grenzen gesetzt und sie ist daher bei komplexen Programmen praktisch unmöglich durchzuführen (siehe auch Berechenbarkeit). Allerdings gibt es mittlerweile Werkzeuge, die diesen Nachweis laut eigenen Angaben zumindest für Teilbereiche (Laufzeitfehler) schnell und zuverlässig erbringen können.

Neben der mathematischen Verifizierung gibt es noch eine praxistaugliche Form der Verifizierung, die durch die Qualitätsmanagement-Norm ISO 9000 beschrieben wird. Bei ihr wird nur dann ein Fehler konstatiert, wenn eine Anforderung nicht erfüllt ist. Umgekehrt kann demnach ein Arbeitsergebnis (und damit auch Software) als fehlerfrei bezeichnet werden, wenn es nachweisbar alle Anforderungen erfüllt. Die Erfüllung einer Anforderung wird dabei durch Tests festgestellt. Wenn alle Tests das erwartete Ergebnis bringen, ist eine Anforderung erfüllt.

Aufgetretene Fehler werden im Allgemeinen im Fehlermanagement systematisch bearbeitet. Nach der IEEE-Norm 1044 (Klassifizierung von Softwareanomalien) durchläuft dabei jeder Fehler einen sogenannten Klassifizierungsprozess, bestehend aus den vier Schritten Erkennung (Recognition), Analyse (Investigation), Bearbeitung (Action) und Abschluss (Disposition)^[9].

Kriterien, nach denen Fehler dabei klassifiziert werden können, sind u. a. (mit Beispielen):

• die Art des Fehlers: Nach ^[10] werden dabei unterschieden: Lexikalische Fehler (unbekannter Bezug), syntaktische Fehler (vergessenes Semikolon), semantische Fehler (falsche Deklaration), Laufzeitfehler (falsch formatierte Eingabedaten) und logische Fehler (plus statt minus, Schleifenfehler, ...)
• die Fehlerursache: unpräzise Vorgabe, Zahlendreher, falsche Eingabedaten ...
• der Zeitpunkt der Fehlerentstehung: Bereits bei der Programmvorgabe, im Codeentwurf, beim Codieren, ...

Ein grundsätzlicher Unterschied ergibt sich daraus, ob der Fehler während der Programmentwicklung auftritt, zum Beispiel beim Testen (hier ist dies ein Normalfall^[1]) oder im im produktiven Betrieb (wo er häufig eine kritische Störung darstellt).

• der Zeitpunkt der Entdeckung: Je länger die 'Fehlerverweilzeit' ist, desto aufwändiger wird i. A. die Korrekturmaßnahme verlaufen.
• die Wirkung des Fehlers: Darstellungsfehler, falsches Ergebnis, Programmabbruch, Außenwirkung ...
• Aufwand und Dauer zur Fehlerbehebung: minimal ... sehr hoch; sofort ... sehr lange Dauer
• Bearbeitungsstatus: aufgetreten, untersucht, Korrekturauftrag in Bearbeitung, Retest möglich, ..., erledigt

Mit Hilfe von diesbezüglich entwickelten Metriken „sollten die Ergebnisse [und Erkenntnisse über Fehler] auch Anlass zur Suche nach den Ursachen hinter den Problemen sein“.^[1] „Fehlerklassifikationen bilden die Grundlage für standardisierte Verfahren zur Fehlerbehandlung und unterstützen zudem eine kontinuierliche Qualitätsverbesserung im Sinne des Qualitätsmanagements.“^[11]

Weitere Angaben je Fehler wie eine ausführliche Fehlerbeschreibung, betroffene Programme, beteiligte Personen etc. begleiten die Maßnahmen zur Behebung der Fehler und dokumentieren diese. Näheres siehe^[11].

Die Folgen von Programmfehlern können hochgradig unterschiedlich sein und sich in vielfältiger Weise zeigen. Werden Fehler im Rahmen der Entwicklungsprozesse entdeckt, so beschränken sich die Fehlerfolgen i. W. auf die Überarbeitung der Software (Codekorrekturen, Konzeptüberarbeitung, Dokumentation ...) – je nach Situation mit mehr oder weniger großen Auswirkung auf das Projektbudget und die Projektdauer. Dagegen wirken erst im Produktivbetrieb erkannte Fehler nicht selten ungleich kritischer, zum Beispiel können sie Prozess-Störungen oder Produktionsstillstand bewirken, Imageschäden hervorrufen, den Verlust von Kunden und Märkten verursachen, Regresspflichten auslösen oder gar das Unternehmen in Existenzgefahr bringen. Fehler in technischen Anwendungen können im schlimmsten Fall zu Katastrophen führen.

Konkrete Beispiele für Programmfehler und deren Folgen finden sich in der Liste von Programmfehlerbeispielen.

Manche Programmfehler sind nur äußerst schwer oder gar nicht zuverlässig reproduzierbar. Bei der Wiederholung eines zuvor gescheiterten Vorgangs unter scheinbar unveränderten Bedingungen ist die Wahrscheinlichkeit hoch, dass sich diese Fehler nicht erneut äußern. Es gibt zwei mögliche Gründe für dieses Verhalten: Zum einen kann es zu Verzögerungen zwischen der Fehleraktivierung und dem letztlich auftretenden Problem beispielsweise einem Programmabsturz kommen, welche die tatsächliche Ursache verschleiern und deren Identifikation erschweren. Zum anderen können andere Elemente des Softwaresystems (Hardware, Betriebssystem, andere Programme) das Verhalten der Fehler in dem betrachteten Programm beeinflussen. Ein Beispiel hierfür sind Fehler, die in nebenläufigen Umgebungen mit mangelnder Synchronisation (genauer: Sequentialisierung) auftreten. Wegen der hieraus folgenden Wettlaufsituationen (Race Conditions) können die Prozesse in einer Reihenfolge abgearbeitet werden, welche zu einem Laufzeitfehler führt. Bei einer Wiederholung der gleichen Aktion ist es möglich, dass die Reihenfolge der Prozesse unterschiedlich ist und kein Problem auftritt.

• Softwarequalität
• Bug-Tracker
• Patch (Software)
• Bananensoftware

• Die 25 gefährlichsten Programmierfehler (englisch)

• William E. Perry: Software Testen. Mitp-Verlag, Bonn 2002, ISBN 3-8266-0887-9.
• Elfriede Dustin, Jeff Rashka, John Paul: Software automatisch testen. Verfahren, Handhabung und Leistung. Springer, Berlin u. a. 2001, ISBN 3-540-67639-2.
• Cem Kaner, Jack Falk, Hung Quoc Nguyen: Testing Computer Software. 2nd edition. John Wiley & Sons, New York NY u. a. 1999, ISBN 0-471-35846-0.

1. ↑ ^{a b c} M. Pol, T. Koomen, A. Spillner: Management und Optimierung des Testprozesses. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2.
2. ↑ Uni Leipzig [1]
3. ↑ ISTQB german-testing-board [2]
4. ↑ Vgl. den Beitrag zu Rear Admiral Grace Murray Hopper in The History of Computing (engl.)
5. ↑ IX-Studie Software-Testmanagement [3]
6. ↑ ^{a b} Wallmüller Software-Qualitätsmanagement in der Praxis [4] Hanser München 2001 ISBN 978 3 446 21367 8
7. ↑ Junginger Wertorientierte Steuerung von Risiken im Informationsmanagement [books.google.de/books?isbn=3824482258] 2005
8. ↑ Georg Edwin Thaller Softwaretest, Verifikation und Validdation 2002, ISBN 978-3-88229-198-8
9. ↑ safaribooksonline [5]
10. ↑ Uni Oldenburg [6]
11. ↑ ^{a b} BITKOM Fehlerklassifikation ... [7]