Wie erfassen Sie Anforderungen mit deklarativen Akzeptanztests?

Question

Hintergrund

Ich versuche, mein Team für ein neues Handy-App-Projekt zu helfen, organisieren. Wir haben beschlossen, BDD zu folgen (siehe auch BDD definition), um klare englische Anforderungen zu erfassen, die einen Vertrag zwischen Stakeholdern und Entwicklern für jede einzelne User Story bilden.

Wir verwenden die Abnahmetests, um die Anforderungen jeder User Story zu dokumentieren. Akzeptanztests werden vor der Sprintplanung geschrieben. Entwickler verfeinern und ergänzen die Tests während der Sprintplanung.

Wir definieren Kriterien Acceptance als eine Liste von Regeln (zB: Eingabevalidierung, Standardwerte, etc.) und Abnahmen als eine Liste von Gurken-Szenarien. Wir planen die Verwendung von Calabash für mobile Tests.

Ich glaube, dass Akzeptanzkriterien/Tests eine flexiblere und daher bessere Lösung für formalere Anforderungsdokumente sind.

Ich glaube, ich habe eine effektive Lösung gefunden, aber ich würde gerne verstehen, wie andere Anforderungen sammeln und Akzeptanztests schreiben.

Problem

Es gibt eine Debatte in der Gurke Gemeinschaft von imperative vs declarative Prüfschritte. Ich lehne mich dem Imperativ zu, denn ein Entwickler muss wissen, wie eine lieferbare User Story aussieht.

Ich glaube nicht, UI-Kopplung aka spröde Tests ist ein Problem. Es gibt Möglichkeiten, die UI vom Test zu entkoppeln (zB: page objects). Ich habe auch nicht das Gefühl, dass es für einen nicht technischen Stakeholder schwierig ist, detaillierte Schritte zu machen (es sei denn, sie wissen nicht, wie sie einen Webbrowser oder ein mobiles Gerät verwenden sollen, aber das ist ein separates Problem).

Ich kann den Begriff "Acceptance Test" unterschlagen. Bei mir ist ein Abnahmetest nicht auf dem gleichen Niveau wie ein Komponententest. Ich sehe einen Abnahmetest als eine hohe Ebene integration test.

Das Beispiel

• Als Gast
• I
• für den Zugriff auf App-Funktionalität

Imperative-Test

anmelden möchten
• Szenario: Gültig Login
  • Da ich auf der "Login" -Bildschirm am
  • Wenn ich „E-Mail @ domain eingeben.com“in "E-Mail"
    • Und ich geben "password1" in "Passwort"
    • Und ich tippen Sie auf "Login"
  • Dann sehe ich, "Anmeldung erfolgreich"

deklarative-Test

• Sc enario: Gültig Login
  • Gegeben Ich habe ein gültiges Konto
  • Dann kann ich mich diese

beide können decken die gleiche Funktionalität und letztere ist kürzer, aber nicht sagen, ob anmelden kann sich mit einem Benutzernamen, E-Mail oder Facebook/Twitter/Google/etc-Konto anmelden. Es ist einfach genug, um nicht wirklich eine Lösung zu kodieren

Die Frage

Wie erfassen Sie die Anforderungen für ein Feature mit deklarativen Schritten?

Answer 1

Schön geschriebene Frage!

Wie erfassen Sie die Voraussetzungen für eine Funktion mit deklarativen Schritten?

Die Anforderungen für ein Feature sind in den Schrittdefinitionen aufgeführt.

daher in Ihrem Imperativ Beispiel:

When I enter "email@domain.com" in "email" 
And I enter "password1" in "password" 
And I tap "login" 

dieses deklarativen gemacht werden könnte durch Umschreiben es als:

Given I login using valid credentials 

Die Schritte zu einem gültigen Konto zu navigieren (dh die Akzeptanzkriterien der Umsetzung was definiert, was "gültig" bedeutet) kann dann in der Schrittdefinition für diese Szenarioanweisung implementiert werden. Das gleiche gilt für das entgegengesetzte Szenario gilt das heißt

Given I login using invalid credentials 

Auch hier sind die Schritte, um dieses Szenario zu implementieren, die die Annahmekriterien entsprechen, können in der zugrundeliegenden Schrittdefinition implementiert werden. Der deklarative Ansatz bedeutet, dass Sie die (imperativen) Anforderungen der Funktion verlieren (dh welche genauen Schritte ausgeführt werden müssen), was es für das Unternehmen schwieriger macht, genau zu sehen, was diese Szenarien beim Lesen tun die Feature-Datei. Was Sie jedoch gewinnen, ist, dass die Tests weniger spröde werden, da die spezifischen Schritte zum Erreichen einer Aufgabe in der Schrittdefinition aufgezeichnet werden, und diese Schrittdefinition kann unter vielen Merkmalen geteilt werden.

In meiner Firma ringen wir mit den gleichen Sorgen, und wir finden, dass es in einigen Fällen besser ist, Imperativ als Deklarativ zu verwenden, und umgekehrt.Zum Beispiel können in Ihrem Fall die Schritte, die "Vorgegeben, dass ich einen gültigen Account habe" in vielen Funktionen verwendet werden, so dass es deklarativ ist rationell zu machen. Wenn Sie jedoch eine Funktion haben, bei der viele verschiedene Zeichenfolgenwerte eingegeben werden, ist es in diesem Fall wahrscheinlich am besten, sie zwingend zu schreiben.

"Horses for courses!"

Es wird sehr interessant sein, andere Antworten von der SO Gemeinschaft auf diese Frage zu sehen.

Answer 2

Ich besuchte vor kurzem ein Geschäft/online, um eine Waschmaschine und eine Spülmaschine zu kaufen. Ich wollte nur eine kaufen, die weniger Wasser verbraucht und sich schnell waschen kann. Aber die Details, denen ich begegnete, waren überwältigend; wie RPM, Dicke der inneren Trommel, gesamte angeschlossene Last in KW etc.

Imperative Art mag von Ihrem einfachen Beispiel oben passend erscheinen, aber in Wirklichkeit macht es Leseszenarien härter und langweilig. Sie können es erleben, indem Sie 10 Szenarien aus einem Projekt lesen, in dem Sie nicht direkt auf technischer/alltäglicher Ebene involviert sind.

Angesichts der Tatsache, dass die Verwendung von Gurken zum Ziel hat, Transparenz über das Projekt, insbesondere die nichttechnischen Benutzer, zu bringen, ist der deklarative Stil viel besser darin, das Management aktiv einzubeziehen. Das habe ich in meinen Projekten gesehen.

Hier ist eine fiktive Geschichte. Versuchen und implementieren Sie es im imperativen Stil, kommen Sie zurück und lesen Sie es in ein paar Tagen, werden Sie feststellen, dass es zu langweilig ist.

Feature: Delivery 
    Free delivery is offered to customers who order two or more items 

    Scenario Outline: Calculate postage for delivery 
    Given I am signed-in 
    When I "<order>" items 
    Then postage should be "<postage>" 

    Examples: 
    | order | postage | 
    | 1  | 0.99 | 
    | 2  | 0  | 
    | 3  | 0  | 
    | 0  | ?  | 

Ein weiterer Link, den Sie wünschen kann How to implement UI testing without shooting yourself in the foot