Come introdurre il “Continuos Testing” nei propri team

Rosario Turco

Il termine “Continuous Testing” originariamente fu introdotto dal Program Analysis Group al MIT a seguito
di una ricerca, con la quale fu trovato che “gli sviluppatori che usano un test continuo hanno una
probabilità di terminare prima della consegna, di almeno tre volte maggiore, rispetto a quelli che non lo
usano” e che “il Continuos Testing permette di ridurre il tempo perso del 92-98%”.

Al di là di questi numeri dichiarati dalla ricerca del MIT, che vanno interpretati con cautela per chi inizia
su queste tematiche, ci sono oggettivi vantaggi, che riassumiamo di seguito.

Minor Overhead
I test non vanno lanciati manualmente, uno alla volta; ma vengono lanciati a gruppi. L’apporto umano su
attività ripetitiva è bassissimo, mentre è alto su aspetti qualitativi di verifica dei risultati e del
comportamento atteso per il business in questione.

Riduzione dei difetti e riduzione delle modifiche

Oggi esistono molti tools di aiuto di compilazione/test, da accoppiare al software o eventualmente da
integrare con propri simulatori, a seconda delle tecnologie in gioco.

I simulatori devono essere semplici e facili da configurare e magari open source (primo fra tutti SOAPUI
ad esempio per SOA su http/https, JMS etc) oppure per Java esistono molti plug-in per Eclipse, IntelliJ
etc., da usare con JUnit e magari anche con i tools di verifica vulnerability come Fortify, di analisi statica
e dinamica o altro.

L’obiettivo fondamentale da comprendere è di sfruttare al massimo gli IDE o i RAD per la compilazione ed
il testing (system test o Load test).

In tal modo si possono incrementare i feedback e la produttività se si fa un’operazione di continua

compilazione e di Continuos Testing. Questo perché si riduce il tempo tra lo sviluppo, l’introduzione di un
errore o una vulnerabilità di sicurezza e il rilevamento della stessa, a compile time o a Unit Testing!!!.

Il concetto, difatti, è che maggiore è il tempo che passa dallo sviluppo, per individuare vulnerabilità o
difetti, più aumenteranno le modifiche ed i test da fare. Però molti di questi problemi sono risolvibili
spesso a compile time e test unitario o col software auto-testato (… qui penso a JUnit …).

Inoltre un test massivo e automatizzato di integrazione, di moltissimi test, permette grandi regressioni di
release tra un kit e l’altro (… qui penso all’open source e al meraviglioso SOAPUI adatto a catena di test
di integrazione, a test unitari e a Load Test …).

Il costo diventa basso pian piano se si accumulano di volta in volta i file di prova e migliora la qualità da
kit a kit. Anche il refactoring, favorito dalle Metodologie Agili, trae beneficio da una tale pratica.

Promuove le “Best Practices”

E’ evidente che trovare un errore già in fase di concepimento di una piccola parte di software realizzata
permette di fare modifiche migliorative senza stravolgere l’architettura del tutto, anche perché non è
ancora realizzata tutta l’applicazione. Compilare e testare continuamente “per piccole parti”, sin dal test
unitario, permette di verificare prima le cose e impiegare le migliori pratiche, quando il software è ancora
di piccola dimensione (magari si tratta ancora di un metodo).

Questo è favorito dalla metodologia Agile che ha come principio fondamentale: “fare cambiamenti
incrementali”. Il Continuos Testing ottiene, quindi, un grande beneficio soprattutto da metodologie
incrementali e light.

Fare i test velocemente

L’utilizzo di un test continuo aiuta a mantenere il test rapido e con una profondità di copertura maggiore
ed in poco tempo.
Esistono molti tools disponibili a seconda della propria piattaforma e tecnologia; alcuni sono ad esempio:

1. SOAP-UI
http://www.soapui.org/
http://www.soapui.org/IDE-Plugins/eclipse-plugin.html

2. CT-Eclipse (was Continuous Testing Plugin for Eclipse) – Java/Eclipse

3. ZenTest::Autotest – Ruby
4. Fireworks – Java/IntelliJ
5. Infinitest – Java
Ovviamente ne esistono molti altri ed ogni Team Leader o a seconda dei gruppi di revisione del progetto,
in base alla propria tecnologia, deve scegliersi e progettare il proprio framework di test e gli strumenti
che lo facilitano, adatto alle proprie tecnologie.

Personalmente ho visto i miracoli che può fare SOAPUI anche nei Load Test e nelle catene di test e
scusate la mia preferenza open source.

L’importante anche qui è iniziare. Il costo iniziale è ammortizzato nel tempo e costerà sempre meno la
qualità che si otterrà. Specializzarsi permetterà basso effort e ottima qualità (parafrasando il WU-WEI
cinese).

Il consiglio finale è fare tutto light e “cum grano salis”.