Criteri di Accettazione Given-When-Then Spiegati

Ecco come funziona la struttura:

• Given indica ciò che deve già essere vero prima che l’utente finale faccia qualcosa. 
• When presenta l’azione. È ciò che fa l’utente o l’evento che attiva il sistema.
• Then svela l’esito. È il risultato che prova che il sistema ha risposto correttamente.

Come scrivere criteri di accettazione Given-When-Then

Come scrivere ogni clausola affinché sia solida durante lo sviluppo e la fase di 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 dei dati e la configurazione ambientale. Frasi 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".

Ecco alcune linee guida per scrivere la clausola given:

• Nomina il ruolo o la persona utente quando è rilevante.
• Indica lo stato del sistema come feature flag, stati dei dati o connettività.
• Combina più precondizioni con "E" invece di inserirle tutte in una sola frase.

When: definire l’azione o il trigger

La clausola when cattura l’azione o l’evento che scatena il comportamento che vuoi testare. Deve descrivere una singola interazione utente o un evento del sistema, non una sequenza. Usa il modo attivo. Scrivi "Quando il cliente clicca su 'Applica Coupon'" invece di "Quando il pulsante coupon viene cliccato". Così si elimina l’ambiguità su chi compie l’azione.

Tieni questa clausola concisa. Se hai bisogno di più di un when, probabilmente stai descrivendo due scenari separati. Separali.

Then: specificare l’esito atteso

La clausola then indica ciò che l’utente dovrebbe osservare o cosa dovrebbe fare il sistema dopo l’azione. Descrivi risultati osservabili. "Poi si carica la dashboard" è debole. "Poi il sistema mostra la dashboard del cliente entro due secondi" è testabile. Includi dettagli come messaggi d’errore, destinazioni di redirect, modifiche ai dati, invio di email, o cambiamenti nell’interfaccia utente.

Usa E per collegare più risultati quando una stessa azione produce effetti osservabili multipli. Ad esempio: "Poi viene visualizzata la pagina di conferma dell’ordine" E "il cliente riceve un’email di conferma entro 60 secondi".

Lead Smarter in the Age of AI

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

LinkedIn

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 vari contesti.

Login utente

Scenario 1: Login riuscito con credenziali valide

Dato che un utente registrato si trova nella pagina di accesso Quando l’utente inserisce un’email valida e la password corretta e clicca su "Accedi" Allora il sistema reindirizza l’utente alla dashboard del proprio account

La clausola given qui è volutamente essenziale perché lo scenario non dipende dal tipo di abbonamento o dallo stato dell’account. Nota la clausola when composta: inserire le credenziali e cliccare un pulsante è un’unica azione logica (l’invio del modulo di accesso), quindi la tengo insieme invece di dividere in due scenari distinti per ogni tasto premuto.

Scenario 2: Accesso fallito con credenziali non valide

Dato che un utente registrato si trova sulla pagina di login Quando l’utente inserisce una email valida e una password errata e clicca su "Accedi" Allora il sistema visualizza il messaggio "Email o password non valida" E l’utente resta sulla pagina di login

La clausola Allora specifica il testo esatto del messaggio di errore. La seconda clausola E è importante perché conferma che l'utente non viene reindirizzato accidentalmente 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 in magazzino Quando il cliente clicca su "Aggiungi al carrello" Allora l’icona del carrello si aggiorna mostrando un articolo E un messaggio di conferma recita "Articolo aggiunto al carrello"

La clausola dato include "disponibile in magazzino" perché il comportamento è diverso per gli articoli non disponibili, che costituiscono 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 specifici in dollari rendono impossibile un’interpretazione errata. Questo tipo di scenario per lo sconto può aiutare a individuare un bug di arrotondamento in produzione, dove uno sconto percentuale su un totale dispari produceva un prezzo con tre decimali. La precisione nella clausola dato ($80.00) e in quella allora ($64.00) è ciò che rende prezioso lo scenario.

Recupero Password

Scenario 1: Richiesta di reimpostazione della password con email registrata

Dato che un utente si trova sulla pagina di login Quando l’utente clicca su "Password dimenticata", inserisce un indirizzo email registrato e clicca su "Invia" Allora il sistema visualizza "Un link di reimpostazione è stato inviato alla tua email" E il sistema invia un’email per la reimpostazione della password entro 60 secondi

Il quando composto rappresenta qui un unico flusso logico: la richiesta di reimpostazione. La limitazione temporale di 60 secondi nella clausola allora è fondamentale. Senza di essa, una email che arriva dopo 20 minuti può "passare" tecnicamente. Gli esiti vincolati dal tempo sono uno dei dettagli più spesso omessi.

Scenario 2: Uso di un link di reimpostazione scaduto

Dato che un utente ha ricevuto l’email di reimpostazione password da più di 24 ore Quando l’utente clicca sul link di reimpostazione presente nell’email Allora il sistema visualizza "Questo link è scaduto. Si prega di richiedere una nuova reimpostazione."

La clausola dato contiene una condizione temporale, che costringe a discutere quale debba essere la finestra di scadenza.

Validazione dei Form

Scenario 1: Invio di un form 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 visualizza un messaggio di errore inline "Email obbligatoria" sotto il campo Email E il form non viene inviato

La clausola allora specifica dove appare 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 "Bio" con un limite di 500 caratteri Quando l’utente inserisce 501 caratteri Allora il sistema impedisce ulteriori inserimenti E viene visualizzato il messaggio "Massimo 500 caratteri consentiti"

GWT vs. Checklist vs. Casi d’Uso

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

Ho riscontrato che i use case funzionano meglio quando è necessario documentare un sistema per la conformità normativa o per passarlo a un fornitore esterno. Per il lavoro di sprint quotidiano, il formato given-when-then è più snello e veloce.

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 chiari trigger e risultati, quando prevedi di automatizzare i test di accettazione o scenari di test con strumenti di behavior-driven development (BDD), o quando è necessario che sviluppatori e QA condividano una definizione di done (DoD) precisa.

• Usa una checklist quando la storia riguarda dettagli grafici dell’UI, semplici configurazioni, regole di business senza un flusso utente, o requisiti non funzionali come soglie di performance.

• Usa un use case quando la funzionalità è complessa e con molti flussi ramificati, quando documenti per team esterni o per la compliance, o quando gli stakeholder hanno bisogno di una documentazione formale.

Best practice per Given-When-Then

Ecco alcune best practice per aiutarti a utilizzare efficacemente GWT:

• Evita linguaggio vago o ambiguo: Invece di “Then the page loads quickly”, scrivi “Then the search results page loads within two seconds.” Sostituisci aggettivi come “appropriato” o “rilevante” con valori misurabili. Se non puoi testarlo, riscrivilo.
• Tieni gli scenari semplici e mirati: Segui la regola di un solo comportamento per scenario. Ogni scenario deve testare un’unica cosa. Quando combini più azioni o risultati, crei casi di test difficili da mantenere e correggere. Se sotto "then" hai più di due and, chiediti se stai testando un comportamento o due.
• Organizza 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 affinano insieme i criteri GWT, prevenendo rielaborazioni. 
• Mantieni coerenza nella terminologia e nello stile: Scegli termini standard e usali in tutte le storie. Se usi “cliente” in uno scenario e “utente” in un altro, crei confusione. Se serve, crea un piccolo glossario. Mantieni la stessa struttura nelle frasi delle clausole.

Cinque anti-pattern comuni

Ecco alcuni errori comuni da evitare quando scrivi i criteri di accettazione given-when-then:

1. Scrivere dettagli di implementazione invece di comportamenti: Scenari come "Dato che la chiamata API restituisce un codice di stato 200" descrivono un'implementazione tecnica, non un comportamento utente. Riscrivi dal punto di vista dell'utente: "Dato che il catalogo prodotti è stato caricato sulla homepage." Lascia i dettagli tecnici al codice di automazione dei test.
2. Accorpare più scenari in uno solo: Uno scenario che testa login, navigazione e completamento dell'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 un debugging più semplice.
3. Dimenticare scenari negativi e ai margini: I team agili spesso scrivono solo il percorso "felice" e dimenticano cosa succede quando qualcosa va storto. Per ogni scenario di successo, chiediti: cosa succede se l'input non è valido? Cosa succede se la rete cade? Cosa succede se i dati mancano? Scrivi almeno uno scenario negativo per ogni storia per individuare problemi prima che arrivino in produzione.
4. Considerare GWT come unico formato accettabile: Usa GWT per i comportamenti e utilizza checklist per tutto il resto. Se costringi ogni storia nel formato dato-quando-allora, inclusi cambi di colore dei bottoni, aggiornamenti del testo o configurazione dell'infrastruttura, finirai per ottenere risultati assurdi (ad es. "Dato che esiste la homepage, 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 stimola. Se i tuoi scenari non vengono discussi almeno da due discipline prima dell’inizio dello sviluppo software, stai usando GWT come un formato di documentazione quando, invece, il suo vero potere risiede nella collaborazione.

E ora?

Criteri di accettazione dati-quando-allora chiari sono solo una parte della realizzazione di progetti di successo. Costruisci su queste basi con una membership DPM gratuita e ottieni accesso a modelli pratici, risorse di esperti e framework comprovati che aiutano a trasformare requisiti ben definiti in una consegna più fluida e risultati più solidi.