MASSIMIZZARE IL ROI DEI PROGETTI
DI TEST AUTOMATION
WHITE PAPER – GENNAIO 2011
1
Sommario
Executive Summary ...................................................................................................... 4
1
Costi e risparmi tra "NON QUALITÁ" e "QUALITÁ"................................................. 5
1.1
Il più comune TEST AUTOMATION "Misundestanding" ..................................... 5
1.2
Breve Tassonomia Tecnologica......................................................................... 6
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.3
Costo
Costo
Costo
Costo
del software....................................................................................11
dell'hardware ..................................................................................12
del personale ed addestramento .......................................................12
di scripting (o codifica) dei casi di test...............................................13
I Benefici dell’Automazione del Test.......................................................................14
2.1
Automazione dei test : quali sono i benefici tangibili? .......................................14
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.2
Velocità e precisione ................................................................................14
Profondità ...............................................................................................14
Riutilizzo .................................................................................................14
Gestibilità................................................................................................14
Proattività ...............................................................................................15
Ripetibilità e disponibilità .........................................................................15
Automazione dei test : quali sono i benefici intangibili?.....................................15
2.2.1
2.2.2
2.2.3
3
per il Test Funzionale.................................................................. 6
per il Test di Performance e Carico .............................................. 7
per il Test Unitario ...................................................................... 7
per il Vulnerability Assessment .................................................... 8
per l’analisi statica del codice ...................................................... 9
di analisi runtime ........................................................................ 9
per la gestione della qualità........................................................10
Automazione dei test : quali sono i costi da affrontare? .....................................11
1.3.1
1.3.2
1.3.3
1.3.4
2
Strumenti
Strumenti
Strumenti
Strumenti
Strumenti
Strumenti
Strumenti
Formalizzazione del processo di test .........................................................15
Customer Retention ed Immagine Aziendale .............................................15
Incremento della professionalità dei tester ................................................15
Alcune cause di fallimento e suggerimenti per evitarli .............................................16
3.1
Assenza di una metodologia ...........................................................................16
3.2
Assenza di un approccio progettuale ...............................................................16
3.3
Serializzazione tra Sviluppo e Test ...................................................................16
3.4
Focalizzazione sul test della GUI ......................................................................17
2
4
5
3.5
Scarsa modularizzazione degli script di test automation ....................................17
3.6
Utilizzo di risorse inadeguate...........................................................................18
3.7
Best Practices per il mantenimento della suite di Test .......................................18
Il Calcolo del ROI ..................................................................................................19
4.1
Come valutare se un'applicazione può essere candidata per l'automazione ...?...19
4.2
Tabella esempio per il calcolo del ROI .............................................................19
4.3
Conclusione ...................................................................................................20
Il Centro di Competenza PALM..............................................................................21
5.1
La Metodologia PALM ....................................................................................21
5.2
Modalità di Erogazione ...................................................................................22
5.3
Primeur: Profilo della Società ..........................................................................22
3
Executive Summary
La costante attenzione delle imprese finalizzata ad evitare gli sprechi ed al puntuale monitoraggio
della redditività degli investimenti ICT, ha nuovamente "rispolverato" il ROI (Return Of
Investment)come importante unità di misura, su cui basare la valutazione di fattibilità di ogni
progetto.
Il ROI è entrato a far parte del lessico aziendale e la sua valorizzazione, è spesso richiesta ed
utilizzata dal management, per confrontare tra loro offerte similari di prodotti e servizi o per
decidere se intraprendere o meno un’iniziativa progettuale.
Ma se la formula per il calcolo del ROI (valore attuale netto di o beneficio derivato da Investimenti /
Costo iniziale) può sembrare una semplice equazione, la difficoltà consiste nel determinare il valore
dei
benefici
intangibili
derivanti
dall’iniziativa
(per
esempio,
gli
aspetti
di
razionalizzazione/ottimizzazione, miglioramento dell’immagine aziendale, mancata competitività
ecc.). Spesso l’investimento richiesto non produce direttamente entrate misurabili, o, in altri casi, i
cost-driver individuati per il calcolo, risultano scarsamente impiegabili per assenza di dati storici
reali, percepiti unicamente come sensazione difficilmente trasformabile in un numero.L’automazione
del test, rientra proprio in questa categoria di iniziative ICT, dove gli aspetti d’indeterminazione dei
benefici conseguibili (anche se immaginabili) spesso non consentono una precisa valorizzazione del
ritorno dell’investimento, rallentando il management nel processo decisionale, pur riconoscendone i
vantaggi ottenibili.
Allo scopo di fornire un ulteriore ausilio nelle valutazioni di fattibilità, il seguito del documento vuole
riassumere ed evidenziare, quali sono i vantaggi derivanti dall’automazione del processo di test
delle applicazioni software, in termini più ampi del solo calcolo del ROI, cercando di analizzarne il
reale valore.
Prelevando le informazioni dall’esperienza diretta di Primeur e dai numerosi studi effettuati al
riguardo da IBM e da analisti del settore, si è cercato di produrre un documento di sintesi che
evidenzi i benefici ottenibili da tali soluzioni, senza sottovalutare le reali problematiche tecnicoorganizzative di adozione e manutenzione dei prodotti di test automatico, che costituiscono il
maggior ostacolo e motivo d’insuccesso di progetti di questo tipo.
4
1
Costi e risparmi tra "NON QUALITÁ" e "QUALITÁ"
Che la "prova", il "test" o il "collaudo" (si scelga il termine più appropriato alla propria
organizzazione), costituisca una grossa fetta dello spesa relativa allo sviluppo di qualsiasi tipologia di
software, è una verità ormai universalmente riconosciuta; così come è assodato che il test sia un
male altrettanto universalmente necessario, per il raggiungimento di standard qualitativi che
consentano di proporre competitivamente prodotti e soluzioni sul mercato.
Studi dell’Istituto Nazionale del Commercio USA hanno valutato intorno ai 60 miliardi di dollari, il
costo della difettosità del software per le aziende americane nell’ultimo anno.
Gli stessi studi hanno stimato che una gestione più strutturata del processo di test, con un
potenziamento delle infrastrutture dedicate a tale scopo, permetterebbe, con una migliore e
preventiva individuazione dei "bachi", un risparmio di circa un terzo della cifra di soldi persi, citata in
precedenza.
In questa categorie di infrastrutture rientrano le tecnologie per la gestione e l’automazione dei test.
In particolare, con le attuali tendenze di mercato che vedono l’accentuarsi dei modelli di sviluppo in
outsourcing ed offshoring, un accurato processo di test, diviene per il committente l’unico mezzo di
controllo ed ownership della qualità dei servizi messi in produzione.
1.1
Il più comune TEST AUTOMATION "Misunderstanding"
Che cosa s’intende con l'automazione dei test?
L'automazione dei test si ottiene mediante l'uso di strumenti dedicati per registrare ed
automatizzare l’esecuzione delle transazioni di business e le operazioni di sistema, allo scopo di
verificare l’aderenza di un’applicazione ai requisiti funzionali e non funzionali richiesti, la correttezza
architetturale, la scalabilità e le prestazioni.
Gran parte degli strumenti di test automation sono dotati di editor, linguaggi di programmazione
(es: Visual Basic, Java, ecc.) e relativi compilatori oppure basano il loro funzionamento su scripting
language standard (Javascript) o proprietari.
Questo significa, e forse questo è il fraintendimento più comune, che non sono solo strumenti di
registrazione di macro e successiva riproduzione, ma altresì ambienti di programmazione
pienamente funzionanti e come tali devono essere trattati. L’utilizzo di tali tecnologie per la
semplice registrazione e riproduzione dei programmi in modalità point-and-click è la maggior causa
di fallimento delle iniziative di testing factory.
Per l’adozione di strumenti di test automation occorre avvalersi quindi di risorse con adeguate
competenze di programmazione per la registrazione, la personalizzazione ed il mantenimento dei
casi di test automatizzati.
5
1.2
Breve Tassonomia Tecnologica
I prodotti di Test Automation sono tipicamente dedicati a verificare che le applicazioni testate
rispettino i requisiti espressi relativi a: funzionalità, prestazioni, sicurezza, affidabilità, ecc.
Un’altra classe di strumenti che ha uno scopo analogo ma un differente approccio è rappresentato
dagli strumenti per l’analisi della qualità delle applicazioni (statica o runtime). I primi operano una
scansione del codice sorgente per verificare se sono state seguite le linee guida di scrittura, se sono
presenti errori di progettazione o punti di vulnerabilità ad attacchi informatici. I secondi permettono
l’analisi delle applicazioni in esecuzione fornendo un vero e proprio laboratorio per l’esecuzione
controllata delle applicazioni.
La suite Rational di IBM è la più completa sul mercato della qualità applicativa, offre all’utilizzatore
una vasta gamma di moduli e funzionalità in grado di coprire tutti gli aspetti necessari all’esecuzione
e gestione del test, permettendo di esercitare qualsiasi tipo di verifica sul software applicativo e
sull’infrastruttura sistemistica di base.
1.2.1 Strumenti per il Test Funzionale
Questa tipologia di strumento è in grado di registrare le interazioni tra utente finale ed applicazione
testata, registrando le azioni intraprese dall’utente sugli oggetti presenti nella GUI dell’applicazione,
dei dati trasmessi e delle interfacce generate dall’applicazione. Tali interazioni vengono registrate su
uno script (tipicamente in linguaggio di programmazione standard come Java o Visual Basic) che
può essere ritoccato da sviluppatori ed eseguito per riprodurre automaticamente l’intera sequenza
di azioni verificando puntualmente i risultati forniti dall’applicazione. Tali strumenti vengono
generalmente impiegati per le funzionalità dell’intera applicazione (ad esempio test di
accettazione/regressione).
Figura 1 - Rational Functional Tester: registrazione automatica di un test case
6
1.2.2 Strumenti per il Test di Performance e Carico
Consistono un ambiente per la registrazione/definizione dello script di test, un ambiente per la
definizione del carico di lavoro ed un ambiente per l’esecuzione dei test e la raccolta dei dati sulle
prestazioni dell’applicazione. La funzionalità su cui testare le performance deve essere
accuratamente scelta tenendo conto dell’architettura dell’applicazione e dell’infrastruttura che la
supporta. Per la generazione del carico di lavoro vengono utilizzati appositi agenti in grado di
simulare da un’unica postazione fisica l’attività di molti utenti concorrenti. I tempi di risposta (endto-end) dell’applicazione vengono misurati per ogni singola sessione. É inoltre possibile analizzare le
performance di tutta l’infrastruttura fisica (banda di rete, memoria utilizzata, I/O) o applicativa (tempi
di risposta dei singoli metodi/funzionalità) permettendo di risalire alle cause di eventuali
malfunzionamenti o di tempi di risposta non adeguati.
Figura 2 - Rational Performance Tester: risultati di una sessione di stress test
1.2.3 Strumenti per il Test Unitario
Si tratta di strumenti utilizzati dai programmatori per testare le singole parti (unità) del codice
sorgente che compone l’applicazione sviluppata. Nel caso di linguaggi di sviluppo object oriented
l’unità è rappresentata dal metodo dell’oggetto sviluppato. Tali strumenti consentono una verifica
puntuale molto approfondita del codice sorgente e sono molto utili quando si adottano metodiche
di sviluppo Agili (ad esempio Test Driven Development o Continuous Integration di estreme
Programming). Tali metodiche prevedono che lo sviluppo dei test unitari vada di pari passo con lo
sviluppo del codice sorgente e che ogni modifica effettuata venga prontamente verificata ai vari
livelli di integrazione. Purtroppo il tempo di introduzione di tali strumenti su code base estese (ad
esempio nel caso di applicazioni già in produzione a cui bisogna fare manutenzione evolutiva e/o
correttiva) risulta molto alto e richiede un’introduzione graduale.
7
Figura 3 – JUnit: risultati del test
1.2.4 Strumenti per il Vulnerability Assessment
Questi strumenti effettuano test automatici di intrusione sull’applicazione identificando le possibili
vulnerabilità a cui l’applicazione è soggetta. L’identificazione delle vulnerabilità viene effettuata
attraverso la simulazione una serie di attacchi seguendo le tecniche di hacking più sofisticate e
registrando quali dei tentativi effettuati vengono respinti e quali no. Al termine della sessione tali
strumenti producono un report che riporta un indicatore del grado di sicurezza dell’applicazione e
l’elenco delle vulnerabilità individuate con i possibili rimedi.
Figura 4 - Vulnerability report prodotto con Rational Appscan
8
1.2.5 Strumenti per l’analisi statica del codice
Questi strumenti per lo più destinati ai programmatori, consentono mediante l’analisi del codice
sorgente una valutazione preventiva della qualità del codice sviluppato secondo metriche standard
internazionali e/o secondo regole di codifica specificamente definite. Oltre alle verifiche sulla qualità
e sulla complessità del codice sviluppato, tali analisi si possono concentrare sul corretto utilizzo delle
risorse operative utilizzate (ad esempio un determinato stream di I/O viene aperto ma in
determinate situazioni non viene chiuso) e sulla vulnerabilità del codice sviluppato a possibili
attacchi (ad esempio SQL Injection).
Figura 5 - Rational Software Analyzer: configurazione delle regole
1.2.6 Strumenti di analisi runtime
Sono strumenti che consentono di strumentare l’applicazione che viene eseguita per verificare il
corretto comportamento dell’applicazione in tutte le situazioni. Attraverso questi strumenti è
possibile verificare la corretta strutturazione dei programmi (ad esempio per programmi
multithread) identificando colli di bottiglia, trovare eventuali risorse non correttamente gestite (ad
esempio memoria allocata ma non rilasciata), nonché di rilevare durante l’esecuzione dei test, la
percentuale di "copertura del codice" (quali sono i cammini di programma eseguiti e quali no).
9
Figura 6 - Applicazione Java profilata tramite TPTP
1.2.7 Strumenti per la gestione della qualità
Questi strumenti forniscono un set completo di funzioni per il governo della qualità delle
applicazioni. Sono solitamente dotati di un repository nel quale vengono memorizzate tutte le
informazioni necessarie alla gestione della qualità (i piani di test, i casi di test ed i loro agganci con
gli script che li automatizzano, le suite di test ed i risultati delle esecuzioni delle varie sessioni di
test). A partire da queste informazioni è possibile ottenere un’ampia reportistica documentativa e
statistica in forma testuale o di dashboard (indicatori rappresentati graficamente). Operano inoltre
come coordinatori centralizzati del workflow delle varie attività di test e possono essere integrati
con gli altri tool per la gestione del ciclo di vita delle applicazioni (per esempio prodotti di Change
Management, Requirement Management, Service Desk, ecc.) ed in particolare con gli strumenti di
test automation per coordinare l’esecuzione delle suite di test nei diversi ambienti.
10
Figura 7 - Rational Quality Manager: dashboard dei test di prodotto
1.3
Automazione dei test : quali sono i costi da affrontare?
Ci sono fondamentalmente quattro diverse categorie di costi connessi con l'automazione di test.
1.3.1 Costo del software
Genericamente parlando il costo delle licenze software varia ovviamente per ogni singolo
produttore e dalla singola situazione di vendita contingente. I valori riportati nel seguito servono
unicamente a fornire un ordine di grandezza medio dell’investimento.
Per il collaudo funzionale il costo del software in media ammonta a qualche migliaio dollari per
utente, mentre il costo di uno strumento di verifica delle prestazioni può oscillare da qualche decina
di migliaia di dollari (se si utilizza ad esempio la sola simulazione virtuale di poche centinaia di utenti
via web – http) a cifre molto più considerevoli all’aumentare del numero di utenti virtuali e dei
protocolli utilizzati.
Esistono numerose tecniche per simulare un carico di lavoro molto superiore al numero di utenti
utilizzati che in genere si basano sulla riduzione del tempo tra una operazione e la successiva da
parte di un utente virtuale. Tali tecniche consentono un risparmio considerevole dei costi di licenza.
11
1.3.2 Costo dell'hardware
Il costo dell'hardware necessario a supportare i test è generalmente contenuto. Nel caso di test
funzionali sarà necessario predisporre un ambiente di sviluppo dei test (che comprenda una
postazione di lavoro per ogni test engineer) ed un computer per ogni ambiente di esecuzione
dell’applicazione da testare specifico in cui si intende eseguire i test (in presenza di una specifica
configurazione di hardware, versione di sistema operativo, database, librerie software, etc). Per
evitare il proliferare di ambienti di esecuzione è utile prendere in considerazione l’uso di macchine
virtuali ospitate da uno stesso computer fisico.
Il costo dell’hardware per il controllo prestazionale (load e stress test) può essere molto superiore. In
genere, quando si parla di qualsiasi tipo di test multi-utente, i produttori di strumenti basano la
capacità in termini di utenti virtuali. Un utente virtuale è un processo o un thread che può emulare
una sessione di accesso.
Il test prestazionale richiede in genere una macchina master centrale che opera come schedulatore
e coordinatore dell’esecuzione delle sessioni di test su le macchine satelliti dove sono installati
appositi agenti che simulano gli utenti virtuali. Ogni utente virtuale consuma le risorse del computer
satellite. Un singolo utente virtuale può consumare da 300KB a 1 MB di RAM durante l’esecuzione.
Inoltre, la CPU di un desktop può supportare dai 100 ai 250 utenti virtuali contemporanei.
Va da se quindi che il costo dell’hardware per il performance test è in stretta dipendenza dal
numero di utenti contemporanei che occorre simulare.
Per ridurre sensibilmente questa tipologia di investimenti, IBM offre la possibilità di utilizzare l’intera
infrastruttura necessaria al test automatico, mettendo a disposizione la suite Rational in cloudcomputing. In questo caso si può parlare (in svariate forme) di noleggio dell’intero ambiente di
Testing Factory senza ulteriori oneri aggiuntivi.
1.3.3 Costo del personale ed addestramento
L’impianto della testing factory automatizzata ed il suo mantenimento nel tempo, necessita di
personale dedicato e preparato. Per il test funzionale gli skill richiesti possono essere ricondotti a
quelli necessari per lo sviluppo applicativo (coordinatori, analisti/programmatori, tester).
Per lo sviluppo degli script di test occorre un’esperienza di almeno 2 anni di programmazione
applicativa. Mediamente una risorsa diviene autosufficiente nel giro di 3-6 mesi a seconda della
complessità intrinseca delle applicazioni da testare. Una scarsa conoscenza delle tecniche di
sviluppo degli script di test comporta una scarsa qualità degli script sviluppati con la conseguenza di
avere degli script scarsamente automatici e dei costi di manutenzione degli stessi script che
aumentano a dismisura. Per contro una conoscenza approfondita degli strumenti di test e delle best
practices consente lo sviluppo di script che minimizzano i costi di manutenzione anche nel caso di
modifiche radicali alle interfacce delle applicazioni (situazione tipica nei cambi di versione
dell’applicazione).
Le competenze necessarie ad effettuare correttamente i test di performance vertono maggiormente
sugli aspetti architetturali e sistemistici. Per queste tipologie di test è necessario disporre di una
competenza approfondita dell’applicazione e dell’ambiente che la ospita in modo da individuare le
funzionalità da invocare, la crescita del carico di lavoro, l’interpretazione dei dati relativi ai tempi di
risposta o all’occupazione delle risorse di sistema o applicative, l’individuazione delle cause di
eventuali malfunzionamenti o ritardi.
12
1.3.4 Costo di scripting (o codifica) dei casi di test
Dal punto di vista funzionale è rappresentato dal tempo di registrazione dei casi di test e dal tempo
di adattamento ed estensione degli stessi (codifica dello script).
Il tempo di customizzazione degli script è sicuramente più oneroso dell’esecuzione del test manuale,
ma diventa vantaggioso già dopo poche ri-esecuzioni dello stesso. Gli script sviluppati devono poi
essere mantenuti nel tempo e seguire il variare delle applicazioni.
Primeur ha messo a punto una propria metodologia e strumentazione per limitare al massimo i costi
di manutenzione ed i tempi di esecuzione dei test di regressione.
Per ridurre i costi di manutenzione degli script di test funzionali è necessario seguire un insieme di
pratiche che minimizzino le dipendenze di tali test dal look and feel delle applicazioni attraverso
l’identificazione diretta degli oggetti presenti nell’interfaccia applicativa.
Per ridurre i tempi di esecuzione dei test di regressione, a partire dal change set (insieme di moduli
che sono stati modificati per il nuovo rilascio) vengono identificati tutti i test case su cui tali
modifiche possono avere impatto e si costruisce una suite di test specifica che contiene tutti e soli i
test necessari. In questo modo vengono limitati al minimo i tempi di esecuzione dei test e nel
contempo vengono eseguiti tutti i test che insistono su tali moduli e che possono quindi rilevare
eventuali malfunzionamenti.
13
2
I Benefici dell’Automazione del Test
2.1
Automazione dei test : quali sono i benefici tangibili?
Di seguito vengono elencati i principali e reali vantaggi ottenibili nell’automazione del processo di
test.
2.1.1 Velocità e precisione
L’automazione rende il test più accurato del controllo manuale. L’esecuzione delle sessioni di
collaudo può arrivare ad essere anche 50 più veloce dell’esecuzione manuale, robotizzando l’intera
attività di inserimenti, cancellazioni, aggiornamenti e visualizzazioni.
Una Suite di test comprende generalmente migliaia di casi di test che sollecitano l’applicazione con
richieste che riportano valori ammissibili, valori limite e valori non ammessi e verificando per ogni
richiesta il corretto funzionamento dell’applicazione.
Gli strumenti automatici risultano inoltre notevolmente più precisi e rigorosi dell’attività umana (in
media 3 errori ogni 1000 battute), non si stancano ed annoiano mai, non prendono scorciatoie o
fanno assunzioni di ciò che funziona.
2.1.2 Profondità
Gli strumenti di automazione consentono di accedere e controllare oggetti, dati, protocolli di
comunicazione e sistemi operativi che un tester manuale non sempre è in grado di fare. Questo
permette una maggiore profondità ed ampiezza dei test.
2.1.3 Riutilizzo
Una volta sviluppati i test case, i benefici a lungo termine sono derivati attraverso il riutilizzo degli
stessi, in modo particolare nei test di regressione che spesso vengono trascurati: si tende a
concentrarsi sulla verifica del funzionamento della nuova funzionalità, tralasciando di controllare che
ciò che è stato programmato in precedenza continui a funzionare.
Le applicazioni sono in continuo cambiamento e la loro complessità si incrementa di volta in volta
nel tempo, conseguentemente il numero dei test da eseguire è sempre in aumento.
I test engineer possono aggiungere casi di test alla suite e ripetere gli stessi controlli, senza spreco
di tempo migliaia di volte nella stessa unità di tempo.
2.1.4 Gestibilità
La capacità di gestire l’intero ambiente di test, i suoi oggetti e risultati attraverso tool dedicati,
porta ad una razionalizzazione dell’intero processo e aumenta il livello di maturità dell’azienda (cfr
CMMI).
14
2.1.5 Proattività
Più volte si è ribadito di quanto danno porti la scoperta di una difettosità in ambiente di produzione.
L’automazione del test aiuta sensibilmente ad individuare i problemi in modo precoce, durante le
fasi di sviluppo, riducendo i rischi di fallimento in produzione ed i relativi costi di rispristino.
2.1.6 Ripetibilità e disponibilità
Una suite di automazione fornisce un processo ripetibile per verificarne sia le funzionalità che la
scalabilità delle applicazioni, e le batterie di test possono essere eseguite in qualsiasi momento del
giorno o della notte senza la necessità del presidio umano.
2.2
Automazione dei test : quali sono i benefici intangibili?
2.2.1 Formalizzazione del processo di test
Il flusso d’informazioni e la precisa esplicitazione dei requisiti, necessaria al processo di
automazione, rafforza la strutturazione del processo stesso tra i vari dipartimenti aziendali,
rendendone più agevole il controllo ed evidenziandone eventuali carenze ed inefficienze.
2.2.2 Customer Retention ed Immagine Aziendale
Quando i sito web non funziona correttamente od è poco performante, i clienti possono abbondare
il fornitore dei servizi per la concorrenza. Qual’ è il costo per l'azienda di tale scenario? Oppure, una
transazione di home banking è stata malevolmente intercettata perché non correttamente protetta
dalle intrusioni sulla rete? Quale danno per l’immagine?
L’esecuzione sistematica dei test aiuta a garantire un servizio di qualità per il clienti sia interni che
esterni.
2.2.3 Incremento della professionalità dei tester
L’eliminazione delle attività ripetitive, svolte dagli addetti all’esecuzione dei test, che devono
eseguire manualmente gli stessi casi più e più volte conduce ad un progressivo aumento della
professionalità individuale. L’utilizzo di tool vicini all’ambiente di programmazione, rende l’attività
più interessante e stimolante, aumentando il coinvolgimento ed il grado di responsabilità e
professionalità dei singoli.
15
3
Alcune cause di fallimento e suggerimenti per evitarli
Prendendo spunto dall’esperienza maturata internamente nei laboratori Primeur e
nell’implementazione di infrastrutture di test automation presso i clienti, di seguito sono elencate le
criticità principali che potrebbero comportare di fallimento del progetto ed al tempo stesso alcune
regole di base per superarle, in modo che l’iniziativa possa essere di successo.
3.1
Assenza di una metodologia
Occorre attuare una metodologia strutturata di automazione dei test. Implementare cioè un
approccio pragmatico ai test che sia controllabile, ripetibile, misurabile, migliorabile, automatizzato
e basato sul rischio.
Controllabile: scomposizione del progetto in fasi modulari, con compiti definiti, risorse
assegnate e scadenze concrete.
Ripetibile: in modo che altri possano facilmente portare avanti il processo che è stato
definito.
Misurabile: in modo tale che l’effort sia quantificabile e comparabile con i risultati ottenuti
(numero di difetti riscontrati in ogni fase, trend dei livelli di gravità dei differenti, livelli di
performance, ecc.).
Migliorabile: tanti più difetti riesco a riscontrare nel ciclo di collaudo tanti meno occorrerà
gestirne in fase di produzione.
Automatizzato: l’automazione coma già detto in precedenza, riduce il rischio di errori e
trova la sua massima redditività d’impiego nei test di regressione e di carico.
Basato sul rischio: effettuando cioè un analisi approfondita delle funzionalità
dell’applicazioni focalizzandosi sulle specifiche necessità di test di quelle più critiche ed
utilizzate.
3.2
Assenza di un approccio progettuale
Spesso l'automazione dei test non è trattata come un vero e proprio progetto con relativi obiettivi,
pianificazione, risorse e time-to-market adeguati.
L’attività viene piuttosto interpretata come l’impiego di una comodity per un utilizzo strettamente
tattico. La tecnologia viene vista come un semplice registratore ed esecutore di Macro.
Si tratta di un approccio totalmente errato. Occorre trattare l'automazione dei test come si farebbe
con un progetto di sviluppo gestendone in modo corretto i costrain di tempi e risorse disponibili
commisurati agli obiettivi da raggiungere.
3.3
Serializzazione tra Sviluppo e Test
Spesso l’esecuzione dei collaudi avviene unicamente al completamento della codifica dell’intera
applicazione ed anche la progettazione dei casi di test, è solitamente poco correlata ai requisiti
raccolti durante le varie fasi di analisi (funzionale e tecnica) e dall’evoluzioni che durante lo sviluppo,
gli stessi hanno subito in virtù di revisioni, affinamenti ed introduzione di altre richieste.
16
Questo metodo di sviluppo a cascata (Waterfall) che detta che la fase di test deve avvenire a valle
del system design, dell’analisi di dettaglio ed a completamento dell’intera codifica, è un approccio
che ha funzionato bene quando i sistemi informativi erano totalmente mainframe (single tier).
Con le odierne infrastrutture distribuite, multi-tier, per loro natura complesse ed i nuovi paradigmi
di sviluppo iterativo, occorre modificare questo tipo di approccio, traguardando l’impiego di
metodologie di Agile Testing.
Inizio
Rilascio
Sviluppo, Test &
Verifiche
Sviluppo, Test &
Verifiche
Sviluppo, Test &
Verifiche
Il test e collaudo va anticipato alla fase di very early development dedicando l’effort necessario al
test design, alla pianificazione dei collaudi, l’esecuzione e la tracciatura dei risultati con i requisiti di
progetto.
L’automazione ben si adatta a cicli di sviluppo iterativo rendendo la ripetitività delle prove
altamente performante ed abbassando notevolmente i costi di verifica.
3.4
Focalizzazione sul test della GUI
Con le odierne architettura eterogenee, non è più sufficiente dichiarare che l'applicazione non
funziona correttamente o non scala, basandosi unicamente sul test pilotato dall’interfaccia utente. Il
personale tecnico ha bisogno di sviluppare una adeguata strategia, supportata da strumenti
tecnologici moderni, che consentano di determinare dove esattamente si verificato il problema e
mantenendo il controllo e la tracciatura del test, attraverso tutti gli strati infrastrutturali (sistemi
operativi, rete, middleware, application server, erp, web, ecc.) implicati nel funzionamento
dell’applicazione.
Ciò richiede un approccio basato su componenti in cui l’architettura dell'applicazione è scomposta
in componenti più piccoli. I dati vengono rintracciati e verificati dal primo livello-tier fino all’ultimo
attraversato.
3.5
Scarsa modularizzazione degli script di test automation
Come si è detto nelle pagine precedenti, i tools di automazione sono da consideransi veri e propri
ambienti di programmazione il cui utilizzo è quello di codificare programmi aventi lo scopo di
robotizzare l’esecuzione e la verifica dei casi di test.
17
Occorre quindi applicare nello sviluppo degli script gli stessi accorgimenti se regole applicabili ad
una corretta programmazione:
Evitare di scrivere script troppo lunghi, nidificati e complessi, ma piuttosto scomporli in
librerie di funzioni elementari, modulari e richiamabili in differenti sessioni di prova.
Evitare la registrazione di navigazioni ridondanti.
Utilizzare una naming convention parlante, che renda fruibile l’ambiente anche dai meno
esperti e faciliti la manutenzione.
3.6
Utilizzo di risorse inadeguate
L’impiego di qualsiasi strumentazione porta maggiori benefici, quanto più la si conosce e ne si
domina l’intera potenzialità.
I tool di automazione non sono particolarmente complessi da utilizzare ma al tempo stesso, per
rendere proficuo l’investimento, devono essere sfruttate a pieno le loro potenzialità. E’ necessario
perciò dotarsi di personale con skill adeguati, supportati da un corretto addestramento ed
affiancamento da parte di personale esperto. Si tenga in considerazione che l’autonomia operativa
si raggiunge in un paio di settimane mentre per la vera e propria expertise occorrono almeno tre-sei
mesi di utilizzo intensivo sul campo.
3.7
Best Practices per il mantenimento della suite di Test
Spesso succede che dopo aver inizialmente investito nella creazione di suite per l'automazione
(magari legata ad uno sviluppo strategico importante), il cliente non mantiene aggiornata la suite
per collaudare le future versioni dell’ applicazione (nuove build).
Perché spendere tempo e denaro per lo sviluppo di una solida suite di automazione test e quindi
non supporto e mantenerla? Perché l’investimento iniziale possa essere remunerativo, le suite di test
devono essere mantenute seguendo di pari passo l’evoluzione di ogni nuova build e rilascio di
un'applicazione.
Occorre programmare questo tipo di manutenzione e dedicare una struttura organizzativa
centralizzata interna all’azienda (od appaltata ad un fornitore esterno) che possa prendere in carico
di analizzare gli impatti sull’environment di test, dell’evolversi delle applicazioni ed effettui le
eventuali modifiche al parco di test script. Il lavoro di manutenzione degli script di test richiede in
genere il 20% del tempo impiegato originariamente, nella creazione degli stessi.
Primeur è in grado di offrire un servizio di outsourcing per questo tipo di esigenza consentendo al
cliente un efficientamento dell’assegnazione delle risorse interne unitamente alla salvaguardia
dell’investimento.
18
4
Il Calcolo del ROI
4.1 Come valutare se un'applicazione può essere candidata per
l'automazione ...?
Fermo restando il fatto che non tutto il test può o deve essere robotizzato, in caso di risposta
affermativa a una di queste domande, l'applicazione in oggetto è un buon candidato per
l'automazione, commisurato al ritorno d’investimento ottenibile.
L’applicazione deve operare su configurazioni hardware/software differenti?
L’applicazione prevede di avere almeno 5 nuovi rilasci ?
Lo sviluppo dell’applicazione è dato in outsourcing od offshoring ed il
onorare un contratto basato su SLA (Service Level Agreement)?
fornitore deve
L’applicazione prevede più di 5 utenti contemporanei e/o concorrenti?
Ci sono task ripetitivi che vengono eseguiti per mantenere l’applicazione (per esempio
caricamento dei dati, configurazione, ecc.)?
4.2
Tabella esempio per il calcolo del ROI
La tabella riportata di seguito, ha lo scopo di fornire una piccola guida per la raccolta dei dati più
significativi, necessari ad una veloce valutazione circa la convenienza dell’automazione del test di un
applicazione, rispetto ad un’esecuzione totalmente manuale.
19
Voci
Risorsa x
Test
Manuale
Totale
Costi Test
Manuale
Risorse x
Test
Automatico
Totale
Costi
Automazione
Costo orario della risorsa
Effort per la progettazione di
1 Test Case
Effort per la progettazione di
(*)100 Test Case
Effort per l’automazione dei
Test Case
Effort per esecuzione ed analisi
di ogni singolo Test Case
Effort per esecuzione totale
sulla 1° release
dell’applicazione
N. di release applicative
previste
Effort per esecuzione totale
sulle release successive
Numero Manutenzioni
Correttive/Evolutive Previste
(su base annua)
Effort per esecuzione totale
Manutenzioni
N. Piattaforme operative
Effort per esecuzione
Piattaforme Operative
TOTALE
4.3
Conclusione
Il rendimento dell’investimento nell’automazione di test è abbastanza ovvio.
Se utilizzate correttamente, le suite di automazione si riveleranno molto più efficienti ed efficaci del
test manuale per scovare difettosità funzionali e risultato forse l’unico ausilio, per verificare la
scalabilità, il carico ed eventuali problemi prestazionali.
Le sessioni di test possono essere eseguite durante la notte, nei weekend e festivi, in modo
totalmente non presidiato. E’ possibile proattivamente emulare il maggior numero di utenti
effettuando qualunque mix di operazioni necessarie.
Pertanto, il ROI, (=benefici tangili+intangibili / costo iniziale) del test automatizzato garantisce un
ritorno enorme, a patto che le insidie e le criticità elencate nelle pagine precedenti vengano
affrontate e superate.
20
5
Il Centro di Competenza PALM
Il Centro di Competenza PALM dispone di profonde competenze e documentata esperienza sulla
problematica del governo dello sviluppo di applicazioni.
Più di venti anni di esperienza nello sviluppo di infrastrutture software su sistemi eterogenei
(Windows, Linux, Unix, z/Os, ecc.), la solida partnership con IBM, la profonda conoscenza dei tool
Rational e WebSphere comprovata da numerose certificazioni tecniche e dagli add-on sviluppati,
sono gli elementi che distinguono l’offerta Primeur nel campo dell’Application Lifecycle
Management.
5.1
La Metodologia PALM
La metodologia PALM, frutto della ricerca costante e della profonda esperienza maturata,
garantisce il raggiungimento degli obiettivi preposti, fornendo razionali tangibili e misurabili lungo
tutto il percorso di svolgimento delle attività di progetto.
Assess
Improve
Execute
Plan
Figura 8 - La Metodologia Palm
Stabiliti gli obiettivi dell’iniziativa, viene condotta una fase di Assessment del processo attuale che si
pone l’obiettivo di comprendere il livello di maturità dell’organizzazione del cliente, in termini di
strutturazione dei processi e degli strumenti metodologici e tecnologici utilizzati.
Una volta che è ben chiaro dove siamo e dove vogliamo arrivare, viene definito un percorso (piano
di attività) per raggiungere gli obiettivi definiti. Tipicamente viene seguito un approccio prototipale
di tipo Think big and start small, in modo da fornire al cliente la visione complessiva del risultato a
tendere, però saldamente articolata in piccoli passi evolutivi, precisamente definiti per contenuti e
tempi di realizzazione, in modo da consentire risultati tangibili e misurabili a breve/medio termine,
che evidenzino il miglioramento del processo ALM rispetto alla situazione precedente e lo sforzo
economico sostenuto per raggiungere l’obiettivo.
21
Una costante misurazione dei livelli di servizio e del grado di utilizzo della soluzione, consentirà
inoltre di diluire in tempi ragionevoli gli impatti organizzativi e le resistenze al cambiamento, nonché
la verifica del progressivo grado di adozione della soluzione.
5.2
Modalità di Erogazione
I servizi offerti da Primeur coniugano aspetti metodologici di gestione della qualità con l’esperienza
che Primeur ha maturato in più di 20 anni di sviluppo di infrastrutture software su sistemi eterogenei
e si avvalgono dei migliori tool presenti sul mercato per offrire una soluzione adatta a qualsiasi
realtà aziendale dalla piccola software house che lavora con team Agili, all’organizzazione enterprise
che impiega team distribuiti su scala globale utilizzando processi altamente strutturati e fornitori in
outsource o offshore.
I servizi offerti possono essere erogati secondo due modalità:
"*In house*": Il cliente si dota di tecnologie, e risorse a supporto del processo di sviluppo, che
viene gestito operativamente dalla struttura organizzativa ICT interna del cliente.
"*As a service*" (SAAS): Il processo di "Application Lifecycle Management" viene commissionato
come servizio. Le nostre soluzioni sono in grado di guidare i team di sviluppo ad ottenere risultati
misurabili in termini di efficienza, qualità, valore e innovazione. In questo caso il committente
concorda con Primeur tempi, metodi e deliverables della gestione e dell’analisi di qualità del
software e relativi SLA che consentano di valutare l’efficienza ed efficacia del servizio stesso.
5.3
Primeur: Profilo della Società
Primeur, azienda multinazionale fondata a Genova nel 1986 e presente in Europa, (Italia, Spagna,
UK, Irlanda, Svizzera, Benelux (*), Germania (*)). USA(*) e Sud America(*), è uno dei principali
produttori di soluzioni middleware per sistemi informatici distribuiti ed eterogenei.
(*) tramite Partners/Distributori.
Primeur è un IBM Premier Business Partner e presta particolare attenzione agli ambienti IBM
WebSphere, Tivoli, Rational e Information Management, offrendo nel contempo soluzioni in tre aree
di primaria importanza: Integrazione, Sicurezza e System Management.
Primeur fornisce software e servizi per la SOA, middleware di comunicazione, integrazione di
applicazioni legacy e sicurezza dati.
La base della strategia di Primeur è fondata sul continuo sviluppo della propria tecnologia, basata su
SPAZIO Managed File Transfer / Secure (SPAZIO MFT/S) che è ora integrato con l’ambiente SOA di
IBM. SPAZIO MFT/S è l’esempio dell’adozione delle tecnologie e standard emergenti, in particolare
della Service Oriented Architecture.
Grazie a questa strategia i prodotti e le soluzioni Primeur sono disponibili sulle principali piattaforme
hardware e software quali: z/OS, UNIX, Windows, OS/400, Linux, Guardian, ecc.
Primeur impiega oggi oltre 200 dipendenti. Con più di 500 Clienti nel mondo, Primeur è considerata
un partner strategico da più di 100 grandi aziende operanti nelle aree della Finanza, Industria,
Servizi.
22
Nel 2007 nel Gruppo Primeur è stata costituita una nuova Società, denominata Primeur Pubblica
Amministrazione. Le attività della società sono indirizzate in via prioritaria verso la Pubblica
Amministrazione Centrale (PAC) e Locale (PAL), gli Organi, gli Enti e le Società di dette
Amministrazioni, le Autorità, gli Organismi nazionali ed internazionali, gli Enti pubblici economici.
Attraverso una combinazione di prodotti, servizi ed esperienza qualificata dei "Competence Center"
le soluzioni di Primeur possono essere adattate per soddisfare le necessità di ogni tipo di impresa.
L’obiettivo del Gruppo Primeur è diventare il "partner tecnologico" dei Clienti nell’implementazione
delle infrastrutture, con particolare riguardo alle problematiche di Integrazione, Sicurezza e System
Management. In queste aree Primeur offre:
Consulenza
Analisi e sviluppo progetti
Estensioni e integrazioni di tecnologie e prodotti di mercato, per costruire soluzioni
rispondenti al 100% alle esigenze dei Clienti
Servizi di gestione dell’infrastruttura IT del Cliente
Training.
Per ulteriori informazioni vi invitiamo a visitare il nostro sito web: http://www.primeur.com/palm o
contattarci inviando una mail a [email protected].
23