Testdokumentation nach IEEE 829
Wenn Sie demnächst mal wieder vor der Aufgabe stehen, eine Testdokumentation für einen Softwaretest zu erstellen, und den Hinweis erhalten, sich doch an der ANSI 829 zu orientieren, dann antworten Sie einfach mit einem klaren und entschiedenen Jein! Und warum das so ist und wie man es vielleicht einfacher, besser machen kann, das will ich versuchen mal ein wenig zu beleuchten.
Aufbau der IEEE 829
Die Norm unterscheidet Planungs- und Berichtsdokumente, wobei die Planungsdokumente in einer hierarchischen Struktur angeordnet sind.
ANSI 829 Struktur
Insgesamt haben wir also die folgenden Dokumente zu betrachten
Planungsdokumente
Und dann noch die Berichtsdokumente (ohne hierarchische Struktur)
Im Testplan werden Planungselemente beschrieben, so wie man es halt kennt: Personal, Zeitplan, die Testumgebung, welche Softwarekomponenten zu testen sind und was genau (welche Merkmale) so zu testen sind. Darüber hinaus findet man auch Softwaretest-typische Punkte wie Akzeptanzkriterien (welche Kriterien erfüllt sein müssen, damit die Software vom Kunden akzeptiert wird), was zu tun ist, wenn der Test unterbrochen und wieder aufgenommen wird, Informationen zu Risiko und Risikomanagement und vieles mehr.
Zu jedem Testplan gehören verschiedene Spezifikationen. Inhalt der Testspezifikationen ist die Beschreibung der anzuwendenden Testverfahren, die zu testenden Fuktionen, die Pass / Fail Kriterien usw.
Die beiden weiteren Planungsdokumente sind quasi parallel zu betrachten: In der Testvorschrift wird beschrieben, welche Reihenfolge der Testfälle einzuhalten ist und welche speziellen Anforderungen zu beachten sind. Im Testfalldokument stehen die Eingabedaten, die erwartete Ausgabe, Abhängigkeiten zu anderen Testfällen usw.
Wenn ich solche eine (in Dateien oder Papierform) vorliegende Planung in einem Projekt sehe, verziehe ich zwar das Gesicht, aber: hey, man kann es so machen.
Kommen wir doch nun mal zu den Berichtsdokumenten: Um den Übergabebericht kommt man nicht herum. Aber, bitte, ich erstelle doch nicht immer ein Dokument! Wenn man ernsthaft Softwareentwicklung betreibt, dann verwendet man auch eine Quellcode Verwaltungssoftware (z.B. subversion, sourcesafe usw.). Also setzt man einen Tag oder Label und damit ist klar was zu testen ist und wo es zu finden ist.
Die Problemmeldung ist das wahrscheinlich wichtigste Element einer Testdokumentation. Problemmeldungen dürfen auf gar keinen Fall in Form von Dokumenten in einem Verzeichnis dümpeln. Es gibt hervorragende freie OpenSource Software (z.B. Bugzilla), die wesentliche Verbesserungen mit sich bringen. Auf einfache Art und Weise kann nachgehalten werden wer, wann, was berichtet hat und was damit geschehen soll, wie der aktuelle Stand ist und vieles mehr. Machen Sie sich die Mühe auch verschiedene kommerzielle Produkte zu testen. Empfehlung gefällig?
Das eigentliche Durchführen des Testens benötigt Informationen, die einfach zu erfassen sind und beieinander stehen. Testvorschrift und Testfall gehören zusammen und das am besten in einer tabellenartigen Datenstruktur. Man findet viele Produkte in diesem Bereich und kann sehr viel Geld dafür ausgeben. Allerdings kann man kleinere bis mittlere Projekte auch mit Hilfe einer Tabellenkalkulation lösen. In einem Tabellenblatt kann man dann auch einfach Auswertungen vornehmen, so dass der Abschlussbericht gleich mit erschlagen wird. Vielleicht biete ich mal ein, zwei Lösungen dazu zum Download an.
Hallo!
Was sind die häufigsten Applikationen für Software Tests und insbesondere dort wo IEEE oder ähnliche Dokumentation verlangt wird?
Man liest einiges über Automotive. Wird Automotiv deshalb genannt weil es ein gutes Beispiel ist oder weil der Marktanteil dort weit größer ist?
mfg,
Martin
Applikationen für SW Tests ist so allgemein, dass man auch nur allgemein antworten kann:
Muss:
* Standard Büro Applikationen: Internetzugang, Email, Officesoftware (Text, Tabellen, Präsentation, Visualisierung usw.)
* Bug-/ Defect- / bzw. Issuetrackinng Tool
Da gibt es 100te unterschiedliche freie und sehr teure Lösungen. Bitte nicht versuchen, selber etwas mit Access o.ä. zu stricken. Das geht idR. schief. Sehr gute und freie Lösung ist Bugzilla (http://www.bugzilla.org/)
* Sourcecode Verwaltung und Verfolgung
Viele freie und gute Werkzeuge: in erster Linie ist wohl subversion zu nennen. Wenn im Microsoftumfeld entwickelt wird auch mal sourcesafe anschauen. uvm.
* Testcaseverwaltung: je nach Projekt und Umfang lassen sich gute Ergebnisse mit MS Office Lösungen erzielen. Ein paar Exceltemplates dazu werde ich bei Gelgenheit hier mal anbieten. Es gibt große, umfangreiche Testsuites (z.B. HP Testdirector).Lizenz nicht unter 5000 EUR …
Kann:
- Testautomatisierung
- Werkzeuge für den Entwicklertest (Codeüberdeckungstests usw.)
- Kommunikation-, Groupwarewerkzeuge (z.B. Wikis, Instant Messaging Systeme, aber auch viele kommerzielle Anbieter) uvm.
IEEE 829 ist immer auch nur ein Vorschlag, wie eine Testdokumentation aussehen KANN, aber nicht MUSS. Bitte dringend die Norm an die tatsächlichen Gegebenheiten anpassen.
Unter “Automotive” werden alle Vorgehensweisen zusammengefasst, die sich in irgendeiner Form auf die “Fahrzeugindustrie” beziehen (Auto, Schiene, Flugzeug usw.) Diese Industriebereiche haben ein sehr eigenes Vokabular und eigene Vorgehensmodelle (idR. Spice). Automaotive hat also zunächst einmal nix mit Test und/oder Dokumentation zu tun.