I ritmi che le esigenze del business impongono oggi allo sviluppo e aggiornamento delle applicazioni si riversa inevitabilmente sui gruppi di lavoro delegati al testing. Si devono verificare funzionalità e rispondenza ai requisiti di applicazioni molto complesse e spesso con componenti sviluppati da terze parti. L’avvento dei dispositivi mobili, ad esempio, porta un nuovo livello di complessità nella realizzazione di interfacce per device, sistemi operativi e operatori di rete differenti. In questo contesto, gli strumenti e le pratiche abituali del testing mostrano i loro limiti e occorre ripensare processi che, per quanto consolidati, non sono ormai più in grado rispondere alle sfide che il time-to-market impone all’It aziendale. Un modo per uscire da questa impasse è applicare al testing i princìpi del metodo Agile, che un crescente numero di dipartimenti It sta già adottando nello sviluppo applicativo sebbene in Italia, per una serie di concause (si veda al proposito l’intervista a Diego Lo Giudice come prima correlata a lato), ciò avvenga con una certa prudenza e in ambiti ancora di nicchia.
Le considerazioni che seguono sul tema si basano in larga parte su uno studio, relativo appunto all’inclusione del testing in un quadro di adozione del metodo Agile, pubblicato nel gennaio di quest’anno da Forrester Research e svolto con interviste in profondità presso vendor It e aziende utenti.
I limiti del testing tradizionale
Sotto la denominazione ‘Agile’ vanno diversi metodi di project management tesi a coinvolgere il committente (la business unit) nel ciclo di sviluppo per meglio rispondere alle sue richieste; tali metodologie prevedono di regola il frazionamento del progetto in blocchi (iterazioni) da eseguire in tempi brevi e completare in ogni aspetto, testing incluso, prima di passare al blocco successivo.
L’adozione dell’approccio Agile rappresenta pertanto un elemento di rottura con tutto quello che conosciamo sul testing: da quali pratiche seguire e quali capacità sviluppare a come sfruttare gli strumenti tecnologici e organizzare la stessa struttura delegata ai test funzionali. Ciò in quanto il testing stesso con tutto ciò che vi è correlato, pratiche, skill e strumenti di automazione, entra in gioco sin dall’inizio del processo di sviluppo, con il quale si relaziona in un rapporto di lavoro quotidiano.
Fonte: Forrester research
Sebbene il ’manifesto’ dello sviluppo Agile non faccia specifici riferimenti al testing, è chiaro come le pratiche tradizionali siano incompatibili con i suoi valori (vedi figura 1). Il problema è che non c’è un preciso percorso alternativo: il testing Agile non è una pratica consolidata e la maggioranza di chi adotta lo sviluppo Agile si limita, in realtà, ad adattare alcune delle sue pratiche ai processi di testing in atto. Per quanto ciò porti già dei vantaggi per arrivare a includere il testing in un processo di sviluppo Agile, la strada è ancora lunga.
Vi sono vari modi per approcciare il concetto Agile. Molti iniziano semplicemente con pratiche di project management (Scrum) o metodi lean (Kanban) prima di aggiungervi tecniche più avanzate, come l’integrazione e la delivery continua. In generale, la sopracitata indagine Forrester evidenzia come l’approccio più diffuso (39% dei casi) sia un mix di tecniche di tipo Agile e tradizionali. Un buon 31% usa diverse metodologie Agile, mentre solo il 17% ne sceglie una sola e cerca di seguirla per quanto possibile. In ogni caso, la spinta che porta ad abbandonare le pratiche di testing tradizionali quando il team di sviluppo inizia ad applicare metodi Agile è la ricerca di una maggiore velocità di rilascio delle applicazioni, una scelta giustificata da almeno tre considerazioni:
1) le pratiche correnti di testing non aiutano lo sviluppo Agile, ma al contrario lo frenano: è difficile infatti eseguirle nell’ambiente di rapida iterazione di cicli di sviluppo tipico dell’Agile senza che ciò comprometta le prestazioni del team. Inoltre, purtroppo, tester e sviluppatori sono spesso organizzativamente e anche fisicamente separati, il che rende impossibile applicare i princìpi dell’Agile in modo efficace;
2) il testing manuale non può reggere il passo con la velocità di sviluppo cercata: i testing team tradizionali hanno di regola una buona quota di specialisti che intervengono alla fine di un progetto per eseguire cicli di test che possono durare anche mesi. I cicli iterativi dell’Agile sono invece di poche settimane, per cui il testing manuale, specie per i test di regressione non è praticabile;
3) l’automazione dei test, difficile e costosa, nel metodo Agile rende molto di più. Dalle dichiarazioni degli utenti si stima che la maggioranza di chi usa i processi tradizionali automatizzi meno di un terzo dei test-case e che la quota di chi ne pratica regolarmente il riutilizzo sia ancora minore. L’integrazione dei framework d’automazione nei cicli di sviluppo Agile ne consente un impiego molto più efficiente.
Prepariamoci al cambiamento
L’adozione dei princìpi dell’Agile impatta su tutte le strutture e le figure professionali coinvolte nel testing. Ecco come gli analisti Forrester sintetizzano i cambiamenti cui ci si deve preparare.
– Con l’adozione dell’Agile i responsabili dei TCoE (Test Center of Excellence) devono rivedere il propri compiti e ruoli. Il passaggio infatti cambia sia il numero che il tipo delle risorse occorrenti al test delle applicazioni. Le strutture di testing grandi e rigide, difficili da gestire e coordinare, non servono più e il focus si sposta su ciò che davvero porta valore: adattare all’Agile le pratiche di testing, espanderne l’automazione e formare competenze che funzionino nel nuovo ambiente.
– Cambiano anche i compiti deI testing manager. Dalla supervisione delle attività in un ambiente chiuso dove esercita il ruolo di custode delle procedure di testing e di controllo della qualità, deve portarsi all’esterno al fine di raccogliere e organizzare risorse per sviluppare le pratiche di testing Agile e partecipare direttamente alle decisioni di rilascio (passa / non passa) dei team di sviluppo.
– Alcune capacità maturate nel testing tradizionale diventano inadeguate, non potendosi adattare alla flessibilità operativa richiesta dai nuovi metodi di sviluppo. Tipicamente, data l’importanza che i processi automatizzati vengono ad avere nel metodo Agile per la maggiore efficienza di cui si è detto, diminuisce il bisogno di esperti nel testing manuale. Attenzione: non si dice che il testing manuale non servirà più, ma che non sarà la pratica standard. Gli skill relativi diventano quindi un valore aggiunto utile solo in specifici casi. In breve: chi crede di potersi familiarizzare con le nuove tecniche dovrà impegnarsi quanto prima a farlo, ma stando ai dati raccolti da Forrester nel passare dal testing tradizionale a quello Agile c’è da mettere in conto un tasso di abbandono tra il 40 e il 50%.
– Molti strumenti non saranno più d’aiuto. I più diffusi tool per i test funzionali coprono solo un’area limitata di ciò che va testato e con l’avvento dei processi di testing automatizzati divengono inevitabilmente superflui. Purtroppo, si tratta di strumenti con i quali la maggior parte dei tester è familiare e il passaggio ad Agile e automazione avrà per risultato di porre queste persone in difficoltà, contribuendo alle perdite di cui sopra.
Per concludere, l’approccio tradizionale al testing non si accorda ai concetti dei metodi Agile e bisogna quindi prepararsi a quella che Forrester definisce la ‘nuova normalità’.
