Introduzione

Le dimensioni e la complessità del software rendono difficile produrre codice con un alto livello di qualità (difettosità molto bassa). Le difficoltà aumentano, sempre più, con la richiesta di anticipare i tempi di consegna e di ridurre i costi.

Nonostante gli sforzi profusi dall'industria del software per migliorare i propri processi rimane una chimera produrre software con zero difettosità!Purtroppo, tutti gli sforzi si concentrano nel migliorare il processo di sviluppo trascurando (quasi sempre) le attività di testing. L'anticipazione delle attività di test è spesso confinata al "debugging" dimostrando una certa confusione tra testing e debugging.

Il modello CMMI (Capability Maturity Model), accettato dall'industria del settore come quello più adatto per migliorare i processi di sviluppo software, è utilizzato nella maggior parte dei casi per le fasi alte del ciclo di vita e per quella di produzione, intesa come codifica e test d'integrazione.

Test Maturity Model integration (TMMi) è il modello sviluppato da TMMi Foundation, un'organizzazione di esperti del settore, appositamente per le organizzazioni di testing. Il modello, giunto alla versione 3.1, rappresenta lo strumento più valido per il miglioramento dei processi di testing e delle relative organizzazioni. Esso quindi si affianca al modello CMMI (non è in sua contrapposizione!). TMMi è stato infatti sviluppato partendo proprio dal modello CMMI ereditandone l'impostazione "a stadi" (staged) e un insieme di aree di processo (Process Areas).

Livelli di maturità

Il modello TMMi definisce dei livelli di maturità lungo i quali un'organizzazione software può procedere lungo il suo percorso di miglioramento e crescita (maturità). Consolidare i processi presenti in ciascun livello, raggiungendo tutti gli obiettivi definiti per esso, consente all'organizzazione di passare al livello successivo. I cinque livelli definiti dal modello TMMi costituiscono una sorta di gerarchia nell'evoluzione della maturità del processo di test dell'organizzazione. La figura che segue mostra i cinque livelli del modello.

Level 1 – Initial

Quando il processo di test non sia ancora definito nell'organizzazione, il modello TMMi assume che le corrispondenti attività sia condotte in maniera "caotica" (cioè non strutturate) ed esse siano considerate come parte delle attività di debugging. Generalmente l'organizzazione basa le sue attività di testing su figure "eroiche" (persone brave che si sacrificano per raggiungere gli obiettivi) oppure si accettino i rischi connessi (si rilascia il software senza sapere esattamente il livello di difettosità residuo del software). Le organizzazioni a questo livello generalmente lavorano sovracaricandosi di lavoro, abbandonano i processi nei momenti di crisi e sono incapaci di ripetere i successi. In questo livello non ci sono processi definiti. Si raccomanda quindi di definire i propri processi prima di passare al livello successivo.

Level 2 – Managed

In questo livello il testing è un processo gestito che distingue il debugging dal testing vero e proprio. L'obiettivo principale del processo di testing è di verificare che il prodotto software soddisfi i requisiti concordati. Il processo di testing è considerato come una fase del progetto di sviluppo software che segue quella di codifica. A questo livello il testing viene considerato come un'attività multilivello che va dal test unitario a quello finale di accettazione. Per ciascun livello sono definiti obiettivi specifici nella fase di definizione della strategia di test. I processi previsti nel livello 2 sono:

1. Test Policy and Test Strategy

2. Test Planning

3. Test Monitoring and Control

4. Test Design and Execution

5. Test Environment

Level 3 – Defined

A questo livello, l'organizzazione acquisisce l'importanza delle revisioni tecniche ai fini del controllo della qualità e definisce un programma di ispezioni (Peer Reviews) collegato alle attività di testing dinamico. Il processo di testing è integrato nel ciclo di vita del software e definisce i punti di controllo (Milestones). Il miglioramento continuo del processo di testing è preso in considerazione (è istituzionalizzato) e l'attività di testing è vista come una professione. Le aree di processo del livello 2 sono:

1. Test Organization

2. Test Training Program

3. Test Lifecycle and Integration

4. Non-Functional Testing

5. Peer Reviews

Level 4 – Measured

A questo livello, il processo di testing è sottoposto a misurazioni che consentono (e supportano) il passaggio dal livello 2 al livello di 3 fornendo i dati oggettivi per il miglioramento dei processi. Il processo di testing è considerato come lo strumento principe per valutare la consistenza dell'intero ciclo di vita del software e, in particolare, delle attività di verifica e validazione del prodotto.

Relativamente alla qualità del prodotto, la presenza del programma di misurazione permette di definire il profilo di qualità del prodotto (requisiti di qualità, attributi di qualità, obiettivi di qualità e relative metriche) e di misurarne l'effettivo sviluppo. Il prodotto finale e i relativi prodotti intermedi (deliverables) sono quindi valutati su base quantitativa utilizzando i criteri e gli attributi di qualità definiti: usabilità, prestazioni, affidabilità e manutenibilità.

A questo livello si stabilisce e si coordina l'interazione e correlazione tra il test statico (ispezioni) e quello dinamico (test vero e proprio) permettendo l'ottimizzazione del processo in base all'analisi dei dati prodotti e registrati. Le ispezioni (Peer Reviews) sono integrate nel processo di testing e fanno parte della strategia di test, del piano di test e dell'approccio al testing. Le aree di processo di questo livello sono:

1. Test Measurement

2. Product Quality Evaluation

3. Advanced Peer Reviews

Level 5 – Optimization

Al livello 5, l'organizzazione è capace di migliorare continuamente i propri processi basandosi sul controllo statistico dei processi. Il miglioramento dei processi è conseguito tramite un approccio incrementale e innovativo, oltre che sul miglioramento tecnologico (es.: tramite l'adozione di tool specifici). Anche i metodi e le tecniche sono migliorate e ottimizzate di conseguenza con il progredire dell'evoluzione dei processi. Si adotta il processo di prevenzione dei difetti con il compito di analizzare gli errori più comuni lungo l'intero ciclo di vita, identificare le cause e rimuoverle. Le aree di processo di questo livello sono:

1. Defect Prevention

2. Quality Control

3. Test Process Optimization

Conclusioni

Riassumendo, le aree di processo del modello TMMi forniscono supporto e dettagli sulle specifiche richieste per stabilire e adottare un processo maturo di verifica e validazione del software. TMMi rappresenta un framework che indirizza tutti i livelli di testing (staici e dinamici) in maniera strutturata (ciclo di vita del testing, tecniche, infrastrutture e organizzazione).