Definire i criteri di accettazione per una storia utente

Question

Definire i criteri di accettazione per una storia utente

#1 da (5 voti)
#2 da (0 voti)

2

Mi è stata assegnata una storia utente / epica che mostra una pagina web che fornisce dettagli su un negozio al dettaglio per un'azienda.

In parole povere, se l'url fosse mywebsite.com/newyork mostrerebbe i dettagli del negozio di New York mywebsite.com/athens mostrerebbe i dettagli di Atene, ecc. Le cose che verrebbero visualizzate sono cose come orari di apertura, posizione, numero di telefono

Dalla mia lettura sembra che i criteri di accettazione della user story siano di altissimo livello. Come tale Ho 2 domande sui criteri di accettazione per il mio progetto attuale.

Domande

1) Il proprietario del prodotto ha messo la visualizzazione Benvenuto in myRetailStore yyy dove yyy è il nome della pagina dello store visualizzata come tag h1 nella parte superiore della pagina sotto la barra di navigazione principale

è un criterio di accettazione pertinente? la parte relativa al tag h1 dovrebbe essere nei dettagli? (non sembra abbastanza alto per me)

2) supponendo che ci siano 400 negozi che controllano il fatto che Welcome to myRetailStore New York sia visualizzato per New York significa che la storia ha superato i suoi criteri di accettazione o dovrebbe essere controllata per tutti i 400 negozi?

agile scrum

posta lostinwpf 14.04.2015 - 02:19

fonte

2 risposte

Leggi altre domande sui tag agile scrum

Molte classi diverse che richiedono funzionalità simili. Miglior approccio? Come gestire un elenco aggregato dei campi di più oggetti?

score 5 · Answer 1

Personalmente, direi che un criterio di accettazione di "Deve essere un tag <h1> " non è un criterio di accettazione appropriato, a meno che il PO non sia disposto a rifiutare la storia se il team usasse qualche altro tag e lo stile applicato per fare assomiglia a un tag <h1> . In altre parole, l'uso di <h1> veramente è una parte necessaria della soluzione?

Consiglierei di impegnarmi in una conversazione con il PO per assicurarmi che cosa sia veramente importante e perché. Forse c'è un motivo aziendale specifico per un h1 - per supportare gli screen reader, forse? O forse l'OP conosce solo abbastanza HTML per essere pericoloso e non si rende conto che il tag non è importante quanto il rendering finale.

Per quanto riguarda la seconda parte, direi che solo perché si presenta per New York non è sufficiente. Come ordine di acquisto, scriverei i criteri di accettazione in modo tale che sia necessario che venga visualizzato il saluto corretto per ogni negozio supportato.

Questo non significa che devi avere 400 casi di test, ma fa significa che hai un numero sufficiente di casi di test per dimostrare che tutti i casi limite e le permutazioni sono coperti.

Ricorda: l'obiettivo dei criteri di accettazione è di aiutare il team - in modo che sappiano quando hanno finito. Se essere specifici sui tag aiuta il team, è un criterio appropriato. Se interferisce con la squadra che fa il lavoro, non lo è.

score 0 · Answer 2

Dipende.

Il livello di dettagli nei criteri di accettazione può dipendere molto dal tipo di storia. Prendi in considerazione la possibilità di creare una User story per una pagina Web o per un nuovo linguaggio di programmazione? Suppongo che saranno necessari diversi livelli di dettaglio per accettare la storia (il che significa che è stata eseguita correttamente).

Trovo che quanto più dettagliato è l'AC, tanto meno le possibilità di errata interpretazione dei requisiti da parte dello sviluppatore.

Nel caso in cui importa come viene visualizzato il messaggio di benvenuto, specificarlo, altrimenti non può essere omesso.

Per 400 negozi, se le pagine sono basate su modelli e vengono popolati i nomi dei negozi, la storia dovrebbe apparire come "quando apro una pagina per un negozio specifico (newyork) i campi corretti sono popolati nel modello (ore, nome, ecc.) "- non c'è bisogno di ripeterlo per ogni negozio. Come ci sarebbe un'altra storia sulla creazione di record di dati per tutti i negozi con dati corretti.

Consiglierei di dare un'occhiata agli strumenti per ATDD . Abbiamo utilizzato SpecFlow ed è stato molto utile nel fornire la giusta quantità di dettagli.