Fehlerbegriff

R 2.2.0

Was ist ein Fehler?

Was ist ein Fehler?

Fehlhandlung: Die menschliche Handlung, die zu einem falschen Ergebnis führt.

Fehlerzustand: Eine Unzulänglichkeit oder ein Mangel in einem Arbeitsergebnis, sodass es seine Anforderungen oder Spezifikationen nicht erfüllt.

Fehlerwirkung: Ein Ereignis in welchem eine Komponente oder ein System eine geforderte Funktion nicht im spezifizierten Rahmen ausführt.

Beschreibung

In der Praxis findet die Differenzierung des Begriffs kaum Anwendung, statt dessen spricht man häufig nur von "Fehlern" in der Software. Anders als bei physikalischen Systemen treten Fehler bei Softwaresystemen nicht durch Alterung oder Verschleiß auf. Sie sind seit dem Moment der Entwicklung im Artefakt vorhanden, zeigen sich jedoch erst bei Ausführung der Anwendung. Zwischen den Ursachen und den nach außen sichtbaren Auswirkungen eines Fehlers ist zu unterscheiden.

Worin liegen diese Unterschiede?

ALT MISSING
Abb. 1: Unterschiede der Fehlerbegriffe

Video: Fehlerhandlung, Fehlerzustand und Fehlerwirkung (Länge: 01:51)

Wirkungskette

Die Ursache für einen Fehlerzustand in der Software ist i.d.R. eine menschliche Fehlhandlung, z.B. wird während der Entwicklung eines Programmteils ein Fehler in der Programmierung gemacht. (engl. error)

Diese Fehlhandlung ist der Ausgangspunkt für einen Fehlerzustand (engl. fault) im Programmcode. Andere gebräuchliche Bezeichnungen dafür sind auch Defekt oder innerer Fehler. Es handelt sich dabei beispielsweise um eine fehlerhafte oder vergessene Anweisung im Programm.

Nach außen sichtbar wird dieser Fehlerzustand bei der Ausführung des Programms im Test oder Betrieb in Form einer Fehlerwirkung (engl. failure). Es könnte in der Praxis ein falscher Ausgabewert angezeigt werden oder ein Programmabsturz die Folge sein. Andere Bezeichnungen dafür sind äußerer Fehler oder Ausfall.

Beispiel

An einem einfachen Beispiel einer Entscheidung durch eine if - else Anweisung lassen sich die Fehlerbegriffe am besten erklären. In dem u.g. Codeschnipsel soll die Eingabe des Nutzeralters geprüft werden.

Falls die Alterseingabe 17 oder jünger ist, soll die Anwendung folgende Textausgabe erscheinen: "Unbegleitetes Autofahren ist selbst mit Führerschein nicht erlaubt, das Alter ist 17 Jahre oder jünger."

Ansonsten soll die Ausgabe lauten: "Unbegleitetes Autofahren mit Führerschein ist erlaubt, das Alter ist 18 Jahre oder älter."

[...]
if (user_age <= 17) {
    System.out.println("Unbegleitetes Autofahren ist selbst mit Führerschein nicht erlaubt, das Alter ist 17 Jahre oder jünger."); +
} else {
    System.out.println("Unbegleitetes Autofahren mit Führerschein ist erlaubt, das Alter ist 18 Jahre oder älter.");
}
[...]

Die Wirkungskette im Falle unseres Beispiels von einer Fehlhandlung bis zur Fehlerwirkung könnte zum Beispiel folgendermaßen aussehen:

Fehlhandlung

Es ist den Beteiligten ein Programmierfehler unterlaufen, da der Vergleich des eingegebenen Alters nur mit dem Operator "<" ausgeführt wird.

ALT MISSING

Fehlerzustand

Im Inneren des Programms: Im Falle der Eingabe des Alters 17 Jahre wird aufgrund des fehlenden "=" Zeichens in der vergleichenden Programmlogik der else-Pfad (18 Jahre oder älter) genommen.

Fehlerwirkung

Nach außen sichtbar: Am Bildschirm erscheint die Textausgabe "Unbegleitetes Autofahren mit Führerschein ist erlaubt, das Alter ist 18 Jahre oder älter", obwohl die Eingabe des Alters 17 Jahre durch den Anwender vorgenommen wurde.

ALT MISSING
Abb. 2: Wirkungskette von der Fehlhandlung zur Fehlerwirkung

Umgang mit Fehlern

Irren ist menschlich und somit natürlich auch, das Fehler in der Softwareentwicklung gemacht werden. Vor diesem Hintergrund ist es hilfreich, einen konstruktiven Umgang mit Fehlern zu etablieren, der auf unnötige Schuldzuweisungen verzichtet.

Kennen Sie das? Nicht selten erfolgt auf die Feststellung der Tester, dass ein Fehler gemacht wurde, eine empfindliche Reaktion der beteiligten Entwickler. Zum einen kann das natürlich am Tonfall oder Auftreten des Überbringers dieser Nachricht liegen, zum anderen womöglich an den verwendeten Begriffen. Auch steht häufig zum Zeitpunkt des Testens noch nicht fest, ob es sich tatsächlich um einen "Fehler" handelt oder z.B. einen Änderungswunsch oder einen Irrtum des Testers. Die Aufgaben der beiden "Lager" werden zudem häufig unterschiedlich wahrgenommen - auf der einen Seite die "konstruktive" Entwicklung, zum anderen das "destruktive" Testen.

Aus verschiedenen Gründen ist es sinnvoll, das Testen einem unabhängigen Team zu übertragen (Betriebsblindheit gegenüber eigenen Fehlern, zu optimistische Haltung gegenüber eigener Arbeit usw.). Eine Aufgabe der Tester ist es in diesem Fall, den Autoren und/oder dem Management die festgestellten Fehlerwirkungen mitzuteilen. Wichtig für eine positive Kultur, die diese psychologischen Umstände und Vorurteile berücksichtigt, sind aus der Praxiserfahrung in Projekten die in den gemeinsamen Klärungsterminen eingesetzten Begriffe.

So hat sich im Projektaustausch beispielsweise der neutrale Begriff der Abweichung bewährt, der den Ursprung der Fehlerwirkung offen lässt.

Zusammenfassend lässt sich festhalten, dass in der Zusammenarbeit Entwicklung/Test Fingerspitzengefühl gefragt ist. Die Art und Weise der Kommunikation sowie die Kenntnis der gegenseitigen Aufgaben im Projekt können helfen und das Verständnis für einander fördern.

Quellen