Come creare una checklist di accettazione da una demo registrata
Trasforma la demo in una checklist con condizioni, azioni, risultati attesi ed evidenze. Con un esempio basato sui requisiti concordati.
Una demo riuscita copre gli scenari mostrati
Durante la chiamata il modulo sembrava inviare correttamente la richiesta. L’uso con un ruolo diverso, un invio ripetuto o un campo obbligatorio vuoto potrebbero essere rimasti fuori. La registrazione conserva ciò che è stato mostrato. Gli altri casi vanno verificati.
La checklist parte da requisiti concordati in precedenza. Una nuova idea del pubblico può essere utile, ma registrala a parte. Se il perimetro cambia durante l’accettazione, il team finisce per discutere versioni diverse dell’incarico.
Prepara la verifica dalla registrazione
Registra versione e condizioni
Indica versione o build, chi ha svolto la demo e con quale ruolo. Descrivi i dati e l’ambiente di prova in modo che un’altra persona possa ripetere lo scenario. Segnala le condizioni ignote.
Collega il controllo a un requisito
Individua nella registrazione il comportamento concordato. Una demo può coprire più controlli, ciascuno con il proprio risultato atteso. Aggiungi come «non testato» ogni requisito obbligatorio che non è stato mostrato.
Descrivi l’azione e il risultato atteso
Al posto di «controllare il modulo», scrivi quali dati inserire, che cosa premere e che cosa deve succedere. Specifica la reazione a un input non valido. Includi un nuovo caso limite solo se rientra nel perimetro.
Ripeti la verifica
Esegui i casi sulla versione concordata, registra il risultato reale e allega l’evidenza. Distingui errori, controlli bloccati e dati mancanti. Dopo una correzione ripeti il caso e annota la nuova data.
Accettazione di un modulo di richiesta di consulenza
L’esempio è fittizio. Nomi, condizioni e risultati servono a spiegare il metodo.
Il telefono è obbligatorio. Se l’invio riesce, la richiesta appare in elenco e il visitatore vede una conferma. Senza telefono il modulo deve bloccare l’invio.
Ci sono tre esiti osservabili: convalida del campo, creazione della richiesta e conferma al visitatore. Una schermata ben fatta dopo il clic prova una sola parte.
Se il tester non ha accesso all’elenco, segna la creazione come «bloccata». Le parole del presentatore non bastano a segnare il controllo come superato.
| Verifica | Risultato atteso | Che cosa conservare |
|---|---|---|
| Telefono vuoto | Avviso di campo obbligatorio e nessuna richiesta creata | Schermata e controllo dell’elenco |
| Dati validi | Una richiesta con i valori inseriti | Voce nell’elenco di prova |
| Invio riuscito | Conferma chiara al visitatore | Schermata dopo l’azione |
Modello per un controllo di accettazione
Ogni riga indica quale osservazione determina lo stato finale.
ID del controllo: Requisito concordato: Versione / ruolo / ambiente: Dati in ingresso: Azioni: Risultato atteso: Risultato effettivo: Stato: superato / non riuscito / non testato / bloccato Evidenza e riferimento temporale: Correzione associata: Data del nuovo test:
Controlla la checklist prima di iniziare
- Le voci rimandano al perimetro concordato.
- Il risultato atteso è visibile o misurabile.
- Quanto mostrato è distinto dai test riprodotti.
- Le condizioni degli errori sono riproducibili.
Entriamo nei dettagli
Bisogna inserire tutte le osservazioni della riunione?
Distingui i difetti rispetto ai requisiti dalle richieste nuove. Valuta e concorda le richieste separatamente per evitare di allargare senza fine il progetto.
Si può accettare il risultato dal solo video?
Dipende dalle regole concordate. Il video può provare il caso mostrato. Indica nel documento come è stato eseguito il controllo e che cosa copre.