Criteri di Accettazione Given-When-Then Spiegati

Ecco come funziona la struttura:

• Given definisce ciò che deve già essere vero prima che l’utente finale faccia qualsiasi cosa. 
• When introduce l’azione. È ciò che fa l’utente o l’evento che il sistema attiva.
• Then mostra il risultato. È l’esito che dimostra che il sistema ha risposto correttamente.

Come scrivere i criteri di accettazione Given-When-Then

Come scrivere ogni clausola affinché sia valida durante lo sviluppo e i test del software.

Given: Definire il contesto e le precondizioni

La clausola given descrive ciò che deve già essere vero. Include lo stato del sistema, il ruolo dell’utente, le condizioni sui dati e la configurazione ambientale. Le dichiarazioni given efficaci sono specifiche. Evita di scrivere "Dato che l’utente è autenticato" quando lo scenario dipende dal ruolo. Meglio scrivere "Dato che un cliente registrato con un abbonamento valido si trova nella pagina delle impostazioni dell’account".

Alcune linee guida per la scrittura della clausola given:

• Specifica il ruolo o la persona utente quando è importante.
• Indica le condizioni del sistema come flag di funzionalità, stati dei dati o connettività.
• Combina più precondizioni con "e" invece di inserirle tutte in un’unica clausola.

When: Definire l’azione o il trigger

La clausola when cattura l’azione o l’evento che scatena il comportamento da testare. Dovrebbe descrivere una sola interazione dell’utente o un evento di sistema, mai una sequenza. Usa il voce attiva. Scrivi "Quando il cliente clicca su 'Applica Coupon'" invece di "Quando viene cliccato il pulsante del coupon". Così si elimina ambiguità su chi compie l’azione.

Mantieni questa clausola concisa. Se hai bisogno di più di una when, probabilmente stai descrivendo due scenari diversi. Suddividili.

Then: Specificare l’esito atteso

La clausola then definisce ciò che l’utente dovrebbe osservare o cosa deve fare il sistema dopo l’azione. Descrivi risultati osservabili. "Allora si carica la dashboard" è debole. "Allora il sistema visualizza la dashboard del cliente entro due secondi" è verificabile. Includi specifiche come messaggi di errore, pagine di reindirizzamento, modifiche ai dati, invii di email o cambiamenti nello stato dell’interfaccia.

Usa E per concatenare più risultati quando una singola azione produce più riscontri osservabili. Ad esempio, "Allora viene visualizzata la pagina di conferma dell’ordine" E "il cliente riceve un’email di conferma entro 60 secondi."

Guida con Intelligenza nell'Era dell'AI

Unisciti alla community DPM per accedere a contenuti esclusivi, template pratici, eventi riservati ai membri e approfondimenti settimanali sulla leadership: è gratis.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Company

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Esempi di Given-When-Then

Ecco alcuni esempi di criteri di accettazione given-when-then in diversi ambiti.

Login Utente

Scenario 1: Accesso riuscito con credenziali valide

Dato che un utente registrato è sulla pagina di login Quando l’utente inserisce un’email valida e la password corretta e clicca su "Accedi" Allora il sistema reindirizza l’utente alla dashboard del suo account

La clausola given qui è volutamente snella perché lo scenario non dipende dal tipo di abbonamento o dallo stato dell’account. Nota la clausola when composta: inserire le credenziali e cliccare sul pulsante sono una singola azione logica (l’invio di un form di login), per questo la tengo insieme invece di separarla in uno scenario per ogni tasto premuto.

Scenario 2: Accesso fallito con credenziali non valide

Dato che un utente registrato si trova sulla pagina di accesso Quando l'utente inserisce un'email valida e una password errata e clicca su "Accedi" Allora il sistema mostra il messaggio "Email o password non validi" E l'utente rimane sulla pagina di accesso

La clausola "Allora" specifica il testo esatto del messaggio di errore. La seconda clausola "E" è importante perché conferma che l'utente non viene accidentalmente reindirizzato altrove.

Carrello e Checkout

Scenario 1: Aggiunta di un articolo al carrello

Dato che un cliente sta visualizzando la pagina di dettaglio di un prodotto disponibile Quando il cliente clicca su "Aggiungi al carrello" Allora l'icona del carrello si aggiorna mostrando un articolo E appare un messaggio di conferma con il testo "Articolo aggiunto al carrello"

La clausola "dato" include "disponibile" perché il comportamento è diverso per gli articoli esauriti, che rappresentano uno scenario separato.

Scenario 2: Applicazione di un codice sconto valido

Dato che un cliente ha due articoli nel carrello per un totale di $80.00 Quando il cliente inserisce il codice sconto "SAVE20" e clicca su "Applica" Allora il sistema applica uno sconto del 20% E il totale del carrello si aggiorna a $64.00

Gli importi in dollari specifici evitano possibili malintesi. Questo tipo di scenario relativo agli sconti può aiutare a individuare un bug di arrotondamento in produzione, dove uno sconto percentuale su un totale dispari generava un prezzo con tre cifre decimali. La precisione della clausola "dato" ($80.00) e di quella "allora" ($64.00) è ciò che rende lo scenario prezioso.

Recupero Password

Scenario 1: Richiesta di reset della password con un'email registrata

Dato che un utente si trova sulla pagina di accesso Quando l'utente clicca su "Password dimenticata", inserisce un indirizzo email registrato e clicca su "Invia" Allora il sistema mostra "È stato inviato un link di reset alla tua email" E il sistema invia un'email di reset password entro 60 secondi

Il "quando" composto qui rappresenta un unico flusso logico: la richiesta di reset. Il vincolo temporale di 60 secondi nella clausola "allora" è fondamentale. Senza di esso, un'email di reset che arriva 20 minuti dopo tecnicamente "passerebbe". Gli esiti vincolati dal tempo sono uno dei dettagli più frequentemente omessi.

Scenario 2: Utilizzo di un link di reset scaduto

Dato che un utente ha ricevuto un'email di reset password più di 24 ore fa Quando l'utente clicca sul link di reset nell'email Allora il sistema mostra "Questo link è scaduto. Si prega di richiedere un nuovo reset."

La clausola "dato" incorpora una condizione temporale, il che obbliga a discutere su quale debba essere il periodo di validità del link.

Validazione dei Moduli

Scenario 1: Invio di un modulo con campi obbligatori mancanti

Dato che un utente si trova sul modulo di registrazione Quando l'utente lascia vuoto il campo "Email" e clicca su "Invia" Allora il sistema mostra un errore inline "L'email è obbligatoria" sotto il campo Email E il modulo non viene inviato

La clausola "allora" specifica dove compare l'errore ("sotto il campo Email"), non solo che appare. 

Scenario 2: Superamento del limite di caratteri in un campo di testo

Dato che un utente sta compilando il campo "Biografia" con un limite di 500 caratteri Quando l'utente inserisce 501 caratteri Allora il sistema impedisce ulteriori inserimenti E compare il messaggio "Massimo 500 caratteri consentiti"

GWT vs. Checklist vs. Casi d'Uso

Ecco altri tipi di criteri di accettazione e quando potresti usare ciascuno di essi:

Ho scoperto che gli use case danno il massimo quando bisogna documentare un sistema per la conformità normativa o consegnarlo a un fornitore esterno. Per il lavoro quotidiano negli sprint, il given-when-then è più snello e rapido.

Quando usare ciascun formato

Il formato giusto dipende dai membri del team, dal progetto e dalla storia.

• Usa GWT quando la storia riguarda il comportamento dell’utente con trigger e risultati chiari, quando prevedi di automatizzare i test di accettazione o scenari di test con strumenti di behavior-driven development (BDD), oppure quando sviluppatori e QA devono condividere una definizione precisa di “done” (DoD).

• Usa una checklist quando la storia copre rifiniture UI, semplici configurazioni, regole di business senza un flusso utente oppure requisiti non funzionali come soglie di performance.

• Usa un use case quando la funzionalità è complessa con molti flussi ramificati, quando documenti per team esterni o la conformità, oppure quando le parti interessate hanno bisogno di una documentazione formale.

Best practice per Given-When-Then

Ecco alcune best practice per aiutarti a usare GWT in modo efficace:

• Evita un linguaggio vago o ambiguo: Invece di “Then la pagina si carica velocemente”, scrivi “Then la pagina dei risultati di ricerca si carica entro due secondi.” Sostituisci aggettivi come “appropriato” o “rilevante” con valori misurabili. Se non puoi testarlo, riscrivi la frase.
• Mantieni gli scenari semplici e focalizzati: Segui la regola un comportamento per scenario. Ogni scenario deve testare esattamente una cosa. Quando combini più azioni o risultati, crei casi di test difficili da debuggare e mantenere. Se uno scenario ha più di due and nella clausola then, chiediti se stai davvero testando un solo comportamento o due.
• Fai una sessione three-amigos: Una sessione three-amigos è una breve e mirata conversazione in cui una persona di prodotto (product owner o business analyst), uno sviluppatore e un tester rivedono insieme le storie in arrivo prima dell'inizio dello sprint. Scrivono o raffinano insieme i criteri GWT, prevenendo così il rework. 
• Mantieni coerenza nella terminologia e nello stile: Scegli termini standard e usali in ogni storia. Se usi "cliente" in uno scenario e "utente" in un altro, crei confusione. Crea un piccolo glossario se necessario. Utilizza la stessa struttura di frase nelle clausole.

Cinque Anti-Pattern Comuni

Ecco alcuni errori comuni da evitare quando si scrivono criteri di accettazione given-when-then:

1. Scrivere dettagli di implementazione invece del comportamento: Scenari come "Dato che la chiamata API restituisce un codice di stato 200" descrivono l'implementazione tecnica, non il comportamento dell'utente. Riscrivi dal punto di vista dell'utente: "Dato che il catalogo prodotti è stato caricato nella homepage." Salva i dettagli tecnici per il codice dei test automatizzati.
2. Raggruppare più scenari in uno solo: Uno scenario che testa accesso, navigazione e acquisto in un unico blocco è un test di integrazione, non un criterio di accettazione. Suddividi ogni comportamento nel proprio scenario. Otterrai risultati più chiari e debug più semplici.
3. Saltare scenari negativi e casi limite: I team agili spesso scrivono solo il percorso positivo e dimenticano cosa accade quando le cose vanno storte. Per ogni scenario di successo, chiediti: cosa succede se l'input è non valido? E se la rete cade? E se i dati sono mancanti? Scrivi almeno uno scenario negativo per ogni storia, per intercettare problemi prima che arrivino in produzione.
4. Considerare GWT come l'unico formato accettabile: Usa GWT per il comportamento e le checklist per tutto il resto. Se forzi ogni storia in un dato-quando-allora, incluse le variazioni di colore dei pulsanti, aggiornamenti di testo e configurazione delle infrastrutture, otterrai risultati assurdi (es. "Dato che la homepage esiste, Quando l'utente la visualizza, Allora il font dell'intestazione è 16px.").
5. Scrivere scenari in isolamento: Non scrivere i criteri GWT da solo. Il valore del formato deriva dalla conversazione che genera. Se i tuoi scenari non vengono discussi da almeno due discipline prima dell'inizio dello sviluppo del software, stai usando GWT come formato di documentazione mentre il suo vero potere è come formato di collaborazione.

E adesso?

Criteri di accettazione chiari secondo la formula dato-quando-allora sono solo una parte del successo di un progetto. Costruisci su questa base con una membership gratuita DPM e accedi a template pratici, risorse degli esperti e framework comprovati che ti aiutano a trasformare requisiti ben definiti in una delivery più fluida e risultati più solidi.