So dokumentieren Sie Ihre Designs mit verhaltensgesteuerten User Stories

() translation by (you can also view the original English article)

Ein häufiges Problem bei der Dokumentation von Anforderungen besteht darin, einen Standpunkt aus der Systemperspektive einzunehmen, um zu beschreiben, was benötigt wird, und zu vergessen, dass der Benutzer im Mittelpunkt der Interaktionen steht. User Stories, die von Agile eingeführt wurden, gehen dieses Problem an, indem sie den Benutzer in den Mittelpunkt der Anforderung stellen, und Behavior Driven Development (BDD) geht noch einen Schritt weiter und bietet einen Rahmen, bei dem das Benutzerverhalten die Entwicklung antreibt.

Die Verwendung von BDD-Techniken zum Erstellen von User Stories erleichtert das Schreiben und Lesen von Dokumentanforderungen. Außerdem bietet es zusätzliche Tools, um die beabsichtigte Benutzererfahrung eines Designs zu kommunizieren, die Designer, Entwickler und QA-Ingenieure verwenden können, um einen Teil ihrer Arbeit zu beschleunigen und sogar zu automatisieren. In diesem Artikel werde ich diesen Ansatz untersuchen und zeigen, wie Sie damit Ihre eigenen Designs dokumentieren können, angefangen bei kleinen Geschichten bis hin zur Organisation dieser Geschichten, um voll funktionsfähige Funktionen zu kommunizieren.

UI-Anforderungen vs. UX-Anforderungen

Es gibt einen wichtigen Unterschied zwischen UI-Anforderungen (auch als Spezifikationen bezeichnet) und UX-Anforderungen. Einerseits sind UI-Anforderungen technische Dokumente, die Besonderheiten der Benutzeroberfläche auflisten, einschließlich Schriftarten, Farben, Abmessungen und Layout von Elementen. Ein gutes Beispiel für diese Art von Dokumentation sind Living Style Guides.

UX-Anforderungen hingegen beschreiben, wie die Erfahrung für einen bestimmten Benutzer aussehen sollte, da dieser Benutzer in einem bestimmten Szenario eine bestimmte Aktion durchführt. Eine User Story kann eine UX-Anforderung sehr prägnant erfassen. Zum Beispiel:

Als.. Publisher-Benutzer,
Ich möchte.. Artikel überprüfen können, bevor sie veröffentlicht werden,
Damit.. ich zeitnah Feedback geben und die Qualität sicherstellen kann.

Diese Geschichte zeigt zuerst die Rolle des Benutzers, was dieser Benutzer erreichen möchte, und erklärt dann den Grund dafür. Das ist großartig, da es Entwicklern und Testern einen Einblick in das ultimative Ziel gibt: ein Benutzerbedürfnis zu befriedigen. Beachten Sie, dass die fettgedruckten Wörter die Vorlage sind, die zum Schreiben der Geschichte verwendet wird. Es gibt immer einen Benutzer, der etwas tun möchte, damit er ein bestimmtes Ziel erreichen kann. Sie können diese Tipps befolgen, um gute User Stories zu schreiben.

Vor diesem Hintergrund kann das Designteam entscheiden, dass eine „Genehmigung“-Aktion erforderlich ist, um das Ziel des Benutzers zu erreichen. Dann können Sie die Gherkin-Syntax verwenden, die ein BBD-Tool zum Schreiben von geschäftlich lesbaren Anforderungen ist, um Einzelheiten zur tatsächlichen Funktionsweise bereitzustellen. Die Gherkin-Syntax ähnelt agilen User Stories, da sie eine Möglichkeit bietet, Anforderungen zu schreiben, die auch als Vorlage verwendet werden können. Der Vorteil besteht darin, dass Sie genauere Informationen erhalten und Szenarien und Aktionen bereitstellen können, die der Benutzer ergreifen würde, ohne sich mit der Implementierung zu befassen. Schauen wir es uns genau an.

Schreiben von User Stories mit der Gherkin-Syntax

Die Grundlagen einer Geschichte mit Gherkin Syntax lassen sich in diesen Teilen zusammenfassen:

Eine Eigenschaft
Ein Szenario
Eine Voraussetzung
Eine Handlung
Ein Ergebnis

Ein Feature ist ein Ort, um den gesamten Geschäftswert der Implementierung zu beschreiben. Es kann auch verwendet werden, um zusätzliche Informationen bereitzustellen, z. B. Geschäftsregeln oder alles, was das Verständnis der Funktion erleichtert (z. B. Links zu Prototypen oder UI-Anforderungen).

Ein Szenario beschreibt die spezifischen Umstände, in denen sich der Benutzer befindet. Aus Sicht des Benutzerdesigns ermöglichen Szenarien die Kommunikation der mehreren Variablen eines Designs und wie die Benutzeroberfläche diese je nach Benutzer handhaben sollte.

Eine Vorbedingung hilft beim Aufbau des Szenarios und beseitigt jede Mehrdeutigkeit. In einem Szenario, das beispielsweise beschreibt, dass ein Benutzer zum ersten Mal auf einen bestimmten Bildschirm zugreift, kann die Vorbedingung klarstellen, dass der Benutzer angemeldet ist.

Eine Aktion gibt genau an, was der Benutzer in der Benutzeroberfläche tut, und ist normalerweise ein „Trigger“, wie zum Beispiel das Klicken auf eine Schaltfläche, das Absenden eines Formulars oder das Navigieren zu einem anderen Ort.

Ein Ergebnis ist die Konsequenz der Handlung und sollte immer etwas sein, das getestet werden kann.

Lassen Sie uns unter Berücksichtigung dieser Teile eine User Story für die zuvor beschriebene Funktion schreiben:

Als.. Publisher-Benutzer,
Ich möchte.. Artikel überprüfen können, bevor sie veröffentlicht werden,
Damit.. ich zeitnah Feedback geben und die Qualität sicherstellen kann.

Mit der Gherkin-Syntax würde diese Geschichte so aussehen:

Besonderheit	Erlauben Sie Verlagen, Artikel vor der endgültigen Veröffentlichung zu überprüfen und ihnen ihre Genehmigung zu stempeln.
Szenario	Genehmigen eines Artikels, der zur Veröffentlichung bereit ist.
Voraussetzung	Vorausgesetzt, der Autor hat einen Artikel zur Veröffentlichung eingereicht. und der Verlag hat auf die Artikelbearbeitungsansicht zugegriffen
Handlung	wenn der Publisher "genehmigen" auswählt
Ergebnis	dann wird der Artikel zum geplanten Termin veröffentlicht und der Verlag sieht eine Erfolgsmeldung, die angibt, dass der Artikel erfolgreich veröffentlicht wurde und der Artikel wird als "genehmigt" markiert und es wird eine Benachrichtigung an den Verfasser gesendet, die angibt, dass sein Artikel genehmigt wurde.

Sie können sehen, wie die anfängliche Geschichte zu einem detaillierteren Fluss wird, dem der Benutzer folgen kann und der somit getestet werden kann. Beachten Sie auch, dass die fettgedruckten Wörter die Schlüsselwörter sind, die Software wie Gurke verwendet, um die Ausführung von Tests zu automatisieren. Ich werde später mehr dazu erklären, aber vorerst möchte ich darauf hinweisen, dass diese Schlüsselwörter auch für das Schreiben der Geschichte sehr hilfreich sind, da sie helfen, die verschiedenen Teile der Geschichte zu unterscheiden.

Es ist noch darauf hinzuweisen, dass die Geschichte zwar mehr Details zum Benutzerfluss enthält, die Benutzeroberfläche jedoch nicht beschrieben wird. Der Grund dafür ist, dass die Beschreibung der Benutzeroberfläche die Geschichte schnell in UI-Anforderungen verwandeln kann, was ein großes Problem darstellt, da sie ziemlich schnell veraltet sein können. Wenn die Story beispielsweise beschreibt, wie die Erfolgsmeldung aussieht und was die spezifische Nachricht sagen soll, kann die Story bei einer Änderung nicht mehr synchron sein, wodurch die Möglichkeit besteht, dass Tests fehlschlagen.

Der Trick besteht also darin, genügend Details bereitzustellen, ohne die Arbeit von adäquateren Tools wie Designmodellen, Prototypen und Styleguides zu übernehmen. In dieser Hinsicht werden Sie feststellen, dass die Aktion "Genehmigen auswählen" anzeigt, anstatt nur "Genehmigen" zu verwenden. "Genehmigen auswählen" ist nicht spezifisch für das Aussehen dieses Steuerelements (es kann eine Schaltfläche, eine Schaltfläche, die wie ein Link aussieht, oder ein anklickbares Feld sein), aber es bedeutet, dass ein Element in der Benutzeroberfläche ausgelöst wird. Es zeigt auch an, dass dieses Element "genehmigen" geschrieben hat. Dies ist eine Grauzone, in der Sie Ihren gesunden Menschenverstand anwenden müssen, da Sie in einigen Fällen so spezifisch sein möchten, damit Aktionen von anderen unterschieden werden können. Wenn es beispielsweise eine andere Möglichkeit gibt, einen Artikel auf derselben Seite zu genehmigen, ermöglicht dies die Unterscheidung, dass der Benutzer ihn in diesem Szenario „auswählen“ muss.

Die Bedeutung von Szenarien

Neben der durchdachten Syntax, die Gherkin bietet, finde ich eines der nützlichsten Dinge die Verwendung des Teils „Szenarien“. Szenarien sind mächtig, weil sie verwendet werden können, um das Design zu testen und sicherzustellen, dass alle Grundlagen abgedeckt sind.

Normalerweise beginnen Designs jeglicher Art mit dem „Happy Path“, d. h. was passiert, wenn in der Benutzeroberfläche alles gut läuft und wie es auf die Mehrheit der Benutzer zutrifft. In unserem vorherigen Beispiel hatten wir:

Szenario

Genehmigen eines Artikels, der zur Veröffentlichung bereit ist.

Da wir wissen, dass Artikel ein Veröffentlichungsdatum haben, können wir auch sagen: Dies ist unser erstes Szenario, da in den meisten Fällen Artikel, die genehmigt werden müssen, zur Veröffentlichung bereit sein sollten. Damit stellt sich aber die Frage: Was passiert, wenn ein Artikel nicht publikationsreif ist und der Verlag darauf zugreift? Sollten sie überhaupt auf diese Artikel zugreifen können?

Was würde passieren, wenn ein genehmigter Artikel ein Veröffentlichungsdatum in der Vergangenheit hat? Soll der Artikel sofort veröffentlicht oder in eine Warteschlange gestellt werden?
Und noch einen Schritt weiter: Was ist, wenn ein Verlag einen Artikel aus Versehen freigibt? Wie wird diese Aktion rückgängig gemacht? Wer soll benachrichtigt werden?

All diese Fragen sind Teil des Designprozesses und höchstwahrscheinlich kennen Sie die Antworten, wenn Sie sich mit den Dokumentationsanforderungen befassen. Die gute Nachricht ist, dass die Verwendung von Szenarien in Ihrer Story-Dokumentation Ihnen dabei hilft, diese zu strukturieren und in vielen Fällen Ihnen bei der Qualitätssicherung Ihrer eigenen Designs hilft, um sicherzustellen, dass für jedes von ihnen ein Design und ein Ablauf vorgesehen sind.

Sehen wir uns an, wie unsere Geschichte mit den zusätzlichen Szenarien Gestalt annehmen würde:

Besonderheit	Erlauben Sie Verlagen, Artikel vor der endgültigen Veröffentlichung zu überprüfen und ihnen ihre Genehmigung zu stempeln.
Szenario 1	Genehmigen eines Artikels, der zur Veröffentlichung bereit ist. Da der Autor einen Artikel zur Veröffentlichung eingereicht hat und der Verlag hat auf die Ansicht zum Bearbeiten von Artikeln zugegriffen wenn der Publisher auf "genehmigen" klickt dann wird der Artikel zum geplanten Termin veröffentlicht und der Verlag sieht eine Erfolgsmeldung, die angibt, dass der Artikel erfolgreich veröffentlicht wurde und der Artikel wird als "genehmigt" markiert und eine Benachrichtigung wird an den Verfasser gesendet, die anzeigt, dass sein Artikel genehmigt wurde.
Szenario 2	Auf einen Artikel zugreifen, der nicht zur Veröffentlichung bereit ist. Wann ...
Szenario 3	Genehmigen eines Artikels, dessen Fälligkeitsdatum überschritten ist Wann ...
Szenario 4	Ablehnen eines Artikels mit einem Veröffentlichungsdatum in der Zukunft Wann ...
Szenario 5	Ablehnen eines veröffentlichten Artikels Wann ...

Je nach Funktion können viele Szenarien in Betracht gezogen werden. Wichtig ist, sie kurz zu halten, damit Sie sie leicht beschreiben und testen können. Sie können auch versuchen, sie mit gemeinsamen Nennern zu gruppieren. Wenn beispielsweise einige Szenarien dieselbe Vorbedingung haben, können Sie dies in einen „Hintergrund“ kapseln, der von mehreren Szenarien verwendet werden kann. Zum Beispiel:

Hintergrund	Der Autor hat einen Artikel zur Veröffentlichung eingereicht und der Herausgeber hat auf die Ansicht Artikel bearbeiten zugegriffen.
Szenario 1	Genehmigen eines Artikels, der zur Veröffentlichung bereit ist. Vorausgesetzt, der Hintergrund ist erfüllt Wenn ...
Szenario 2	Genehmigen eines Artikels, dessen Fälligkeitsdatum überschritten ist. Vorausgesetzt, der Hintergrund ist erfüllt Wenn ...
Szenario 3	Ablehnen eines Artikels mit einem Veröffentlichungsdatum in der Zukunft. Vorausgesetzt, der Hintergrund ist erfüllt Wenn ...

Organisieren von Geschichten, um ein Feature zu kommunizieren

Eine häufige Herausforderung bei der Dokumentation von Anforderungen besteht darin, zu entscheiden, in welcher Reihenfolge sie ausgeführt werden soll. Der Grund dafür ist, dass sich in den meisten Fällen alles im Aufbau befindet, was es schwierig macht, eine Interaktion zu testen, wenn die Teile der Interaktionen noch nicht gebaut sind. Bei der einfachen Interaktion zum „Genehmigen“ eines Artikels müssen beispielsweise viele Dinge vorbereitet werden:

Die Benutzeroberfläche sollte in der Lage sein, bei erfolgreicher Genehmigung eine Erfolgsmeldung und bei einem Systemproblem eine Fehlermeldung zurückzugeben.
Die Benutzeroberfläche sollte in der Lage sein, Artikel als genehmigt zu markieren.
Das UI sollte den Artikel gemäß der „veröffentlichten“ Geschäftslogik anzeigen können.
Systembenachrichtigungen sollten aktiviert sein, damit Autoren benachrichtigt werden können, wenn die Genehmigung erfolgt.

Ein Ansatz zur Dokumentation der Anforderungen für jede dieser Abhängigkeiten besteht darin, sie als verschiedene Funktionen aufzuzeichnen, die dann entsprechend ihrem Geschäftswert priorisiert werden können.

Besonderheit	Beschreibung	Priorität
Warnsystem	Die Benutzeroberfläche sollte in der Lage sein, eine Erfolgsmeldung sowie eine Fehlermeldung zurückzugeben, falls ein Systemproblem auftritt	2
Tagging-System	Die Benutzeroberfläche sollte in der Lage sein, Artikel als genehmigt zu markieren	4
Veröffentlichungssystem	Die Benutzeroberfläche sollte den Artikel gemäß der „veröffentlichten“ Geschäftslogik anzeigen können	1
Benachrichtigungssystem	Systembenachrichtigungen sollten aktiviert sein, damit Autoren benachrichtigt werden können, wenn die Genehmigung erfolgt	3

Dann können Sie eine „Integrationsgeschichte“ erstellen, um alle zusammenzubringen. Eine User Story für das Tagging-System sieht zum Beispiel so aus:

Besonderheit	Erlauben Sie Benutzern und dem System, Artikel nach einem bestimmten Status (nicht veröffentlicht, genehmigt, veröffentlicht oder archiviert) zu markieren.
Szenario 1	Markieren eines Artikels als unveröffentlicht. (Einzelheiten…)
Szenario 2	Markieren eines Artikels als genehmigt. (Einzelheiten…)
Szenario 3	Markieren eines Artikels als veröffentlicht. (Einzelheiten…)
Szenario 4	Markieren eines Artikels als archiviert. (Einzelheiten…)

In der Integrations-Story können Sie auf die Tagging-Story verweisen, falls die Details für dieses Szenario erneut verifiziert werden müssen oder Sie einfach wissen möchten, ob diese Fälle bereits verifiziert wurden.

Besonderheit

Erlauben Sie Verlagen, Artikel vor der endgültigen Veröffentlichung zu überprüfen und ihnen ihre Zustimmung zu stempeln.

Szenario 1

Genehmigen eines Artikels, der zur Veröffentlichung bereit ist.

Da der Autor einen Artikel zur Veröffentlichung eingereicht hat
und der Verlag hat auf die Ansicht zum Bearbeiten von Artikeln zugegriffen
wenn der Publisher auf "genehmigen" klickt
dann wird der Artikel zum geplanten Termin veröffentlicht
und der Verlag sieht eine Erfolgsmeldung, die angibt, dass der Artikel erfolgreich veröffentlicht wurde
und der Artikel wird als „genehmigt“ markiert (Referenzszenario 2 aus der Tagging-Story)
und es wird eine Benachrichtigung an den Verfasser gesendet, die angibt, dass sein Artikel genehmigt wurde.

Es geht darum, eine Wiederholung der Dokumentation zu vermeiden, die nicht nur unnötig Zeit beansprucht, sondern auch nicht mehr synchron sein kann.

Verwandeln Sie die User Stories in Testfälle

Wir haben gesehen, wie nützlich Behavioral Driven User Stories für das Schreiben von Anforderungen sein können, die fokussiert, prägnant, aber auch gründlich und beschreibend sind. Ab der Designphase kann dieses Tool QS-Ingenieuren eine gute Grundlage für das Schreiben von tatsächlichen Testfällen bieten.

Neben diesen großen Vorteilen können Behavioral Driven User Stories mit Hilfe von Software wie Gurke oder Salat tatsächlich in Funktionstests umgewandelt werden. Die Grundidee ist, dass Sie, sobald die Geschichten mit der Gherkin-Syntax geschrieben wurden, sie in einer .feature-Datei in Ihrer App platzieren und sie dann als Tests ausführen können, um zu zeigen, ob sie erfolgreich waren oder nicht. Ein ausführliches Tutorial zur Verwendung von Lettuce für eine Python-Implementierung finden Sie im Tutorial von David Sale:

Python

Verhaltensgesteuerte Entwicklung in Python

David Sale

Abschluss

Das Schreiben von User Stories nach den Prinzipien von BDD kann dazu dienen, Geschäfts- und Designanforderungen mit einem benutzerzentrierten Ansatz im Detail zu kommunizieren, während eine Sprache verwendet wird, die für Menschen lesbar ist, aber für die Softwareinterpretation erweiterbar ist. Außerdem kann es zum Testen verwendet werden:

Ihre eigenen Designs, während Sie Anforderungen dokumentieren
die eigentliche Anwendung manuell, sobald sie von einem QS-Ingenieur in Testfälle umgewandelt wurde
die eigentliche Anwendung automatisch, wenn sie mit der BDD-Software in Funktionstests umgewandelt wird.

Dies bedeutet, dass Fehler mehr Ebenen durchlaufen, Lücken im Design vermieden und Ihre Anwendung weiter vor Fehlern geschützt werden.