Come si acquisiscono i requisiti con i test di accettazione dichiarativi?

Question

Sfondo

Sto cercando di aiutare la mia squadra ad organizzare per un nuovo progetto di applicazione per cellulare. Abbiamo scelto di seguire BDD (vedere anche BDD definition) al fine di acquisire semplici requisiti inglesi che formano un contratto tra parti interessate e sviluppatori per ogni singola storia utente.

Utilizziamo i test di accettazione per documentare i requisiti di ogni utente. I test di accettazione vengono scritti prima della pianificazione dello sprint. Gli sviluppatori perfezionano e aggiungono ai test durante la pianificazione dello sprint.

Definiamo Criteri di accettazione come un elenco di regole (ad esempio: convalida dell'input, valori predefiniti, ecc) e Test di collaudo come un elenco di scenari cetriolo. Abbiamo in programma di utilizzare Calabash per i test sui dispositivi mobili.

Ritengo che i criteri/test di accettazione siano una soluzione più agile e quindi migliore per documenti con requisiti più formali.

Sento di aver trovato una soluzione efficace per me, ma vorrei capire come altri stanno raccogliendo i requisiti e scrivendo test di accettazione.

Problema

C'è un dibattito nella comunità Cetriolo di imperative vs declarative fasi della prova. Mi avvicino all'imperativo, perché uno sviluppatore deve sapere che aspetto ha una storia utente consegnabile.

Non mi sento un problema con l'accoppiamento UI. Esistono modi per disaccoppiare l'interfaccia utente dal test (ad esempio: page objects). Inoltre, non ritengo che avere passaggi dettagliati rendano difficile per un partecipante non tecnico comprendere (a meno che non sappia come utilizzare un browser Web o un dispositivo mobile, ma si tratta di un problema separato).

È possibile che il termine "Acceptance Test" sia errato. Nel mio utilizzo, un test di accettazione non è allo stesso livello di un test unitario. Vedo un test di collaudo come livello elevato integration test.

L'esempio

• Come ospite
• voglio login
• per accedere alle funzionalità di app

prova imperativo

• Scenario: accesso valido
  • Dato Sono nella schermata di "login"
  • Quando entro in "e-mail @ dominio.com" in "e-mail"
    • E io entro in "password1" in "password"
    • E io batto "Login"
  • poi vedo "login riuscito"

dichiarativa di prova

• Sc enario: accesso valido
  • Dato che ho un account valido
  • Allora posso accedere

Questi sia in grado di coprire le stesse funzionalità e la seconda è più breve, ma non dice se io può accedere con un nome utente, e-mail o account facebook/twitter/google/etc. E 'solo non è sufficiente per codificare in realtà una soluzione

La questione

Come si fa a catturare i requisiti per una funzione con gradini dichiarativi?

Answer 1

Domanda ben scritta!

Come si acquisiscono i requisiti per una funzionalità con passaggi dichiarativi ?

I requisiti per una funzione sono registrati nelle definizioni di passo.

Quindi nel tuo esempio imperativa:

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

questo potrebbe essere fatto dichiarativa riscrivendo come:

Given I login using valid credentials 

I passaggi per spostarsi ad un account valido (ossia attuazione dei criteri di accettazione che definisce cosa significa "valido") può quindi essere implementato nella definizione di passo per questa dichiarazione di scenario. Lo stesso vale per lo scenario opposto cioè

Given I login using invalid credentials 

Nuovamente, i passaggi per implementare questo scenario che soddisfano i criteri di accettazione può essere implementato nella definizione passaggio sottostante.

Questo approccio dichiarativo significa che si perde i requisiti (imperativo) dalla funzione (vale a dire quali passi precisi devono essere eseguite), rendendo più difficile per l'azienda per vedere esattamente ciò che questi scenari stanno facendo da solo la lettura il file delle caratteristiche. Tuttavia, ciò che si ottiene è che i test diventano meno fragili, poiché i passaggi specifici per eseguire un'attività vengono registrati nella definizione del passo e questa definizione del passo può essere condivisa tra molte funzioni.

Nella mia azienda lottiamo con le stesse preoccupazioni, e scopriamo che in alcuni casi è meglio usare imperativo piuttosto che dichiarativo, e viceversa.Ad esempio, nel tuo caso i passaggi che compongono "Dato che ho un account valido" possono essere utilizzati in molte funzioni, quindi renderlo dichiarativo è razionale. Tuttavia, se si dispone di una funzione in cui vengono immessi molti valori di stringa diversi, in tal caso è probabilmente meglio scriverli in modo imperativo.

"Horses for courses!"

Sarà molto interessante vedere altre risposte a questa domanda dal SO comunità.

Answer 2

Recentemente ho visitato un negozio/online per acquistare una lavatrice e una lavastoviglie. Tutto quello che volevo era comprarne uno che utilizza meno acqua e ha un lavaggio veloce. Ma i dettagli che ho incontrato sono stati travolgenti; come RPM, Spessore tamburo interno, Carico totale collegato in KW ecc.

Lo stile imperativo può sembrare adatto dal semplice esempio sopra riportato ma in realtà rende gli scenari di lettura più difficili e noiosi. Puoi provarlo leggendo 10 scenari da un progetto in cui non sei direttamente coinvolto a livello tecnico/giornaliero.

Dato che uno degli obiettivi dell'utilizzo del cetriolo è quello di portare trasparenza nel progetto, in particolare gli utenti non tecnici, lo stile dichiarativo è molto più efficace nel coinvolgere la direzione. L'ho visto nei miei progetti.

Ecco una storia fittizia. Prova e implementalo in modo imperativo, torna indietro e leggilo tra un paio di giorni, ti accorgerai che è troppo noioso.

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  | ?  | 

Un altro collegamento che si potrebbe desiderare di leggere How to implement UI testing without shooting yourself in the foot