Welche Detailebene für BDD-Szenarien?

Ist es angemessen, dass BDD-Szenarien eine „Klicken Sie hier“-Stilspezifität haben?

Ich habe viele Beispiele gelesen, in denen Szenarien angegeben sind, um eine bestimmte Benutzeroberflächeninteraktion zu vermeiden, aber Tools wie SpecFlow würden anscheinend diese Detailgenauigkeit erfordern.

Ist es angemessen, vom BA zu verlangen, eine Geschichte zu schreiben, die Szenarien auf hohem Niveau enthält, und sie dann während der 3 Amigos-Phase auf ein technischeres (und elementspezifisches) Niveau herunterzuarbeiten?

Ist das z.B. angemessen:

Given the user is on /search
And the "Jeff" is entered into the field "searchinput"
When the "Search" button is clicked
Then the page displayed is /results/Jeff
And the fields displayed include "Name"
And the second field displayed is "Post Code"

Das Story-Beispiel und das Tooling-Beispiel auf dieser Seite scheinen inkompatibel zu sein, wenn wir versuchen, von einem zum anderen zu gelangen (wobei die Tatsache ignoriert wird, dass sie sich in sehr unterschiedlichen Geschäftsprozessen befinden): https://en.wikipedia.org/wiki/ Verhaltensgesteuerte_Entwicklung

Ich würde sagen, dass die Detaillierung von BDD-Szenarien auf der Ebene liegen sollte, auf der der Geschäftswert gut und für Geschäftsleute verständlich dargestellt wird. Tiefer als das kann für Techniker wichtig sein. Dies ist eine Abstraktion. Wenn Sie diese Szenarien jedoch automatisieren, müssen Sie sie detaillierter gestalten, um die Schritte gut wiederverwenden und die Wartungskosten senken zu können.
Danke dir. An welchem ​​Punkt – und wie – wird diese Lücke für nicht-technische Geschäftsleute, die diese Geschichten schreiben, und für technische Entwickler, die die Arbeit ausführen, überbrückt?
Ich glaube es kommt auf den Einzelfall an. Ich kenne Geschäftsleute, die mit mehr Details zufrieden sind, und ich kenne auch Geschäftsleute, die dies nicht tun. Wir müssen die richtige Balance finden, um unseren Lieferjob zu erledigen und sie glücklich zu machen.

Antworten (1)

Ihr Verhaltensniveau ist richtig. Die meisten Praktiker (mich eingeschlossen) würden empfehlen, dass Sie es weniger implementierungsspezifisch formulieren. Zum Beispiel:

Given the user is on the search page 
When the user searches for "Jeff"
Then the results page is displayed
And the "Name" field is displayed with the value "Jeff"
And the "Post Code" field is displayed with the value "80273"

Dies ist implementierungsunabhängig, was bedeutet, dass Sie die Implementierung nicht im Voraus kennen müssen und mehrere Implementierungen (z. B. Web und Mobil) einfacher angehen können.

Ich habe auch den Wortlaut angepasst, damit es einfacher zu automatisieren ist. Wenn ein PO oder eine andere nicht-technische Person den Test schreibt, würde ich nicht erwarten, dass sie wissen, dass sie einige dieser Änderungen vornehmen müssen. Ich würde erwarten, dass die Entwickler sie erkennen und dort helfen. Insbesondere die letzten beiden Zeilen haben jetzt das gleiche Muster und sind einfacher zu automatisieren, und das gesamte Szenario könnte mit vielen verschiedenen Werten ausgeführt werden, die für jedes dieser Elemente in Anführungszeichen sehr sauber eingefügt werden.

Schließlich haben Sie in einem Kommentar gefragt, wie Sie die Lücke schließen. Meine Empfehlung ist, den Testfall zu schreiben, bevor Sie die Implementierung kennen. Das zwingt Sie zu mehr dieser implementierungsagnostischen Sprache.

Danke dir. Meine Sorge ist, dass ich diese Geschichten in einer (ziemlich) anderen Umgebung schreibe als früher. Das Hauptproblem ist, dass die Leute, die die Systeme in- und auswendig kennen, die BAs und nicht agil sind. Die Entwickler, die (meistens) agil sind, kennen die Systeme nicht. Mein Ziel ist es, Scrum zu nutzen, um allen dabei zu helfen, zu lernen und gleichzeitig produktiv zu sein. (Die typischen Probleme treten auf, wie Sie sich sicher vorstellen können.)
Welche Detailebene für BDD-Szenarien?
AntwortenHierDatenschutz-Bestimmungen1y, 0v