Testing software: Il test esplorativo di un nuovo software

Il test esplorativo è un approccio efficace ed interessante alla tecnica Black-Box, ed in alcune situazioni può risultare più produttivo di un comune test pianificato. Ogni tester, forse anche inconsapevolmente, utilizza di tanto in tanto il test esplorativo nella sua attività. Nonostante questo, il test esplorativo non gode di grande credito nel settore. Secondo James Bach, il test esplorativo può essere definito come un porsi di fronte ai problemi senza una impostazione predefinita, e risolverli analizzando sul momento le reazioni ed i possibili difetti del programma che si sta testando.

Una definizione canonica di test esplorativo è quella che lo considera come:

“Una attività di test design e di esecuzione di test nello stesso istante.”

Questo si oppone ai test pianificati, che antepongono la progettazione dei test tramite test- case alla sua esecuzione materiale (manuale o automatica). La cosa più ovvia è che non si può pianificare una attività di test esplorativo sul fronte nella durata e dei risultati attesi. Tuttavia un tester esplorativo esperto ha già una esperienza che lo porta a identificare in breve tempo le idee e la strategia da adottare per testare una particolare applicazione, quindi anche la sua durata in un certo senso. Il termine “test esplorativo” è stato coniato da Cem Kaner nel suo testo “Testing Computer Software”, e negli ultimi dieci anni sono stati svolti degli studi dallo stesso Kaner, James Whittaker e James Bach per identificare le capacità e le tecniche necessarie ad una buona attività di test esplorativo.

Molte volte nelle nostre attività di tester, ci imbattiamo in test esplorativi più spesso di quanto non crediamo, anche senza accorgerci di questo. Allora, quando ci troviamo dinanzi ad un test esplorativo?
Se nel fare i test, veniamo influenzati sul risultato del test precedente nell’impostare il test successivo, stiamo facendo del test esplorativo. Anche quando stiamo seguendo un test pianificato, ed un particolare output ci da una idea su come rendere più efficace un test da eseguire successivamente, stiamo effettuando un test esplorativo. L’approccio pianificato rimane non influenzato dal test esplorativo solo quando si testano funzioni relativamente poco critiche o già dimostratesi stabili, e quando ci si attiene strettamente al documento senza ulteriori approfondimenti. Gli approcci di test esplorativo e test pianificato portano spesso a risultati compatibili, e sono attività perfettamente miscelabili tra loro, come dimostrano compagnie quali Nortel e Microsoft che adottano questo sistema da anni.

L’approccio pianificato cerca di mettere su carta le idee che il tester matura sulla strategia da adottare per testare una applicazione, e come è evidente questa operazione ha un notevole valore aggiunto per la precisione della documentazione relativa disponibile (e per la certificazione ISO, aggiungerei…). Il tester esplorativo invece considera che la scrittura di questa lunga documentazione distragga e rallenti il processo intellettuale di test, impedendo di risolvere i problemi in maniera rapida e concentrata. La ricchezza del test esplorativo consiste nella libertà di espressione delle idee del tester, che può agire senza vincoli in base alle intuizioni ricavate dalle reazioni della applicazione, e nella maggiore rapidità ed efficienza nella esecuzione dello stesso.

Ovviamente un test pianificato rimane utile ed indispensabile per quanto riguarda l’automatizzazione. La possibilità di documentare un test ripetibile in maniera univoca è utile sia per fini interni all’azienda, sia per la possibilità di fare un regression test (ovvero testare le stesse funzionalità in versioni successive del prodotto). Il test esplorativo viene maggiormente adottato in situazioni complesse, quando il prodotto ha numerose funzionalità e la documentazione non è esauriente, o affiancato al test pianificato per migliorare la copertura. La regola basilare è quella di utilizzare il test esplorativo quando il prossimo passo da eseguire nel test non è ovvio, o quando non si vuole che il prossimo passo sia quello previsto. James Bach afferma come questo avvenga nella maggioranza dei casi.