Tempo di lettura: 7 minuti

Il successo di qualsiasi progetto dipende dalla capacità di un team di sviluppo di soddisfare le esigenze del proprio cliente. La comunicazione tra il cliente e il team di sviluppo svolge un ruolo fondamentale nella fornitura di una soluzione che si adatta alle esigenze del prodotto e del mercato., I problemi sorgono se i clienti spiegano le loro esigenze troppo vagamente e il team non riesce a capire i requisiti chiari e alla fine il problema aziendale dietro di loro. Immagina di chiedere al tuo team di consentire agli utenti di cercare un prodotto in una libreria online per categorie. Ci si aspetta di avere un’interfaccia chiara con i link di categoria per fare clic su di essi (ad esempio fantasy, saggistica, storico, ecc.) Dopo due settimane di sviluppo, si riceve una funzione di barra di ricerca in cui gli utenti devono digitare la categoria a cui sono interessati, invece di sfogliare le categorie pre-elencate., Anche se questo funziona, il tuo obiettivo iniziale era quello di esporre tutte le categorie disponibili e consentire agli utenti di esplorare ulteriormente.

Questo è quando la documentazione software di alta qualità potrebbe aiutare a evitare il problema. User stories e criteri di accettazione (AC) come i principali formati di documentazione dei requisiti. Una storia utente è una descrizione in linguaggio naturale di una funzione. Di solito è accompagnato da criteri di accettazione.

I criteri di accettazione (AC) sono le condizioni che un prodotto software deve soddisfare per essere accettato da un utente, un cliente o altro sistema., Sono unici per ogni storia utente e definiscono il comportamento della funzionalità dal punto di vista dell’utente finale. Criteri di accettazione ben scritti aiutano a evitare risultati imprevisti alla fine di una fase di sviluppo e assicurano che tutte le parti interessate e gli utenti siano soddisfatti di ciò che ottengono.

I criteri di accettazione sono i requisiti funzionali di livello più basso

Criteri di accettazione scopi principali

Chiarire i requisiti degli stakeholder è un obiettivo di alto livello. Per rendere più chiari gli scopi di AC, scomponiamoli.,

Caratteristica ambito detalization. AC definire i confini delle storie degli utenti. Forniscono dettagli precisi sulle funzionalità che aiutano il team a capire se la storia è completata e funziona come previsto.

Che descrive scenari negativi. Yor AC può richiedere al sistema di riconoscere gli input password non sicuri e impedire a un utente di procedere ulteriormente. Il formato password non valido è un esempio di un cosiddetto scenario negativo quando un utente esegue input non validi o si comporta in modo imprevisto. AC definire questi scenari e spiegare come il sistema deve reagire su di essi.

Impostazione della comunicazione., I criteri di accettazione sincronizzano le visioni del cliente e del team di sviluppo. Assicurano che tutti abbiano una comprensione comune dei requisiti: gli sviluppatori sanno esattamente che tipo di comportamento deve dimostrare la funzionalità, mentre le parti interessate e il cliente capiscono cosa ci si aspetta dalla funzionalità.

Ottimizzazione dei test di accettazione. AC sono la base del test di accettazione della storia utente. Ogni criterio di accettazione deve essere verificabile in modo indipendente e quindi avere un chiaro passaggio o fallire scenari. Possono anche essere utilizzati per verificare la storia tramite test automatici.

Stima delle funzionalità., I criteri di accettazione specificano cosa deve essere sviluppato esattamente dal team. Una volta che il team ha requisiti precisi, può dividere le storie degli utenti in attività che possono essere valutate correttamente.

Criteri di accettazione tipi e strutture

AC possono essere scritti in diversi formati. Ce ne sono due più comuni e la terza opzione è quella di ideare il proprio formato:

• orientato allo scenario (Dato/Quando/Allora)
• orientato alle regole (lista di controllo)
• formati personalizzati

Poiché il primo e il secondo formato hanno strutture molto specifiche, ci concentreremo principalmente su di essi., Tuttavia, potresti scoprire che altri formati si adattano meglio al tuo prodotto, quindi toccheremo brevemente anche loro.

Criteri di accettazione orientati allo scenario

Il formato di scrittura orientato allo scenario AC è noto come tipo/When / Then (GWT) dato.

• Data qualche precondizione
• Quando faccio qualche azione
• Allora mi aspetto qualche risultato

Questo approccio è stato ereditato da behavior-driven development (BDD) e fornisce una struttura coerente che aiuta i tester a definire quando iniziare e terminare il test di una particolare funzionalità., Riduce anche il tempo dedicato alla scrittura di casi di test in quanto il comportamento del sistema viene descritto in anticipo.,

Ogni criteri di accettazione scritto in questo formato ha le seguenti dichiarazioni:

1. Scenario – il nome per il comportamento che verrà descritto in
2. Dato lo stato iniziale dello scenario
3. Quando si specifica l’azione che l’utente
4. Allora il risultato dell’azione nel “Quando”
5. E utilizzato per continuare in una qualsiasi delle tre precedenti dichiarazioni

Quando combinato queste dichiarazioni coprire tutte le azioni che un utente richiede il completamento di un compito e l’esperienza del risultato.

Diamo un’occhiata ad alcuni esempi.,

Esempio 1

User story: Come utente, voglio essere in grado di recuperare la password del mio account, in modo da poter accedere al mio account nel caso in cui avessi dimenticato la password.,igated alla pagina di login

Quando: L’utente ha selezionato dimenticato password opzione

E: Inserite un indirizzo email valido per ricevere un link per il recupero della password

Quindi: Il sistema ha inviato il link per email inserito

: L’utente ha ricevuto il link via e-mail

Quando: L’utente navigato attraverso il link ricevuto nella e-mail

Quindi: Il sistema consente all’utente di impostare una nuova password

Esempio 2

User story: Come utente, voglio essere in grado di richiedere il denaro dal mio conto in ATM, in modo tale da essere in grado di ricevere il denaro dal mio conto in fretta e in luoghi diversi.,coperchio

E: il dispenser contiene cassa

Quando: il cliente richieda la cassa

: – garantire il conto viene addebitato

E: assicurarsi che la cassa è dispensato

E: verificare che la scheda viene restituito

i criteri di Accettazione 2:

Date: che il conto è in rosso

E: la carta è valida

Quando: il cliente richieda la cassa

: – garantire il rifiuto viene visualizzato il messaggio

E: garantire il denaro non è dispensato

Regola-oriented criteri di accettazione formato

In alcuni casi, e ‘ difficile inserire i criteri di accettazione in Data/Quando/Poi la struttura., Ad esempio, GWT sarebbe difficilmente utile per i seguenti casi:

• Stai lavorando con storie utente che descrivono la funzionalità a livello di sistema che richiede altri metodi di garanzia della qualità.
• Il target di riferimento per i criteri di accettazione non ha bisogno di dettagli precisi degli scenari di test.
• Gli scenari GWT non si adattano alla descrizione dei vincoli di progettazione e esperienza utente di una funzionalità. Gli sviluppatori possono perdere una serie di dettagli critici.

È possibile risolvere questi casi con il formato AC orientato alle regole.,

La forma orientata alle regole implica che esiste un insieme di regole che descrivono il comportamento di un sistema. Sulla base di queste regole, è possibile disegnare scenari specifici.

Di solito, i criteri composti usando questo modulo sembrano un semplice elenco puntato. Diamo un’occhiata a un esempio.

Esempio

User story: come utente, voglio usare un campo di ricerca per digitare una città, un nome o una strada, in modo da poter trovare le opzioni di hotel corrispondenti.,

Criteri di accettazione dell’interfaccia di ricerca di base

• Il campo di ricerca viene posizionato sulla barra superiore
• La ricerca inizia quando l’utente fa clic su “Cerca”
• Il campo contiene un segnaposto con un testo di colore grigio: “Dove stai andando?”
• Il segnaposto scompare quando l’utente inizia a digitare
• La ricerca viene eseguita se un utente digita in una città, un nome di hotel, una strada o tutto combinato
• La ricerca è in inglese, francese, tedesco e ucraino
• L’utente non può digitare più di 200 simboli
• La ricerca non supporta simboli speciali (caratteri)., Se l’utente ha digitato un simbolo speciale, mostrare il messaggio di avviso: “L’input di ricerca non può contenere simboli speciali.”

Altri formati

La maggior parte delle storie utente possono essere coperti con due formati di cui sopra. Tuttavia, puoi inventare i tuoi criteri di accettazione dato che servono ai loro scopi, sono scritti chiaramente in inglese semplice e non possono essere male interpretati. Alcune squadre usano anche testo normale.,

A volte, i criteri possono essere specificati come esempio di comportamento del sistema:

Un semplice set di AC per password complesse da Mark Levison per agilepainpainrelief.com

Questo approccio fornisce linee guida chiare per il test delle funzionalità password.

Ruoli responsabili e modalità di creazione dei criteri di accettazione

Alcuni dei criteri sono definiti e scritti dal proprietario del prodotto quando crea il product backlog. E gli altri possono essere ulteriormente specificati dal team durante le discussioni sulle storie degli utenti dopo la pianificazione dello sprint., Non ci sono raccomandazioni rigorose per scegliere la persona responsabile della scrittura dei criteri. Il cliente può documentarli se ha ampie conoscenze tecniche e di documentazione di prodotto. In questo caso, il cliente negozia i criteri con il team per evitare malintesi reciproci. In caso contrario, i criteri vengono creati da un product owner, un business analyst, un requirements analyst o un project manager.,

Il processo inizia con la priorità della storia dell’utente e termina con la negoziazione dei dettagli con l’intero team

Principali sfide e migliori pratiche di scrittura dei criteri di accettazione

I criteri di accettazione sembrano molto facili da scrivere. Nonostante i loro formati semplicistici, la scrittura rappresenta una sfida per molte squadre. Diamo uno sguardo più profondo alle migliori pratiche che aiutano a evitare errori comuni.

Criteri del documento prima dello sviluppo. I criteri di accettazione devono essere documentati prima dell’inizio dello sviluppo effettivo., In questo modo, il team probabilmente catturerà tutte le esigenze dei clienti in anticipo. All’inizio, è sufficiente impostare i criteri per un piccolo numero di storie utente per riempire i backlog per due sprint (se si pratica Scrum o un metodo simile). Devono essere concordati da entrambe le parti. Quindi i criteri di accettazione documentati vengono utilizzati dagli sviluppatori per pianificare il processo tecnico.

Non rendere AC troppo stretto. I criteri di accettazione possono essere troppo specifici per vivere poco o nessun opzioni di manovra per gli sviluppatori. Per evitare ciò, ricorda che AC deve trasmettere l’intento ma non una soluzione finale., Inoltre, l’AC stretto può essere privo di più comportamenti degli utenti che non sono coperti.

Mantieni i tuoi criteri realizzabili. Questo punto si interseca strettamente con il precedente. Criteri di accettazione efficaci definiscono il blocco minimo ragionevole di funzionalità che è possibile fornire. Ma nel caso in cui soccombi a descrivere tutti i piccoli dettagli, c’è il rischio che la tua squadra rimanga bloccata con centinaia di piccoli compiti.

Mantenere AC misurabile e non troppo ampio. Ampi criteri di accettazione rendono vaga una storia utente., Criteri di accettazione efficaci devono delineare lo scopo del lavoro in modo che gli sviluppatori possano pianificare e stimare correttamente il loro sforzo.

Evitare dettagli tecnici. Come abbiamo detto, i criteri di accettazione devono essere scritti in inglese semplice. Ciò li renderà chiari e facili da capire per tutti: i tuoi stakeholder o manager potrebbero non avere un background tecnico.

Raggiungere il consenso. Lo stesso problema può può essere risolto in modo diverso da un team e le parti interessate, a seconda dei loro punti di vista. Assicurati di aver comunicato il tuo AC alle parti interessate e raggiunto un accordo reciproco., Lo stesso vale per i membri del team. Tutti devono rivedere l’AC e confermare di comprendere e concordare con ogni riga.

Scrivere testabile AC. Ciò consentirà ai tester di verificare che tutti i requisiti siano stati soddisfatti. In caso contrario, gli sviluppatori non capiranno se la storia utente è completata.

Final word

Non trascurare i criteri di accettazione in quanto – essendo semplici e accessibili – risolvono più problemi contemporaneamente., Documentano le aspettative dei clienti, forniscono una prospettiva per l’utente finale, chiariscono i requisiti e prevengono l’ambiguità e, infine, aiutano il quality assurance a verificare se gli obiettivi di sviluppo sono stati raggiunti. Indipendentemente dal fatto che si utilizzino metodi Agili o meno, assicurarsi di scegliere il formato migliore o sperimentare con quelli propri. Diversi tipi di storie utente e, infine, le caratteristiche possono richiedere diversi fromats e testare quelli nuovi che funzionano per voi è una buona pratica.