Application testing: linee guida per un approccio Agile

Le pratiche e gli strumenti tradizionali di testing non possono funzionare in un contesto di sviluppo Agile per molteplici ragioni (si veda a riguardo l’articolo “Il testing delle applicazioni nell’approccio Agile allo sviluppo” tra le correlate a lato). Si deve cambiare, ma non esistono ‘ricette’ e protocolli da seguire per il cambiamento: decidendo di adottare i principi dell’Agile, ogni realtà ha cercato di trovare una propria via per il testing. È quanto rilevato dagli analisti di Forrester nell’indagine sulla quale si basano queste note, che si pongono l’intento di suggerire non tanto un’ideale best practice (che non esiste), ma delle linee-guida che potranno facilitare il passaggio alla nuova condizione.

Bisogna, prima di tutto, capire che la transizione sarà un’operazione di vasta portata: vi saranno cambiamenti nel modo di operare, nei processi e soprattutto nelle persone. Chiunque, dal Cio in giù, abbia una posizione di responsabilità nell’organizzazione dello sviluppo e testing applicativo deve esserne consapevole e assumere un ruolo-guida nel cambiamento interpretando e cercando di applicare le seguenti direttive:

Figura 1: Il passaggio dal modello classico del TCOEs (Testing Center of Excellence) centralmente organizzato dal PCOEs (practice Center of Excellence) flessibile e vicino ai gruppi di sviluppo
Fonte: Forrester Research

• Creare un Practice Center of Excellence (PCoE), che sia per organizzazione e operatività flessibile e vicino ai gruppi di sviluppo. Avendo il testing Agile come obiettivo l’efficiente automazione delle operazioni relative, il modello classico del TCoE (Testing Center of Excellence) centralmente organizzato non è più applicabile. Si dovrà formare un PCoE nel quale muovere le figure delegate alle attività di testing e alla loro automazione, preparandole a far parte di gruppi misti dove possano lavorare accanto agli sviluppatori e agli analisti business (BA). Questo nuovo PCoE si focalizzerà sulla standardizzazione delle metriche e sul riutilizzo di quanto viene fatto nonché, in certi casi, sulla fornitura di ambienti di testi condivisi o sul supporto a test team distribuiti. (Figura 1)
• Formare i test manager per diventare testing practice leader. Due aree sulle quali bisogna concentrare gli sforzi sono le pratiche Agile e le capacità di relazione interpersonali (soft skill, come le chiama Forrester). Riguardo queste ultime, converrà organizzare workshop focalizzati sulla leadership, sulla comunicazione e sulle tattiche del cambiamento e farvi partecipare in primo luogo quei manager che in queste aree mostrano maggiori debolezze (specie per la capacità di comunicare con le persone e di guidarle). Poi, bisognerà fare in modo che tutti i manager abbiano un adeguato training nelle pratiche Agile. Infine, nel caso si abbia un gruppo di manager con un background di sviluppatori, bisognerà formare queste persone all’approccio Tdd (Test driven development), ai cui corsi sarebbe bene partecipassero anche gli sviluppatori. Si tratta di un programma di formazione importante, da distribuire nel tempo in funzione del budget, ma è un investimento necessario per sostenere il cambiamento.
• Dare ai tester manuali la guida delle strategie di test e del testing esplorativo. Se c’è gente esperta in test manuali e con un’ottima conoscenza del business bisognerà trattenerla e valorizzarne le capacità. Saranno i leader del testing nei gruppi di sviluppo e avranno un ruolo-chiave. Queste figure andranno accoppiate a sviluppatori e analisti business per condurre test esplorativi a complemento dei test automatizzati nei progetti più avanzati o in certi scenari operativi. Il test esplorativo è anche un modo intelligente per convalidare i modelli di testing fatti dagli sviluppatori, focalizzandone le attività nelle aree a rischio più elevato.
• Rendere lo Unit-testing obbligatorio e puntare sullo sviluppo Test-driven. Bisogna che gli sviluppatori sottopongano a test ogni singola unità di codice prodotta (Unit-test) e che comincino a ragionare in termini di sviluppo guidato dai test. All’inizio questo influirà su quanto si potrà realizzare in uno sprint, cioé in un singolo ciclo di sviluppo, ma l’innalzamento generale della qualità ridurrà, alla fine, la quantità dei test necessari. Sapere sin dall’inizio che il codice funziona facilita lo sviluppo dell’applicazione e ne rende il testing più economico.
• Testare il codice nello stesso ciclo nel quale viene prodotto. Alternare cicli di sviluppo e cicli di test usando gruppi di sviluppo e test separati significa falsare completamente il concetto dell’Agile. C’è chi riesce in tal modo ad accorciare i tempi di release, ma non è una pratica sostenibile. S’introduce un comportamento da mini-waterfall, con il test fatto alla fine e poca collaborazione tra sviluppatori e tester. Se si vuole che il metodo Agile funzioni bisogna assolutamente che tutti i test, funzionali e non funzionali, siano fatti all’interno di ogni ciclo.

Automazione, un sogno possibile

Se il testing si deve conformare ai princìpi e ai metodi dell’Agile, anche l’automazione dei test deve essere ripensata: non può più essere vista come un ambito funzionale separato, ma deve seguire un rigoroso processo di Software development life cycle (Sdlc). In realtà, sono ben poche le organizzazioni che nei loro progetti Agile hanno raggiunto un livello significativo di test automation, tale da accorciare il tempo di sviluppo delle applicazioni e migliorarne la qualità. Però esistono alcune aziende che sono arrivate ad automatizzare oltre l’80% delle attività. Gli analisti Forrester hanno indagato su come queste realtà siano riuscite nel loro intento e ne hanno tratto alcune conclusioni su come porre in atto una strategia di test automation che possa avere successo.

In primo luogo, occorre sviluppare i test automatici esattamente come si farebbe per il codice di un’applicazione, seguendo le pratiche Sdlc. Questo approccio obbliga a trattare gli aspetti del testing come si trattano i business requirement, con un’accurata analisi e un robusto disegno del codice sorgente. In una parola, gli Unit-test, i Component-test e i test funzionali e non funzionali vanno scritti all’interno del processo Sdlc. È un lavoro da sviluppatori – non da tester – e non è facile, ma è un’importante evoluzione. In un primo tempo i cicli di sviluppo si potranno allungare (tre o quattro settimane invece di due o tre), ma poi il processo si ottimizzerà man mano che diventerà abituale e organico al modo di lavorare.

In secondo luogo, bisogna essere certi della solidità del codice. Occorre quindi affidare lo sviluppo dei test automatizzati a tester che abbiano una buona esperienza di sviluppo o, se necessario, a sviluppatori da assumere ad hoc. Basarsi sul Gui Recording (la verifica del funzionamento di un’applicazione interattiva tramite tool di cattura e registrazione delle attività dell’interfaccia utente) non è sufficiente. Bisogna far leva su un approccio che non si fermi alla Gui (che tra l’altro, essendo ciò che il business vede dell’applicazione, è il livello che nello sviluppo Agile cambia più di frequente), ma giunga ai processi e alle attività sottostanti.

Infine, basandosi su quello che hanno fatto i test team che hanno raggiunto i più alti livelli d’automazione, conviene sviluppare un framework che acceleri il lavoro di automazione e conviene farlo usando software open source. Esistono framework e tool Oss (Operations support systems) adatti allo scopo. Forrester cita JUnit, NUnit e Ruby per lo unit testing, Cucumber e Fit/Fitness (acceptance driven test) e Selenium (test automation per applicazioni web e multibrowser). Resta comunque diffuso, sempre tra chi ha un ottimo livello d’automazione, anche l’uso di tool commerciali. Ad esempio, risulta largamente adottato il Quality Center di Hp.

Per essere ‘agili’ bisogna far presto

La ricerca sulla quale ci siamo basati si conclude con una serie di raccomandazioni sulle azioni da intraprendere nel giro di sei mesi per avviare un’efficace programma di Agile testing. In breve, si dovrà:

• Definire delle job-description per i nuovi compiti di tester e i test manager. Questi dovranno prendere in considerazione anche le capacità di leadership e di comunicazione (i cosidetti soft skill).
• Valutare gli skill professionali della struttura di testing attuale. Si tratta di un assessment necessario per sapere se si dispone o meno delle risorse indispensabili per adottare test esplorativi e processi di sviluppo test-driven e business-driven. Un tester con esperienza di sviluppo diventerà un valido aiuto per l’automazione, così come uno con acume per gli aspetti di business starà bene in un gruppo di test strategy e planning.
• Investire in formazione, sia generale per lo sviluppo Agile sia specializzata nel testing. Le valutazioni di cui al punto precedente serviranno a dare un’idea sul tipo di formazione necessaria e quali figure ne abbiano più bisogno.
• Investire in tecnologia per complementare gli strumenti esistenti con framework open source come quelli citati, in modo da poter più facilmente integrare la test automation nei processi e nell’ambiente Sdlc dell’organizzazione. Se necessario o conveniente si può anche considerare l’uso di strumenti fruibili via cloud in modalità Software-as-a-Service.
• Assumere personale, se necessario. Inevitabilmente, ci sarà sempre qualcuno che non saprà o non potrà superare la rivoluzione dell’Agile testing. Bisognerà riempire questi vuoti con nuove risorse, a contratto o a tempo pieno a seconda dei casi e delle persone. Non c’è abbondanza di gente valida, anche perché per uno sviluppatore classico passare allo sviluppo test-driven significa cambiare modo di pensare e non è facile.