Share
Ein häufig auftretendes Problem bei der Dokumentation von Anforderungen besteht darin, aus der Systemperspektive Stellung zu nehmen, um zu beschreiben, was erforderlich ist, und zu vergessen, dass der Benutzer im Mittelpunkt der Interaktionen steht. Mit Agile eingeführte User Storys gehen dieses Problem an, indem der Benutzer zum Mittelpunkt der Anforderung gemacht wird. Die BDD (Behavior Driven Development) geht einen Schritt weiter und bietet einen Rahmen, in dem das Benutzerverhalten die Entwicklung antreibt.
Die Verwendung von BDD-Techniken zum Erstellen von User Storys erleichtert das Schreiben und Lesen von Anforderungen. Darüber hinaus stellt es zusätzliche Tools bereit, um die beabsichtigte Benutzererfahrung eines Designs zu kommunizieren, mit der Designer, Entwickler und QS-Ingenieure einen Teil ihrer Arbeit beschleunigen und sogar automatisieren können. In diesem Artikel werde ich diesen Ansatz untersuchen und zeigen, wie Sie ihn verwenden können, um Ihre eigenen Entwürfe zu dokumentieren, angefangen von kleinen Geschichten bis hin zur Organisation dieser Geschichten, um voll funktionsfähige Funktionen zu kommunizieren.
Es ist ein wichtiger Unterschied zwischen UI-Anforderungen (auch als Spezifikationen bezeichnet) und UX-Anforderungen zu unterscheiden. Zum einen handelt es sich bei den Anforderungen an die Benutzeroberfläche um technische Dokumente, in denen die Besonderheiten der Benutzeroberfläche aufgeführt werden, einschließlich Schriftarten, Farben, Abmessungen und Layout von Elementen. Ein gutes Beispiel für diese Art von Dokumentation sind Living Style Guides.
Andererseits beschreiben die UX-Anforderungen, was die Erfahrung für a sein sollte Spezifisch Benutzer, da dieser Benutzer in einem bestimmten Szenario eine bestimmte Aktion ausführt. Eine User Story kann eine UX-Anforderung auf sehr kurze Weise erfassen. Zum Beispiel:
Diese Geschichte zeigt zuerst die Rolle des Benutzers an, was dieser Benutzer erreichen möchte, und erläutert dann den Grund dafür. Dies ist großartig, da es Entwicklern und Testern Einblick in das ultimative Ziel gibt: die Bedürfnisse eines Benutzers zu erfüllen. Beachten Sie, dass die fett gedruckten Wörter die Vorlage sind, die zum Schreiben der Geschichte verwendet wird. Es gibt immer einen Benutzer, der etwas tun möchte, damit er ein bestimmtes Ziel erreichen kann. Sie können diesen Tipps folgen, um gute User Storys zu schreiben.
Vor diesem Hintergrund kann das Designteam entscheiden, dass eine "Genehmigungsaktion" erforderlich ist, um das Ziel des Benutzers zu erreichen. Um genauer anzugeben, wie dies tatsächlich funktionieren wird, können Sie die Gherkin-Syntax verwenden, ein BBD-Tool zum Schreiben von Business-Readable-Anforderungen. Die Gurke-Syntax ähnelt agilen User Storys, da sie eine Möglichkeit zum Schreiben von Anforderungen bietet, die auch als Vorlage verwendet werden kann. Der Vorteil ist, dass Sie sich näher mit den Szenarien und Aktionen befassen können, die der Benutzer durchführen würde, ohne sich mit der Implementierung der Implementierung auseinanderzusetzen. Schauen wir uns das genauer an.
Die Grundlagen einer Geschichte mit Gherkin-Syntax können in diesen Teilen zusammengefasst werden:
Eine Eigenschaft ist ein Ort, um den gesamten geschäftlichen Wert der Implementierung zu beschreiben. Es kann auch verwendet werden, um zusätzliche Informationen bereitzustellen, z. B. Geschäftsregeln oder alles, was die Funktion leichter verständlich macht (z. B. Links zu Prototypen oder Anforderungen an die Benutzeroberfläche)..
Ein Szenario beschreibt die spezifischen Umstände, unter denen sich der Benutzer befindet. Aus Sicht des Benutzerentwurfs ermöglichen Szenarien die Kommunikation der mehreren Variablen eines Entwurfs und die Art und Weise, wie die Benutzeroberfläche diese je nach Benutzer behandeln soll.
Eine Voraussetzung hilft beim Aufbau des Szenarios und beseitigt jegliche Unklarheiten. In einem Szenario, das beispielsweise einen Benutzer beschreibt, der zum ersten Mal auf einen bestimmten Bildschirm zugreift, kann die Vorbedingung klarstellen, dass der Benutzer angemeldet ist.
Eine Handlung gibt genau an, was der Benutzer in der Benutzeroberfläche tut, und ist normalerweise ein "Auslöser", z. B. das Klicken auf eine Schaltfläche, das Senden eines Formulars oder das Navigieren an einen anderen Ort.
Ein Ergebnis ist die Folge der Aktion und sollte immer etwas sein, das getestet werden kann.
Lassen Sie uns im Hinblick auf diese Aspekte eine User Story für die zuvor beschriebene Funktion schreiben:
Mit der Gurken-Syntax würde diese Geschichte so aussehen:
| Merkmal | Erlauben Sie Publishern, Artikel vor der endgültigen Veröffentlichung zu überprüfen und ihnen die Genehmigung zu geben. |
| Szenario | Genehmigung eines Artikels, der zur Veröffentlichung bereit ist. |
| Voraussetzung |
|
| Aktion |
|
| Ergebnis |
|
Sie können sehen, wie aus der anfänglichen Geschichte ein detaillierterer Fluss wird, dem der Benutzer folgen kann und der daher getestet werden kann. Beachten Sie auch, dass die fettgedruckten Wörter die Schlüsselwörter sind, mit denen Software wie Gurke die Ausführung von Tests automatisiert. Ich werde später mehr dazu erklären, aber im Moment möchte ich darauf hinweisen, dass diese Schlüsselwörter auch beim Schreiben der Geschichte sehr hilfreich sind, da sie dazu beitragen, die verschiedenen Teile der Geschichte zu unterscheiden.
Zu beachten ist noch Folgendes: Obwohl die Story mehr Details zum Benutzerfluss enthält, wird die Schnittstelle nicht beschrieben. Der Grund dafür ist, dass die Beschreibung der Benutzeroberfläche die Story schnell in Anforderungen für die Benutzeroberfläche umwandeln kann, was ein großes Problem darstellt, da sie schnell veraltet werden können. Wenn in der Story beispielsweise beschrieben wird, wie die Erfolgswarnung aussieht und was in der jeweiligen Nachricht angegeben werden soll, kann die Story nicht mehr synchronisiert werden, wenn sich einer dieser Änderungen ändert, was dazu führen kann, dass Tests fehlschlagen.
Der Trick besteht also darin, genügend Details bereitzustellen, ohne dafür ausreichend geeignete Werkzeuge wie Entwurfsmodelle, Prototypen und Style-Guides zu benötigen. In diesem Zusammenhang werden Sie feststellen, dass die Aktion "Auswählen auswählen" und nur "Genehmigen" angibt. Bei der Auswahl von Genehmigen wird nicht genau festgelegt, wie dieses Steuerelement aussieht (es kann sich um eine Schaltfläche handeln, eine Schaltfläche, die wie ein Link aussieht, oder um ein Feld, das anklickbar ist), es bedeutet jedoch, dass ein Element in der Benutzeroberfläche ausgelöst wird. Es zeigt auch an, dass dieses Element "Genehmigen" geschrieben hat. Dies ist ein grauer Bereich, in dem Sie den gesunden Menschenverstand verwenden müssen, da Sie in manchen Fällen so spezifisch sein müssen, dass Aktionen von anderen unterschieden werden können. Wenn zum Beispiel ein Artikel auf derselben Seite genehmigt werden kann, der angibt, dass der Benutzer ihn in diesem Szenario "auswählen" muss, kann die Differenzierung vorgenommen werden.
Neben der durchdachten Syntax, die Gherkin bietet, halte ich unter anderem den Teil "Szenarien" für sinnvoll. Szenarien sind leistungsfähig, da sie dazu verwendet werden können, das Design zu testen und sicherzustellen, dass alle Grundlagen abgedeckt sind.
In der Regel beginnen Designs jeglicher Art mit dem „glücklichen Weg“. Dies bedeutet, was passiert, wenn in der Benutzeroberfläche alles gut läuft und wie es für die Mehrheit der Benutzer gilt. In unserem vorherigen Beispiel hatten wir:
| Szenario | Genehmigung eines Artikels, der zur Veröffentlichung bereit ist. |
Da wir wissen, dass Artikel Veröffentlichungsdaten haben, können wir auch Folgendes angeben: Dies ist unser erstes Szenario, da Artikel, die genehmigt werden müssen, in der Mehrzahl der Fälle zur Veröffentlichung bereit sein sollten. Dies wirft jedoch die Frage auf: Was passiert, wenn ein Artikel nicht zur Veröffentlichung bereit ist und der Verlag darauf zugreift? Sollten sie überhaupt auf diese Artikel zugreifen können?
Alle diese Fragen sind Teil des Designprozesses. Wenn Sie in die Dokumentationsanforderungen einsteigen, werden Sie wahrscheinlich die Antworten kennen. Die gute Nachricht ist, dass die Verwendung von Szenarien in Ihrer Story-Dokumentation Ihnen beim Strukturieren hilft. In vielen Fällen helfen Sie Ihnen bei der Qualitätssicherung Ihrer eigenen Entwürfe, um sicherzustellen, dass für jedes von ihnen ein Design und Ablauf vorgesehen ist.
Mal sehen, wie unsere Geschichte mit den zusätzlichen Szenarien Gestalt annehmen würde:
| Merkmal | Erlauben Sie Publishern, Artikel vor der endgültigen Veröffentlichung zu überprüfen und ihnen die Genehmigung zu geben. |
| Szenario 1 | Genehmigung eines Artikels, der zur Veröffentlichung bereit ist.
|
| Szenario 2 | Zugriff auf einen Artikel, der nicht zur Veröffentlichung bereit ist.
|
| Szenario 3 | Genehmigen eines Artikels, dessen Fälligkeitsdatum überschritten ist
|
| Szenario 4 | Die Genehmigung eines Artikels mit einem zukünftigen Veröffentlichungsdatum wird nicht genehmigt
|
| Szenario 5 | Die Genehmigung eines Artikels, der veröffentlicht wurde, kann nicht genehmigt werden
|
Je nach Funktion können viele Szenarien berücksichtigt werden. Der Schlüssel ist, sie kurz zu halten, damit Sie sie leicht beschreiben und testen können. Sie können auch versuchen, sie unter Verwendung gemeinsamer Nenner zu gruppieren. Wenn zum Beispiel einige Szenarien die gleiche Voraussetzung haben, können Sie dies in einen "Hintergrund" einkapseln, der von mehreren Szenarien verwendet werden kann. Zum Beispiel:
| Hintergrund | Der Verfasser hat einen Artikel zum Veröffentlichen eingereicht und der Herausgeber hat auf die Bearbeitungsartikelansicht zugegriffen. |
| Szenario 1 | Genehmigung eines Artikels, der zur Veröffentlichung bereit ist.
|
| Szenario 2 | Genehmigen eines Artikels, dessen Fälligkeitsdatum überschritten ist.
|
| Szenario 3 | Die Genehmigung eines Artikels mit einem zukünftigen Veröffentlichungsdatum wird nicht genehmigt.
|
Eine häufige Herausforderung bei der Dokumentation der Anforderungen ist die Entscheidung, in welcher Reihenfolge sie ausgeführt werden soll. Der Grund ist, dass sich in den meisten Fällen alles im Aufbau befindet, was es schwierig macht, eine Interaktion zu testen, wenn die Teile der Interaktion noch nicht aufgebaut sind. In der einfachen Interaktion des "Genehmigens" eines Artikels müssen zum Beispiel viele Dinge vorbereitet sein:
Ein Ansatz, um die Anforderungen für jede dieser Abhängigkeiten zu dokumentieren, ist es, diese als unterschiedliche Merkmale aufzuzeichnen, die dann nach ihrem Geschäftswert priorisiert werden können.
| Merkmal | Beschreibung | Priorität |
|---|---|---|
| Warnsystem | Die Benutzeroberfläche sollte in der Lage sein, eine Erfolgsmeldung sowie eine Fehlernachricht zurückzugeben, falls ein Systemproblem vorliegt | 2 |
| Tagging-System | Die Benutzeroberfläche sollte in der Lage sein, Artikel als genehmigt zu kennzeichnen | 4 |
| Veröffentlichungssystem | Die Benutzeroberfläche sollte in der Lage sein, den Artikel gemäß der "veröffentlichten" Geschäftslogik anzuzeigen | 1 |
| Benachrichtigungssystem | Systembenachrichtigungen sollten aktiviert sein, damit die Autoren benachrichtigt werden können, wenn die Genehmigung erfolgt | 3 |
Dann können Sie eine Integrationsgeschichte erstellen, um sie alle zusammenzubringen. Eine User Story für das Tagging-System würde beispielsweise Folgendes wünschen:
| Merkmal | Benutzern und dem System gestatten, Artikel nach einem bestimmten Status zu kennzeichnen (unveröffentlicht, genehmigt, veröffentlicht oder archiviert). |
| Szenario 1 | Artikel als unveröffentlicht kennzeichnen.
|
| Szenario 2 | Einen Artikel als genehmigt kennzeichnen.
|
| Szenario 3 | Einen Artikel als veröffentlicht kennzeichnen.
|
| Szenario 4 | Artikel als archiviert kennzeichnen.
|
In der Integrationsstory können Sie auf die Tagging-Story verweisen, falls die Details für dieses Szenario erneut überprüft werden müssen oder wenn Sie einfach wissen möchten, ob diese Fälle bereits bestätigt wurden.
| Merkmal | Erlauben Sie Publishern, Artikel vor der endgültigen Veröffentlichung zu überprüfen und mit deren Zustimmung zu versehen. |
| Szenario 1 | Genehmigung eines Artikels, der zur Veröffentlichung bereit ist.
|
Es ist wichtig, das Wiederholen von Dokumentationen zu vermeiden, die nicht nur unnötig Zeit benötigen, sondern auch, dass sie nicht mehr synchron sind.
Wir haben gesehen, wie nützlich verhaltensorientierte User Stories sein können, um zielgerichtete, prägnante, aber auch gründliche und beschreibende Anforderungen zu schreiben. Ausgehend von der Entwurfsphase kann dieses Tool den QS-Ingenieuren eine gute Grundlage für das Schreiben tatsächlicher Testfälle bieten.
Neben diesen großen Vorteilen können Behavioral Driven User Stories mit Hilfe von Software wie Gurken oder Salat tatsächlich in Funktionstests umgewandelt werden. Die Grundidee ist, dass, sobald die Stories mit der Gherkin-Syntax geschrieben wurden, sie in einer platziert werden können .Merkmal Datei in Ihrer App und führen Sie sie als Tests aus, um anzuzeigen, ob sie erfolgreich waren oder nicht. Ein ausführliches Tutorial zur Verwendung von Lettuce für eine Python-Implementierung finden Sie in dem Tutorial von David Sale:
Das Schreiben von User Storys nach den Prinzipien von BDD kann dazu dienen, Geschäfts- und Designanforderungen detailliert mit einem benutzerzentrierten Ansatz zu kommunizieren und dabei eine Sprache zu verwenden, die für den Menschen lesbar, aber für die Interpretation von Software erweiterbar ist. Zusätzlich kann es zum Testen verwendet werden:
Dies bedeutet, dass mehr Fehler durchlaufen werden müssen, um Lücken im Design zu vermeiden und die Anwendung zusätzlich vor Fehlern zu schützen.
Accentsconagua