Glossario · Fondamenti del testing
Piano di test (test plan)
In inglese: Test plan
Detto anche: piano dei test, pianificazione dei test, documento di strategia di test
Definizione
Documento che definisce ambito, approccio, risorse, calendario, ambienti, rischi e criteri di ingresso e di uscita per il testing di un rilascio o di un progetto.
Un piano di test (test plan) descrive come verrà svolto il testing per un rilascio, un progetto o una funzionalità specifici: cosa rientra nell’ambito e cosa no, quali tipi di test si applicano, chi fa cosa, dove si esegue, quando avviene e come il team saprà di aver finito. È l’accordo sul testing tra QA, sviluppo e prodotto, messo per iscritto prima che inizi l’esecuzione. Lo standard IEEE 829 (oggi sostituito da ISO/IEC/IEEE 29119-3) è il modello classico.
Cosa contiene un piano di test utile
- Ambito: le funzionalità incluse e, altrettanto importante, quelle esplicitamente escluse.
- Approccio: livelli e tipi di test (unit, API, UI, performance, sicurezza, accessibilità), cosa è automatizzato e cosa è manuale.
- Ambienti e dati: quali ambienti, come vengono creati o mascherati i dati di test, sandbox di terze parti.
- Criteri di ingresso: cosa deve essere vero prima di iniziare a testare, ad esempio “build distribuita in staging e smoke test verdi”.
- Criteri di uscita: cosa significa “finito”, ad esempio “nessun difetto critico o maggiore aperto, tutti gli scenari P1 superati, suite di regressione verde”.
- Rischi e mitigazioni: ad esempio “la sandbox di pagamento è instabile, quindi la sostituiremo con uno stub per i test funzionali ed eseguiremo un controllo end-to-end giornaliero sulla sandbox reale”.
- Ruoli, calendario e deliverable: chi testa cosa, le date chiave e quali report vengono prodotti.
Piano di test e strategia di test
Una strategia di test è l’approccio di alto livello e di più lunga durata per un prodotto o un’organizzazione: i principi di testing, i livelli, gli strumenti e gli standard. Un piano di test applica quella strategia a un singolo rilascio o progetto, con ambito, date e persone concrete. Molti team agili mantengono una pagina di strategia leggera e un piano breve per ogni rilascio o epic.
Errori comuni
- Scrivere un documento di 40 pagine che nessuno legge. Nei team agili, un piano di una pagina mantenuto aggiornato batte uno esaustivo che è già superato al secondo sprint.
- Criteri di uscita vaghi. “Testing completato” non è misurabile. Indica le condizioni.
- Nessuna sezione sulle esclusioni. Le esclusioni non dichiarate si trasformano in discussioni dopo il rilascio.