Testfälle ermöglichen strukturiertes Testen

Strukturiertes Testen bedeutet vor allem, dass man die an das System gestellten Anforderungen gezielt abprüft, statt „mal kurz durch zu klicken“. Man nimmt also Konzept oder Anforderungsspezifikation als Basis und beschreibt in sich abgeschlossene Benutzerfunktionen, die das zu testende System bereitstellen muss. Diese Beschreibung enthält auch das erwartete Ergebnis und ermöglicht dem Tester, zu beurteilen ob der Test erfolgreich ist oder fehlschlägt.

Testfälle kann man mithilfe von Testmanagement-Tools verwalten, oder man erstellt sie einfach in einer Tabelle. Tools unterstützen die Verwaltung der Testfälle und bieten meist Funktionen zur Ausführung und Dokumentation der Testfälle. Für den Einsteig – und um das Prinzip zu erläutern – verzichte ich erst mal auf ein konkretes Tool und begnüge mich mit einer Testfallbeschreibung in Tabellenform.

Testfall IDBeschreibungAktionSoll-Verhalten
 
 
 

Beispiel:
Eine Website verfügt über einen geschlossenen Bereich, den man nur nach Login mit Benutzername und Passwort aufrufen kann. Gibt man nicht die korrekten Zugangsdaten ein, soll der Login fehlschlagen und eine entsprechende Fehlermeldung angezeigt werden.

Testfall IDBeschreibungAktionSoll-Verhalten
TF_001Login mit falschem PasswortEinen gültigen Benutzernamen sowie ein falsches Passwort eingeben und auf ,Login‘ klicken.Der Login schlägt fehl. Es wird folgender Hinweis ausgegeben: „Login fehlgeschlagen! Bitte überprüfen Sie Benutzernamen und Passwort“
TF_002Login mit ungültigem BenutzernamenEinen ungültigen Benutzernamen sowie ein beliebiges Passwort eingeben und auf ,Login‘ klicken.Der Login schlägt fehl. Es wird folgender Hinweis ausgegeben: „Login fehlgeschlagen! Bitte überprüfen Sie Benutzernamen und Passwort“
TF_003Login mit korrektem PasswortEinen gültigen Benutzernamen sowie das dazugehörige richtige Passwort eingeben und auf ,Login‘ klicken.Der Login ist erfolgreich. Es wird die Startseite des geschlossenen Bereichs angezeigt.

Unter Umständen erfordern manche Funktionen des Systems gewisse Vorbedingungen, die auch der Tester kennen muss, damit er diese vor Ausführung des Tests herstellen kann. Beispiel: Login mit einem gesperrten Benutzer soll fehlschlagen.
Dazu kann man die Tabelle um eine Spalte erweitern:

Testfall IDBeschreibungVorbedingungAktionSoll-Verhalten
TF_004Login mit gesperrtem Benutzergesperrter Benutzer im System vorhandenDen gesperrten Benutzernamen sowie das dazugehörige richtige Passwort eingeben und auf ,Login‘ klicken.Der Login schlägt fehl. Es wird folgender Hinweis ausgegeben: „Benutzer gesperrt. Wenden Sie sich an den Administrator“

Die Testfälle sollten unmissverständlich die auszuführenden Schritte beschreiben, so dass der Tester den Testfall bei jeder Ausführung gleich ausführt und vergleichbare Ergebnisse erhält. Dem entgegen steht der Aufwand, der für Erstellung und Pflege sehr detaillierter Testfälle erforderlich ist. Für die Abwägung der optimalen Detailtiefe können u.a. folgende Aspekte hilfreich sein: Wie erfahren ist der Tester? Müssen die Testfälle auch für Projektfremde verständlich sein? Worauf genau legt man den Fokus beim Testen (vgl. Anforderungen!)?

Ausführung und Dokumentation

Obige Tabelle kann um zwei Spalten „Testergebnis“ und „Bemerkung“ erweitert werden und dann zur Testdokumentation dienen: Erfolgreiche Tests werden abgehakt oder grün markiert; fehlgeschlagene Tests werden rot markiert, wobei die genaue Fehlerwirkung dann im Bemerkungsfeld erfasst werden kann (oder ID/Verweis auf Bugtracking-System).

Schwierig wird dieses dateibasierte System ab einer gewissen Projektgröße, wenn mehrere Leute daran arbeiten oder wenn sich Anforderungen und Testfälle im Projektverlauf häufig ändern. Dann sollte man ggf. überlegen, auf ein Tool zur Testfallverwaltung zurückzugreifen.


Kommentieren ist momentan nicht möglich.