Fehlerprotokoll in der Doku

[fonk]

Hallo,

ich habe des öfteren was davon gelesen, dass man Fehler und Fehlerbehebung ausführlich dokumentieren soll. In meinem Projekt ist nun ein Problem aufgetreten, was ich nur durch einen workaround im grunde auch nur "umgehen" konnte - keiner konnte mir direkt sagen woran es liegt und es deutet wohl auf einen hardwarekonflikt hin... muss dazu Zwangsläufig ein Fehlerprotokoll in der Doku bzw. im Anhang auftauchen?

Gruß

der fonk

[charmanta]

Nicht zwangsläufig. Aber Du solltest das erwähnen und Dich darauf einstellen dass dieser Punkt im Fachgespräch möglicherweise beleuchtet wird. Ein FiSi sollte Methoden kennen um Probleme zu lösen und nicht zu umgehen

[timmi-bonn]

ich habe des öfteren was davon gelesen, dass man Fehler und Fehlerbehebung ausführlich dokumentieren soll. In meinem Projekt ist nun ein Problem aufgetreten, was ich nur durch einen workaround im grunde auch nur "umgehen" konnte - [...] muss dazu Zwangsläufig ein Fehlerprotokoll in der Doku bzw. im Anhang auftauchen?

Den Fehler wirst du ja wahrscheinlich beim Testen (QS) festgestellt haben. Also gehört er ins Test-Protokoll. Und das übergibst Du, zusammen mit den anderen Unterlagen, bei der Abnahme an den Auftraggeber.

Wichtig ist nicht, dass beim Projekt-Ende alles sauber läuft; wichtig ist, dass Du das Projekt sauber strukturierst und dokumentierst.

gruss, timmi

[fonk]

Also in der Doku gehe ich im Kapitel "Betriebssystem installation" wie folgt auf das Problem ein:

"Nach Neustart der Rechner von der Festplatte trat ein Problem mit dem PC-Speaker auf: Dieser gab nach dem Initialisieren des ISA-Systems einen dauerhaften Piepton von sich, der sich nur durch abziehen des entsprechenden Kabels vom Mainboard abschalten ließ. Eine Recherche im Internet, sowie Anfragen in entsprechenden Channels des IRC blieben erfolglos und wiesen auf eine Inkompatibilität des OpenBSD GENERIC-Kernels mit dem Mainboard hin. Da die Funktionalität und Stabilität soweit jedoch gegeben schien, das Betriebssystem ohne Fehlermeldungen hoch fuhr und die Fehlerreportage in Serversystemen üblicherweise über Monitorsysteme oder E-Mail und nicht über PC Speaker Signale erfolgt, wurde die Lösung, die PC-Speaker deaktiviert zu lassen, als ausreichend angesehen."

Also das Problem ist auf zwei baugleichen Rechnern aufgetreten, die für das Projekt beide mit OpenBSD laufen müssen. Naja, ich hätte natürlich noch 3 Stunden suchen können und mir mal'n neuen Kernel kompilieren können - aber irgendwo muss ja ein Kompromiss zwischen investierter Zeit und ergebnis gefunden werden...

Naja, ich hab jedenfalls mittlerweile auch mal im internet nach fehlerprotokoll gesucht, aber wie soetwas auszusehen hat, konnte ich nirgends finden! Hat da mal jemand einen Vordruck - dann will ich ja gerne eins dafür schreiben...

[fonk]

(doppelposting)

[timmi-bonn]

Naja, ich hab jedenfalls mittlerweile auch mal im internet nach fehlerprotokoll gesucht, aber wie soetwas auszusehen hat, konnte ich nirgends finden! Hat da mal jemand einen Vordruck - dann will ich ja gerne eins dafür schreiben...

Das wird es als "Vordruck" wohl kaum geben. Denn das entsteht aus deinem Test-Konzept (Test-Matrix) - welches wiederum das Fachkonzept als Ursprung hat ... welches das Pflichtenheft als Vorgänger hatte.

gruss, timmi

[fonk]

Hm, ich weiß nicht ob ich uneinsichtig bin - aber ich lege doch nicht im pflichtenheft fest "später gucken, ob die pc-speaker richtig arbeiten"! Ich installier das OS, ich boote es - es fängt an zu piepen! Da tu ich doch was dagegen, bevor ich kopfschmerzen bekomme! :-) Also trifft ein fehlerprotokoll nun in meinem Fall gar nicht zu, weil der fehler nicht beim testen entstanden ist? *confused*

[timmi-bonn]

[...] ich lege doch nicht im pflichtenheft fest "später gucken, ob die pc-speaker richtig arbeiten"! Ich installier das OS, ich boote es - es fängt an zu piepen! [...] Also trifft ein fehlerprotokoll nun in meinem Fall gar nicht zu, weil der fehler nicht beim testen entstanden ist?

Es gibt verschiedene Testverfahren. Der von Dir geschilderte Fehler zeigt sich (bereits) beim sogenannten Anschalt-Test, dem üblicherweise ersten Test überhaupt. Und da er (der Test) nicht dem erwarteten Ergebnis entsprach, gehört er in das Fehler-Protokoll.

Die "eigentlichen" Testfälle ergeben sich dann aus dem Fachkonzept, in dem ja ganz genau drin stehen muss, was das erzeugte OProdukt alles können muss - bzw., direkt daraus folgend, welche Fehler nicht auftreten dürfen. Und genau gegen diese Fehler testest Du.

Sinngehalt hinter dieser Form des Testens ist, dass Du niemals Fehler-Freiheit garantieren kannst. Du kannst aber anhand einer Testmatrix nachweisen, welche Fehler (in einer definierten Umgebung) NICHT auftreten. Hier liegt einer der häufigsten Fehler der von mir bewerteten Dokumentationen.

Allens Chlor?!?, ...wie der Schwimmeister zu sagen pflegt.

gruss, timmi

[fonk]

Naja, nicht ganz... zum einen finde ich, dass ich ziehmlich schlecht auf die Doku vorbereitet wurde, da ich z.b. nie was von einem anschalttest gehört habe - aber viel wichtiger: Wenn ich die Doku projektbegleitend schreibe, kommt ja irgendwann der punkt "Betriebssystem installieren". Und genau an der stelle habe ich halt den oben zitieren Textabschnitt eingefügt! Soll ich dann besser da reinschreiben: "Ich habe den Anschalttest durchgeführt (siehe Fehlerprotokoll XYZ im Anhang)." Und in der Doku ansich sowas gar nicht erwähnen?

Außerdem hab ich ja zwischendurch immer mal kleine zwischentests gemacht, ob das was ich konfiguriert hab auch geht. Es macht ja keinen sinn erstmal alles zu konfigurieren und dann zu gucken ob alles als komplettes system einwandfrei funktioniert - und wenn nicht jede kleinigkeit nochmal durch zu gehen! Ich dachte halt, es gäb nur einen offiziellen, großen test am ende - im kapitel projekttest! Das ist also falsch, so wie ich das verstehe... :-?

Weiterhin habe ich unter www.projekthandbuch.de ein testprotokoll mit testspezifikation gefunden! Ist das so ausführlich (also, dass ich zu jedem protokoll auch erst eine spezifikation schreibe) notwendig?

Danke für die geduldigen Erläuterungen,

der fonk

[timmi-bonn]

[...] zum einen finde ich, dass ich ziehmlich schlecht auf die Doku vorbereitet wurde, da ich z.b. nie was von einem anschalttest gehört habe

Du meinst "auf das Projektmanagement vorbereitet". Solltest Du nie etwas von den verschiedenen Tests gehört haben, dann fehlt in Deiner Ausbildung wirklich etwas.

Außerdem hab ich ja zwischendurch immer mal kleine zwischentests gemacht, ob das was ich konfiguriert hab auch geht.

Das ist auch OK. Beim Anwendungsentwickler heisst das Äquivalent dann "Modul-Test".

Ich dachte halt, es gäb nur einen offiziellen, großen test am ende - im kapitel projekttest!

Den gibt es AUCH. Das ist die eigentliche QS-Phase - für die Du ein Testkonzept haben solltest. Man geht halt nicht in den Testraum und testet dann "das, was einem gerade so einfällt". Tests sollten strukturiert und gut vorbereitet sein. Nur dann machen sie wirklich Sinn. Und die Test-Ergebnisse werden im sog. Testprotokoll (das kann ganz unterschiedlich aussehen) festgehalten und dem Auftraggeber bei der Abnahme übergeben. Aam sinnvollsten ist zum Testen meistens eine Testmatrix, die alle möglichen Fehler enthält, die NICHT vorkommen dürfen. Und die werden der Reihe nach abgehakt.

dass ich zu jedem protokoll auch erst eine spezifikation schreibe

Nach der reinen Lehre wäüre das so. Aber das würde den Rahmen eines Abschlussprojektes bei weitem sprengen. Daher ist es schon OK, wenn überhaupt ein nachvollziehbarer Test vorhanden ist.

gruss, timmi