Archivi categoria: testing

Scuole di software testing

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 .

Exploratory Testing 3.0

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

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.

 

Test Driven Development: indispensabile?

Nelle ultime settimane si è sviluppata una discussione in merito al Test Driven Development (sviluppo guidato dai test, una pratica che prevede la scrittura dei test prima della scrittura del codice necessario a superarli).

Iniziata con un intervento di David Heinemeier Hansson, l’ideatore di Ruby on Rails, la discussione sta coinvolgendo alcuni tra i migliori esperti di software design, come Robert Martin, Kent Beck e Martin Fowler. Tra Heinemeier Hansson, Beck e Fowler sono in corso dialoghi interessanti: uno , due , tre (e successivi).