Warum wollen Programmierer immer so viel wissen?

Published by Marc on

Updated by Marc on

Mit dem anrollenden Testen von ersten Munjari-Versionen ist mal wieder das Thema „Testen von Software“ bzw. − damit verbunden – das „Melden von Problemen“ aufgekommen. Eigentlich ist das früher oder später bei jedem Software-Projekt ein Thema. Irgendwann gibt es immer Software-Probleme zu melden.

Also nimmt man als Anwender fix das Telefon oder Emailprogramm und meldet das kurz und bündig beim zuständigen Programmierer. Und schon geht’s los! Was der alles von mir als einfacher Anwender seiner Software wissen will!

Aus der Sicht des Programmierers ist es oft so, dass dieser vom Anwender eine relativ kurze Problemmeldung bekommt (manchmal nicht mal ein ganzer Satz) und damit noch nichts anfangen kann. Er muss erst mal mittels Hin und Her die ganzen benötigten Informationen vom Anwender in Erfahrung bringen muss. Viel lieber würde dieser gleich beginnen in die Tasten zu hauen. Stattdessen muss er jetzt zuerst Emails schreiben oder gar telefonieren (machen Programmierer überhaupt nicht gerne).

Warum brauchen die Programmierer denn eigentlich so viele Informationen und können nicht einfach von sich aus das angetönte Problem beheben? Wie kann ich das Hin und Her zwischen mir als Anwender und dem Programmierer bzw. der IT reduzieren und komme schneller mein Problem gelöst?

Warum sind die Programmierer auf so viele Informationen angewiesen?

Um diese Frage zu beantworten, müssen wir etwas weiter ausholen. Heutige Computerprogramme (PC-Programme, interaktive Webseiten, etc.) sind, auch für den Programmierer, sehr komplex und werden, aus verschiedenen Gründen, immer komplexer.

Ein Programmierer entwickelt Programme indem er den Quelltext schreibt. D.h., er formuliert für alles was das Programm anzeigt oder machen soll, Anweisungen als mehr oder weniger lesbarer Text. In diesem Quelltext muss er für wirklich alles entsprechende Anweisungen „programmieren“.

Damit man eine Ahnung bekommt, wie detailreich diese Anweisungen sein müssen, im folgenden ein ganz kleiner Ausschnitt aus einem solchen Quelltext. Dieser zabert eine „OK“-Schaltfläche auf dem Bildschirm.

Button okButton = new Button(myForm);
okButton.Text = „OK“;
okButton.Left = 254;
okButton.Top = 154;
okButton.Width = 200;
okButton.Height = 23;
okButton.Show();

Wie zu sehen ist, müssen wir unserer OK-Schaltfläche alles einzeln „erklären“:

  • Erstelle eine neue Schaltfläche innerhalb des Fensters „myForm“
  • Beschrifte diese mit dem Text „OK“
  • Koordinate (in Pixel) der oberen, linken Ecke der Schaltfläche
  • Breite und Höhe (in Pixel) der Schaltfläche
  • Zeige diese Schaltfläche jetzt an

Wir brauchen also schon mal 6 Zeilen Text um, eine ganz einfache OK-Schaltfläche auf den Bildschirm zu bringen. Dabei haben wir noch nicht mal definiert, was überhaupt geschehen soll, wenn diese Schaltfläche vom Anwender gedrückt wird. Wie würde den dieser Quelltext aussehen? Keine Angst − dieser Quelltext würde den Rahmen dieses Artikels sprengen.

Der Umfang des Quelltextes von Programmen, welche wir täglich verwenden, liegt, bei kleineren Hilfsprogrammen, bei ein paar tausend Zeilen und kann bei grösseren Lösungen auf hundert tausende oder gar auf über eine Million Zeilen ansteigen. Um uns das etwas besser vorstellen zu können: eine Million Zeilen entsprächen über 15‘000 A4 Seiten – ca. 38 Bundesordner für nur ein einziges Programm!

Damit nicht genug! Diese 15‘000 A4 Seiten ändern und wachsen stündlich, weil der Programmierer ja neue Funktionen einbaut oder bestehende ändert (z.B. um die Probleme der Anwender zu beheben). Für jede Version eines Programms (Version 1.1, Version 1.2, etc.) werden die zu dem jeweiligen Zeitpunkt gültigen 15‘000 A4-Seiten archiviert, so dass man später bei Problemmeldungen von Anwendern in den richtigen 38 Bundesordnern nachschlagen kann.

Nur noch leicht erschwerend kommt jetzt hinzu, dass vielfach nicht nur ein Programmierer an diesen Bundesordnern programmiert, sondern zeitgleich bis zu einem ganzen Team daran modifizieren und erweitern kann. Einige dieser Bundesordner können sogar von externen Firmen dazu gekauft und eingebunden werden. D.h., ein Programmierer hat selten den ganzen Quelltext selbst geschrieben und somit auch nicht auswendig im Kopf. Häufig arbeiten Programmierer auch in mehreren Projekten mit.

Kurz und bündig: als Programmierer ist man täglich mit tausenden und abertausende von Quelltextzeilen konfrontiert und wühlt sich durch diese. Das gute daran: das macht uns Programmierer sogar Spass!

Ein Problem tritt auf

Jetzt gehen wir davon aus, der Anwender schreibt uns zu diesen 15‘000 A4 Seiten: „Das Einloggen ins Programm funktioniert nicht“. Da stellt man sich als Programmierer erst mal die Frage, in welchem Kapitel unseres 15‘000 Seiten umfassenden Quelltextes man zu suchen beginnen soll? Ist es das Kapitel „Login-Formular anzeigen“ oder eher das Kapitel „Passwort mit dem auf dem zentralen Server gespeicherten vergleichen“ oder gar „Netzwerkkommunikation zwischen PC-Programm und Firmenserver“? Hätte der Anwender z.B. noch einen zweiten Satz dazu geschrieben wie z.B. „Ich erhalte die Fehlermeldung, dass der Server nicht gefunden wird“, so hätten wir Programmierer uns wohl direkt auf das dritte Kapitel gestürzt. Denke es ist klar, dass das die Dinge sehr vereinfacht hätte.

Hat ein Programmierer nur den ersten Satz, bleibt ihm nichts anderes übrig, als auf seinem PC zu schauen ob da irgend etwas den Anschein macht “nicht zu funktionieren”. Da es andere PC-Systeme, andere Computer-Netzwerke, andere Benutzernamen und Passwörter sind, ist die Chance relativ klein, dass der Programmierer das Problem auf diese Art finden wird.

Nachvollziehbarkeit

Hat man mit Programmierer zu tun, so sprechen diese häufig von der Nachvollziehbarkeit bzw. wie sie das Problem “reproduzieren” können. Warum das?

Auch hier müssen wir etwas weiter ausholen:

Wie gehen die Programmierer denn vor, wenn ein Anwender ein bestimmtes Problem meldet? Er wird wohl kaum jedes mal die 38 Bundesordner Zeile für Zeile auf Fehler kontrollieren gehen? Ich kann da beruhigen: nein, das tun wir nicht.

Viel mehr versuchen wir Programmierer aus den Informationen, welche wir haben, uns den „Weg“ vorzustellen, welches das Programm durch den Quelltext geht. Die einen mögen sich jetzt fragen, ob es da unterschiedliche „Wege„ gibt? Ja – leider. Ein Programm besteht eigentlich nie aus einem einzigen linearen Ablauf. Man kann sich ein Programm als ein Weglabyrinth vorstellen, welches aus tausenden von Wegabschnitten und Kreuzungen besteht. Kommt das Programm an eine Kreuzung entscheidet es anhand der aktuellen Situation, welchen Weg es weiter gehen soll.

Wir Programmierer müssen also genau wissen oder erraten, an welcher Kreuzungen der Anwender welche Abzweigung genommen hat um eine Vermutung zu bekommen, auf welchen Wegabschnitt wir mit der Suche begonnen werden soll. Dann gehen wir auf die A4-Seite(n) welche in Frage kommen und schaue, ob uns da was auffällt. Nehmen wir an einer Kreuzung eine andere Abzweigung, kann es sein, dass wir tausende von A4-Seiten entfernt vom Problem des Anwenders sind. Ist es uns möglich, denselben Weg wie der Anwender zu gehen und erhalten somit dasselbe Problem, so sprechen wir von Nachvollziehbarkeit.

Müssten wir Programmierer den ganzen Weg mit allem Kreuzungen im Kopf abschreiten, würden wir relativ schnell einen Nervenzusammenbruch erleiden. In der heutigen Zeit haben wir für das Abschreiten des effektiven Weges technische Hilfsmittel: Debugger-Programme [1]. Wir verwenden also ein Programm, um den Weg in einem anderen Programm abzuschreiten. Unser Ziel ist es nun, mit diesen Programmen den genau gleichen Weg Schritt für Schritt durch das Programm zu gehen, wie vor uns der Anwender, so dass wir unmittelbar bevor das Problem auftritt anhalten und die Situation anschauen können.

Mit diesem Wissen um die Situation, welche beim nächsten Schritt zum Problem führen wird, können wir das Problem meistens sehr schnell beheben. Ohne dieses Wissen hingegen sind es häufig Zufallstreffer in der Art: „Wenn ich mich richtig erinnere ist an der Stelle X der Weg etwas schmaler. Könnte ja sein, dass es dort zu einem solchen Problem kommt. Ich geh mal diese Passage des Weges genauer anschauen.“.

Je mehr bzw. genauere Informationen wir vom Anwender erhalten, desto besser bzw. korrekter können wir an den Kreuzungen entscheiden, in welche Richtung wir dem Anwender folgen sollen. Insbesondere an den grossen Kreuzungen ist dies wichtig.

Wie können wir das Hin und Her mit dem Programmierer reduzieren?

Der Programmierer muss erst wissen, welche der 15‘000 A4-Seiten für das Problem des Anwender relevant sind. Dazu muss er möglichst genau wissen, an welcher Kreuzung der Anwender sich für welchen Weg entschieden hat, damit er möglichst genau den Spuren des Anwenders mittels Debugger-Programm folgen kann. Je genauer der Anwender den von Ihm beschrittenen Weg beschreibt, desto besser und vor allem auch schneller kann der Programmierer ihm zum Problem folgen und dieses für den Anwender beseitigen.

In der Praxis sind folgende Informationen sicher mal ein guter Anfang:

  • Welches Programm
    • Genauer Name des Programms (wird hin und wieder auch missverstanden)
    • Welches Programmmodul etc. (falls vorhanden)
    • Welcher Version des besagten Programms?
  • Welche Umgebung
    • Betriebssystem
    • Betriebssystem Version
    • Für Web-Anwendungen: Browser inkl. Version (z.B. Internet Explorer 8, Firefox 3.6, etc.)
    • Mit welchen Daten wurde gearbeitet? z.B. Produktive Datenbank vom Datum X, mit der Datei Y. Falls möglich Daten der Problemmeldung beilegen)
  • Welches Resultat tritt ein?
    • z.B. „Speichert man eine Adresse, wird diese zwar gespeichert aber nichts weiter passiert.“
  • Welches Resultat wird erwartet?
    • z.B. „Speichert man die Adresse sollte direkt eine Adressblatt auf dem Drucker ausgedruckt werden.“
  • Welche Schritte braucht es, um das Problem zu reproduzieren?
    • Bsp:
      1. Als Benutzer „X“ ins Programm einloggen.
      2. In der Symbolleiste mit der Maus auf „Neue Adresse erfassen klicken“.
      3. In der Adresserfassungsmaske folgende Daten eingeben: ….
      4. Mittels der ENTER-Taste die Adresserfassung bestätigen.
      5. Nun wird kein Adressblatt ausgedruckt, sondern man befindet sich wieder auf der Hauptmaske des Programms.
  • Traten Fehlermeldungen auf und wenn ja, welche?
    • Falls es Fehlermeldungen gibt, diese möglichst komplett mitgeben. Man kann evtl. den Text der Fehlermeldung mit der Maus markieren, dann mittels Ctrl+C Tastendruck kopieren und mit Ctrl+V ins Email etc. einfügen. Oder man macht mittels der Print-Screen-Taste ein Bildschirmfoto (engl.: Screenshot) und fügt diesen in ein Word-Dokument oder direkt ins Email ein. Geht das alles nicht, kann man immer noch die Fehlermeldung abtippen.
    • Fehlermeldungen sind für den Programmierer sehr wichtig. Sie helfen ihm, den besagten Weg nicht von ganz vorne beschreiten zu müssen. Eine gute Fehlermeldung sagt dem Programmierer sogar, wo und um welches Problem es sich handelt inkl. den Weg, welchen der Benutzer genommen hat. Somit muss der Programmierer im optimalen Fall gar nicht erst auf die Suche gehen, sondern kann direkt an der Lösung des Problems arbeiten.
    • Es ist schade, wenn vom Anwender beschrieben wird: „…und dann kam eine Fehlermeldung.“ und die aufgetretene Fehlermeldung dann nicht beschrieben ist. In solchen Fällen wird der Programmierer höchst wahrscheinlich als erstes nach der genauen Fehlermeldung bzw. deren Text nachfragen.

Fazit

Je mehr Informationen dem Programmierer gleich beim ersten Kontakt gegeben werden können, desto eher/schneller bekommt man eine Lösung für das Problem. Ist die Problembeschreibung sehr knapp, wird sich der Programmierer wohl erst den Problemen annehmen, die besser beschrieben sind. D.h., das eigene Problem rückt erst mal etwas hinter andere. Kommt hinzu, dass der Programmierer viel motivierter an Probleme ran geht, um so ausführlicher diese dokumentiert sind. Auch der Programmierer vermeidet gerne, wenn nur irgnedwie möglich, ein Hin und Her, um an benötigte Informationen zu kommen.

Übrigens: das waren jetzt etwas mehr als 4 A4-Seiten ;-)



[1] Diese Programme werden “Debugger”-Programme genannt. Dabei handelt es ich um relativ komplexe Programme, mit welchen der Programmierer ein anderes Programm Schritt für Schritt ausführen. Mit einem Debugger ist es auch möglich, jederzeit ein Programm pausieren zu können und sich die Umgebung bzw. Situation anzuschauen, in welchem sich das Programm nach genau diesem Schritt befindet. Die Debugger-Programme sind in der heutigen Software-Entwicklung zwar nicht die einzigen, aber sicher eines der wichtigsten Werkzeuge, welches den Programmierer zur Verfügung stehen.