Criteri di Accettazione

Due formati sono dominanti nei team di prodotto SaaS. Given-When-Then (sintassi Gherkin) è altamente strutturato e si mappa direttamente ai casi di test automatizzati: "DATO un utente loggato sulla dashboard, QUANDO clicca su 'Esporta', ALLORA un file CSV viene scaricato entro 5 secondi contenente tutte le colonne nella vista filtro corrente." Questo formato è preferito per interazioni utente complesse. Il formato Checklist è più semplice e veloce: un elenco puntato di condizioni (es. "Il pulsante appare solo per gli utenti Admin", "Le esportazioni rispettano il filtro data attivo", "Appare una notifica toast al completamento"). Le Checklist sono migliori per storie più piccole. Product Ops stabilisce lo standard per quale formato utilizzare e fornisce modelli nello strumento di gestione del progetto del team.

I criteri di accettazione di alta qualità condividono cinque proprietà: Specifici — descrivono un comportamento esatto, non un obiettivo vago ("Si carica in meno di 2 secondi" vs. "Si carica velocemente"). Verificabili — qualsiasi ingegnere o QA engineer può verificarli indipendentemente senza interpretazioni. Completi — coprono il happy path, gli stati di errore, i casi limite e le considerazioni sul controllo degli accessi. Concordati — vengono revisionati e approvati dall'Engineering prima che una storia entri nello sprint (non scritti unilateralmente dal PM). Concisi — sono il più brevi possibile pur rimanendo inequivocabili; criteri di accettazione lunghi spesso indicano che la storia è troppo grande e dovrebbe essere divisa. Product Ops verifica le storie per la completezza dei criteri di accettazione come parte del controllo del backlog "sprint-ready" prima di ogni cerimonia di pianificazione.

I criteri di accettazione fungono da fonte di verità per la garanzia di qualità. Ogni criterio dovrebbe corrispondere ad almeno un caso di test nella suite QA — sia automatizzato (unit, integration o end-to-end) che manuale (documentato nel piano di test). Quando i criteri di accettazione sono scritti in formato Gherkin, possono essere implementati direttamente come test automatizzati utilizzando framework come Cucumber o Cypress. Questa pratica — Behavior-Driven Development (BDD) — assicura che i criteri di accettazione scritti durante la pianificazione guidino effettivamente la verifica automatizzata, chiudendo il ciclo tra specifica e testing. Product Ops collabora con Engineering e QA per stabilire la pratica BDD e assicura che ogni storia che raggiunge lo stato "done" abbia un caso di test allegato per ogni criterio di accettazione.