Testfälle spezifizieren – Eine triviale Aufgabe im Requirements Engineering? – Teil 3
- Testfälle spezifizieren – Eine triviale Aufgabe im Requirements Engineering? – Teil 1
- Testfälle spezifizieren – Eine triviale Aufgabe im Requirements Engineering? – Teil 2
- Testfälle spezifizieren – Eine triviale Aufgabe im Requirements Engineering? – Teil 3
In Teil 2 der Serie „Testfälle spezifizieren“ haben wir beschrieben, wie Testfälle in einem Anforderungsmanagement-Tool optimal spezifiziert werden. Die spezifizierten Testfälle sind selbstverständlich wenig hilfreich, wenn diese nicht ausgeführt und ihre Ergebnisse nicht dokumentiert werden. Daher beschäftigt sich der dritte und letzte Teil dieser Serie damit, wie Testergebnisse in einem Anforderungsmanagement-Tool dokumentiert werden können.
Warum müssen Testergebnisse überhaupt dokumentiert werden?
Wenn es etwas gibt, das in jedem Projekt vorkommt, dann ist es mit Sicherheit die Frage des Projektleiters: „Wie weit sind wir?“. Dann sind diejenigen, die Ihre Testergebnisse ordentlich dokumentiert haben, klar im Vorteil. Sind die Testergebnisse mit den Testfällen und die Testfälle, wie in Teil 2 der Serie beschrieben, mit den Anforderungen (Requirements) aus der Systemspezifikation verlinkt, können wir dem Projektleiter selbstbewusst eine Antwort geben. Anhand der Anzahl erfolgreich ausgeführter Testfälle und der Anzahl noch nicht ausgeführter bzw. fehlgeschlagener Testfälle ist es möglich, dem Projektleiter einen prozentualen Status mitzuteilen. Wir haben also stets eine Übersicht wie viele Anforderungen bereits erfolgreich implementiert wurden.
Wie können wir nun am besten Testergebnisse zu vorliegenden Testfällen dokumentieren?
Mit folgender Umsetzung im Anforderungsmanagement-Tool „IBM Rational DOORS“ haben wir gute Erfahrungen gemacht:
Ein separates DOORS Modul ist mit den Testfällen verlinkt, so dass zu jedem Testfall ein Objekt im Testergebnismodul existiert. Das Testergebnismodul sollte mindestens folgende Attribute besitzen:
- Testergebnis ID: Eine eindeutige Identifizierung des Objekts im Testergebnismodul ermöglicht textuelle Referenzen auf einzelne Testergebnisobjekte.
- Testergebnis Typ: Handelt es sich bei dem Testergebnisobjekt um ein „Testergebnis“ oder um „Freitext“, wie etwa eine Erläuterung zu einem Abschnitt im Testergebnismodul?
- Testergebnis: Das ist das wichtigste Attribut in diesem Modul, da es den Status der verlinkten Testfälle wiedergibt. Die Werte das Attributs sind daher:
- „bestanden“
- „nicht bestanden“
- „nicht ausgeführt“
- Testdatum/-zeit: Es muss dokumentiert werden, wann der jeweilige Testfall ausgeführt wurde. Ist ein erfolgreicher Testfall schon mehrere Tage oder Wochen alt, sollte ein Regressionstest durchgeführt werden, um sicherzustellen, dass aktuelle Implementierungen keine negativen Einflüsse auf das bereits dokumentierte Testergebnis haben.
- Version: Neben der Angabe des Testdatums und der Testzeit ist die Angabe der getesteten Version wichtig, um ebenfalls beurteilen zu können, ob ein Regressionstest nötig ist. Des Weiteren können wir anhand der Angabe der getesteten Version erkennen, ab welcher Version eine bestimmte Funktionalität erfolgreich umgesetzt wurde.
- Tester: Gerade dann, wenn mehrere Tester an einem Projekt beteiligt sind, sollte dokumentiert werden, wer den jeweiligen Test durchgeführt hat. Hier bietet sich die Angabe eines eindeutigen Benutzernamens an.
- Weitere Informationen: Der Tester sollte immer die Möglichkeit haben Kommentare zum ausgeführten Test niederzuschreiben. Dies ist insbesondere dann wichtig, um festzuhalten warum ein Test nicht bestanden oder nicht ausgeführt wurde.
Wie oben erwähnt helfen die Attribute „Testdatum/-zeit“ und „Version“ bei der Ermittlung der Funktionen, welche regressiv getestet werden müssen. Daher kann die Dokumentation der Testergebnisse auch als eine Checkliste gesehen werden, welche zeigt, ob die Testergebnisse aktuell sind und ob mit dem Testen aufgehört werden kann.
Während der Entwicklung stellt man fest, dass die Dokumentation der Testergebnisse bei der Qualitätssicherung hilfreich ist, so dass man ein gutes Gefühl hat dem Kunden das Produkt zur Prüfung bzw. zur Abnahme zu liefern.
Diese Serie hat gezeigt, dass das Spezifizieren von Testfällen und das Dokumentieren der Testergebnisse keine triviale Aufgabe im Requirements Engineering ist und daher nicht auf die leichte Schulter genommen werden darf.
Auf unserer Website finden Sie weitere Informationen zum spannenden Thema „Testmanagement“. Ihr Wissen rund um das Thema „Testmanagement“ können Sie in unseren Schulungen vertiefen (z.B.: „Anforderungsbasiertes Testen“ oder „Testen im agilen Umfeld“).
Pedro Ferreira
Kontaktieren Sie Pedro FerreiraPedro Ferreira ist als Consultant und Trainer bei der HOOD GmbH im Bereich Requirements Engineering tätig. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehörigen Werkzeugen (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Erstellung von objektorientierten Modellen unter Einsatz der UML und das Spezifizieren von Testfällen. Erfahrungen konnte Pedro Ferreira bisher in der IT-, Automobil- und in der Luftfahrtindustrie sammeln. Als Trainer hat er sich auf die gute Formulierung von textuellen Anforderungen und auf die Methoden zur Erhebung von Anforderungen aus der UX Domäne spezialisiert.
Wissen, das bewegt!
Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.
Jetzt abonnieren und keine wichtigen Insights mehr verpassen!
Diskussion