Test case — sono scenari preparati in anticipo con passaggi chiaramente definiti, risultati attesi e input. L'exploratory testing si basa sull'esplorazione sul campo: il tester genera verifiche mentre esplora il prodotto, utilizzando la propria esperienza e intuizione. Storicamente, i test case hanno dominato in precedenza, ma con la complessità crescente dei sistemi e l'aumento del volume di testing manuale, l'exploratory testing ha iniziato a integrare gli approcci formali.
Seguire ciecamente un solo tipo di testing limita la creatività del tester e può lasciare il prodotto con bug non scoperti che non sono descritti nei casi.
Utilizzare entrambi gli approcci in modo equilibrato: test case — per funzionalità critiche e di regressione, exploratory — per sezioni nuove che non sono ancora completamente formalizzate e nei tempi stretti.
Caratteristiche chiave:
È possibile utilizzare solo test case per una copertura del 100%?
No. Anche il set di casi più dettagliato non copre comportamenti inaspettati dell'utente o bug non standard.
Richiede l'exploratory testing una preparazione preliminare?
Sì. È necessario comprendere la funzionalità, studiare i requisiti e capire la logica di business prima di esplorare liberamente il prodotto.
È obbligatorio redigere un bug report dopo l'exploratory testing?
Sì. Qualsiasi difetto trovato deve essere documentato con la stessa cura di un bug da uno scenario formale, altrimenti è difficile riprodurlo e correggerlo.
Il team ha coperto il rilascio solo con test case formali. Un tester ha eseguito i test rigorosamente secondo le istruzioni, senza controllare i "casi associati", il che ha portato a perdere un bug che si verifica solo in una certa sequenza di azioni non prevista in anticipo.
Pro:
Contro:
Il tester, dopo aver completato i test case chiave, ha dedicato un'ora all'exploratory testing, trovando un bug che si verifica solo quando si cambia l'ora sul dispositivo durante l'esecuzione dell'applicazione.
Pro:
Contro: