📋 Indice dei Contenuti
1. Cosa sono gli Acceptance Criteria
Gli Acceptance Criteria sono condizioni specifiche e misurabili che devono essere soddisfatte affinché una User Story possa essere considerata completa. Rappresentano il contratto tra il team di sviluppo e il Product Owner.
🎯 Scopo degli Acceptance Criteria
- Chiarezza: Eliminano ambiguità sui requisiti
- Testabilità: Forniscono criteri oggettivi di verifica
- Completezza: Definiscono quando una story è "finita"
- Comunicazione: Allineano team e stakeholder
🔗 Perché è importante
Evita ambiguità
Previene il classico "ah ma io intendevo un'altra cosa"
Esplicita chi e cosa
Chiarisce chi usa la funzione, cosa fa ed evidenzia perché serve
Semplifica stime
Facilita la stima di tempo e priorità per il team
🤔 Abbiamo finito? No ;)
Ci mancano i dettagli, o meglio, i "Criteri di Accettazione" (Acceptance Criteria). Questi criteri non vanno "raccontati" in forma discorsiva ma elencati, come condizioni, per comprendere quando una funzionalità possiede tutte le caratteristiche che desideriamo per considerare la funzionalità completata.
2. Formato BDD (Given-When-Then)
Il formato Given-When-Then è lo standard del Behavior Driven Development (BDD). Struttura gli Acceptance Criteria in modo logico e testabile.
Struttura Standard BDD (Behavior Driven Development)
GIVEN [contesto iniziale/precondizioni]
WHEN [azione/evento scatenante]
THEN [risultato atteso/postcondizioni]🔍 Anatomia di un AC Perfetto
GIVEN (Contesto)
Stabilisce le precondizioni necessarie per il test:
- Stato iniziale del sistema
- Dati pre-esistenti
- Permessi utente
- Configurazioni attive
• GIVEN un utente autenticato come amministratore
• GIVEN un carrello con 3 prodotti
• GIVEN una connessione internet stabile
WHEN (Azione)
Descrive l'azione specifica che scatena il comportamento:
- Interazione utente
- Evento di sistema
- Trigger temporale
- Chiamata API
• WHEN clicca il pulsante "Elimina account"
• WHEN il sistema riceve un pagamento
• WHEN passano 30 giorni di inattività
THEN (Risultato)
Definisce il risultato atteso osservabile e verificabile:
- Cambiamenti UI
- Notifiche inviate
- Dati salvati/modificati
- Redirect o navigazione
• THEN appare una modale di conferma
• THEN l'utente riceve email di conferma
• THEN viene reindirizzato alla homepage
💡 Pro Tip: AND per Condizioni Multiple
Usa AND per aggiungere condizioni multiple nella stessa sezione:GIVEN un utente autenticato AND con permessi di amministratore
3. Esempi Dettagliati di Acceptance Criteria
Vediamo esempi reali di Acceptance Criteria per User Story comuni. Nota come ogni AC sia specifico, testabile e misurabile.
✔️ Per US-001: Moderazione Commenti
GIVEN un amministratore autenticato
WHEN accede alla sezione moderazione
THEN vede tutti i commenti in attesa di approvazione ordinati per data
GIVEN un commento in moderazione
WHEN l'admin clicca "Approva"
THEN il commento diventa visibile pubblicamente entro 2 secondi
GIVEN un commento inappropriato
WHEN l'admin clicca "Rifiuta" e inserisce una motivazione
THEN il commento viene archiviato e l'utente riceve una notifica email
GIVEN più di 10 commenti in moderazione
WHEN l'admin usa i filtri per data o parola chiave
THEN vede solo i commenti che corrispondono ai criteri
✔️ Per US-002: Notifiche Email
GIVEN un utente con notifiche attive
WHEN riceve un nuovo messaggio
THEN riceve un'email entro 5 minuti
GIVEN una notifica email generata
WHEN l'utente la riceve
THEN contiene mittente, anteprima messaggio e link diretto
GIVEN un utente che non vuole notifiche
WHEN disattiva le notifiche nelle impostazioni
THEN non riceve più email per nuovi messaggi
✔️ Per US-003: Assegnazione Lead
GIVEN un responsabile vendite autenticato
WHEN accede alla sezione lead
THEN può visualizzare l'elenco dei lead non assegnati
GIVEN un lead non assegnato
WHEN seleziona il lead e sceglie un membro del team dal menù a tendina
THEN il lead viene assegnato al membro selezionato
GIVEN un lead appena assegnato
WHEN l'assegnazione è completata
THEN il lead deve risultare visibile nel cruscotto dell'utente assegnato
GIVEN un'assegnazione completata
WHEN il sistema registra l'assegnazione
THEN l'utente assegnato riceve una notifica email con il template "template-assegnazione-lead"
GIVEN un'assegnazione effettuata
WHEN l'operazione è completata
THEN il sistema registra data, ora e responsabile che ha effettuato l'assegnazione
4. Best Practices per Acceptance Criteria Efficaci
Specifici e Misurabili
Evita termini vaghi come "veloce" o "facile". Usa numeri e criteri oggettivi.
✅ Specifico: "La pagina si carica entro 2 secondi"
Testabili
Ogni criterio deve essere verificabile oggettivamente da QA o stakeholder.
✅ Testabile: "Un nuovo utente completa la registrazione in <3 click"
Indipendenti
Ogni AC dovrebbe essere testabile separatamente dagli altri.
✅ Indipendente: "GIVEN un carrello con prodotti, WHEN..."
Completi
Coprono tutti gli scenari principali e edge case importanti.
• Happy path (caso normale)
• Error cases (errori previsti)
• Edge cases (casi limite)
• Boundary conditions (valori limite)
Comprensibili
Scritti in linguaggio business, non tecnico. Devono essere chiari per tutti.
✅ Business: "L'utente vede il proprio nome nel profilo"
Concordati
Approvati da Product Owner e team prima dello sviluppo.
1. Product Owner scrive AC iniziali
2. Team review e discussione
3. Raffinamento collaborativo
4. Approvazione finale condivisa
💡 Pro Tip: La Regola SMART per AC
Gli Acceptance Criteria dovrebbero essere:
- Specific - Specifici e dettagliati
- Measurable - Misurabili oggettivamente
- Achievable - Raggiungibili tecnicamente
- Relevant - Rilevanti per il valore della story
- Time-bound - Con tempistiche definite quando necessario
5. Errori Comuni da Evitare
⚠️ Anti-Pattern negli Acceptance Criteria
❌ Troppo Generici
"GIVEN un utente sulla homepage, WHEN carica la pagina, THEN tutti gli elementi sono visibili entro 2 secondi"
❌ Troppo Tecnici
"GIVEN un utente che crea una password, WHEN salva l'account, THEN la password è archiviata in modo sicuro e non reversibile"
❌ Non Testabili
"GIVEN un nuovo utente, WHEN usa l'app per la prima volta, THEN completa la prima azione entro 3 click"
❌ Incompleti
• Login successful
• Password errata
• Account bloccato
• Primo accesso
🔍 Checklist di Validazione AC
Prima di approvare gli Acceptance Criteria, verifica che passino questi controlli:
- ☐ Ogni AC segue il formato Given-When-Then
- ☐ È possibile scrivere un test automatizzato per ogni AC
- ☐ Non contiene dettagli di implementazione tecnica
- ☐ È comprensibile a chi non era presente nelle discussioni
- ☐ Copre sia happy path che error cases
- ☐ Ha criteri di successo misurabili (tempi, quantità, stati)
- ☐ È stato approvato dal Product Owner
6. Acceptance Criteria vs Test Cases
Spesso c'è confusione tra Acceptance Criteria e Test Cases. Sono correlati ma hanno scopi diversi nel processo di sviluppo.
📋 Acceptance Criteria
"GIVEN un carrello con prodotti, WHEN l'utente clicca 'Checkout', THEN viene reindirizzato alla pagina di pagamento"
🧪 Test Cases
"1. Login con user: [email protected], pwd: Test123!
2. Aggiungi prodotto ID:1001 al carrello
3. Click su button[data-testid='checkout']
4. Assert: URL contiene '/payment'"
🔄 Relazione AC → Test Cases
Definisci comportamenti attesi in linguaggio business
Traduci ogni AC in test step dettagliati
Implementa test automatizzati basati sui test cases
7. Domande Frequenti
📊 Quanti Acceptance Criteria per User Story?
3-8 AC è il range ideale per la maggior parte delle User Story. Troppo pochi = story sotto-specificata, troppi = story troppo complessa.
👥 Chi scrive gli Acceptance Criteria?
È un processo collaborativo, ma con responsabilità chiare:
🔄 Posso modificare gli AC durante lo sviluppo?
Sì, ma con processo controllato. Gli AC possono evolversi, ma i cambiamenti devono essere documentati e approvati.
Scrivi cosa cambia e perché
Stima effort aggiuntivo e impatto su timeline
Product Owner e Scrum Master approvano
Aggiorna tutti gli stakeholder
🎯 Come gestire AC per API e servizi backend?
Per API e servizi, gli AC si concentrano su input, output e comportamentiosservabili, non su implementazione interna.
GIVEN dati validi (email unica, password forte)
WHEN POST /api/register
THEN risponde 201, crea utente, invia email conferma
GIVEN email già registrata
WHEN POST /api/register
THEN risponde 409 con messaggio "Email già in uso"
GIVEN password < 8 caratteri
WHEN POST /api/register
THEN risponde 400 con dettagli errori validazione
✅ Hai bisogno di supporto per gli Acceptance Criteria?
Il nostro team può aiutarti a implementare un processo di definizione degli Acceptance Criteria efficace e training BDD per il tuo team.