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.