Che cos'è la User Story e i criteri di accettazione (esempi)

Esempio:

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

Che cosa sono i criteri di accettazione?

Un criterio di accettazione è un insieme di condizioni o regole aziendali accettate che la funzionalità o la caratteristica deve soddisfare e soddisfare per essere accettata dal Product Owner / dagli stakeholder.

Questa è una parte molto importante del completamento della user story e dovrebbe essere studiata dal Product Owner e dall'analista aziendale in modo molto meticoloso perché perdere un singolo criterio può costare molto. Questo è un semplice elenco numerato o puntato.

Il suo formato è il seguente:

' Data una precondizione quando eseguo un'azione, mi aspetto il risultato '.

le principali domande dell'intervista in c ++

Esempio (rispetto alla storia utente sopra):

• Consideriamo che sto chattando con un amico e dovrei essere in grado di scattare una foto.
• Quando clicco su un'immagine, dovrei essere in grado di aggiungere una didascalia all'immagine prima di inviarla.
• Se si verificano problemi con l'avvio della fotocamera del telefono, viene visualizzato un messaggio di errore del tipo 'Impossibile avviare la fotocamera'. ecc. dovrebbero essere visualizzati di conseguenza.

Quindi, la User story definisce il requisito per qualsiasi funzionalità o caratteristica mentre i Criteri di accettazione definiscono la 'Definizione di fatto' per la User story o il requisito.

In qualità di QA è molto importante comprendere a fondo la user story e i suoi criteri di accettazione, senza nemmeno un singolo dubbio che rimanga all ''inizio del test'. Andando avanti, capiamo perché è estremamente importante scavare 'in profondità' nelle storie degli utenti e nei criteri di accettazione.

Approfondire le storie degli utenti

Per cominciare, dobbiamo prima comprendere l'importanza di uno studio 'approfondito' di una cosa di base e fondamentale, ovvero 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 gli addetti alle consegne.

Avresti visto un addetto alle consegne venire a casa tua per la consegna. E hanno un cellulare su cui ti chiedono di firmare dopo la consegna. Questa firma si riflette sul portale dei fornitori di servizi di corriere come DTDC, FedEx ecc.

Immaginiamo che l'app per dispositivi mobili sia appena stata lanciata e i loro portali siano già esistenti e aggiornati.

Problema: Per uno Sprint, il proprietario del prodotto ha una storia utente per questa app mobile che 'In qualità di amministratore del portale, dovrei essere in grado di visualizzare la firma presa dall'addetto alla consegna al momento della consegna' . Qui il portale (web app) viene modificato e aggiornato di conseguenza per riflettere la firma.

In qualità di QA devi verificare se la firma acquisita nell'app mobile si riflette come previsto nel portale.

Se guardi questa storia utente, sembra semplice, ma qui c'è un requisito nascosto: '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 cancellati? Dovremmo consentire arresti anomali o errori per tali dati?

Ovviamente no, questo dovrebbe essere gestito con gentilezza.

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 dovrebbe essere visualizzato un messaggio che indica 'Nessuna firma'.

Questo può essere definito come un errore dal Product Owner o dall'analista aziendale, ma è necessario farlo. L'implementazione di una funzionalità con successo ma rompere qualcosa insieme ad essa non è desiderabile dai clienti. Questo deve essere fatto insieme alla stessa user story e nello stesso sprint.

Caso n. 2

6 anni fa, stavo lavorando a un'applicazione finanziaria per la pianificazione pensionistica (senza BA) che era un'applicazione globale in cui persone di finanza come CA, consulenti finanziari potevano usarla per diverse valute per proiettare i piani di investimento, i risparmi, ecc. grande periodo ai propri clienti.

Problema: Il Product Owner ti offre una User Story che 'In qualità di consulente, desidero visualizzare il report del mio cliente in base ai dettagli finanziari forniti'.

Qui c'erano 2 requisiti nascosti e la definirei una storia incompleta perché:

per) I rapporti dovrebbero considerare il tasso di conversione della valuta giornaliero e non quello storico come nell'ultimo rapporto visualizzato e

b) Se la valuta viene modificata dopo aver fornito i dettagli finanziari del cliente, i rapporti dovrebbero essere visualizzati nella valuta modificata.

Soluzione: Ho sollevato questa preoccupazione direttamente con il nostro Product Owner e gli ho fatto presente che entrambe le operazioni dovevano essere eseguite il prima possibile. Era d'accordo con me e ha creato 2 storie diverse per i prossimi sprint con priorità.

Porta via: Questi sono stati catturati perché eravamo tutti molto ben consapevoli dei prodotti, del loro design, della struttura, ecc. Tale conoscenza può essere ottenuta solo comprendendo completamente il prodotto, comprendendo l'interoperabilità dei moduli e studiando a fondo la user story, anche se è un 2 liner.

Prendi appunti per rendere le cose più facili e discuti con i BA e gli sviluppatori del loro pensiero.

Analisi approfondita dei criteri di accettazione

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

Immagino che prima o poi tutti avremmo utilizzato il net banking e la maggior parte di noi lo usa ogni giorno e io scarico molto i miei rendiconti storici. Se lo osservi attentamente, sono disponibili alcune opzioni specifiche per scaricarli.

C'è un'opzione per selezionare il tipo di file per scaricare il tuo estratto conto. C'è un'opzione da scegliere se si desidera scaricare solo i crediti / debiti / entrambi.

Ora immagina che il Product Owner ti dia questa User story '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 Scarica rendiconto storico, dovrei selezionare il periodo per il quale voglio scaricare il rendiconto.
• Considerando che sono nella pagina Scarica rendiconto storico, dovrei selezionare l'account per il quale desidero scaricare il rendiconto.
• Considerando che sono nella pagina Scarica rendiconto storico, non dovrei essere autorizzato a scaricare il rendiconto per la futura data 'A'.
• Considerando che sono nella pagina Scarica rendiconto storico, non dovrei essere autorizzato a selezionare la data 'Da' 10 anni dopo nel passato.
• Considerando che ho scaricato la mia dichiarazione, dovrei essere in grado di visualizzare il file scaricato.
• Considerando che sono nella pagina Scarica rendiconto storico, dovrei essere in grado di scaricare il mio rendiconto nei formati doc, excel e pdf.

Se passi attraverso questa accettazione, qui mancano 3 cose:

• Nome e formato del nome del file che verrà scaricato.
• Quali informazioni (nomi di 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 di tanto in tanto, tuttavia studia bene ogni criterio di accettazione e prova a visualizzarlo con riferimento alla user story. Più studi approfonditamente sulle condizioni e sulle regole aziendali, maggiore sarà la tua conoscenza della funzionalità.

I bug trovati nella fase iniziale non costano nulla rispetto a quanto potrebbero costare nella fase di 'test'.

Importanza di trovare discrepanze nella User Story / Criteri di accettazione

È sempre importante fare un'immersione profonda nelle storie degli utenti e nei criteri di accettazione in una fase iniziale, anche prima dell'inizio dello sviluppo o del test.

Perché coinvolge:

# 1) Perdita di tempo:

Se le discrepanze o gli errori nella user story / nei criteri di accettazione vengono rilevati quando lo sviluppo è in corso o il test è in corso, potrebbe essere necessario fare molte rielaborazioni nel tempo di sprint rimanente.

Non succede che, anche se il Product Owner ha tralasciato poche cose, sposterà la user story allo sprint in arrivo. Il 95% di probabilità è che chiedano 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 a tarda notte. Questo può essere evitato studiando e discutendo la storia dell'utente / i criteri di accettazione il più presto possibile.

# 2) Spreco di sforzi:

Gli sviluppatori e il QA devono rivedere il codice implementato e testare di nuovo i casi. Aggiornare, aggiungere e rimuovere secondo il requisito non è un compito facile. Diventa troppo doloroso perché c'è già una pressione da consegnare in tempo.

In una situazione del genere, ci sono possibilità di errori nella fase di sviluppo o test. Se ti imbatti in una situazione del genere, scegli 'DevQA Pairing'. Come ciliegina sulla torta, potresti non ottenere un compenso per il lavoro extra.

Conclusione

Una profonda comprensione della User Story e dei criteri di accettazione può essere raggiunta solo dedicando immenso tempo 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-plan, 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 riguardo alle storie degli utenti e ai 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 User Story? Per favore esprimi i tuoi pensieri qui sotto !!

Lettura consigliata

• MongoDB Crea utenti e assegna ruoli con esempi
• Modello di esempio per rapporto del test di accettazione con esempi
• Autenticazione utente in MongoDB
• Parametrizzazione dei dati JMeter mediante variabili definite dall'utente
• Autorizzazioni Unix: Autorizzazioni file in Unix con esempi
• Che cos'è il test di accettazione (una guida completa)
• Che cos'è il test di accettazione dell'utente (UAT): una guida completa
• Tutorial Python DateTime con esempi