Come esprimere cosa fare quando si verifica un errore in un utente?

Avrai molte opinioni contrastanti su questo.

In genere mi piace specificare il comportamento del percorso felice e il comportamento di errore in una singola storia se non che improvvisamente rende la storia troppo grande su cui lavorare. Se il comportamento degli errori è complesso, dovrebbe essere la sua storia.

Il mio modo preferito di specificare chiaramente cosa è previsto in una storia (solo percorso felice o percorso di errore?) è utilizzando i criteri di accettazione.

Non considero che una storia debba essere implementata fino a quando tutti i suoi criteri di accettazione non sono stati implementati.

Nel tuo esempio, questi potrebbero essere:

Given I'm at the payment page,
When I pay with a Credit Card,
And the payment is accepted,
Then I expect access to the Services

Given I'm at the payment page,
When I pay with a Credit Card,
And the payment is declined
Then I expect a payment declined message

La gestione degli errori dovrebbe essere spiegata nei criteri di accettazione, non nella storia. La user story riguarda esclusivamente la funzionalità fornita all'utente finale e presumibilmente non stai fornendo errori all'utente finale.

Riesco a vedere un caso per rendere la gestione degli errori parte della storia per un prodotto destinato ad altri sviluppatori, in cui i codici di errore e la gestione degli errori sono caratteristiche effettive che stai fornendo.

Il punto di adottare un approccio basato su una storia è di fornire il valore del cliente in modo incrementale. Idealmente, useresti pratiche come l'accoppiamento e TDD in modo che il codice possa evolvere anche in modo incrementale.

Ciò significa che le storie dovrebbero essere il più minimale possibile, e quindi interromperò l'elaborazione dell'errore in una storia separata. È difficile scrivere i dettagli della gestione degli errori di una storia fino a quando non hai completato la storia, quindi è più facile metterla fuori.

Come spiegazione migliore del perché, diciamo che ho 5 storie che devo fare prima di poter ottenere feedback dal mio cliente. Più minimale riesco a creare quelle storie, più velocemente riuscirò a farle e più rapidamente riceverò feedback. Ogni volta che ottengo il feedback dei clienti, c'è la possibilità che invalidi il lavoro che ho già fatto, quindi voglio ridurre al minimo la quantità di lavoro che potrebbe invalidare. Per la tua pagina di carta di credito, sarei lieto di mostrare una pagina collegata a un servizio falso per ridurre il mio time-to-feedback.

L'altro vantaggio di più storie è che sono più facili da inserire negli sprint. Se la linea principale è terminata e la gestione degli errori non lo è, posso considerare che "fatto" per lo sprint, ma se è tutto insieme dovrò separarli, il che è spesso problematico.

Infine, i team si sentono meglio a fare due piccole cose rispetto a una grande.

Come la maggior parte delle altre risposte uso solo il Happy_path o "scenario principale di successo" per la descrizione del User_story

Successivamente aggiungo Scenari che descrivono le differenze con Happy_path come alternative e errori

Esempio

• (a) pagamento con Creditcard (Successfull)
• alternative :
  • (b) come a (a) ma la carta di credito proviene da un paese straniero
• errori che annullano la transazione:
  • (c) come (a) ma la carta di credito è scaduta

Scrivi la tua storia. Se c'è molta gestione degli errori, suddividila in 2 storie. Dopo tutto, il valore aziendale del completamento del percorso felice è diverso dal valore aziendale della comprensione del motivo di un errore.

Aggiungi criteri di accettazione incentrati sul / i percorso / i felice / i per ogni storia o l'unica grande storia. Se hai una storia per la gestione degli errori, allora la tua AC descriverà gli errori del percorso felice.

Se un caso d'eccezione ha un impatto significativo sul business, considera di inserirlo nell'AC se scrivi una grande storia, ma non cercare di elencare ogni edge / error / scenario d'eccezione

Lascia che le tue risorse di QA si preoccupino della maggior parte dei casi limite / eccezioni e lascia che siano loro a documentare i casi di test. Dovrebbero anche capire i criteri di accettazione e generare i casi di test positivi da quelli.

Se possibile, prova ad automatizzare il maggior numero possibile di casi di test, ma è neutrale al rischio. L'automazione di tutto è costoso; considera se alcuni casi non valgono la pena di essere automatizzati.

No, dovresti solo creare una user story con WHAT che l'utente vuole e qual è il suo obiettivo. L'utente non si cura degli errori, quindi non dovrebbe far parte della storia. Ma dovresti sempre stimare il tempo per la gestione degli errori, perché ci vuole tempo e vorresti che si visualizzi nel tuo grafico di burndown.

Tutti i requisiti per rendere accettabile una user story inclusi gli errori dovrebbero essere menzionati in "Criteri di accettazione" della user story. È responsabilità dello sviluppatore collaborare con e discutere tutti gli scenari relativi a una storia utente con il proprietario del prodotto. Solitamente con discussioni dettagliate i criteri di accettazione della storia dell'utente si evolvono.