Cos’è la User Story e i criteri di accettazione (esempi)

Una guida perfetta ai criteri di accettazione della User Story con scenari reali:

Nel settore dello sviluppo software, la parola “Requisito” definisce quale sia il nostro obiettivo, ciò di cui i clienti hanno esattamente bisogno e ciò che renderà la nostra azienda

Che si tratti di una società di prodotti che produce prodotti software o di una società di servizi che offre servizi in vari campi del software, la base principale per tutti loro è il requisito e il successo è definito da quanto bene i requisiti sono soddisfatti.,

Il termine “requisito” ha nomi diversi in diverse metodologie di progetto.

In Waterfall, viene indicato come “Documento requisito / specifica”, in Agile o SCRUM viene indicato come “Epico”, “Storia utente”.

Sotto il modello Waterfall, i documenti dei requisiti sono documenti enormi di 200 o più pagine poiché l’intero prodotto viene implementato in un’unica fase. Ma questo non è il caso di Agile/SCRUM perché in queste metodologie i requisiti sono dati per piccole funzionalità o caratteristiche mentre il prodotto viene preparato in modo graduale.,

In questo articolo, ho fatto del mio meglio per condividere tutti i miei 4 anni di esperienza sul lavoro con le storie degli utenti e i relativi criteri di accettazione insieme a facili e semplici scenari di vita reale per una migliore comprensione.

Cerchiamo di ri-visitare i fondamenti prima.

Che cos’è una storia utente?

Una storia utente è un requisito per qualsiasi funzionalità o caratteristica che è scritto in una o due righe e max fino a 5 righe. Una storia utente è di solito il requisito più semplice possibile e riguarda una e una sola funzionalità (o una caratteristica).,

Il più diffuso formato per una User Story, la creazione è indicato di seguito:

nel <ruolo utente/cliente, Voglio < obiettivo da raggiungere> in modo che io possa <la ragione dell’obiettivo>.

Esempio:

Come utente di WhatsApp, voglio un’icona della fotocamera nella casella di scrittura della chat per catturare e inviare immagini in modo da poter fare clic e condividere le mie foto contemporaneamente con tutti i miei amici.

Che cos’è un criterio di accettazione?,

Un criterio di accettazione è un insieme di condizioni o regole aziendali accettate che la funzionalità o la funzionalità dovrebbero soddisfare e soddisfare, al fine di essere accettate dal proprietario del prodotto/dalle parti interessate.

Questa è una parte molto importante del completamento della storia utente e dovrebbe essere studiata dal proprietario del prodotto e dall’analista aziendale molto meticolosamente perché manca un singolo criterio può costare molto. Questo è un semplice elenco numerato o puntato.

Il suo formato è il seguente:

“Dato qualche precondizione quando faccio qualche azione, mi aspetto il risultato”.

Esempio (w. r.,t to above user story):

• Consideriamo che sto chattando con un amico e dovrei essere in grado di catturare una foto.
• Quando clicco su un’immagine, dovrei essere in grado di aggiungere una didascalia all’immagine prima di inviarla.
• Se c’è qualche problema con l’avvio della fotocamera del telefono, un messaggio di errore come “La fotocamera non può essere avviata”. ecc., dovrebbe essere mostrato di conseguenza.

Quindi, la storia utente definisce il requisito per qualsiasi funzionalità o funzionalità mentre i criteri di accettazione definiscono la “Definizione di fatto” per la storia utente o il requisito.,

Come QA è molto importante comprendere profondamente la storia dell’utente e i suoi criteri di accettazione senza nemmeno un solo dubbio che rimane all’inizio del test. Andando avanti capiamo perché è estremamente importante scavare “in profondità” nelle storie degli utenti e nei criteri di accettazione.

Scavando in profondità nelle storie degli utenti

Per cominciare, comprendiamo prima l’importanza di uno studio “approfondito” di una cosa fondamentale e fondamentale, ovvero le storie degli utenti.

I seguenti casi sono le mie esperienze reali.,

Caso #1:

Prima di 3 anni, stavo lavorando a un progetto di applicazione mobile e il prodotto era un’applicazione progettata per le persone di consegna.

Avresti visto una persona di consegna venire al tuo posto per la consegna. E hanno un telefono cellulare su cui ti chiedono di dare la tua firma dopo la consegna. Questa firma si riflette sul portale dei fornitori di servizi di corriere come DTDC, FedEx ecc.

Immaginiamo che l’applicazione mobile è appena lanciato e loro portali sono già esistenti e fino.,

Problema: per uno Sprint il proprietario del prodotto ha una storia utente per questa app mobile che ” Come amministratore del portale, dovrei essere in grado di visualizzare la firma presa dalla persona di consegna al momento della consegna”. Qui il portale (web app) viene modificato e aggiornato di conseguenza per riflettere la firma.

Come QA è necessario verificare se la firma acquisita nell’app mobile si riflette come previsto nel portale.,

Se si guarda a questa storia utente, sembra semplice ma c’è un requisito nascosto qui che “Per le consegne storiche, non c’era alcuna funzionalità di riflessione della firma, quindi cosa dovrebbe accadere se i ragazzi del portale visualizzano le consegne storiche?”I dati storici dovrebbero essere spazzati via? Dovremmo consentire arresti anomali o errori per tali dati?

Ovviamente no, questo dovrebbe essere gestito gentilmente.,

Soluzione: Quando le rispettive tabelle DB vengono aggiornate per aggiungere una nuova colonna per la posizione della firma, i vecchi dati dovrebbero avere un valore NULL o 0 che dovrebbe essere controllato e un messaggio che indica ‘Nessuna firma esiste’ dovrebbe essere mostrato.

Questo può essere chiamato come una mancanza dal proprietario del prodotto o analista aziendale, ma questo deve essere fatto. Implementare una funzionalità con successo ma rompere qualcosa insieme ad essa non è auspicabile dai clienti. Questo deve essere fatto insieme alla stessa storia utente e nello stesso sprint.,

Caso # 2

6 anni fa, stavo lavorando a un’applicazione di finanza di pianificazione pensionistica (senza BA) che era un’applicazione globale in cui la gente della finanza come CA, i consulenti finanziari potevano usarlo per diverse valute per proiettare i piani di investimento,i risparmi, ecc., sopra un grande periodo ai loro clienti.

Problema: il proprietario del prodotto ti fornisce una storia utente che ” Come consulente, voglio visualizzare il report del mio cliente in base ai dettagli finanziari forniti”.,

Qui c’erano 2 requisiti nascosti e lo chiamerei come una storia incompleta perché:

a] I rapporti dovrebbero considerare il tasso di conversione giornaliero della valuta e non quello storico come nell’ultimo rapporto visualizzato e

b] Se la valuta viene cambiata dopo aver fornito i dettagli finanziari del cliente, i rapporti dovrebbero mostrare nella valuta cambiata.

Soluzione: ho sollevato questa preoccupazione direttamente con il nostro Product Owner e gli ho fatto sapere che entrambi dovevano essere fatti il prima possibile. Era d’accordo con me e ha creato 2 storie diverse per i prossimi sprint con priorità.,

Take Away: questi sono stati catturati perché eravamo tutti molto ben consapevoli dei prodotti, del loro design, della struttura ecc. Tale conoscenza può essere raggiunta solo comprendendo completamente il prodotto, comprendendo l’interoperabilità dei moduli e studiando a fondo la storia dell’utente anche se si tratta di un liner 2.

Prendere appunti per rendere le cose più facili e discutere con il BA e gli sviluppatori circa il loro pensiero.,

Uno sguardo approfondito ai criteri di accettazione

Comprendere i criteri di accettazione e tutte le altre condizioni& regole in modo esaustivo è ancora più importante che sottovalutare una storia utente. Perché se un requisito è incompleto o vago, può essere ripreso nello sprint successivo, ma se viene mancato un criterio di accettazione, la storia utente stessa non può essere rilasciata.

Immagino che tutti avremmo usato il net banking ad un certo punto e la maggior parte di noi lo usa ogni giorno e scarico molto le mie dichiarazioni storiche., Se si osserva con attenzione, ci sono alcune opzioni specifiche disponibili per il download di loro.

C’è un’opzione per selezionare il tipo di file per scaricare la tua dichiarazione. C’è un’opzione da scegliere se si desidera scaricare solo i crediti/Debito /entrambi.

Ora immagina che il proprietario del prodotto ti fornisca questa storia utente “Come cliente, voglio scaricare il mio estratto conto in modo da poter visualizzare tutte le mie transazioni effettuate per un periodo specifico”.,

Con i seguenti criteri di accettazione:

• Considerando che sono nella pagina di download della dichiarazione storica, dovrei selezionare il periodo per il quale voglio scaricare la dichiarazione.
• Considerando che sono nella pagina di download della dichiarazione storica, dovrei selezionare l’account per il quale voglio scaricare la dichiarazione.
• Considerando che sono nella pagina di download della dichiarazione storica, non dovrei essere autorizzato a scaricare la dichiarazione per la futura data “To”.,
• Considerando che sono nella pagina della dichiarazione storica di download, non dovrei essere autorizzato a selezionare la data ” Da ” 10 anni oltre nel passato.
• Considerando che scarico la mia dichiarazione, dovrei essere in grado di visualizzare il file scaricato.
• Considerando che sono nella pagina Download Historical Statement, dovrei essere in grado di scaricare la mia dichiarazione nei formati doc, excel e pdf.

Se si passa attraverso questa accettazione, ci sono 3 cose mancanti qui:

• Nome e formato del nome del file che verrà scaricato.,
• Quali informazioni (nomi delle colonne) devono essere visualizzate nel file.
• L’elenco delle opzioni per selezionare il tipo di transazione che il cliente desidera, ovvero solo addebiti o solo crediti o entrambi.

Tali casi possono accadere una volta ogni tanto, tuttavia ancora studiare bene su ogni criterio di accettazione e cercare di visualizzarlo con riferimento alla storia utente. Quanto più si studia a fondo le condizioni e le regole di business più sarà la vostra conoscenza circa la funzione.

I bug trovati nella fase iniziale non costano nulla rispetto a quanto potrebbe costare nella fase di “test”.,

Importanza di trovare discrepanze nei criteri di User Story/Acceptance

E ‘ sempre importante fare un tuffo profondo nelle storie degli utenti e criteri di accettazione in una fase iniziale, anche prima dello sviluppo o test inizia.

Perché comporta:

#1) Spreco di tempo:

Se si riscontrano discrepanze o errori nei criteri di user story / acceptance quando lo sviluppo è in corso o il test è in corso, potrebbe essere necessario eseguire molte rilavorazioni nel tempo rimanente dello sprint.,

Non succede che anche se il proprietario del prodotto ha perso alcune cose, sposterà la storia dell’utente allo sprint in arrivo. le probabilità di 95% sono che chiedono al team di eseguire l’implementazione necessaria e rilasciarla nello stesso sprint.

Quindi diventa un incubo per la squadra in quanto devono trascorrere più tempo, venire nei fine settimana o lavorare fino a tarda notte. Questo può essere evitato studiando e discutendo la storia utente/criteri di accettazione al più presto possibile.

#2) Spreco di sforzi:

Gli sviluppatori e il QA devono rivedere di nuovo il codice implementato e i casi di test., L’aggiornamento, l’aggiunta e la rimozione come requisito per non è un compito facile. Diventa troppo doloroso in quanto vi è già una pressione per consegnare in tempo.

In una situazione del genere, ci sono possibilità di errori nella fase di sviluppo o test. Se vi imbattete in tale situazione andare per ‘DEVQA Pairing’. Come ciliegina sulla torta, non si può ottenere un risarcimento per il lavoro extra.

Conclusione

La comprensione profonda della storia dell’utente e dei criteri di accettazione può essere raggiunta solo trascorrendo un tempo immenso a studiarla.,

Non esiste uno strumento o un corso specifico disponibile sul mercato per farlo per te, poiché si tratta di pensiero logico, esperienza e conoscenza del prodotto.

Partecipare attivamente alla riunione pre-piano, parlare con il BA, studiare da soli può solo aiutarti a raggiungere questo obiettivo. Più sforzi metti, più impari e cresci.

Che si tratti del QA o degli sviluppatori, tutti devono essere sulla stessa pagina sulle storie degli utenti e sui loro criteri di accettazione, solo allora le aspettative del cliente possono essere raggiunte con successo.,

Hai qualcosa di nuovo da condividere con noi sulle tue esperienze di lavoro con le Storie degli utenti? Si prega di esprimere i vostri pensieri qui sotto!!