Anforderungsanalyse

CX Services Software Quality Assurance

So können sich bereits während der Erstellung der Anforderungen – z. B. in Form von User Stories – weitreichende Fehlerquellen einschleichen. Oft werden hier etwa Begrifflichkeiten verwendet, die im ersten Moment hinreichend klar erscheinen. Sobald es jedoch um die Testbarkeit geht, wird deutlich, dass sie eben nicht exakt genug definiert wurden. (Beispiel: siehe unten)

Testanalysten sind dank ihrer Expertise in der Lage, diese Art von Fehlern frühzeitig zu erkennen und bereits während der Anforderungsanalyse zu beheben. Der entscheidende Vorteil dieser Vorgehensweise: Sie ist äußerst kostengünstig. Denn wenn ein Fehler erst im Testsystem auffällt, müssen sämtliche vorhergehenden Phasen noch einmal durchlaufen werden.

Das bedeutet: Der Fehler wird in Defect Calls besprochen, von den Business Analysten im Nachgang analysiert, Anpassung werden vorgenommen und an den Entwickler weitergegeben. Nach der erneuten Entwicklungsarbeit wird der Fix dann mit einer neuen Version auf das Testsystem aufgespielt, um schließlich vom Testanalysten bestätigt zu werden …

Die folgende Grafik zeigt, wie extrem die Kosten für die Behebung von Fehlern steigen, je später sie identifiziert werden – bzw. wie hoch das Einsparpotenzial durch frühzeitige Fehlererkennung ist.

Wie aber unterscheidet sich die Sichtweise eines Testanalysten von der eines Business Analysten? Aufschluss gibt hier ein Beispiel aus unserer Praxiserfahrung. Dabei handelt es sich um eine Anforderung eines Kunden, der ein neues CRM-System einführen möchte, um seinen Sales-Prozess zu optimieren.

Der elementare Unterschied zwischen den Sichtweisen: Business Analysten betrachten eine User Story im Gesamten. Ihr Fokus liegt dabei auf dem Ziel und den Weg dorthin. Testanalysten betrachten die User Story aus der Perspektive der Qualitätssicherung. Auf der Suche nach potenziellen Fehlerquellen betrachten sie jedes Detail.

Business Analyst: