Fehlerbegriff – Bug, Defekt, Fehler, Abweichung, Problem?

Als reine Software-Bude hat man’s vergleichsweise leicht, denn seit über 100 Jahren bereits hat sich Bug als Synonym für Software-Fehler etabliert. Sobald man aber auf der Suche nach einem Überbegriff ist, der auch mechnische und elektronische Probleme umfasst, wird es schwierig. Auch eine Übersetzung der Begriffe zwischen deutsch und englisch scheint nicht eindeutig zu sein.

Fehler, Mangel, Abweichung, Anomalie

Eine Situation kann nur dann als fehlerhaft eingestuft werden, wenn vorab festgelegt wurde, wie die erwartete, korrekte, also nicht fehlerhafte Situation aussehen soll. Ein Fehler ist somit die Nichterfüllung einer festgelegten Anforderung, eine Abweichung zwischen Istverhalten und Sollverhalten.

Ein Mangel liegt vor, wenn eine gestellte Anforderung oder berechtigte Erwartung nicht angemessen erfüllt wird, bspw. wenn die Funktionalität zwar erfüllt, die Verwendbarkeit aber beeinträchtigt ist oder eine angemessene Erwartung nicht erfüllt wird.

Diese beiden Fälle setzen voraus, dass die Ursache des Problems sicher im untersuchten Produkt zu finden ist. Die Ursache des Problems kann aber auch anderen Ursprungs sein. Auch hier lässt sich wieder unterscheiden zwischen dokumentiertem Sollwert (Abweichung) und undokumentiertem Sollwert (Anomalie).

Fehlerhandlung, Fehlerzustand, Fehlerwirkung

Der ISTQB definiert im Rahmen des Softwaretests die Begriffe Fehlhandlung, Fehlerzustand und Fehlerwirkung.

Softwarefehler entstehen natürlich nicht durch Verschleiß. Fehler und Mängel sind also bereits seit dem Zeitpunkt der Entwicklung des Source Codes vorhanden. Beim Testen wird dann die Fehlerwirkung (auch äußerer Fehler, engl. failure) des Fehlers oder Mangels sichtbar.

Die Ursache des Auftretens einer Fehlerwirkung bezeichnet man als Fehlerzustand (auch Defekt, innerer Fehler, engl. Bug, engl. fault). Problematisch ist, dass ein Fehlerzustand gar nicht zu einer Fehlerwirkung führen muss. Eine Fehlerwirkung kann gar nicht, einmalig oder mehrmals auftreten. Fehlerzustände können durch andere Defekte maskiert sein. Korrekturen können zu Seiteneffekten führen. All dies macht die Fehlersuche oft schwierig und zeitaufwendig.

Die Ursache der Fehlerwirkung ist also der Fehlerzustand, der Bug. Die Ursache für diesen Bug wiederum ist in der Regel die Fehlhandlung (engl. error) eines Software-Entwicklers, also etwa die Erstellung fehlerhaften Source Codes. Fehlhandlungen sind nicht auszuschließen. Die Häufigkeit ist abhängig von Zeitdruck, Komplexität des Source Codes, Änderungsfrequenz der Anforderungen, verwendeten Technologien und vielen weiteren Faktoren.

Laufzeitfehler sind spezielle Fehler

Für Software kann man die Laufzeitfehler (engl. fault) noch als spezielle Fehler klassifizieren. Das sind die, die während des Ausführung der Software auftreten und somit zu einer Fehlerwirkung führen (s.o.). Diese hat man wohl vorrangig im Blick, gerade beim Testen.

Aber wie erwähnt führt nicht jeder Fehler, genauer jeder Fehlerzustand, zu einer Fehlerwirkung, zeigt sich also bei der Ausführung der Software. Daher existieren auch statische Testmethoden, Source Code Reviews, die defects aufdecken, die keine faults sind.

Corrective Change Requests

Aus dem Maintenence-Bereich gibt es eine Klassifizierung von verschiedenen Change Request Typen. Oftmals wirkt das Wort Änderungsantrag so formal, drückt aber letztendlich nichts anderes aus als eine Anweisung, etwas zu ändern.

• Corrective Change Request: zum Beheben von Fehlern und somit auch ein weiterer Fehlerbegriff
• Adaptive Change Request: zum Anpassen der Software an geänderte Software-Umgebung
• Perfective Change Request: zum Implementieren neuer Anforderungen
• Preventive Change Request: zum Verbessern der Wartbarkeit oder Zuverlässigkeit, um Probleme in der Zukunft zu vermeiden

Fazit

Ich hoffe, die Ausführungen konnten ein wenig Licht ins Dunkel bringen. Wir haben uns für den Begriff Abweichung entschieden, da er nach obiger Vorstellung den Fehler einschließt, aber offen lässt, ob es wirklich ein Problem in der untersuchten Komponente ist. Das folgende UML-Diagramm fasst die Begriffe nochmal zusammen.