Published by Marc on 1. May 2010 09:59:24
Updated by Marc on 10. Sep 2010 14:21:47
------------------------------------------------------------------------

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.