Testfälle spezifizieren – Eine triviale Aufgabe im Requirements Engineering? – Teil 2

Im ersten Teil der Reihe „Testfälle spezifizieren“ wurde beschrieben, warum das Spezifizieren von Testfällen keine triviale Aufgabe im Requirements Engineering darstellt. Teil 2 beschäftigt sich damit, wie Testfälle im Anforderungsmanagement-Tool „IBM Rational DOORS“ optimal spezifiziert und verwaltet werden können.

Spezifizieren von Testfällen – DOORS

Bei einem unserer Kundenprojekte hatten wir die hochwertige Spezifikation eines geforderten Softwaresystems vorliegen, so dass wir uns für einen „Spezifikationsbasierten Test“ [1] entschieden. Dieses Vorgehen stellt sicher, dass die gesamte Spezifikation mit Testfällen abgedeckt wird.
Wie sieht nun eine Spezifikation von Testfällen unter „IBM Rational DOORS“ aus?

Liegt eine Systemspezifikation als Baseline eines DOORS Moduls vor, kann ein separates Testfallmodul angelegt werden, so dass dieses mit der Systemspezifikation verlinkt werden kann. Anhand der Verlinkungen ist eine vollständige Abdeckung der Anforderungen durch Testfälle leicht zu überprüfen, da jede Anforderung mit einem Testfall abgedeckt werden muss.

Wichtige Angaben im Testmodul – die Checkliste

Um optimales Spezifizieren von Testfällen zu garantieren, sollten im Testfallmodul mindestens folgende Angaben zu jedem Testfall zu finden sein:

• Testfall-ID: Eine ID erlaubt die eindeutige Identifizierung jedes Testfalls und ermöglicht daher stets auch eine textuelle Referenz auf einen Testfall.
• Zweck: Hier sollte möglichst kurz und treffend festgehalten werden, welche Funktionen der entsprechende Testfall überprüft. So ist es für den Tester bei späteren Regressionstests leicht, sich an die zu testenden Funktionen zu erinnern und muss nicht erst erneut die verlinkte Anforderung lesen.
• Testfall-Typ: Handelt es sich um einen Software-, Hardwaretest oder ein Review (z.B. Code-Review)? Hier kann es durchaus noch weitere Attributwerte geben. Es sollte aber auch stets ein Attributwert „Freitext“ auswählbar sein, da ein Testfallmodul auch beschreibende Objekte beinhalten kann, die lediglich Hinweise zu dem Ausführen der Testfälle geben.
• Vorbedingungen: Was muss vor der Ausführung des Testfalls beachtet werden? (Z.B.: Die GUI des Testobjekts ist sichtbar und der „Start“- Button ist aktiviert.)
  In diesem Fall ist es wichtig zu beachten, dass genannte Vorbedingungen vorher schon einmal mit einem Testfall beschrieben wurden (z.B.: Wie wird die GUI gestartet und wie wird der „Start“- Button aktiviert) und in der Vorbedingung referenziert werden (Testfall-ID!).
• Testsequenz: Einzelne Aktionen müssen beschreiben, was der Tester ausführen bzw. eingeben muss. Jede Aktion muss dabei nummeriert werden.
  Beispiel:
  1. Das Programm „XYZ“ starten.
  2. „Excel-Export“ auswählen.
  3. Den „Start“- Button anklicken.
• Erwartetes Ergebnis: Jeder unter „Testsequenz“ beschriebenen Aktion muss das erwartete Ergebnis zugeordnet werden. Dieses Attribut ist jedoch nicht für die Dokumentation des tatsächlichen Ergebnisses, aus der Ausführung des Testfalls, bestimmt.
  Beispiel:
  1. Die „XYZ“- GUI ist sichtbar. Der „Start“- Button ist deaktiviert.
  2. „Excel-Export“ ist ausgewählt. Der „Start“- Button ist aktiviert.
  3. Eine Excel-Arbeitsmappe ist sichtbar.
  Es handelt sich hierbei selbstverständlich um ein vereinfachtes Beispiel. In einer realen Beschreibung der Testsequenz und der erwarteten Ergebnisse muss genau angegeben werden, welche Daten in der Testsequenz eingegeben und im erwarteten Ergebnis als Ausgabe erwartet werden. Denkbar wären hierfür auch zwei separate Attribute „Eingabedaten“ und „Ausgabedaten“.
• Weitere Informationen: Hier können Bemerkungen zum entsprechenden Testfall festgehalten werden. Handelt es sich z.B. um einen Testfall, welcher die Performance des Testobjekts messen soll, so kann man hier Anmerkungen zu der Systemumgebung machen, so dass das Ergebnis der Performanz unter denselben Bedingungen reproduziert werden kann.

Mit spezifizierten Testfällen hat man eine „Checkliste“, mit der es möglich ist, die geforderten Funktionen eines Systems zu testen. Da jeder Testfall mindestens mit einer Anforderung aus der Systemspezifikation verlinkt sein muss, ist es möglich zu erkennen, welche Anforderungen noch nicht mit einem Testfall abgedeckt wurden und noch abgedeckt werden müssen.

Mehrere Tester sind möglich

Da die Testfälle anhand o.a. Informationen detailliert spezifiziert werden, können diese von beliebigen Testern ausgeführt werden, so dass die Arbeit aufgeteilt werden kann.
Zu guter Letzt können anhand der Testfälle Reviews oder Abnahmen durchgeführt werden, um die Qualität des gelieferten Systems sicherzustellen.

Teil 3 dieser Serie wird sich damit beschäftigen, wie Testergebnisse der ausgeführten Testfälle optimal dokumentiert werden können.

Bei Interesse finden Sie auf unserer Website aktuelle Schulungen. Daneben empfehle ich Ihnen, den Intensivworkshop zur IREB® CPRE-Foundation Level Zertifizierung oder das Training zum Certified Agile Requirements Specialist (CARS), es ist sicher etwas für Sie dabei. 

[1] K. Pohl: Requirements Engineering – Grundlagen, Prinzipien, Techniken. dpunkt.verlag, Heidelberg, 1. Auflage, 2007

Dieser Blogbeitrag wurde von Pedro Ferreira für HOOD geschrieben.