Un piano di test è il contratto su cui il team di test lavora durante una release. Un tipico piano di test per una release di checkout di e-commerce dichiara l’ambito (carrello, pagamenti, conferma dell’ordine), l’approccio (testing basato sul rischio per l’integrazione dei pagamenti), le risorse (due tester, un ambiente di test con un gateway di pagamento sandbox) e il calendario (tre settimane, con criteri di uscita legati alla densità dei difetti e alla copertura dei test). Registra inoltre le tecniche di progettazione dei test da utilizzare — ad esempio la partizione di equivalenza per il campo dello sconto — e i criteri di ingresso che devono essere soddisfatti prima che il testing inizi.
Un piano di test è la stessa cosa di una strategia di test? No. Una strategia di test è una descrizione di alto livello, a livello di organizzazione, dei livelli di test e del testing al loro interno, mentre un piano di test applica quella strategia a uno specifico progetto o programma. Pensa: strategia = politica, piano = esecuzione.
Chi scrive il piano di test? Di solito il test manager o il test lead, in consultazione con gli stakeholder. Il piano è una registrazione del processo di pianificazione dei test, non un documento scritto da una sola persona.
Ogni progetto ha bisogno di un piano di test completo? La profondità deve corrispondere alla dimensione e al rischio del progetto. Una piccola release di manutenzione può giustificare un piano leggero; un sistema critico per la sicurezza ne richiede uno dettagliato, con criteri di ingresso e di uscita espliciti.
Cosa succede se il calendario slitta? Un buon piano di test è un documento vivo. Ambito, approccio, risorse e calendario vengono rinegoziati con gli stakeholder, e la motivazione aggiornata viene registrata — ecco perché il piano identifica i rischi che richiedono una pianificazione delle contingenze.
