Seite 2: Anforderungen, Testpläne

Inhaltsverzeichnis

Definition der Anforderungen

Für die Anforderungsdefinition verwendet der Autor in den Projekten häufig zwei Dokumenttypen: zum einen das Lastenheft, das der Kunde zur Angebotsfindung in einem Format seiner Wahl, etwa ein PDF oder als Excel-Liste, vorlegt, und zum anderen die Detailspezifikation in Form eines Pflichtenhefts, das als Basis für die weitere Projektplanung und -durchführung dient. Um die Dokumente für spätere Projektphasen und Werkzeuge verwendbar zu gestalten, wird das Pflichtenheft in einem standardisierten Format erstellt, wobei die einzelnen Anforderungen in Tabellenform angelegt sind.

Die Tabellenformulare dienen der Synchronisierung mit dem TFS, der die Anforderungen zentral speichert. Für die Anbindung von Word-Dokumenten hat AIT das Zusatzwerkzeug WordToTFS entwickelt.

Das Word-Pflichtenheft bleibt das führende Dokument für die funktionalen Beschreibungen der Spezifikation, denn es dient als Vertragsgrundlage gegenüber dem Kunden. Über einen Änderungsprozess lassen sich Change Requests in den TFS einstellen und die Anforderungen nach ihrer Freigabe im Word-Dokument verändern. Nach der Abnahme des Dokuments werden die Änderungen durch eine erneute Synchronisierung in den TFS übernommen.

Die Anforderungen liegen somit in einem zentralen Repository, auf das sich über Client-Applikationen zugreifen lässt. Die Idee ist, dass jede Rolle im Team zwar spezifische Werkzeuge verwendet, allerdings auf die gleiche Datenbasis zugreifen kann. Für den fachlichen Tester bietet Microsoft den Test Manager 2010 als Client-Applikation an. Im Testing Center der Applikation lassen sich die Anforderungen direkt aus dem TFS öffnen, anlegen und bearbeiten. Die Anforderungen im TFS dienen als Planungselemente für Release- und Iterationsplanung und als Ausgangsbasis für die Definition der Tests.

Ableitung von Akzeptanzkriterien und Testplänen

Um Akzeptanzkriterien und Testplänen abzuleiten, werden für die Anforderungen Akzeptanzkriterien und Systemtests in Form von Testfällen angelegt. Häufig passiert das in einem separaten Tool. Die Verbindung zwischen Test und Anforderung ist aufwendig über IDs oder Ähnliches zu pflegen. Der TFS kann Testfälle verwalten und direkt mit den Anforderungen über Artefakt-Links verbinden. Diese Verknüpfungen sind in Abfragen verwendbar. Beispielsweise lässt sich eine Liste der Anforderungen mit verknüpften Testfällen oder eine Auflistung aller Anforderungen abfragen, für die noch kein Testfall erstellt wurde. Das bietet einen schnellen Überblick der noch offenen Arbeit auch für den Tester.

Häufig stellt sich die Frage, ob nicht schon die Anforderungsdefinition, zum Beispiel in Form von Szenarien, für die Tests ausreichend ist. Das lässt sich in den meisten Fällen verneinen. Testfälle definieren ein möglichst in sich geschlossenes Szenario, das aus einzelnen Testschritten und konkreten Testdaten besteht, die möglichst unterschiedliche Fälle innerhalb der Applikationslogik abdecken. Ist die Anforderungsdefinition noch generisch und arbeitet mit Wertebereichen, ist der Testfall eine konkrete Ausprägung der späteren Verwendung der Applikation durch den Benutzer. Oft identifiziert der Tester bereits während der Testfallerstellung Lücken oder Widersprüche in den Anforderungen, was teure Fehlerbehebungen in späteren Phasen spart.

Abbildung 5 zeigt das Formular eines Testfalls im Testing Center mit der Beschreibung der einzelnen Testschritte. Zu jedem Schritt lassen sich erwartete Ergebnisse in Form von Text und angehängten Dokumenten angeben. Über Testparameter kann man Testdaten hinterlegen, um eine mehrfache Ausführung des Tests mit verschiedenen Benutzereingaben zu definieren. Benötigt man mehrere zusammenhängende Testschritte in den Testfällen immer wieder, lassen sich diese als sogenannter Shared Step auslagern und zentral verwalten. Es ist sogar möglich, das Action Log des zentralen Schritts aufzuzeichnen und dann in den referenzierenden Testfällen abzuspielen.

Die Testfälle sind nicht nur bloße Definitionen der Testschritte mit verknüpften Anforderungen. Sie stellen vollständige Planungselemente – sogenannte Work Items im TFS-Vokabular – dar, werden zum Beispiel einer Person zugewiesen sowie in Iteration und Bereich klassifiziert. Die Generizität der Work Items erlaubt die Anpassung des Formulars und der dahinter liegenden Zustandsmaschine, die für Testfälle die Zustände "Design", "Ready" und "Closed" definiert. Ein Testfall wird demnach entworfen, dann zum Test freigegeben und letztlich nach erfolgten Testzyklen und Abnahme der getesteten Funktionen geschlossen. Bei Bedarf lässt sich der Testfall allerdings auch wieder öffnen.

Eine Anforderung bedarf häufig der Definition mehrerer Testfälle. Für einen Anwendungsfall zum Beispiel bieten sich unterschiedliche Szenarien (Normalfall und Ausnahmefälle) an. Das reicht allerdings noch nicht für einen vollständigen Testplan. Dieser soll ganze Systeme in Form von Anforderungsgruppen abdecken. Testpläne sind ein zentraler Bestandteil des Testing Center und fungieren als Ausgangspunkt für die weitere Planung und Ausführung der Tests. Dabei liegen der Testplan und seine Elemente wiederum im Team Foundation Server.

Öffnet man nun einen Testplan im Testing Center, kann die Planung beginnen. Erst strukturiert man ihn dazu in Unterelemente, sogenannte Testsuiten, die die Testfälle enthalten. Über diese Strukturierungsmechanismen lassen sich Funktionsgruppen, Produktbereiche oder auch Testteams unterscheiden – je nach individuellem Projekt-Setup. Über die unterschiedlichen Testsuite-Typen kann man unterschiedlich Testfälle zusammenstellen, wobei sich diese mehrfach referenzieren lassen, zum Beispiel wenn die Testfälle mehreren Testkonfigurationen zugewiesen werden. Eine solche Konfiguration repräsentiert eine zu testende Umgebung über Variablen wie das Betriebssystem, die Sprache oder die Browserversion. Einen Testfall kann man in mehreren Testumgebungen wiederverwenden. Man unterscheidet drei Typen von Testsuiten:

Testsuite-Typ	Beschreibung
Suite	Sie stellt einen einfachen Strukturierungsknoten ähnlich einem Verzeichnis dar. Testfälle lassen sich manuell hinzufügen, was keine Auswirkungen auf den Testfall hat.
Query-based Suite	Durch eine Work-Item-Abfrage, die zum Beispiel einen Filter auf die Teststufe enthält, werden Testfälle aus dem Repository aufgelistet. Entspricht ein Testfall nicht mehr den Kriterien der Abfrage, entfernt man ihn aus der Suite. Das hat keine Auswirkungen auf den Testfall.
Requirement	Sie repräsentiert eine Anforderung aus dem Projekt. Es wird etwa ein Work Item vom Typ "Requirement" referenziert, und fügt man einen Testfall zur Suite hinzu, wird dieser mit der Anforderung verknüpft. Entfernt man die Verknüpfung, ist der damit entkoppelte Testfall nicht mehr Bestandteil der Suite.

Die Abbildung 6 zeigt einen mit den einfachen Suiten und Requirements strukturierten Testplan für die Akzeptanz- und Systemtestebene. Der linke Bereich des Testing Center stellt die Struktur der Suiten dar, im rechten Teil sind die der ausgewählten Suite zugeordneten Testfälle aufgelistet.

Auch Suiten haben einen Zustand, dargestellt durch ein kleines Icon links neben dem Suite-Namen. Die Zustände reichen von "In Planning" (= noch nicht bereit zum Testen) über "In Progress" (= bereit zum Testen) bis zu "Completed". Letzteres bedeutet, dass alle Tests absolviert und in dieser Suite nicht mehr auszuführen sind. Dadurch lässt sich die Menge der auszuführenden Tests trotz umfangreicher Testpläne für den Tester übersichtlich halten.

Die folgende Tabelle zeigt zudem die Navigationsleiste im oberen Teil des Testing Center mit den Bestandteilen Plan, Test, Track und Organize.

Bereich	Beschreibung
Plan	Der Planungsbereich ist der Verwaltung des ausgewählten Testplans verschrieben. Darin enthalten sind Einstellungen zur Durchführung, individuelle Testsuiten und Testfälle.
Test	Für die Ausführung der Tests dient der Testbereich. Hier lassen sich Testläufe starten, Testergebnisse speichern und Fehlerberichte anlegen. Zudem kann man die zurückliegenden Testläufe auswerten.
Track	Zur erweiterten Auswertung ist der Track-Bereich da. Zum einen können hier Differenzen zwischen zwei Builds des Systems analysiert, zum anderen die von Code-Änderungen betroffenen Tests ermittelt werden.
Organize	Dieser Bereich bietet eine Übersicht zum schnellen Zugang zu und zu Bearbeitung von Testplänen, -fällen und -konfigurationen.