Le Attività di Test

Una delle principali attività che caratterizza un progetto di sviluppo ed implementazione di un applicativo software è quella di Testing.

Risulta opportuno specificare che in merito alla casistica presa in esame nel presente documento, non trattandosi di un progetto riguardante la messa a punto e realizzazione ex novo di un applicativo software, ma bensì di una sua implementazione all’interno di una preesistente architettura informativa, la definizione di Testing non fa riferimento a quella categoria di attività volte verificare la correttezza e la qualità dei codici sui quali il sistema software è stato costruito.

Pertanto le fasi di Testing che hanno caratterizzato l’attività del team di Implementatori, riportate nel dettaglio di Figura 19, e inerenti lo sprint di processo, si sono incentrate sul livello di conformità delle funzionalità della soluzione CCH® Tagetik e sulla valutazione del rispettivo impatto all’interno dell’architettura informativa esistente, in risposta ai requisiti espressi dall’Agenzia.

Figura 19. Scenario Di Emergenza: scheduling di dettaglio per la fase di testing.

Durante il progetto formativo il candidato è stato supportato nella conduzione di quella categoria di attività definite Regression Test, che hanno segnato entrambe le deliverables stabilite per lo sprint “Scenario di Emergenza” e attuate nell’omonimo Ambiente di sistema. La terminologia Regression Test, riferita ad un contesto di architettura informativa, sottintende l’attività volta a verificare la correttezza delle nuove funzionalità apportate al sistema identificando potenziali anomalie o malfunzionamenti.

All’interno della classe di attività che prende il nome di Regression Test, sono categorizzate le seguenti tipologie:

• Unit Test; • Integration Test; • System Test;

• User Acceptance Test.

Queste, descritte più approfonditamente nei paragrafi successivi, si discriminano per il diverso contesto applicativo nel quale vengono condotte, nonché per le rispettive finalità e tempistiche di esecuzione; tuttavia risultano comuni a tutte, specifiche attività preparatorie alla vera e propria esecuzione. In particolare queste ultime si profilano con la Definizione dell’Approccio utilizzato per il Test e la Preparazione dei Dati.

Come possibile evincere dalla Figura 19, riportante nel dettaglio dei task costituenti le Fasi di Test dello sprint Progettuale, per ognuna delle distinte tipologie21 sono state impostate le seguenti attività congruenti:

21 _{Si tenga presente che all’interno dello Scheduling gli Integration Test ed i System Test sono stati inseriti}

• Test Approach Definition: fase di pianificazione del test all’interno della quale il team di consulenti predisponeva e presentava ai referenti progettuali IT dell’Agenzia le modalità di conduzione delle verifiche. In merito agli User Acceptance Test l’attività risultava coordinata dal team dell’Agenzia, il quale presentava al team di KPMG S.p.A le utenze selezionate per la conduzione del test e fornendo in aggiunta gli specifici script test inerenti gli step che sarebbero stati performati da questi ultimi. • Data Preparation: attività di predisposizione della base dati scelta per le attività di

test altamente impattante sul livello qualitativo di queste. Nel dettaglio, si tratta di un task che può prevedere compiti quali la ripulitura del database da contenuti informativi destabilizzanti la verifica, oppure la creazione di opportune istanze, anche di tipo dummy22, da utilizzare per i test ecc.

• Execution.

Unit Test

La categoria incorpora tutte quelle attività condotte sulle entità situate al minimo livello testabile e va a delinearsi come un vero e proprio controllo puntuale operato tra il nuovo elemento informativo e la funzionalità che esso deve incorporare all’interno dell’ambiente informativo.

Entrando nell’ottica specifica del Budget Planning Tool e ricollegandosi ai task eseguiti ai fini del completamento di entrambe le deliverable progettuali, i differenti Unit Test hanno interessato:

• Controllo dell’effettiva registrazione al database di sistema dei nuovi elementi definiti per la dimensione “Attività”. Il corrente test è stato svolto attraverso un’attività di scraping, condotta all’interno della Tabella Anagrafica delle Attività, utilizzando le funzionalità di filtraggio che il sistema CCH® Tagetik fornisce per la ricerca di puntuali contenuti informativi risiedenti all’interno del database.

• Controllo dell’effettivo assegnamento degli elementi “Account” per la rispettiva “Attività” tra le nuove definite. Il test è stato portato avanti attraverso le medesime attività che hanno caratterizzato il precedente. L’unico elemento discriminante tra i due è costituito dal database destinatario della verifica: nella presente casistica infatti, ad essere esplorata e sottoposta ad un controllo non è stata la rispettiva

22 _{Il termine identifica un’istanza fittizia, non presente nella realtà informativa e creata appositamente a}

Tabella di Anagrafica, bensì quella di “Abbinamento” tra gli elementi “Account” e quelli della dimensione “Attività”.

Il controllo dei database anagrafici si configura come significativo laddove siano stati creati nuovi elementi a sistema, istanza che per lo specifico sprint progettuale non ha coinvolto la dimensione “Account”.

• Test sull’effettivo inserimento all’interno del workflow di Processo del nuovo Step “Scenario di Emergenza”. Il presente test è stato implementato all’interno della sezione “Processo” presente in ambiente Web delineandosi inizialmente come una verifica operata a livello visivo dell’effettiva presenza del nuovo step all’interno del workflow del Processo di Pianificazione Basato sulle Esigenze – Draft. Una volta apportato questo primo controllo sono stati revisionati anche tutti i parametri di lancio necessari alla sua corretta conduzione. In particolare, per quanto concerne questo ultimo punto è stato testato che lo step fosse adeguatamente collegato al rispettivo Report di Data Entry costruito ad hoc. La verifica è stata tempestiva in quanto la sezione riportante i parametri è accessibile direttamente dal workflow attraverso un comando di doppio click da eseguire sul blocco di processo interessato.

In linea generale, i tre test miravano a mettere in luce eventuali anomalie legate alle attività di settaggio e registrazione dei nuovi dati all’interno del database. Esse potrebbero essere riconducibili ad errori umani, tra i quali un mancato salvataggio o errate digitalizzazioni durante la definizione dei codici di registrazione delle informazioni. In modo analogo, seppur più raramente, un potenziale errore sarebbe potuto scaturire anche a fronte di un malfunzionamento del sistema non rintracciato, come ad esempio una perdita temporanea di connessione durante il momento del salvataggio dei nuovi contenuti informativi.

Le tre attività di test appena riportate dal punto di vista funzionale sono state prioritarie in quanto un risultato positivo avrebbe stabilito una solida base su cui successivamente andare a impostare gli elementi di livello superiore necessari all’idoneo completamento delle due deliverables progettuali e caratterizzati da un grado di criticità significativamente rilevante.

Integration Test

La presente classe di attività di test viene condotta con lo scopo di verificare l’idonea interazione sussistente tra i diversi componenti di un sistema informativo. In particolare risulta vitale che i contenuti informativi non subiscano deterioramento, modifica, alterazione o la perdita durante la migrazione da un’interfaccia a un’altra.

In particolare, gli Integration Test condotti hanno verificato l’adeguato funzionamento tra le interfacce Web ed Excel del Budget Planning Tool, fondamentale ai fini della conduzione ottimale dei processi di Pianificazione e Budgeting.

Come precedentemente definito, durante lo sprint “Scenario di Emergenza” il team di implementatori, a seguito delle esigenze richieste e formalizzate dall’Agenzia, ha apportato significative modifiche strutturali all’architettura tecnico-informativa del Budget Planning Tool.

Dal lato dell’interfaccia Web il cambiamento si è concretizzato con la reingegnerizzazione apportata al workflow del Processo di Pianificazione Basata sulle Esigenze mediante l’aggiunta di un nuovo Step. A cascata, la messa in atto di tale requisito, ha richiesto la conseguente inizializzazione e il settaggio di tutti gli elementi informativi e parametrici fondamentali per la conduzione della nuova attività.

Sull’interfaccia Excel invece, le modifiche hanno sottinteso la creazione di nuovi report di Data Entry costruiti ad hoc per le due deliverable progettuali, “Nuova Attività” e “Nuova Unità di Budget e Programmazione”.

Facendo riferimento a quanto riportato nei capitoli descrittivi le due interfacce di sistema, si può intuire quanto risulti prioritario che lo scambio di informazioni tra essi risulti privo di anomalie.

I test, condotti da parte del team di consulenti, si sono pertanto concretizzati come vere e proprie simulazioni di potenziali situazioni operative affrontabili dagli utenti finali.

Una prima istanza di tale verifica prevedeva l’attuazione delle attività di inserimento dei dati, relativi agli importi finanziari delle voci di Budget, all’interno delle matrici dei rispettivi prospetti ed il loro conseguente salvataggio. Una volta finalizzati, i contenuti informativi risultavano registrati e memorizzati all’interno del database del Sistema e riorganizzati nelle apposite Tabelle Dati. Successivamente a tale fase, il team di implementatori operava un controllo sull’effettivo risultato della migrazione dei dati, verificando che le informazioni non avessero subito alcun tipo di modifica, ne che fossero andate incontro a un eventuale perdita o cancellazione non prevista.

Una volta convalidati i risultati del test, questi venivano tempestivamente comunicati ai membri del Team dell’Agenzia che a loro volta implementavano nuovamente le verifiche provvedendo successivamente a fornire feedback approvativi.

Gli Integration Test costituiscono un’attività contraddistinta da un elevato livello di criticità in quanto, di fatto, i risultati uscenti stabiliscono o meno il grado di fattibilità delle funzionalità implementate per soddisfare le richieste. Per questo durante la loro conduzione l’interazione tra i due Team incaricati di Progetto è risultata particolarmente intensa e caratterizzata da uno scambio continuo e tempestivo di informazioni estremamente dettagliate e puntuali, esplicative della corretta modalità di svolgimento.

Data la rilevanza, per tali attività di test sono state definite e schedulate, all’interno del documento di Progetto, tutte le tempistiche inerenti la loro conduzione, attuata solamente a seguito del completamento delle nuove funzionalità apportate dal team di implementatori. Il successo di questi test ha sancito un primo passo verso il raggiungimento delle milestone progettuali concordate all’interno del ciclo vita delle due deliverable che si sarebbe formalizzato solamente a seguito degli User Acceptance Test.

System Test

All’interno dell’architettura informativa di UNC coesistono simultaneamente diversi applicativi software a supporto dei Processi di Pianificazione e Budgeting. In particolare, il Budget Planning Tool interagisce sia monte del processo, con l’applicativo Comet per l’acquisizione dei dati di natura anagrafica costituenti l’input per l’avvio dei processi finanziari, sia a valle con il database SAP contenente i dati finanziari processati.

Per l’Agenzia risulta essenziale che i tre sistemi che supportano la conduzione delle attività di Budgeting e Pianificazione siano perfettamente integrati e interagenti tra di loro.

In particolare questa integrazione è poggiata su:

• Standardizzazione dei contenuti informativi: attività di definizione univoca dei contenuti informativi scambiati tra i diversi sistemi.

• Formattazione del Dato: attività di conversione del dato nei formati specificatamente richiesti da ognuno dei sistemi.

In sintesi, i test di interazione per lo specifico caso in esame sono stati portati avanti seguendo gli stessi principi utilizzati per gli Integration Test, differenziandosi da quest’ultimi per il dominio di applicazione. Infatti, mentre gli Integration Test sono stati

circoscritti all’interno del perimetro del Budget Planning Tool, i System Test hanno esteso i propri confini anche agli applicativi Comet e Wings.

User Acceptance Test

Una volta convalidati i risultati dei test funzionali precedentemente descritti, per poter validare la completa idoneità di una soluzione software informativa è fondamentale che questi siano integrati anche con una prova dell’effettiva capacità dell’applicazione di incontrare le esigenze dei suoi user finali.

Conformità Funzionale e Semplicità di Utilizzo non sono sempre legate da un rapporto di correlazione diretta, ma al contrario, molto spesso soluzioni caratterizzate da un elevato livello funzionale si rivelano non attuabili o perseguibili, all’interno della realtà aziendale, a fronte di una scarsa capacità di integrazione con le esigenze dei suoi utilizzatori finali.

Gli User Acceptance Test, altresì detti UAT, rappresentano l’ultima tipologia di test eseguita da parte del cliente sul sistema, nonché l’opportunità finale per misurarne la sua reale capacità di perseguimento degli scopi e delle esigenze stabilite. In sintesi, costituiscono il filtro che abilita o meno il passaggio del progetto dalla fase di Sviluppo e Implementazione a quella di Go-Live.

Durante il perseguimento delle due deliverable progettuali che hanno definito lo sprint “Scenario di Emergenza” sono stati eseguiti due diversi UAT, finalizzati alla validazione, approvazione e al rilascio delle due nuove soluzioni “Nuova Attività” e “Nuova Unità di Budget e Programmazione” nell’Ambiente Produzione. A condurre i test sono stati inizialmente i portavoce Business del Team progettuale di UNC, i quali durante le Riunioni precedentemente descritte, hanno sperimentato le nuove soluzioni funzionali. Una volta approvate, i test sono stati sottoposti all’attenzione di specifici key users localizzati in diversi Paesi. Terminato anche quest’ultimo step di verifica, che ha richiesto più giorni per il suo svolgimento, a seguito della validazione convenuta, per lo sprint è stato formalmente approvato il rilascio delle due soluzioni in Ambiente di Produzione.