Geht es um die Anforderungsanalyse, denken viele in erster Linie an die Aufgaben der Business Analysten. Im Austausch mit den Key Usern identifizieren, analysieren und priorisieren sie die Requirements an Prozesse und IT-Systeme.

 

Doch die Analyse der Anforderungen hat noch eine weitere Dimension. Dass das Requirement Engineering dabei strikt vom Testing getrennt werden muss, wird jedoch häufig falsch verstanden. Denn Anforderungsmanagement und Testing sind zwei Seiten derselben Medaille. Und Testanalysten können in dieser Phase maßgeblich dazu beitragen, potenzielle Fehler – und die entsprechenden Kosten – frühzeitig zu vermeiden.

 

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.

Anforderungsanalyse: Kosten eines Softwarefehlers

Praxisbeispiel:

User Stories durch die Brillen von Business- und Testanalysten

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:

Als User möchte ich eine Datei an meinen Kunden anhängen, um alle Informationen an einem Ort zu sammeln.

Testanalyst:

Als User möchte ich eine Datei an meinen Kunden anhängen, um alle Informationen an einem Ort zu sammeln.

Welcher User genau soll das im System machen? Hier wurden die Rollen und Rechte nicht berücksichtigt.

Um welche Dateitypen handelt es sich? Würde die User Story ohne Spezifikationen (z.B. Word- oder Excel-Dateien) umgesetzt, könnte es zu Fehlern kommen, die eine nachträgliche Anpassung erfordern.

Auch hier wurde der „Kunde“ nicht näher spezifiziert. Muss ggf. zwischen Anwendern im B2B- oder B2C-Bereich unterschieden werden? Gibt es weitere relevante  Anwender? Die mangelnde Differenzierung könnte zu vermeidbaren Fehlern führen.

Bereinigte User Story:

Als Salesmanager möchte ich eine Excel-File an meinen B2C-Kunden anhängen, um alle Informationen an einem Ort zu sammeln.

Schluss mit unnötigen Entwicklungsrunden!

Unser Beispiel zeigt:

Schon beim Definieren einer Anforderung können Fehlerquellen mit schwerwiegenden Folgen entstehen.

Durch den frühzeitigen Einsatz unserer Testanalysten lassen sich diese Stolpersteine bereits im Vorfeld identifizieren

und kostengünstig beseitigen. Kunden ersparen sich auf diese Weise unnötige Entwicklungsrunden

– und können von Anfang an mit einer fehlerfreien Software arbeiten.

Unsere Referenzen

Ihr Ansprechpartner

Daniel Loderer

Daniel Loderer

+49 151 6294 5816

Insights aus dem Blog

Software-Qualitätssicherung: Mehr als nur Testen

Beim Thema Qualitätssicherung oder Qualitätsmanagement denken viele sofort an Materialprüfung in der Produktion. Im Softwarebereich wird das Testen von Software oft als gleichwertiges Äquivalent angesehen. Dabei ist Software-Qualitätssicherung weit mehr als stumpfes Testen. In diesem Blogbeitrag zeigen wir auf, wie Software-Qualitätssicherung den Projekterfolg von Anfang bis Ende entscheidend beeinflusst und welche Vorteile sie bietet.

Softwarequalität: Wie sie wirklich entsteht

Ein allzu typischer Fall: Das Projekt läuft. Die Software ist entwickelt. Jetzt noch schnell durch die Testphase, um Qualität in das Produkt zu bekommen. Doch ist das der richtige Weg? Erreichen wir Softwarequalität alleine dadurch, indem wir die Software testen? Und: Ist die Testphase tatsächlich die einzige Prozessphase, in der sich Qualität erzeugen lässt?

Testautomatisierung: Qualität noch effizienter sichern

Mit der voranschreitenden digitalen Transformation steigen auch die Anforderungen der Kunden hinsichtlich Funktionalität, Benutzerfreundlichkeit, Performance und Verfügbarkeit einer Software. Um diese Erwartungen zu erfüllen, sind Unternehmen darauf angewiesen, qualitativ hochwertige Software in immer kürzeren Zeiten zu liefern.

Geht es um die Anforderungsanalyse, denken viele in erster Linie an die Aufgaben der Business Analysten. Im Austausch mit den Key Usern identifizieren, analysieren und priorisieren sie die Requirements an Prozesse und IT-Systeme. Doch die Analyse der Anforderungen hat noch eine weitere Dimension: Anforderungsmanagement und Testing sind zwei Seiten derselben Medaille.