Che cosa sono i criteri di accettazione? Come scrivere condizioni su cui tutti sono d'accordo

I criteri di accettazione sono le condizioni che un pezzo di lavoro deve soddisfare prima che qualcuno lo dichiari finito. Si scrivono prima che il lavoro cominci, li scrive chi lo chiede e si concordano con chi lo costruirà e lo collauderà.

Il loro compito è spostare una discussione più indietro nel tempo. Senza di essi, “è finito?” si decide dopo il lavoro, e lo decide chi ci crede di più. Con essi era già deciso prima, da persone che erano tranquille.

Che cosa non sono

Non sono una descrizione della funzione. “L’utente può filtrare il rapporto” è un riassunto. Un criterio dice che cosa deve essere vero: quali filtri, che cosa succede quando nessuno corrisponde, in che stato ci si ritrova dopo un ricaricamento.

Non sono un progetto grafico. I criteri descrivono risultati, non impaginazioni. “Un menù a tendina in alto a destra” decide la soluzione e la toglie a chi è nella posizione migliore per sceglierla.

Non sono casi di test. Un criterio è una condizione; un caso di test è una procedura per verificarne una. Da un solo criterio pendono di solito più casi di test, e vengono scritti dopo, da qualcuno che può non essere la stessa persona.

I due formati che si usano

Un elenco di controllo è il più semplice dei due, e per la maggior parte del lavoro basta.

Fatto quando:
- Una persona autenticata vede solo i propri ordini
- Un ordine senza righe compare comunque, con un totale di 0,00
- L'elenco si carica entro due secondi per un account con 10.000 ordini
- L'ordinamento per data regge da una pagina di risultati all'altra

Dato, quando, allora è più formale, e la cerimonia in più si ripaga quando il comportamento dipende dallo stato.

Dato un cliente con una carta scaduta
Quando invia il modulo di pagamento
Allora il pagamento viene rifiutato
E i campi della carta mantengono i valori che ha inserito
E il messaggio dice quale campo correggere

Il valore sta nel dato. La maggior parte dei malintesi vive nello stato di partenza - un account di prova, un token scaduto, un elenco vuoto - e non nell’azione, e il formato costringe qualcuno a nominarlo.

Nessuno dei due è migliore. Usate l’elenco di controllo come impostazione predefinita e ricorrete a dato-quando-allora dove la stessa azione deve comportarsi in modo diverso a seconda della situazione.

Che cosa separa un criterio buono da uno cattivo

La prova è se due persone potrebbero non essere d’accordo sul fatto che sia soddisfatto.

Debole

La pagina dovrebbe caricarsi in fretta e mostrare risultati pertinenti

Meglio

La prima pagina di risultati compare entro due secondi per un account con 10.000 ordini, e mostra solo gli ordini di quell'account

Quattro abitudini producono quasi tutti quelli deboli:

• Aggettivi invece di soglie. Veloce, intuitivo, robusto, facile da usare. Nessuno può essere verificato; su tutti si può discutere.
• Solo il percorso felice. I criteri che descrivono che cosa succede quando tutto funziona lasciano ogni fallimento al giudizio di qualcuno alle quattro del pomeriggio del giorno del rilascio.
• Soluzioni. “Aggiungere una finestra di conferma” invece di “l’utente non può eliminare una fattura senza confermare”.
• Tutto in una volta. Una storia con diciannove criteri sono più storie, e resterà a metà per due settimane.

Chi li scrive, e quando

Li scrive chi chiede il lavoro, e si concordano prima che qualcuno cominci. È la parte che i team saltano, e saltarla è quello che trasforma un compito di due giorni in una settimana di chiarimenti.

Non deve essere per forza pesante. Uno sviluppatore che legge la bozza e chiede “che cosa dovrebbe succedere se non ha ancora nessun ordine?” è l’intero processo che funziona: la domanda costa poco adesso e costa cara quando il codice esiste già.

Scriveteli dove vive il lavoro, non in un messaggio di chat. I criteri che esistono solo nel ricordo che qualcuno ha di una riunione producono esattamente la discussione che dovevano evitare.

Dove finiscono per contare

Due posti, e sono il motivo per cui ne vale la pena.

L’accettazione. Chi esegue il collaudo di accettazione ha bisogno di qualcosa rispetto a cui accettare. Senza criteri diventa un sondaggio di opinioni su un software che qualcuno ha già pagato.

Il triage dei bug. La discussione più noiosa del software è se una cosa sia un difetto o una richiesta di modifica, e la decide quello che era stato concordato. Un difetto è un comportamento che contraddice un criterio; tutto il resto è una richiesta nuova, per quanto ragionevole. I team senza criteri scritti fanno quella discussione una volta per rilascio, per sempre.

È anche il motivo per cui la segnalazione di un difetto dovrebbe dire che cosa ci si aspettava oltre a che cosa è successo - è la stessa frase del criterio che contraddice.

La guida alla segnalazione di bug copre il resto di quello che quella segnalazione richiede, e il suo modello ha una riga per il comportamento atteso.

La versione breve

Condizioni, scritte prima del lavoro, concordate fra chi lo ha chiesto e chi lo costruirà, abbastanza precise perché due persone non possano essere in disaccordo sul fatto che siano soddisfatte. Un elenco di controllo di solito basta; dato-quando-allora quando lo stato di partenza decide il risultato. Coprite che cosa succede quando le cose falliscono, non solo quando funzionano.