Cosa sono i criteri di accettazione? Definizione ed esempi

Criteri di accettazione

In inglese: Acceptance criteria

Detto anche: criterio di accettazione, AC

Definizione

Le condizioni specifiche e verificabili che una user story o una funzionalità deve soddisfare per essere accettata come completa dal product owner.

I criteri di accettazione sono le condizioni che stabiliscono quando una user story è “fatta” dal punto di vista del business. Ogni criterio è un’affermazione chiara e verificabile, con un esito di superamento o fallimento. Vengono concordati durante il refinement, prima che inizi lo sviluppo, e diventano il punto di partenza per gli scenari di test e i controlli automatizzati.

Esempio

Story: come cliente, voglio applicare un codice sconto al checkout per pagare il prezzo promozionale.

Formato a regole:

Un codice valido e non scaduto riduce il totale dell’ordine della percentuale prevista dal codice.
Un codice scaduto mostra “This code has expired” e non modifica il totale.
Si può applicare un solo codice per ordine; applicarne un secondo sostituisce il primo.
I codici non distinguono maiuscole e minuscole (SAVE10 e save10 sono equivalenti).

Lo stesso criterio sul codice scaduto in formato Given/When/Then:

Scenario: Expired discount code is rejected
  Given my cart total is $50.00
  And the code "SPRING10" expired yesterday
  When I apply the code "SPRING10"
  Then I see the message "This code has expired"
  And my cart total is still $50.00

Criteri di accettazione e Definition of Done

I criteri di accettazione sono specifici di una singola story: cosa deve fare questa funzionalità. La Definition of Done vale per tutte le story: codice revisionato, test automatizzati, documentazione aggiornata, rilascio in staging. Una story è completa solo quando soddisfa entrambi.

Scrivere buoni criteri

Verificabili. “La pagina si carica velocemente” non è verificabile; “la pagina dei risultati viene renderizzata entro 2 secondi con 1.000 prodotti sul dataset di staging” lo è.
Comportamento, non implementazione. Descrivi i risultati, non quale tabella del database cambia.
Includi i casi negativi. Input non validi, permessi e messaggi di errore fanno parte della funzionalità.
Concordati dai three amigos. Product, sviluppo e testing li rivedono insieme. È qui che i tester portano più valore, chiedendo “cosa succede se…?” prima che venga scritto il codice.