Glossario · Progettazione dei test
Test delle transizioni di stato
In inglese: State transition testing
Detto anche: diagramma di transizione di stato, tabella delle transizioni di stato, test basato sugli stati, state transition diagram
Definizione
Tecnica di test design che modella un sistema come stati ed eventi che lo spostano dall'uno all'altro, per poi testare le transizioni valide e quelle non valide.
Il test delle transizioni di stato (state transition testing) si applica quando la risposta del sistema dipende da ciò che è successo prima, non solo dall’input corrente. Modelli il sistema come un insieme di stati, gli eventi che causano le transizioni tra di essi ed eventuali azioni o condizioni (guard) su ogni transizione. I test coprono poi le transizioni valide e, cosa altrettanto importante, verificano che quelle non valide vengano rifiutate.
Esempio: blocco del login
Un account si blocca dopo tre password errate consecutive e un login riuscito azzera il conteggio.
Stati: Active (0 failures), 1 failure, 2 failures, Locked, Logged in.
| Stato corrente | Evento | Stato successivo |
|---|---|---|
| Attivo (0) | Password errata | 1 errore |
| Attivo (0) | Password corretta | Autenticato |
| 1 errore | Password errata | 2 errori |
| 1 errore | Password corretta | Autenticato (conteggio azzerato) |
| 2 errori | Password errata | Bloccato |
| 2 errori | Password corretta | Autenticato (conteggio azzerato) |
| Bloccato | Password corretta | Bloccato (rifiutato) |
| Bloccato | Sblocco da parte dell’admin | Attivo (0) |
Test che se ne ricavano:
- Ogni transizione valida almeno una volta (copertura 0-switch): errata, errata, errata porta a Bloccato; errata, corretta porta ad Autenticato.
- Eventi non validi o inattesi: la password corretta su un account bloccato deve comunque essere rifiutata. È qui che si nascondono i bug di sicurezza.
- Sequenze: errata, corretta, poi logout ed errata, errata. Il conteggio viene davvero azzerato o l’account si blocca al secondo errore? Testare coppie di transizioni consecutive si chiama copertura 1-switch.
Dove si applica
A tutto ciò che ha un ciclo di vita: ordini (creato, pagato, spedito, consegnato, annullato, rimborsato), workflow dei bug, abbonamenti, approvazioni di documenti, stati dei pagamenti, media player e wizard nella UI. Domande da porsi per ogni stato: quali eventi sono consentiti qui, cosa succede a quelli non consentiti e l’utente può raggiungere questo stato per una strada inattesa, come il pulsante Indietro del browser o una chiamata API diretta?
Errori comuni
- Testare solo l’happy path. Creato, pagato, spedito è un solo percorso. Un ordine può essere annullato dopo la spedizione? Rimborsato due volte?
- Testare solo dalla UI. La UI può nascondere il pulsante Annulla, ma l’API potrebbe comunque accettare la richiesta. Testa le transizioni anche a livello di API.
- Non avere la tabella degli stati. Il diagramma mostra cosa dovrebbe succedere; la tabella completa di ogni stato per ogni evento mostra le lacune in cui il comportamento non è definito.