In questa fase si considera terminato il momento di sviluppo propriamente detto, in cui il sistema viene costruito nella sua interezza, e si inizia la fase di testing allo scopo di individuare errori nel sistema.
L'applicazione di tecniche di Unit Testing non garantiscono, infatti, la funzionalita' del sistema nella sua totalita' ed in generale possiamo individuare due tipi di errori nella fase di testing:

• Errori di runtime: questi sono considerati errori di programmazione, risultato di una fase di Unit Testing incompleta.
• Errori Logici: Il sistema si comporta diversamente rispetto alla funzionalita' descritta nel documento Proof Of Concept.

Deve essere chiaro fin dall'inizio che la fase di testing e' parte integrante dello sviluppo del software ed e' del tutto naturale aspettarsi degli errori durante il testing.

Fase di Testing
Come abbiamo detto, il testing ha lo scopo di identificare tutti gli errori (di runtime e logici) e garantire che la funzionalita' del sistema consegnato sia privo di malfunzionamenti e rispecchi la documentazione accettata durante la fase di Discovery.
Nel testing viene utilizzata una nuova figura professionale quella del QA tester (Quality Assurance Tester).
Per piccoli progetti puo' bastare una sola persona, ma per sistemi complessi puo' essere necessario creare un vero e proprio QA Group con tanto di QA Manager.
Al gruppo QA spetta il compito di scegliere e rendere operativi tutti gli strumenti necessari per la loro attivita', questi strumenti possono essere identificati nella lista seguente:

• Scripting Engines per il testing automatico dell'applicazione (ad esempio Rational Robot per applicazioni web)
• Scripting Engines per il load testing dell'applicazione (es. Load Runner)
• Defect Reporting and Release System utilizzato dal gruppo QA per gestire e documentare gli errori trovati.

Il gruppo QA deve avere a disposizione un ambiente di testing che deve essere l'esatta copia di quello di produzione sia dal punto di vista hardware che software (tranne che per le unita' ridondanti come doppi web servers etc). Questo assicura che l'applicazione testata si comportera' allo stesso modo una volta installata nell'ambiente di produzione, evitando cosi spiacevoli sorprese.
Il gruppo di development lavorera' in stretto contatto con il gruppo QA ed il project leader dovra' essere disponibile a chiarificare concetti e funzionalita' al gruppo QA allo scopo di rendere il piu' efficiente possibile la fase di testing.
L'intero processo puo' essere descritto nella figura seguente:

Figura 1 - Processo QA
(clicca per ingrandire)

Come momento iniziale, l'applicazione verra' installata nell'ambiente di testing. Chi effettua l'istallazione vera e propria dipende dagli standards aziendali: per piccole aziende e' lo stesso gruppo di sviluppo, mentre in aziende molto grandi e strutturate esistera' un gruppo apposito.
La terminologia cambia se si sta installando l'applicazione nell'ambiente di testing o di produzione. In particolare l'installazione nell'ambiente di testing verra' chiamata "Rollout", mentre nel caso dell'ambiente di produzione verra' chiamata "Release".
Le procedure possono essere diverse nei due casi, e vedremo questi dettagli successivamente.
Una volta che l'applicazione viene installata nell'ambiente di testing, il gruppo QA e' pronto ad iniziare la sua attivita'.
Deve essere chiaro che il lavoro del gruppo di QA si basa sul documento Proof Of Concept in cui sono descritti chiaramente tutti i requisiti, la funzionalita' del sistema e le schermate utilizzate a descrivere questa funzionalita'. Se questo documento non e' stato opportunatamente preparato, aspettatevi di dover affrontare una lunga serie di problemi durante il testing di sistema.
Se non si ha una documentazione di base, il QA Tester tendera' ad interpretare la funzionalita' del sistema e giudicarla secondo criteri personali e non sulla base delle specifiche. Questo si traduce nel dover trattare come difetti intere porzioni di funzionalita', semplicemente per il fatto che il tester non ha alcuna conoscenza del sistema sviluppato.
Possiamo descrivere il processo di testing nel modo seguente:

1. Il gruppo QA testa la funzionalita' dell'applicazione utilizzando la documentazione messa loro a disposizione (solitamente il POC)
2. Quando viene individuato un errore (runtime o logico) questo viene inserito nel Defect Reporting System con le seguenti informationi:
   1. Il tester che ha trovato l'errore
   2. Il tipo di errore (di runtime o logico)
   3. La priorita' nel trovare una soluzione (Urgente, Normale, ecc.)
   4. Una chiara descrizione dell'errore
   5. Una chiara descrizione di come riprodurre l'errore
   6. La versione dell'applicazione che si sta testando
3. Il project leader viene notificato (attraverso email) dell'errore inserito nel sistema.
4. Il project leader assegna il difetto al programmatore che ritiene piu' idoneo nel risolvere il problema
5. Il programmatore risolve il problema nell'ambiente di sviluppo (development environment) ed assegna al difetto lo stato di "Risolto".
6. Il programmatore etichetta il nuovo codice per essere incluso nel rollout successivo.
7. Il gruppo QA viene notificato che il difetto e' stato risolto.

Ci sono in commercio degli ottimi applicativi di "Defect Reporting", molti dei quali basati anche su interfaccia web: ClearQuest, Aardvark, ecc.
Quando tutti i difetti riportati, per quella particolare versione, sono stati "risolti" dal gruppo di sviluppo siete pronti per il "rollout" della nuova versione dell'applicazione.
Introducete una chiara nomenclatura per etichettare versioni e rollout, solitamente viene utilizzato il seguente formato:

Versione.Release.Rollout ad esempio 1.3.5

che rappresenta la prima versione del prodotto. Il prodotto e' alla sua terza release e questa e' stata sottoposta a cinque rollout.

Il Processo di Rollout
Come abbiamo definito precedentemente, il processo di rollout prevede l'istallazione dell'applicazione dall'ambiente di sviluppo all'ambiente di testing. Durante la fase di testing ci saranno diversi rollouts.
La fase di rollout prevede una serie di passi che possono essere descritti nella seguente lista:

1. Assicuratevi che tutti gli sviluppatori abbiano aggiornato il Source Control System con l'ultima versione del codice modificato.
2. Etichettate il codice prelevato con la corrente versione di rollout. Questo e' molto importante nella fase di release perche' vi permettera' di prelevare la corretta versione del codice testato.
3. L'intera applicazione viene ricompilata
4. Assicuratevi che nessuna persona stia utilizzando il testing environment. Ogni rollout deve essere preceduto da una notifica a tutti i membri del gruppo QA sulla data e ora di rollout.
5. Dipende dal tipo di applicazione sviluppata: fermate ogni Application Server attivo nel testing environment. Se state sviluppando un'applicazione web fermate anche il web server.
6. Avvertite il DBA che puo' procedere ad eventuali modifiche del database
7. Installate la nuova applicazione nell'ambiente di testing e, se si tratta di una applicazione Web, aggiornate i contenuti nel web server ed i corrispondenti file di configurazione.
8. Riavviate l'application server ed eventualmente il web server.
9. Fate un piccolo test per assicurarvi che il sistema sia stato aggiornato correttamente.
10. Notificate il gruppo QA che il sistema e' pronto per essere testato.

Se la nuova fase di testing prevede una nuova funzionalita' non documentata nel POC, assicuratevi di fornire al gruppo QA la nuova documentazione.
Il processo sopra descritto verra' reiterato fino ad avere una versione dell'applicazione abbastanza "robusta" per poter essere installata nell'ambiente di produzione.
Come definito precedentemente, l'istallazione dell'applicazione nell'ambiente di produzione viene chiamata "Release", ma prima della release l'applicazione deve essere "certificata" dal cliente attraverso un apposito "Acceptance Test".
L'Acceptance Test deve essere eseguito insieme al cliente utilizzando la funzionalita' descritta dal documento POC e da qualsiasi altro addendum ufficiale. Questo test e' molto semplice e verra' eseguito da un rappresentante del gruppo QA alla presenza del cliente e del project manager. Solitamente e' anche presente il project leader che dara' spiegazioni in caso di dubbi o domande tecniche.
Alla fine del test il cliente certifica l'applicazione e questa e' pronta ad essere installata nell'ambiente di produzione.
L'Acceptance Test e' necessario soltanto per nuove applicazione e normalmente non viene richiesto per upgrades o release successive.

Il Processo di Release
La versione dell'applicazione che deve essere installata nell'ambiente di produzione e' quella presente nell'ambiente di testing. E' infatti questa (e soltanto questa) versione che e' stata testata dal gruppo QA.
Mi e' capitato che durante la fase di release la persona che si occupava dell'installazione considerava come versione di release quella contenuta nel Source Control System causando non pochi problemi.
Solitamente il Source Control System (come PVCS o ClearCase) permette di etichettare la versione del codice presente nei vari ambienti e questa e' un'importante caratteristica.
In ogni caso, il processo di release e' piu' complicato per il fatto che coinvolge l'ambiente piu' importante: quello di produzione.
Gli approcci utilizzati possono essere diversi, ma in questo articolo descrivero' le fasi che dovrebbero essere tenute da conto per una release di successo.
Prima di tutto voglio sottolineare il fatto che l'ambiente di produzione deve essere un ambiente chiuso alla struttura aziendale ed accedibile solamente a personale autorizzato. La fase di release deve quindi essere autorizzata da tale personale e questo avviene solitamente attraverso una richiesta formale da parte del project management.
Questa richiesta deve contenere le seguenti informazioni:

1. L'applicazione da installare
2. I sistemi influenzati da questa applicazione
3. Modifica della configurazione dei sistemi su cui l'applicazione deve essere installata.
4. Configurazione di apparati particolari come Servers, Routers, Firewall ecc.
5. La data di release
6. Il nominativo di almeno una persona che assistera' il personale specializzato all'installazione
7. Il nome della persona che effettuera' l'installazione
8. Istruzioni dettagliate della procedura di installazione
9. Istruzioni dettagliate da seguire nel caso la procedura d'installazione fallisca (Istruzioni di rollback)

La richiesta verra' considerata dal personale responsabile dell'ambiente di produzione ed accettata oppure rifiutata. Le ragioni sul perche' una richiesta viene rifiutata dipendono dalla struttura e dalle regolamentazioni interne dell'azienda e non verranno considerate al fine di questa trattazione.
La tipologia di release dipendera' molto dalla piattaforma utilizzata:

1. Piattaforma Microsoft: e' possibile utilizzare procedure automatiche di installazione come InstallShield. In questo caso al gruppo di installazione verra' fornito semplicemente il file di installazione automatica. Questa procedura deve essere accompagnata da una chiara documentazione sul procedimento di installazione e sull'eventuale configurazione successiva (se questa non puo' essere automatizzata).
2. Piattaforma Unix: I file da installare vengono consegnati come un insieme di tar files insieme ad una chiara documentazione indicante dove questi file devono essere copiati e come devono essere espansi.

In entrambi i casi la documentazione che descrive il processo di installazione deve indicare tutti i passi necessari alla configurazione dell'applicazione installata e di eventuali altri prodotti necessari al funzionamento dell'applicazione stessa.
Oltre a queste note, sarebbe opportuno una descrizione di un test che deve essere condotto dopo l'installazione per assicurarsi la buona riuscita della release.
Possiamo ora descrive i passi necessari per una release:

1. Il project leader preparera', insieme con gli sviluppatori e DBAs, il piano di relase con le istruzioni dettagliate da consegnare all'installatore. Le istruzioni verranno accompagnate con la lista di tutti i componenti software che devono essere inclusi nella relase.
2. Dipende dall'azienda, ma spesso esiste un gruppo apposito (Packaging Group) che si occupa di preparare i file necessari alla release (InstallShield, tar, zip, ecc)
3. Il project manager inviera' una richiesta ufficiale di release includendo il documento preparato al punto 1. Solitamente il project manager puo' anche scegliere la persona che installera' la release.
4. Se la richiesta viene accettata, l'installazione puo' procedere.

Vorrei darvi dei suggerimenti ulteriori per la fase di release:

1. Assicuratevi che tutti gli utenti siano a conoscenza del giorno della release. Questo al fine di evitare inutili chiamate al Customer Service da parte di clienti che non erano a conoscenza della release.
2. Il project leader deve assicurarsi e coordinare tutte le persone coinvolte nella release: DBA, Network Administrators ecc.
3. Avere un gruppo QA disponibile per testare l'applicazione non appena l'applicazione viene installata.
4. Notificare il gruppo interessato quando l'installazione e' terminata

Conclusioni
Questo conclude la serie di articoli sul project management. Dalle tante email ricevute ho potuto constatare come il problema di project management sia attuale e comune.
Appare comunque chiaro che il problema principale puo' essere ricondotto alla superficialita' delle fase di analisi dei requisiti e di design. Continuero' sempre a ripetere quanto importanti siano queste fasi: il tempo speso nell'analisi e design verra' ripagato nelle fasi successive, potete essere certi di questo.
Ritornero' comunque su questi concetti in articoli futuri, specialmente nel descrivere in maggior dettaglio queste due importantissime fasi.

Giancarlo Crocetti si e' laureato in Scienze dell'informazione all'universita' "La Sapienza" di Roma per poi conquistare il Master in Computer Science alla Rutgers University del New Jersey nel 1998. Dal 1996 vive a New York dove lavora come consulente per importanti aziende ed enti governativi come: Computer Science Corporation, United Nations, Merrill Lynch, Lockheed Martin e per il governo degli Stati Uniti.
Da piu' di quattro anni il 60% dei sistemi da lui architettati e sviluppati vengono implementati utilizzando tecnologie Java. Nel 2000 ha creato la propria azienda Nous USA inc., che offre servizi di consulenza e di training concentrate soprattutto su tecnologie Java.