Come avviene la gestione della configurazione di test nel processo di testing

Fasi del processo di testing

La complessità dei sistemi sviluppati oggi assegna grande importanza ad una buona pianificazione e realizzazione della fase di testing software. L’introduzione delle tecnologie legate alla Rete, inoltre, ha portato ad una sostanziale modifica dell’architettura applicativa e ad una più specifica e, spesso, più critica necessità di soddisfare le esigenze dell’utenza. Questa, diventata più eterogenea, vasta e globale (è il caso delle applicazioni di ebusiness) pone in luce nuovi aspetti tecnici e qualitativi del software: sicurezza delle transazioni, tempi di risposta della rete e dell’applicazione stessa, disponibilità h24 e 7/7 dei servizi offerti dall’applicazione, usabilità ed altre caratteristiche ancora ( il tema è trattato in un capitolo specifico di questo manuale).

La metodologia di test identifica le seguenti fasi o macro attività (tra parentesi sono riportati i nomi in inglese):

1. Pianificazione dei test (Test Planning);
2. Preparazione e sviluppo dei test (Test Preparation / Development);
3. Esecuzione dei test (Unit Test, Integration Test, System Test, Acceptance Test);
4. Gestione dei difetti (Defect Management);
5. Monitoraggio e reportistica dei test (Test Monitoring and Reporting);
6. Gestione del processo di test (Test Process Management);
7. Gestione della configurazione di test (Test Configuration Management).

Gestione della configurazione di test

Perché i test producano un risultato attendibile (verifica e validazione della qualità del software realizzato e sua rispondenza ai requisiti dichiarati), è necessario che si conosca con precisione “cosa” si stia collaudato. Occorre, cioè, avere certezza che la configurazione sotto test sia quella corretta. La configurazione di test consiste nella definizione esatta sia dei componenti dell’ambiente di test, sia del software applicativo collaudato. I risultati dei test sono quindi sempre riferiti ad un’esatta configurazione (altre configurazioni potrebbero infatti fornire risultati diversi quando sottoposti agli stessi test).

La configurazione dell’ambiente di test descrive la sua composizione in termini di hardware, software di base, prodotti, tool e banche dati, tutti con gli attuali livelli di versione utilizzati.

La configurazione del software applicativo collaudato descrive invece la sua composizione (componenti integrati) e le relative versioni.

Ogni modifica a tali configurazioni deve essere registrata e valutata in termini di pianificazione dei test e di risultati attesi per le rispettive esecuzioni.

L’ambiente di test deve essere “validato” prima di iniziare l’esecuzione dei test per garantire che esso non influenzi i risultati (l’ambiente di test deve risultare “trasparente” rispetto ai risultati). Eventuali modifiche alla configurazione iniziale dell’ambiente di test devono essere analizzate per verificare eventuali impatti sui risultati dei test pianificati e/o eseguiti. Se non sono evidenziati impatti negativi (i risultati dei test non sono influenzati dalle modifiche all’ambiente), si può proseguire nell’attività di collaudo secondo i piani. Se invece le modifiche alla configurazione dell’ambiente possono alterare i risultati attesi, allora occorre intervenire nei piani, modificare i casi di test e rischedulare l’esecuzione. Prima di proseguire con l’attività di test occorre “validare” nuovamente l’ambiente di test.

Le modifiche al software applicativo, sono gestite ugualmente tramite la configurazione software. Ogni modifica alla configurazione attuale del software richiederà che vengano rieseguiti i test già effettuati sugli stessi componenti. Alcune modifiche richiederanno la progettazione di nuovi casi di test.

La tematica discussa è oggetto della disciplina relativa alla gestione delle modifiche e della configurazione (Change and Configuration Management).

E’ buona norma (best practice) gestire la configurazione in modo corretto utilizzando uno tra i vari strumenti disponibili per i diversi ambienti tecnologici.

La gestione delle modifiche richiede un processo definito. Il processo DCR (Design Change Request) è un possibile processo che permette di controllare le modifiche e gli impatti sulla configurazione del software. Tale pratica costituisce a sua volta un “best practice”. Il processo DCR prevede che, a fronte di una richiesta/necessità di modifica, sia emesso un rapporto ufficiale che descriva in dettaglio la modifica, i razionali, gli impatti sul software attuale, i costi ed i tempi. Ogni modifica alla configurazione attuale deve essere approvata (nessuno può modificare la configurazione senza la docuta autorizzazione!).

Le informazioni minime richieste dal processo DCR sono:

• Identificazione della richiesta di modifica (nome del prodotto e versione per i quali è richiesta la modifica, nome del richiedente, data della richiesta, priorità/urgenza della richiesta);
• Descrizione della modifica e razionale;
• Impatto della modifica in termini di elenco di componenti da modificare e/o realizzare ex novo (moduli, documentazione tecnica, documentazione utente, procedure, );
• Costo delle modifiche (giorni-persona per ciascuna attività: analisi e disegno, codifica e test unitario, test d’integrazione, test di sistema);
• Piano di realizzazione delle modifiche (attività, durata e numero di risorse);
• Potenziale rischio legato alla realizzazione delle modifiche ed alla non realizzazione delle stesse;
• Approvazione/non approvazione della richiesta;
• Note (eventuali) di chiarimento delle decisioni prese.