Verificare un flusso di approvazione con criteri di accettazione chiari

Descriva risultato e stato iniziale

Per ogni flusso importante definisca chi può agire, a quali condizioni e quale stato deve essere dimostrabile dopo. GOV.UK descrive i criteri di accettazione come risultati per verificare il bisogno dell’utente. Una promessa generale come «l’approvazione funziona» diventa verificabile con queste condizioni.

Esempio: approvare una richiesta interna di modifica

Il piano è interamente inventato. La richiesta CH-27 parte da draft, passa a pending con motivazione completa e può diventare approved tramite il revisore assegnato. Usi dati sintetici e account adatti in un ambiente di test controllato. La tabella contiene risultati attesi, non test eseguiti.

L’ultima riga presuppone un rifiuto certo prima della modifica. Se manca soltanto la risposta, lo stato salvato è inizialmente incerto; pianifichi un caso distinto sullo stato realmente salvato.

Verifichi stato, permessi e riscontro

Un pulsante nascosto non dimostra controllo degli accessi. OWASP richiede verifica adeguata dei permessi a ogni richiesta. Includa chiamate dirette e stato realmente salvato. Un messaggio di successo non basta.

Prepari ogni caso con stato iniziale definito. Playwright raccomanda test indipendenti con dati e sessioni controllati. Ruolo o stato precedente non devono determinare di nascosto il risultato successivo. Concordi con il team quali controlli dei componenti e flussi completi automatizzare.

Registri versione, ambiente, ruolo e dati usati. Separi risultati reali e riscontri dalle attese; un caso non eseguito resta aperto. Il responsabile aziendale valuti gli scostamenti e faccia ripetere i casi interessati dopo correzione.

Fonti

• GOV.UK: Writing user stories

• OWASP: Authorization checks

• Playwright: Best practices