Immer wieder sehe ich Testberichte, die wichtige Informationen nicht enthalten. Daher möchte ich in diesem Blog-Beitrag etwas Licht ins Dunkel bringen und einige wesentliche Hinweise zu Testberichten geben. Der Artikel soll eine Hilfestellung geben für alle, die Testberichte erstellen oder prüfen und vielleicht nicht ganz sicher sind, worauf dabei zu achten ist.
Allgemeine Inhalte im Testbericht
In der nachfolgenden Tabelle gebe ich Ihnen eine kleine Checkliste welche allgemeinen Inhalte in einem Testbericht enthalten sein sollten.
| Inhalt für Testbericht | Erläuterung zum Inhalt |
| Zweck des Tests | Es sollte in dem Testbericht eine Beschreibung dazu geben, was der Zweck dieses Tests ist. Also ob es sich z.B. um einen Vortest für eine Komponente oder ein System handelt und gegen welche Spezifikation getestet wird. Die Angabe des Spezifikations-Dokumentes mit Version ist zwingend angeraten. Falls sich die Spezifikation ändert, kann man direkt sehen, gegen welche Spezifikation bei diesem Test getestet wurde. Sofern ein Testplan existiert, so ist dieser zu referenzieren. |
| Test Objekt | In dem Testbericht muss stehen, welches System oder welche Komponente getestet wird. Das kann ein System, eine Hardware, Software oder sonstige Komponente sein. Ziel ist eine eindeutige Bezeichnung, die das Test-Objekt eindeutig identifiziert. Idealerweise hat man eine Seriennummer, die man angeben kann. |
| Version | Ein System hat meist eine eindeutige Version. Bitte achten Sie darauf, dass Angaben zu Software Versionen aufgeführt sind. Denn Software ist meist ein zentraler Bestandteil und der Test ist ohne Angabe der Versionen nicht aussagekräftig. Die Versionsangabe ist aber auch für Hardware, Mechanik und Systeme zwingend notwendig. |
| Konfiguration | Systeme, Komponenten und Software können oft konfiguriert werden. Die Konfiguration muss bekannt sein, damit man den Test unter gleichen Bedingungen wiederholen kann. Beispiele für eine Konfiguration sind z.B. die eingestellte Sprache oder andere Settings des Systems. Bei Hardware sind eventuelle Patches anzugeben, damit klar wird, welche Modifikationen vorgenommen wurden. |
| Test Methode | Im Testbericht sollte angegeben werden, welche Test Methode verwendet werden soll. Beispiele für Test Methoden sind:
|
| Test Umgebung | Dabei handelt es sich um Angaben, in welcher Umgebung ein Test ausgeführt werden soll. Das kann z.B. ein gewöhnlicher Arbeitsplatz mit Zimmertemperatur sein. Es kann aber auch sein, dass besondere Anforderungen an Lichtverhältnisse, Klimabedingungen, ESD-Umgebung oder andere Anforderungen gelten. Diese sollten dann in der Test-Umgebung definiert werden. |
| Test Equipment | Für den Test werden eventuell Messgeräte, Simulatoren, Software oder andere Werkzeuge benötigt. Die verwendeten Werkzeuge sind im Testbericht anzugeben. Z.B. ein Multimeter, mit einer Prüfmittelnummer und einem Kalibrierdatum. Aber auch anderes Equipment ist anzugeben. Auch hier ist darauf zu achten, dass das Equipment eindeutig und nachvollziehbar angegeben ist (Prüfmittelnummer oder Seriennummer, Software Version). Bei Messmitteln ist darauf zu achten, dass die benötigte Messgenauigkeit durch das Messmittel eingehalten werden kann und die notwendige Kalibrierung vorhanden und noch gültig ist. |
| Sample Size mit Begründung | Manche Tests können mit einem Muster durchgeführt werden. Andere Tests benötigen entweder mehrere Durchläufe oder mehrere Samples. Es ist wichtig im Test Bericht anzugeben, mit wie vielen Samples getestet wurde. Diese Angabe ist zu begründen, damit ein Prüfer das nachvollziehen kann. Wenn z.B. ein Test prüft, ob ein bestimmtes Softwareverhalten implementiert wurde, dann reicht meist eine Sample Size von 1, da das System deterministisch ist und das Verhalten entweder implementiert wurde oder nicht. Anders sieht es aus, wenn man z.B. prüft, wann eine Komponente unter mechanischem Druck bricht. Hier muss mit mehreren Samples gearbeitet werden, um statistische Schwankungen zu berücksichtigen. |
Inhalte zu den Testfällen
Neben den allgemeinen Angaben stehen dann die eigentlichen Testfälle (engl. Test Case) im Vordergrund. Die nachfolgende Tabelle zeigt auch hier die notwendigen Inhalte an.
| Inhalt für Testbericht | Erläuterung zum Inhalt |
| Test Case ID | Jeder Test Case sollte eine eindeutige ID haben, mit der er eindeutig identifiziert werden kann. Werkzeuge können Ihnen hier die Arbeit erleichtern und das Verwalten der IDs automatisch für sie übernehmen. Die IDs können dann mit der Anforderung verlinkt werden und sie erhalten automatisch eine Traceability. |
| Vorbedingung | Jeder Test benötigt bestimmte Vorbedingungen, die vor der Testdurchführung gelten müssen. Es kann z.B. sein, dass Sie ein System mit vollem Akku testen wollen. Oder sie möchten, dass sich das System in einem bestimmten Gerätezustand mit einer bestimmten Konfiguration befindet. Diese Informationen sind in den Vorbedingungen zu definieren. |
| Test Schritte | Am Besten zerlegen Sie einen Test in Testschritte. Mit Testschritten ist man in der Lage eine Sequenz von Prozeduren zu beschreiben, die dann hintereinander durchgeführt werden. Jeder Testschritt sollte eine Bezeichnung bekommen. Hier kann man entweder einfach durchnummerieren (1, 2, 3, …) oder man vergibt eine aussagekräftige Bezeichnung an (z.B. Einschalten, Zeit messen, Ausschalten). |
| Prozedur oder Beschreibung | Jeder Testschritt bekommt eine eindeutige Prozedur oder Beschreibung, die festlegt, was in dem Testschritt durch den Tester oder die automatisierte Test-Umgebung zu tun ist. Diese Beschreibung sollte eindeutig, verständlich und vollständig sein und keine impliziten Annahmen enthalten. Schließlich muss der Test auch von anderen Personen als dem Schreiber selbst verständlich und durchführbar sein. |
| Akzeptanzkriterium | Das Akzeptanzkriterium ist das mit Abstand wichtigste Element eines Testplanes oder Testberichtes. Hier wird definiert was das Kriterium ist, um einen Test als bestanden zu akzeptieren. Dabei muss das Akzeptanzkriterium mit der zugrundeliegenden Anforderung zusammen passen. Beispiel eines Akzeptanzkriteriums: “Der Test ist bestanden, wenn das System nach Drücken der Einschalttaste innerhalb von 3 Sekunden die Messwerte auf dem Display anzeigt.” |
| Ergebnis | Das Ergebnis enthält die Informationen, was der Tester beobachtet hat. Es wird also neutral beschrieben, wie sich das System beim Test verhalten hat. Pass oder Fail sind nicht das Ergebnis, sondern die Bewertung des Ergebnisses! Es muss möglich sein, das Ergebnis nachzuvollziehen und mit dem Akzeptanzkriterium zu vergleichen. Das ist mit einem einfachen “Pass” nicht möglich. Bitte vermeiden Sie auch einfach das Akzeptanzkriterium zu kopieren. Es ist sehr zu empfehlen die Ergebnisse mit Nachweisen wie z.B. Fotos, Videos, Logdaten oder ähnlichem zu hinterlegen und diese mit abzulegen und im Ergebnis zu referenzieren. Objektive Nachweise sind sowohl in Audits sehr hilfreich als auch in dem Fall, wenn man einen bereits durchgeführten Test nochmal nachträglich nachvollziehen will oder wiederholen möchte. Der Aufwand die Ergebnisse zu dokumentieren hält sich aus meiner Sicht in Grenzen und der Nutzen überwiegt hier deutlich. |
| Kommentare und Abweichungen | Falls bei einem Test die Akzeptanzkriterien nicht eingehalten werden, oder sich andere Abweichungen oder Auffälligkeiten ergeben, so sollten diese zu jedem Testschritt dokumentiert werden. Es ist empfehlenswert ein Bug-Tracking Werkzeug einzusetzen, in dem Anomalien und Fehler verwaltet werden. Dann kann man die ID des Fehlers im Testbericht eintragen und damit auf das Bug-Tracking Werkzeug referenzieren. |
| Datum und Unterschrift | Sofern die Tests nicht mit Werkzeugen wie z.B. Polarion durchgeführt werden, ist es empfehlenswert jeden Test mit Datum und Unterschrift zu signieren. Schließlich kann es insbesondere bei größeren Spezifikationen dazu kommen, dass die Tests nicht an einem Tag und nicht von einer Person durchgeführt wurden. Es ist aber zwingend erforderlich zu wissen, wer die Tests wann durchgeführt hat. Diese Arbeit kann ihnen ein Werkzeug abnehmen. Alternativ sollten Sie es händisch eintragen. |
| Summary oder Assessment | Ganz am Ende eines Testberichtes sollte es einen Abschnitt geben, in dem es eine Zusammenfassung zu den Tests gibt. Das kann in Form einer Prosa-Beschreibung oder in Tabellenform geschehen, in der nochmal auf die Test-Fälle eingegangen wird. Wichtig ist, dass man einfach eine Übersicht bekommt, ob es Abweichungen gibt und wenn ja welche, oder ob alle Tests bestanden sind. |
Ich hoffe, dass die Checkliste Ihnen eine kleine Hilfestellung gibt, um die Qualität Ihrer Testberichte zu verbessern. Gerade bei Testberichten gilt es sehr akkurat zu dokumentieren.
Viele Grüße
Goran Madzar
Auch interessant:
Systemarchitektur und Risikomanagement – zwei wie Pech und Schwefel
Wer Medizinprodukte entwickelt, hat zwangsweise auch mit Risikomanagement zu tun. Sehr viele Unternehmen tun sich jedoch schwer mit dem Thema Risikomanagement. Und…
Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Unser Standort ist im Innovations- und Gründerzentrum in Erlangen. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.
Sehr geehrter Herr Madzar,
vielen Dank für diesen aufschlussreichen Bericht. Auch ich sehe Testberichte in allen Varianten. Häufig ist nicht nachvollziehbar was das Gesamtergebnis des Tests ist. Auch wird häufig die Testumgebung vernachlässigt. Es fehlt meist eine eindeutige Identifizierung der Umgebung (Script Bezeichnung, Version,…). Auch die eingesetzte Testumgebung muss Teil des Konfigurationsmanagements sein.
Summary/Assessment: Die Zusammenfassung des Tests gehört aus meiner Sicht an den Anfang des Testberichtes. Reviewer wollen zunächst wissen, ist der Test bestanden ja/nein. Erst danach wird in die Details gegangen. So ist es möglich sich sehr schnell und einfach einen Überblick zu verschaffen.