Che cos'è un piano di test? La pagina che dice che cosa non stai testando

Un piano di test è un documento breve che dice che cosa verrà testato, che cosa no, da chi, in quali ambienti e che cosa deve essere vero prima che qualcuno cominci o si fermi. Si scrive prima dei test, e il suo valore principale sta nel secondo punto di quell’elenco.

Elencare quello che si intende controllare è alla portata di chiunque. Mettere per iscritto quello che si lascia da parte di proposito è la parte che evita la conversazione di tre settimane dopo, quella in cui qualcuno dava per scontato che una cosa fosse coperta perché nessuno aveva detto che non lo era.

Che cosa ci va dentro

Sei sezioni portano quasi tutto il valore, e ognuna può stare in poche righe.

• Ambito. Che cosa copre questo giro di test: quali funzionalità, quali release, quali piattaforme.
• Fuori ambito. Che cosa deliberatamente non copre, e perché. La sezione più utile e quella che manca più spesso.
• Approccio. Manuale, automatizzato o la divisione tra i due, e a quale livello.
• Ambienti e dati. Dove gira e contro che cosa, che è ciò che decide che cosa si può trovare. Un piano che dice “staging” senza dire quale build e quali dati non sta dicendo granché.
• Criteri di ingresso e di uscita. Che cosa deve essere vero prima che i test comincino, e che cosa deve essere vero prima di dichiararli finiti.
• Rischi. Che cosa potrebbe impedire a questo piano di funzionare, nominato finché dirlo costa poco.

Alcuni piani aggiungono ruoli, un calendario e un processo per i difetti. Contano di più quante più persone sono coinvolte, e contano pochissimo quando siete in due.

I criteri di uscita sono il punto in cui si litiga

“Finito” non è ovvio, e un piano che non lo definisce produce una release discussa il giorno stesso invece che concordata in anticipo.

Debole

Tutti i bug principali risolti e i test completati

Meglio

Ogni caso della suite di checkout passa, nessun difetto aperto di severità 1 o 2, e i tre difetti noti di severità 3 sono registrati con i relativi rimedi nelle note di rilascio

Il secondo può essere verificato da qualcuno che non era nella stanza. Il primo è uno stato d’animo.

Lo stesso vale per i criteri di ingresso: mettersi d’accordo sul fatto che i test cominciano quando la build supera il suo smoke test risparmia a chi testa un pomeriggio passato a dimostrare in quaranta modi che una build rotta è rotta.

Quanto dovrebbe essere lungo

Più corto di quanto pensi, e proporzionato a quante persone devono essere d’accordo.

Due persone che testano una funzionalità che entrambe conoscono hanno bisogno di un paragrafo, e scriverne di più è teatro. Una release regolamentata con un revisore esterno ha bisogno del documento formale, perché qualcuno fuori dal team deve poter leggere che cosa è stato deciso. La maggior parte del lavoro sta nel mezzo, e una pagina di solito è la misura giusta.

Il test da applicare: il comportamento di qualcuno cambierebbe se questa sezione non esistesse? Se no, cancellala. Un piano che nessuno legge è peggio di nessun piano, perché crea la convinzione che i test fossero stati pianificati.

Dove si colloca tra gli altri documenti

Un piano sta un livello sopra le verifiche vere e proprie.

• Il piano dice che il flusso di checkout verrà testato a mano su Chrome e Safari, e che il mobile è fuori ambito in questo giro.
• I casi di test dicono esattamente che cosa fare e che cosa deve succedere.
• La suite di regressione dice che cosa viene ricontrollato perché prima funzionava.
• I criteri di accettazione dicono che cosa la funzionalità doveva fare in partenza, e sono stati scritti prima di tutto il resto.

Confondere il piano con i casi è l’errore ricorrente: un documento che elenca duecento passi non è un piano, è una suite con una copertina.

Il processo per i difetti ne fa parte

Una riga che la maggior parte dei piani salta, e costa più di quanto sembri. Di’ come si segnala un difetto, dove finisce e chi decide se blocca la release.

Senza quello, le segnalazioni arrivano in tre thread di chat e un foglio di calcolo, chi le raccoglie passa l’ultimo giorno del giro a rincorrere i dettagli, e qualcosa di reale si perde nel rumore. Indica la destinazione e la forma di ciò che ci entra, e collega la guida invece di riscriverla: la nostra guida alla segnalazione di bug esiste per essere la cosa che colleghi.

Se chi testa sono persone il cui mestiere non è il software, la forma conta di più, non di meno. Chiedi loro che cosa è successo e che cosa si aspettavano, e lascia che sia lo strumento a portare la parte tecnica.

In breve

Una pagina: che cosa è coperto, che cosa no, come, dove, che cosa deve essere vero per cominciare e per fermarsi, e che cosa potrebbe andare storto. Scritto prima dei test, concordato con le persone che riguarda, e abbastanza corto perché lo leggano. La sezione che saltano tutti, quella fuori ambito, è quella che evita la discussione.