Dovrebbero essere scritti nello stesso modo dei flussi di lavoro umani, in prima persona "Ho inserito ..." in stile linguaggio ecc.? L'utente è effettivamente un "AI" senza genere?
Tutto il software è pensato per servire alla fine su richiesta di un utente umano, e una storia di utenti lo soddisfa. Di conseguenza, qualsiasi riferimento in una user story a una macchina o ad un altro elemento tecnologico sarà in genere un dettaglio di implementazione .
Guarda questo esempio di commercio:
Story: Returns go to stock
In order to keep track of stock
As a store owner
I want to add items back to stock when they're returned
Scenario 1: Refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock
Scenario 2: Replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock.
When he returns the garment for a replacement in black,
Then I should have three blue garments in stock
And two black garments in stock
Si noti che, sebbene la storia utente sia abbastanza dettagliata, e alcune "macchine di inventario" potrebbero essere coinvolte nel processo di inventario, quella macchina non è menzionata nella storia dell'utente.
Ora guarda questa user story:
As a Creator, I want to upload a video so that any users can view it.
Nessuna tecnologia è menzionata. Tuttavia, se inizi a scomporre la user story in modo più dettagliato:
As a Creator, I want to upload a video from my local machine so that any users can view it.
- The “Upload” button will be a persistent item on every page of the site.
- Videos must not be larger than 100MB, or more than 10 minutes long.
- File formats can include .flv, .mov, .mp4, .avi, and .mpg.
- Upload progress will be shown in real time.
Ora hai l'inizio dei requisiti.
Naturalmente, nulla ti impedisce di trattare una macchina come attore. Se desideri farlo, devi semplicemente dare alla macchina un nome generico che descriva il suo ruolo, proprio come faresti con una persona:
As a host machine, I want to collect statistical data to track [some resource] usage.
Ulteriori letture
Uso di Gherkin per scrivere storie utente che abbiano senso
Come scrivere storie utente significative
BDD in realtà iniziato a livello di unità , in cui gli utenti delle classi erano altre classi! Quindi è perfettamente appropriato che un elemento tecnico sia l'utente di un altro. Non importa che si tratti di una "classe" o di un "modulo" o di una "biblioteca" o di un "servizio"; i concetti sono sempre gli stessi.
Alcune delle differenze tra questi due diversi tipi di scenari sono:
Alcune cose rimangono le stesse; in particolare, parlando attraverso gli scenari con qualcuno che ha le competenze necessarie e in grado di dirti quali sono gli scenari da fare. La tua conversazione potrebbe essere simile a questa:
"So, when the data engine gets the new trade, it has to ask the risk calculator to recalculate the risk, then it adjusts the counterparty limits for country, organisation and currency accordingly."
"Can you give me an example?"
"Sure. Let's say we're making a trade with the Belgian arm of a commodity trader for $3m worth of iron, and we're already badly exposed to that trader, and close to the counterparty limit..."
Dan North, che ha inventato il BDD in primo luogo, adora usare la prima persona negli scenari, mentre dice che lo aiuta a immaginare cosa quella persona, classe, sistema, ecc. deve fare.
Mi piace usare la terza persona, in quanto mi aiuta a capire se ci sono parti interessate mancanti i cui risultati sono importanti.
Entrambi sono metodi validi per scrivere scenari. In quella sopra, l'oratore ha automaticamente usato "noi" per indicare l'organizzazione. In questo caso "noi" rappresentiamo in realtà due sistemi: il sistema di prenotazioni commerciali e il sistema che mantiene i limiti della controparte.
Normalmente un sistema di prenotazioni commerciali ha una propria interfaccia utente, ma non si codificherà da quel livello; passerai attraverso l'API del motore di dati, poiché questo è il sistema che ti interessa.
Inoltre, il risultato finale dello scenario è ancora che il limite della controparte sia aggiornato. Nessun utente potrà mai vederlo finché non viene generato un rapporto pertinente o se si avvicina abbastanza ai limiti per attivare un avviso.
La frase: "Puoi farmi un esempio?" è ancora un modo molto semplice per estrarre quegli esempi dalle persone, così come il linguaggio naturale in cui esprimono le loro esigenze ... per qualsiasi livello a cui tali requisiti siano formulati.
Leggi altre domande sui tag bdd specifications product-features cucumber specflow