Vom Umgang mit Anwendungsfehlern

Inhaltsverzeichnis

Irgendwann passiert es jedem: Eine Anwendung funktioniert nicht. Irgendein Fehler hindert einen an der Weiterarbeit. Unschön, aber man kann lernen, damit umzugehen.

In all meinen Jahren als Entwickler war ich immer wieder überrascht, von wie vielen Themen einfach angenommen wird, dass Menschen sie ohne weiteres Zutun beherrschen. Ein Klassiker ist der Umgang mit Anwendungsfehlern. Und genau darum geht es in diesem Blog-Beitrag. Speziell um das Erfassen und die Weitergabe – aus Anwendersicht, aber auch ein Stück weit aus Entwicklersicht.

Informationen zusammentragen

Ist ein Fehler eingetreten und lässt sich ohne seine Behebung die aktuelle Arbeit nicht fortsetzen, dann hat man als Anwender ein Problem. Egal ob man es selbst lösen oder jemand anderes es beheben muss: Während des Auftretens oder kurz danach ist die Gelegenheit, Informationen zum Fehler zu sammeln. Am besten digital und schriftlich, nach Möglichkeit mit Screenshots belegt. Auch Konsequenzen aus dem Fehler wie eine defekte Ausgabedatei helfen bei der späteren Analyse.

Grundsätzlich lässt sich das Sammeln der Informationen anhand von Leitfragen strukturieren. Hier ein paar Beispiele:

• Wie kann der Fehler in drei Sätzen beschrieben werden?
• Welches System ist betroffen?
• Welche Anwendung ist betroffen?
• Zu welchem Zeitpunkt ist der Fehler aufgetreten?
• Welche Auswirkungen hat der Fehler?
• Wie lässt sich der Fehler reproduzieren?

Die Leitfragen lassen sich beliebig erweitern. Möglicherweise arbeitet man mit ein paar generellen Leitfragen. Für bestimmte Anwendungen gibt es dann noch ergänzende, spezifische Fragen.

Klingt logisch, ergibt sich aber nicht von selbst. Soll heißen: Die Fragen müssen vorher abgestimmt werden. Besser noch: Man schult das Erfassen von Fehlern, und zwar wiederholt. Meines Erachtens gibt es da viel Verbesserungspotenzial. Nur ein Ticketsystem zum elektronischen Erfassen von Fehlermeldungen ist nicht die Lösung, wenngleich es oftmals notwendig ist, um den Überblick zu behalten – also als ein Teil der Lösung. Im Grunde geht es aber um die Aussagekraft der Informationen, die in einem solchen System lagern.

Fehler im Kontext aller Informationen betrachten

Nach dem Zusammenstellen der Informationen kommt ein wichtiger Schritt, der oftmals vergessen oder absichtlich ausgelassen wird. Gerade dann, wenn aufgrund der Unternehmensorganisation eine andere Abteilung, beispielsweise der Support, für das Beheben von Fehlern zuständig ist.

Der Schritt, den ich meine, ist das Überdenken der gesammelten Informationen. Ergibt sich bereits ein Hinweis auf die Lösung? Lassen sich Zusammenhänge erkennen? Möglicherweise kann man den Fehler sogar selbst beheben, wenn man mit etwas Abstand die gesamte Informationslage betrachtet. Auf diesen Schritt wird meiner Erfahrung nach häufig verzichtet. Man kann den Fehler ja unreflektiert melden. Die Lösung obliegt schließlich jemand anderem.

Hilfe holen

Wer einen Fehler nicht selbst beheben kann oder darf, der muss sich Hilfe holen. Beispielsweise von der Support-Abteilung. Dort freut man sich für gewöhnlich über gute Vorarbeit in Form der zusammengetragenen Informationen. Das erspart umfassende Rückfragen und ermöglicht den schnellen Einstieg in die Analyse der Fehlerursache. Für Rückfragen sollte man übrigens zur Verfügung stehen.

Sicherlich beschreibe ich hier eine sehr ideale Situation. Jeder hat seine Erfahrungen mit Support. Manche verarbeiten diese Erfahrungen immer noch oder werden sie ein Leben lang nicht vergessen (können). Trotzdem ist es wichtig, dass man seinen Teil zur Lösung beigetragen hat. Wie andere ihre Arbeit angehen, na ja, das ist ihnen überlassen.

Der positive Beitrag, den Entwickler leisten können

Wie eingangs erwähnt geht es in diesem Beitrag auch ein wenig um die Entwicklersicht auf das Thema "Fehler erfassen". Ich denke hier vor allem an das Thema "qualifizierte Fehlermeldung", also eine Fehlermeldung, die Aussagekraft zur aktuellen Fehlersituation besitzt.

Aus eigener Erfahrung weiß ich, wie schwer das Thema sein kann, beispielsweise unter technischen Restriktionen wie einer Längenbeschränkung bei der Fehlermeldung noch etwas Vernünftiges auszugeben. Auch die passenden Worte zu finden ist nicht immer einfach. Soll die Meldung eher fachlich oder technisch über einen Fehler informieren?

Viele Aspekte sind zu berücksichtigen und viele Gedanken erforderlich. Das Gute ist, dass diese Überlegungen von einem oder mehreren Entwicklern übernommen werden können. Andernfalls könnten möglicherweise tausende Anwender rätseln und raten. Alleine aus diesem Ungleichgewicht ergibt sich bereits das positive Potenzial. Aus der Praxis wissen wir aber alle, wie es häufig läuft.

In diesem Sinne, bleibt strukturiert und gesund

euer Michael ()