L'adeguamento del software per Anno 2000 e Euro ha richiesto un investimento rilevante da parte delle aziende. Alcune aziende hanno interpretato la correzione del software come un fatto fine a se stesso; altre, tra cui Sanpaolo Imi, hanno saputo cogliere l'occasione per apportare miglioramenti significativi ai propri sistemi informativi, trasformando l'incombenza in un'opportunità irripetibile per effettuare il censimento dei componenti software esistenti, integrare i modelli di progetto in un modello aziendale, riorganizzare il processo di sviluppo di manutenzione del software.
La necessità di accertare il corretto funzionamento e la non regressione del software sottoposto a conversione, è stata interpretata da Sanpaolo IMI come l'occasione per sviluppare la Test Factory.
Aldo Fresu, responsabile della Funzione Organizzazione e Processi di Business, ripercorre con noi i passi salienti di tale progetto.
"Vi erano alcuni aspetti rilevanti di cui occorreva tener conto", spiega Fresu, "quando sono state esaminate le implicazioni connesse con il testing del sistema informativo dell'Istituto. Da un lato la necessità di non incidere in modo eccessivo sul carico di lavoro delle Aree Applicative, già coinvolte nell'adeguamento del software, dall'altro l'opportunità di consolidare e diffondere la Metodologia di Testing precedentemente sviluppata.
Uno studio condotto in collaborazione anche con Tecnet Dati ha permesso di delineare le direttrici del progetto e precisamente:
istituzione di una unità organizzativa con competenze specifiche, adozione di un approccio formale al testing, gestione della qualità".

Istituzione del Gruppo Indipendente di Test

"Il primo quesito", prosegue Fresu, "riguardava chi dovesse effettuare il testing del sistema informativo dell'Istituto. L'istituzione di un gruppo con competenze specifiche presentava alcuni punti di forza rispetto alla scelta di delegare tale compito alle aree applicative, particolarmente rilevanti se rapportati al contesto evolutivo dell'Istituto: definizione di un processo di testing valido per tutte le aree applicative, adozione di un approccio formale al testing, possibilità di svolgere un controllo effettivo sul livello di qualità del software convertito presso i laboratori esterni. Costituiva inoltre il primo passo verso lo sviluppo della Test Factory ".
Il Gruppo di Test coinvolge diversi attori. L'elemento centrale è costituito dal Comitato cui compete la pianificazione, l'organizzazione e il controllo qualità nell'ambito dei progetti di test. Vi sono poi le Funzioni di supporto, per esempio Specialista di test e Predisposizione ambienti di test, e i rappresentanti delle aree applicative e delle funzioni di business che hanno il compito di progettare i test e sottoporre le applicazioni a verifica.
Le funzioni di supporto sono state istituite al fine di fornire consulenza ai gruppi di test per la progettazione dei test case, l'utilizzo di strumenti specifici, la configurazione degli ambienti di test.
I rappresentanti delle aree applicative e delle funzioni di business intervengono nei progetti secondo modi e tempi ben definiti, in base alle competenze necessarie per verificare la correttezza delle applicazioni. L'integrazione di tali risorse nei confronti dei progetti di testing avviene secondo il modello a matrice, in cui il personale è attivato a tempo parziale e opera sia nel suo ambiente normale, sia in quello dedicato al testing.
"Nel caso in oggetto", spiega Fresu, "considerando l'ampiezza del patrimonio software da sottoporre a verifica (circa 70 milioni di linee di codice) e i vincoli organizzativi, applicativi e tecnologici che portavano a prefigurare uno scenario in cui più gruppi di test avrebbero svolto la propria azione procedendo "in parallelo", si è scelto di coinvolgere nell'azione di verifica anche personale proveniente dalle Filiali del Gruppo. La scelta, già sperimentata dall'Istituto in contesti differenti rispetto a quello considerato si è dimostrata efficace anche in questo caso e sarà adottata in modo sistematico per il futuro".

Adozione di un approccio formale al testing

Il testing ha come obiettivo la verifica del funzionamento di un prodotto software rispetto a criteri predefiniti (per esempio il comportamento presunto del sistema). In altre parole si tratta di esercitare un prodotto software, rispetto a specifiche condizioni, al fine di accertare la convergenza tra le caratteristiche funzionali del prodotto e i requisiti specificati.
"La metodologia adottata", prosegue Fresu, "si fonda sui seguenti presupposti fondamentali: approccio di tipo funzionale al testing (black-boxing), strategia basata su più livelli di test, esistenza di un ciclo di vita del test, con conseguente definizione di attività, responsabilità e prodotti finiti attesi".
L'approccio seguito per il testing è essenzialmente funzionale. In altre parole i prodotti software sottoposti a verifica sono osservati esclusivamente per il loro comportamento "ai morsetti", senza considerare la struttura interna.
Il processo di testing ha un proprio ciclo di vita organizzato in fasi, ciascuna delle quali opera su specifici documenti di input, individua un insieme ben definito di attività e di responsabilità e produce specifici documenti di output.
Le fasi individuate nell'ambito del ciclo di vita del testing sono le seguenti: pianificazione, progettazione, esecuzione.
La pianificazione del testing, in quanto prima fase del processo, consiste nell'attivazione formale delle attività di testing e prevede la produzione del Piano di Test, che descrive la strategia globale di testing adottata, adeguata alla natura dei progetti, fornendo un'indicazione di massima di tempi e costi.
La progettazione dei test rappresenta la fase centrale del processo di testing e prevede la predisposizione delle Checklist e delle Specifiche di Test. La Checklist è l'elemento centrale attorno al quale ruotano tutte le attività di testing e descrive tutte le caratteristiche funzionali che si desidera sottoporre a verifica. Il punto di partenza è costituito dalle specifiche di progetto, che devono essere esaminate in modo analitico al fine di ottenere una buona copertura funzionale dell'applicazione soggetta a prova (la copertura funzionale esprime il rapporto tra numero di funzionalità previste per l'applicazione e numero di funzionalità che si intende sottoporre a test). Le Specifiche di Test riportano ogni informazione utile per la costruzione e l'esecuzione del test. In particolare si tratta di fornire una descrizione delle caratteristiche di ciascun test in termini di scopo, descrizione dell'ambiente di esecuzione (stato iniziale), dati di input, risultati attesi, criteri per l'effettuazione del confronto tra risultati attesi e ottenuti.
La fase di esecuzione prevede l'attivazione dei test progettati in un ambiente appositamente predisposto e l'emissione delle Schede Esito Test, che attestano le attività di verifica effettuate e presentano i risultati ottenuti. Si prevede inoltre la predisposizione del Rapporto Anomalie nei casi in cui vi siano differenze tra i risultati attesi e quelli ottenuti.
Particolare attenzione è rivolta alla predisposizione dell'ambiente di test, in funzione della strategia adottata, come attività propedeutica all'esecuzione delle verifiche.
Al termine della fase di esecuzione, nel momento in cui i risultati ottenuti siano ritenuti soddisfacenti dal referente del Gruppo di Test e dall'utente, rispetto ai requisiti di qualità stabiliti nel Piano di Test, l'applicazione sottoposta a verifica è considerata accettata e può essere rilasciata in ambiente di produzione.

Gestione della qualità

Il testing è uno degli elementi qualificanti per assicurare la qualità del software rilasciato in produzione. La gestione dei cambiamenti applicativi (Configuration/Change Management), istituita dall'Istituto sin dai primi anni '90, si fonda proprio sulla predisposizione di un Piano di Test, articolato in funzione dei fattori di rischio connessi con il rilascio in produzione di un prodotto software. Ma anche il testing, in quanto processo, deve conformarsi a criteri di qualità. "Nella fase di impostazione iniziale dei progetti di testing", spiega Fresu, "molta enfasi è stata posta sugli aspetti connessi con l'assicurazione della qualità. In particolare è stato predisposto un Piano di Qualità specifico per i progetti di testing, conforme alle norme ISO.

Conclusioni

Il testing del sistema informativo per anno 2000 è stata l'occasione per capitalizzare gli investimenti effettuati dall'Istituto nel campo del "software engineering". L'approccio adottato dall'Istituto ha permesso di completare il testing del sistema informativo aziendale secondo i tempi previsti, garantendo una buona copertura funzionale delle applicazioni sottoposte a prova, con conseguente riduzione dei rischi di esercizio.
Al termine dell'impegno richiesto per l'Anno 2000, il Gruppo di Test sarà adottato come base per lo sviluppo della Test Factory.