Come introdurre il “ Continuos Testing” nei propri team Rosario Turco Il termine “ Continuous 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 perme tte 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’ all ’ open 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 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 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 tut to light e “ cum grano salis”.
