Prima: una richiesta troppo vaga
Non sappiamo se il tema deve seguire il sistema operativo, se serve un interruttore, dove salvare la preferenza, quali pagine cambiare e come verificare il risultato.
Aggiungi la modalità scura al sito e rendila bella.Le domande che mancano
- Qual è il risultato visibile per l’utente?
- Quali pagine o componenti rientrano nello scope?
- Quale comportamento deve avere al primo accesso?
- La preferenza deve essere ricordata?
- Cosa non deve essere modificato?
- Come controlliamo accessibilità, mobile e assenza di regressioni?
Dopo: un task implementabile
Goal:
Aggiungi un selettore chiaro/scuro al sito esistente.
User flow:
1. L’utente apre il menu principale.
2. Seleziona il tema chiaro o scuro.
3. Il tema cambia subito e resta selezionato alle visite successive.
Scope:
- Header e stili globali.
- Tutte le pagine già raggiungibili dal menu.
- Salvataggio della preferenza in localStorage.
Constraints:
- Al primo accesso usa la preferenza del sistema operativo.
- Non aggiungere librerie.
- Mantieni contrasto leggibile e focus visibile.
- Non modificare copy, routing o struttura delle pagine.
Acceptance criteria:
- Il selettore è utilizzabile con mouse e tastiera.
- La preferenza sopravvive al reload.
- Nessun testo diventa illeggibile nei due temi.
- Il layout non presenta overflow a 390 px.
- La build di produzione passa.
Verification:
- Prova primo accesso, cambio tema e reload.
- Controlla home e una pagina interna su desktop e mobile.
- Riporta eventuali parti non verificate.La formula riusabile
- Scrivi il goal in una frase orientata al risultato.
- Descrivi il flusso dal punto di vista dell’utente.
- Definisci scope e non-goals.
- Aggiungi i vincoli tecnici o di prodotto davvero importanti.
- Trasforma “deve funzionare” in criteri osservabili.
- Indica come verificare il lavoro.
Acceptance criteria: il confine tra “sembra fatto” e “è verificato”
Gli acceptance criteria descrivono cosa deve essere vero perché una modifica possa essere considerata completata. Non richiedono linguaggio tecnico: richiedono risultati osservabili e una risposta sì o no.
La formula più semplice è: quando l’utente fa X, il prodotto mostra o esegue Y, rispettando il vincolo Z. In questo modo chi implementa sa dove fermarsi e chi verifica non deve basarsi su impressioni.
Da criteri vaghi a controlli eseguibili
Confronta le due versioni sullo stesso modulo. La seconda non impone come scrivere il codice, ma rende espliciti successo, errore, persistenza dei dati e accessibilità.
Prima:
- Il modulo deve funzionare bene.
- Deve essere semplice.
- Deve gestire gli errori.
Dopo:
- Il pulsante "Invia" resta disabilitato finché i campi obbligatori sono vuoti.
- Se l’email non è valida, compare un messaggio vicino al campo.
- Dopo un invio riuscito, l’utente vede una conferma e il modulo viene svuotato.
- Se l’invio fallisce, i dati inseriti restano nel modulo.
- A 390 px non compare scroll orizzontale.
- Tutti i campi sono raggiungibili usando solo la tastiera.Come scrivere acceptance criteria senza essere programmatore
- Parti dall’azione principale che l’utente vuole completare.
- Descrivi il risultato visibile dopo quell’azione.
- Aggiungi lo stato di errore o il caso limite più importante.
- Specifica dispositivi o condizioni che contano davvero.
- Usa verbi osservabili: appare, resta, viene salvato, è disabilitato.
- Evita di imporre una soluzione tecnica se ti interessa solo il risultato.
Quando usare Given / When / Then
Per flussi con più stati puoi rendere ancora più espliciti contesto, azione e risultato atteso.
Dato che il carrello contiene un prodotto
Quando l’utente rimuove quel prodotto
Allora il carrello mostra lo stato vuoto
E il totale non viene più visualizzatoControllo finale prima di passare il task
- Ogni criterio descrive un comportamento osservabile?
- È possibile rispondere sì o no senza interpretazioni?
- Sono presenti successo, errore e caso limite principale?
- Hai evitato parole vaghe come moderno, intuitivo, veloce o robusto?
- I criteri definiscono il risultato senza allargare inutilmente lo scope?
Fonte e metodo
Gli esempi sono adattati a task frontend reali. Il formato Given / When / Then segue la sintassi Gherkin documentata dal progetto Cucumber.