Il testing è troppo importante per essere ridotto alla semplice definizione ed esecuzione di casi di test.

I casi di test sono importanti, certo. La decisione di quali test eseguire (e rieseguire ad ogni modifica) influenza la qualità del sistema e porta vantaggi oppure danni alle persone che lo usano.

Ma il testing necessita soprattutto di competenze e di creatività per trovare i punti di debolezza del prodotto testato. Il testing è una  attività umana essenziale, non riducibile alla documentazione di un insieme di casi da verificare.

James Bach e Aaron Hodder – Test Cases are not Testing: towards a Culture of Test Performance

Per progettare casi di test, l’ottimo Heuristic Test Strategy Model di James Bach: https://t.co/3nNwxeQ2lR

Il software viene testato troppo poco. Almeno, questo è ciò che ci viene da pensare quando funziona male.

Ma qual è il modo migliore di testarlo?  Testare un software critico per la vita umana è un conto; il sito web di un’associazione tra amici comporta di solito meno rischi, anche quando ha dei problemi.

Per il testing si possono adottare diversi approcci organizzativi e tecnici, diverse strategie, diverse tattiche, diversi strumenti.

Per evidenziare affinità e differenze, anni fa alcuni esperti identificarono quattro “scuole” di software testing: l’analitica, l’industriale, la “Quality Assurance”, e infine la propria, “Context-Driven”. L’esistenza e la caratterizzazione delle quattro scuole si possono leggere nella presentazione del 2003 “Four Schools of Software Testing“, di Bret Pettichord.

La “Context-Driven School“, in particolare, affermava che la scelta del processo, delle strategie, delle tattiche e degli strumenti varia in modo sostanziale a seconda del contesto in cui ci si trova: quale tipo di prodotto, in quale mercato, per quale tipo di utenti/clienti, in quale situazione organizzativa.

Un recente e interessante dibattito tra due tra i maggiori esperti di software testing, Rex Black e Cem Kaner, ha discusso se la distinzione in “scuole” sia ancora utile, o non sia soprattutto un argomento usato da alcuni consulenti per promuovere le proprie attività denigrando quelle di altri. Probabilmente entrambe le cose sono vere, come emerge dal video del dibattito: http://kaner.com/?p=437 .

Sul Google Testing Blog: “Just say no to more End-to-End tests“. Interessanti l’articolo e le critiche, tra cui “Making End-to-End tests work“, di Adrian Sutton.

Una ridefinizione della pratica di testing esplorativo è stata proposta da James Bach e Michael Bolton , per superare la distinzione tra  il “testing guidato da script” e, appunto,  il “testing esplorativo”:

we now define all testing as exploratory.  Our definition of testing is now this:

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”

Secondo il loro punto di vista, il testing guidato da script può essere solo uno strumento tattico da usare in particolari situazioni, ma è come un ospite in casa d’altri, un elemento estraneo al vero e proprio testing.

Mocks, Stubs, Spies, Fakes. Sono tutti Test Doubles, cioè porzioni di codice usate per agevolare lo unit testing, quello praticato dagli sviluppatori per verificare una porzione limitata di codice, un singolo mattoncino.

Sono termini propri del testing “white box”, che richiede a chi lo effettua di conoscere il codice che sta testando (a differenza del testing “black box”, che non richiede la conoscenza del codice, e che viene praticato normalmente da chi non ha sviluppato).

Un intervento di Robert Martin sotto forma di dialogo spiega in modo chiaro la differenza tra i diversi tipi di Test Doubles: The Little Mocker.