Requirements Testing Big Data

Wie User-Storys Requirements Engineers und Tester näher zusammenbringen

Use-Case und User-Story, das klingt ähnlich – was ist da der Unterschied? Was davon ist besser geeignet, um Anforderungen zu beschreiben? Wenn man schaut, welches Konstrukt wie häufig angewendet wird, scheint die Sache klar: Früher hat man Use-Cases genommen, heute sind User-Storys deutlich verbreiteter. Hier werden beide kurz erläutert, gegeneinander abgegrenzt, um schließlich darzulegen, warum Use-Cases – aus Requirements-Sicht – immer noch sinnvoll sind und wie diese mit den User-Storys zusammenspielen können. Aus Test-Sicht ergeben sich allerdings beim agilen Vorgehen daraus Herausforderungen, die schließlich zur Frage führen: Was bleibt den Testern noch an Arbeit, wenn die Anforderungen keine feste Basis für Testfälle mehr bilden?

Marcus Winteroll

Author

27.05.2022
Lesezeit: 11 Minuten
123 Views

Um die Verwechslungsgefahr durch die ähnlichen Namen auszuräumen, werden die Use-Cases im Folgenden mit ihrem deutschen Namen „Anwendungsfall“ bezeichnet. Und um beim Anwendungsfall zu bleiben: Was ist damit eigentlich gemeint, welche Idee steckt dahinter? Im Kern geht es darum zu beschreiben, wie die Nutzer ein System verwenden können, um einen bestimmten Zweck zu erreichen [Jac92]. Wenn Sie sich überlegen, wozu beispielsweise ein Geldautomat verwendet wird, wird Ihnen sicher sofort „Geld abheben“ einfallen oder auch „Kontostand abfragen“ und „PIN ändern“. Das sind typische Verwendungen des Systems Geldautomat und damit genau das, was ein Anwendungsfall beschreibt.

Anwendungsfälle

Wichtig bei Anwendungsfällen: Das gewünschte Ergebnis sollte auch einen Grund für den Nutzer darstellen, das System zu verwenden. Bei „Geld abheben“ stellt das gewünschte Ergebnis, also „der Bankkunde hat Geld“, einen solchen Grund dar. Dafür lohnt es sich, zum Geldautomaten zu gehen.

In der Praxis werden Anwendungsfälle aber häufig missbraucht, um einfach eine Funktion zu bezeichnen, also etwa „Als Bankkunde autorisieren“. Zweifellos sollte ein Geldautomat über diese Funktion verfügen, aber das Ergebnis „der Kunde ist autorisiert“ stellt keinen plausiblen Grund dar, das System zu benutzen – wer geht schon zum Automaten, nur um sich als Bankkunde zu autorisieren, und kehrt dann zufrieden wieder heim? Dies bildet hier nur ein Mittel zum Zweck, etwa um Geld abzuheben oder den Kontostand abzufragen.

Kennt man alle oder wenigstens die wichtigsten Anwendungsfälle eines Systems, hat man einen guten Überblick, wofür das System dienen soll.

User-Storys

Anders dagegen die User-Storys: Diese sind kaum geeignet, einen Überblick darüber zu geben, wofür ein System verwendet werden soll. Aber das ist auch nicht ihre Aufgabe!

User-Storys haben durchaus Ähnlichkeiten zu Anwendungsfällen: Auch hier wird beschrieben, wie die Nutzer das System verwenden, um einen Zweck zu erreichen. Meist wird die folgende Satzschablone genutzt [Coh04]:

Als <Nutzer>
möchte ich <etwas tun>,
um <ein Ziel zu erreichen>.

Ein Beispiel hierfür wäre:

Als Bankkunde
möchte ich meinen Kontostand sehen,
um zu entscheiden, was ich mir leisten kann.

Oder

Als Bankkunde
möchte ich auswählen, aus welchen Scheinen sich die Auszahlungssumme zusammensetzt,
um möglichst passende Scheine für meine Bezahlvorgänge zu haben.

Das erste Beispiel entspricht dem zuvor genannten Anwendungsfall „Kontostand abfragen“; das zweite ist jedoch sehr viel kleinteiliger und wäre ein Teil vom Anwendungsfall „Geld abheben“. Damit wird ein wichtiger Unterschied zwischen User-Storys und Anwendungsfällen deutlich: Während diese immer eine eigenständige Verwendung bilden, können jene sehr kleine und sehr große Verwendungsszenarien beschreiben. Allerdings ist auch hier wichtig, dass am Ende ein Ergebnis erreicht wird, das dem Nutzer einen Mehrwert bietet; zum Beispiel die passenden Geldscheine ausgewählt zu haben. Aber das ist natürlich nur ein Zwischenergebnis, denn letztlich geht der Nutzer zum Automaten, um das Geld auch zu bekommen, nicht um Scheine auszuwählen.

Die unterschiedlichen Einsatzzwecke

Dieser Unterschied rührt von der Rolle der User-Storys im agilen Entwicklungsprozess: Als Product-Backlog-Einträge sollen sie nicht nur Anforderungen beschreiben, sondern zudem bezüglich des Entwicklungsaufwands die passende Größe haben, damit sie gut in eine Iteration alias Sprint passen. Was immer man jetzt als passende Größe betrachtet, diese ergibt sich nicht aus analytischen oder fachlichen Gründen, sondern aus Planungsaspekten. Daher sind User-Storys nicht gut geeignet, um einen Überblick über die Verwendung des Systems zu geben, denn um die Planung zu unterstützen, müssen sie eher kleinteilig sein.

Der Umfang eines Anwendungsfalls dagegen ist durch rein fachliche Betrachtungen bestimmt, Planungsaspekte spielen hier keine Rolle. Das ist auch einer der Gründe, warum Anwendungsfälle als Product-Backlog-Einträge nicht geeignet sind.

Anwendungsfälle und User-Storys haben also unterschiedliche Vor- und Nachteile. Daher eignen sie sich für unterschiedliche Zwecke:

Anwendungsfälle sind die richtigen Konzepte, um einen Überblick zu bekommen, welche Nutzer das System für welchen Zweck einsetzen wollen.
User-Storys sind das passende Konstrukt, um Anforderungen so aufzuteilen, dass sie gut in einen Sprint passen, ohne ihren fachlichen Wert zu verlieren.

In der Systementwicklung werden aber beide Aspekte benötigt: Kunde, Entwicklungsteam und weitere Stakeholder sollten sich selbstverständlich einen Überblick darüber verschaffen, wer das System nutzen soll und für welche Zwecke. Und genauso wichtig ist es, für die Planung der Sprints Product-Backlog-Einträge zu haben, die nicht zu groß sind, aber trotzdem noch einen fachlichen Wert haben. Die Schlussfolgerung, Anwendungsfälle und User-Storys gemeinsam zu nutzen, liegt nahe – nur braucht es dafür eine sinnvolle Methode, beides zu kombinieren. Eine solche soll im Folgenden beschrieben werden.

Wie sich Anwendungsfälle und User-Storys kombinieren lassen

Ein Vorgehen, um die Anforderungen mithilfe von Anwendungsfällen und User-Storys in einer agilen Entwicklung zu erarbeiten und umzusetzen, kann so aussehen:

Die Produktvision bestimmen.
Die Anwendungsfälle des Systems identifizieren (z. B. mit einer Story Map).
Die nächsten Releases planen.
Das Product Backlog befüllen.
Den ersten Sprint vorbereiten („Backlog Refinement“).
Ausgewählte Anforderungen umsetzen.
Parallel das Product Backlog verfeinern, um die nächsten Sprints vorzubereiten („Backlog Refinement“).

Es würden den Rahmen sprengen, all diese Schritte hier zu beschreiben. Der Schwerpunkt soll in der Identifikation der Anwendungsfälle liegen und wie sich daraus die User-Storys für das Product Backlog ableiten lassen. Das gesamte oben beschriebene Vorgehen können Sie in [Win21] nachlesen. Dort wird zusätzlich beschrieben, wie auch noch die nicht-funktionalen Anforderungen integriert werden können.

Eine Story Map ist ein sehr hilfreiches Instrument, um die Anwendungsfälle eines Systems zu identifizieren. Damit werden die Abläufe, welche das System unterstützen soll, grob skizziert. So wie Jeff Patton die Story Map in seinem Buch „User Story Mapping“ [Pat14] beschreibt, hat der Storymapper viel Spielraum, die passende Abstraktionsebene für die Schritte zu wählen. Daher spricht nichts dagegen, die Story Map mit Anwendungsfällen zu kombinieren: Diese bilden dann die Schritte des beschriebenen Ablaufs (vgl. Abbildung 1). Die Sicht auf den geschäftlichen Ablauf hilft, die Anwendungsfälle zu identifizieren und abzuschätzen, ob das Gesamtbild vollständig ist. Zudem ordnet die fertige Story Map die Anwendungsfälle in den Kontext des Ablaufs ein und erleichtert deren Verständnis.

Abb. 1: Eine Story Map für ein Auktionssystem

Bei einer agilen Vorgehensweise sollten Sie der Versuchung widerstehen, bereits alle Details auf die Story Map zu bringen, denn dann sind Sie wieder dabei, die Anforderungen vorab umfassend zu analysieren. Zu Beginn reicht es meist, die Anwendungsfälle identifiziert zu haben. Wer es dann etwas genauer wissen will, darf gerne noch eine Kurzbeschreibung pro Anwendungsfall spendieren. Die Detailebene der Story Map kann bei Bedarf noch genutzt werden, um Details festzuhalten, über die während der Identifikation der Anforderungen gestolpert wird, oder um gezielt einzelne kritische Anwendungsfälle explorativ zu detaillieren. Auf keinen Fall sollten sämtliche Details zu den Anwendungsfällen auf der Story Map erscheinen!

Auf der Basis der Story Map können auch sehr gut die Releases geplant werden. Wie das funktioniert, können Sie in [Win21] nachlesen; das mögliche Ergebnis könnte aussehen wie in Abbildung 2. Mit der Story Map haben Sie nun eine gute Basis, um das Product Backlog zu befüllen. Machen Sie einfach aus den Anwendungsfällen User-Storys. Im Ergebnis befinden sich nun alle bekannten Anforderungen im Product Backlog. Allerdings werden die User-Storys in der Regel noch viel zu groß sein, um gut in einen Sprint zu passen. Daher ist vor der ersten Sprint-Planung noch die erste Backlog-Pflege („Backlog Refinement“) fällig, um die wichtigsten User-Storys durch kleinere zu ersetzen.

Abb. 2: Story Map mit Releaseplanung

Die Story Map mit den Anwendungsfällen hat aber damit noch nicht ausgedient, sie wird weiterhin benötigt, um auch im weiteren Entwicklungsprozess den Blick auf das Ganze zu ermöglichen und den Kontext für die User-Storys herzustellen.

Das Zusammenspiel der Story Map mit den Anwendungsfällen auf der einen und dem Product Backlog mit den User-Storys auf der anderen Seite ist in Abbildung 3 dargestellt. Hierdurch können Sie die Stärken beider Konzepte nutzen, um einerseits ein Gesamtverständnis des Systems zu erarbeiten und sicherzustellen sowie andererseits die iterative Umsetzung handhabbarer Anforderungen agil zu planen.

Abb. 3: Zusammenspiel der Anwendungsfälle mit den User-Storys

Die gemeinsame Zukunft von Analyse und Test

Durch das hier beschriebene agile Zusammenspiel von Anwendungsfällen, Story Map und User-Storys ergeben sich für das Testen ein paar Herausforderungen, denn die Anwendungsfälle werden dabei nicht so detailreich spezifiziert wie beim klassischen Vorgehen. Und User-Storys hatten nie den Anspruch, eine detaillierte Anforderungsbeschreibung zu sein. Auf welcher Basis soll also zukünftig getestet werden?

Die Testverantwortlichen werden sich von der Idee verabschieden müssen, dass ihnen jemand fertige Anforderungen als Testgrundlage serviert! Anwendungsfälle und User-Storys sind nicht als strenge Vorgaben für Test und Umsetzung zu verstehen, sondern stecken nur einen Rahmen ab, den das gesamte Scrum-Team gemeinsam ausarbeiten muss. Als Ergebnis liefert es neben der Software unter anderem auch Testfälle. Diese dienen aber nicht nur der abschließenden Verifikation, sondern bereits auf dem Weg dorthin der Analyse und der Validierung. Sie sind dann selber ein Teil der Spezifikation.

Praktisch bedeutet das: Requirements Engineering und Testen müssen noch enger verzahnt werden. Damit stellt sich die Frage, ob es noch zwei unterschiedliche Rollen braucht. Aus Scrum-Sicht ist diese Frage klarerweise mit nein zu beantworten, denn Scrum kennt ohnehin hierfür nur die Rolle „Developer“. Auf jeden Fall hat es verschiedene Vorteile, im Umsetzungsteam eher Generalisten als Spezialisten zu haben, unter anderem weil sich so die Arbeitslast im Team besser verteilen lässt.

Ein nahe liegender Schritt hin zur Generalisierung sollte daher sein, dass Requirements Engineers sich die Techniken des Testens aneignen – und Tester sich die Techniken des Analysierens. Für agile Teams wären das auf jeden Fall ein Gewinn.

Was den Zuschnitt von Rollen und Verantwortlichkeiten betrifft, lässt sich in viele Richtungen denken: Es könnten auch die bekannten Rollen erhalten bleiben und diese einfach eng zusammenarbeiten. Was aber in einer agilen Welt nicht mehr funktionieren wird: feste Anforderungen, die nur noch zu verifizieren sind. Werden die Anforderungen fixiert, ist ein Projekt nicht mehr agil. Das kann nur noch in Umgebungen funktionieren, die so stabil sind, dass sie nicht ständig auf neue Herausforderungen reagieren müssen.