Antwort.

Die Anforderungstestung ist ein wichtiger Schritt im manuellen Testen, da Mängel hier zu teuren Fehlern in der Zukunft führen können.

Hintergrund:

In den frühen Phasen der Entwicklung werden die Anforderungen an das Produkt in Form von Dokumenten (Lastenheft, Spezifikationen) festgehalten. Ihre falsche oder unvollständige Gestaltung führt zu vielen Problemen in der Implementierungs- und Testphase.

Problem:

Anforderungen sind häufig unvollständig, mehrdeutig oder widersprüchlich. Dies führt zu Missverständnissen und einer mangelhaften Implementierung des Produkts. Der Tester muss solche Aspekte frühzeitig identifizieren.

Lösung:

Die manuelle Anforderungstestung umfasst:

Sorgfältige Prüfung der Anforderungen auf Vollständigkeit, Klarheit und Widersprüchlichkeit
Formulierung von klärenden Fragen an Analysten und Business-Interessensvertreter
Dokumentation aller angenommenen Nutzungsmöglichkeiten (positive/negative Fälle)
Anwendung von Analysetechiken für Anforderungen: Konsistenztabellen, Rückverfolgbarkeitsmatrizen, Checklisten für Anforderungen

Wichtige Aspekte:

Identifizierung von Widersprüchen und 'Löchern' - Aufdeckung von Diskrepanzen und Situationen, die in den Anforderungen nicht dargestellt sind
Aktive Kommunikation mit Analysten und dem Team - Klärung von Details, Erklärung von Formulierungen
Formulierung klarer, testbarer Anforderungen - Anforderungen sollten eindeutig, umsetzbar und messbar sein

Fangfragen.

Was bedeutet „eine Anforderung ist testbar“?

Eine testbare Anforderung ist eine solche Anforderung, bei der klar gesagt werden kann, ob sie im Produkt erfüllt ist oder nicht. Abstraktionen, allgemeine Phrasen und unklare Parameter sind nicht zulässig.

Kann man Anforderungen als qualitativ hochwertig betrachten, wenn sie nur den Autoren verständlich sind?

Nein. Qualitativ hochwertige Anforderungen müssen von allen Teammitgliedern (Entwicklern, Testern, Analysten, Business) eindeutig verstanden werden.

Liegt es in der Verantwortung des Testers, Anforderungen zu ergänzen oder zu korrigieren?

Nein, der Tester identifiziert Probleme und informiert die Verantwortlichen, sollte aber nicht eigenständig Anforderungen umschreiben.

Typische Fehler und Anti-Pattern

Anforderungen ohne Klärungsfragen zu akzeptieren
Kleinere Unstimmigkeiten und Annahmen zu ignorieren
Gefundene „Lücken“ und Widersprüche nicht zu dokumentieren, in der Hoffnung, dass „die Entwickler es schon klären werden“

Beispiel aus dem Leben

Negativfall

Der Tester erhielt Anforderungen, prüfte sie nicht auf Vollständigkeit und Konsistenz und achtete nicht auf mehrdeutige Formulierungen. Infolgedessen interpretierten die Entwickler diese Anforderungen unterschiedlich, und es traten nicht berücksichtigte Szenarien auf, die erst beim Release erkannt wurden.

Vorteile:

Zeitersparnis in der Phase der Anforderungsdokumentation

Nachteile:

Viele Korrekturen in späteren Phasen
Hohe Kosten für Bugfixing
Unzufriedenheit des Kunden

Positivfall

In der Phase der Einarbeitung in die Anforderungen stellte der Tester Fragen an den Business-Analysten, klärte strittige Punkte und half, negative Szenarien hinzuzufügen. Dadurch konnte eine Menge Missverständnisse vermieden und die Anzahl der Bugs beim Release erheblich reduziert werden.