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

Während eines viermonatigen DXL-Implementierungsprojekts bei einem unserer Kunden wurde ein Requirements Engineering Framework verbessert und um Funktionalitäten erweitert. In diesem Rahmen hatte ich u.a. die Aufgabe Testfälle zu spezifizieren, welche die geforderten Eigenschaften der Software sicherstellen sollten. Doch das Spezifizieren von Testfällen ist keineswegs eine triviale Aufgabe.

Zu Beginn klingt es ganz einfach, denn es müssen offensichtlich „nur“ alle expliziten Anforderungen des Lastenheftes abgedeckt werden. Dem entsprechend geht man minimalistisch vor und versucht, mehrere Anforderungen mit einem Testfall abzudecken (n:1). Sollte dies nicht klappen, wird für jede Anforderung des Lastenhefts ein Testfall spezifiziert (1:1). Doch wurde mit diesem minimalistischen Prinzip nun eine qualitativ hochwertige Basis geschaffen, um das Softwaresystem (Testobjekt) zu testen und um sicherzustellen, dass es nahezu fehlerfrei ist? Mit Sicherheit nicht!

Es ist möglich, dass es eine Anforderung gibt, die erst durch mehrere Testfälle vollständig abgedeckt wird (1:n). Das folgende simple Beispiel soll dies verdeutlichen:
Anforderung 1: „Das System muss die ausgewählten Daten sowohl nach Excel als auch nach Word exportieren.“
Anforderung 1 muss daher von mindestens zwei Testfällen abgedeckt werden, wobei ein Testfall prüft, ob ein Excel-Export und ein anderer, ob ein Word-Export erfolgreich erzeugt wurde.

Doch damit nicht genug, denn es müssen weitere Testfälle betrachtet werden, um sicherzustellen, dass ein fehlerfreies Produkt geliefert wird. Es stelle sich die Frage, wie es mit der Robustheit des Softwaresystems aussieht. Sollte sie nicht als explizite Anforderungen im Lastenheft niedergeschrieben sein, so müssen trotzdem Testfälle dazu spezifiziert werden um bei einer Testdurchführung Systemabstürze oder Fehlermeldungen zu identifizieren, so dass diese in der Software beseitigt werden können. Dazu folgendes Beispiel:

Anforderung 2: „Das System muss die Ausgabe der Daten aufsteigend nach den Werten der Tabellenspalte ‚Priorität‘ sortieren“.

Es ist klar, dass geprüft werden muss, ob die ausgegebenen Daten tatsächlich nach der angegebenen Priorität sortiert werden. Es muss aber auch mindestens einen Testfall für Anforderung 2 geben, welcher prüft, wie sich das Softwaresystem verhält, falls die Tabellenspalte „Priorität“ nicht existieren sollte. Es könnte nämlich sein, dass dem Softwaresystem als Eingabedaten eine ältere Version einer Tabelle übergeben wurde, in der die Spalte „Priorität“ noch nicht existierte.

Beim Spezifizieren stellt man relativ schnell fest, dass sich viele Testfälle akkumulieren und dass das Testobjekt in der Regel nie vollständig überprüft werden kann. Daher muss man sich auf eine Auswahl aus der Menge aller möglichen Testfälle beschränken [1].
Spezifizierte Testfälle stellen eine essentielle Basis für jeden Tester dar, um die Qualität eines Systems zu beurteilen und über die Abnahme zu entscheiden. Das Spezifizieren von Testfällen ist daher als anspruchsvolle Aufgabe im Qualitätsmanagement anzusehen.

Im kommenden Teil der Reihe „Testfälle spezifizieren“ wird gezeigt, wie Testfälle in einem Requirements Management Werkzeug optimal spezifiziert werden können.

Eine detaillierte Auseinandersetzung mit dem Thema „Test“ ermöglichen Ihnen unsere Schulungen.

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

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

Series Navigation

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