8. Adeguatezza dei test alla criticità del software

L'attività di test, confinata per sua natura come ultima fase del ciclo di vita, risente di tutte le perturbazioni che il progetto subisce durante l'esecuzione. Ritardi, taglio dei costi, risorse inadeguate ecc. Questi, e altri motivi ancora, costituiscono un ostacolo al buon completamento del progetto.

Non dedicare alla fase di testing il tempo necessario e le risorse adatte costituisce una lacuna i cui effetti negativi sono evidenziati dopo il rilascio in esercizio. L'applicazione sviluppata mostrerà allora tutti i suoi punti deboli: difettosità oltre l'aspettativa e funzionalità non esattamente corrispondenti ai requisiti.

Il testing, infatti, ha due obiettivi principali: 1) assicurare che i requisiti siano stati sviluppati correttamente e 2) scoprire gli errori presenti nel software prima del suo rilascio agli utenti. Da ciò si capisce bene, dunque, l'importanza di pianificare ed eseguire correttamente le attività di testing.

Caratteristiche del software

L'adeguatezza dei test dipende dalle caratteristiche del software sviluppato. Gli elementi importanti da prendere in considerazione per una corretta pianificazione dei test sono: a) dimensione del software; b) criticità del software per il business; c) complessità del software; d) vincoli e standard da rispettare; e) rischi del progetto.

Ciascun elemento richiede dei test appropriati alle caratteristiche esposte.

Le dimensioni del software richiedono un numero adeguato di casi di prova: un software di grandi dimensioni richiederà un numero maggiore che non un software di piccole dimensioni. I casi di prova previsti sono riportati in una tabella in corrispondenza dei relativi requisiti indirizzati da ciascuno di essi. La "Matrice di test" (Requisiti-Casi di prova) indicherà quali e quanti casi di prova prevedere. L'analisi della tabella permette di ottimizzare l'impegno riducendo i casi di prova (per esempio, eliminando le duplicazioni). La tabella permette inoltre di verificare il grado di copertura dei requisiti da parte dei casi di prova (livello di copertura).

La criticità del software per il business può essere indirizzata tramite opportuni casi di prova progettati allo scopo. In ottica di contenimento dei costi (sempre richiesto nei progetti) si consiglia di produrre uno  "schema a quattro quadranti" dove riportare le funzionalità del prodotto (F1, F2, ... Fn) in base alla frequenza con cui ciascuna funzionalità sarà utilizzata e alla criticità che essa rappresenta per il business. Nel quadrante in alto a destra, per esempio, saranno riportate le funzionalità più critiche per il business e utilizzate con maggiore frequenza dagli utenti. Viceversa, nel quadrante in basso a sinistra, cadranno le funzionalità meno critiche e meno utilizzate. Le prime richiederanno un numero maggiore di casi di prova che non le seconde.

La complessità del software è un elemento critico di per se e richiede un numero di casi di prova adeguato, Questi saranno progettati ad hoc per indirizzare i diversi aspetti della complessità: prestazioni, usabilità, gestione della memoria, algoritmi applicativi particolari, struttura della base dati, ecc. 

I vincoli e standard da rispettare sono elementi da indirizzare con particolari casi di prova progettati anch'essi ad hoc.

I rischi del progetto sono infine indirizzati da appositi test (es.: tecnologie particolari utilizzate per lo sviluppo del software, indeterminatezza di alcune specifiche tecniche, ecc.).

In conclusione, il numero e i tipi di casi di prova dipenderà dai fattori elencati sopra.

Pianificazione dei test

La pianificazione dei test è fondamentale per valutare l'impegno di tempo e risorse necessarie. Una buona pianificazione deve essere realistica ed efficace. "Realistica" significa prevedere un numero "congruo" di casi di prova che possano essere realmente progettati ed eseguiti; la Matrice di test e lo Schema a quattro quadranti sono due ottimi strumenti per selezionare quali e quanti casi di prova prevedere. "Efficace"  significa che i casi di prova saranno progettati secondo la caratteristica del software da verificare: un requisito prestazionale richiederà un tipo di test (test di performance) diverso da una caratteristica funzionale (test funzionale). Occorre dunque esaminare tutte le caratteristiche del software e pianificare i diversi tipi di test da progettare ed eseguire (test funzionale, test prestazionale, test di usabilità, test di carico, test procedurale, ecc.). La definizione dei tipi di test previsti è detta "Strategia di test". Da essa si parte per una corretta pianificazione. La valutazione dei tempi e delle risorse necessarie è documentata nel "Piano di test" e richiede l'approvazione del management (sponsor, cliente, ecc.) per assicurare le risorse necessarie. Ricordarsi che la pianificazione include la predisposizione degli ambienti di test (non sempre banale e a costo zero!).

Progettazione dei test

La progettazione dei casi di prova e degli ambienti di test determina l'efficacia dei test eseguiti. Essa sarà affidata a personale competente sia dal punto di vista funzionale (es.: competenza di analista funzionale) sia dal punto di vista dei metodi e delle tecniche del test (es.: competenza di esperto di test). Se opportuno o necessario, si progettano i test automatici tramite l'uso dei tool selezionati. La documentazione dei casi di prova permette di accedere ai test anche in momenti successivi (es.: in fase di test di regressione durante la manutenzione per verificare che alcune funzionalità contigue a quelle modificate continuino a funzionare correttamente).

La progettazione tiene conto dei tipi di test e della loro profondità.

I tipi di test, si è detto, indirizzano diversi aspetti del software: funzionalità, prestazioni, usabilità, carico, procedure, regressione, parallelo, ecc.

La profondità dei test (detto anche livello di test) si riferisce appunto al "livello" cui si trova il software sviluppato: codifica, integrazione, sistema, collaudo. In corrispondenza i relativi test sono detti unitari, d'integrazione, di sistema e di accettazione. Ogni tipo di test, così come ogni livello di test, ha caratteristiche proprie ed è progettato di conseguenza.

Esecuzione dei test

L'esecuzione dei  test si effettua come definito nel Piano di test: secondo i tempi previsti, dalle risorse coinvolte, negli ambienti di test predisposti ed eseguendo i casi  di prova progettati.

Gli errori rilevati durante l'esecuzione dei test sono registrati e notificati al gruppo di sviluppo perché li corregga. Il codice modificato viene nuovamente sottoposto a test per verificare che l'errore sia stato rimosso. La registrazione degli errori e la loro rappresentazione cumulativa giornaliera permette di creare la "curva di rimozione degli errori" (detta anche "curva di saturazione degli errori") permettendo di verificare il momento in cui i test possono considerarsi esaustivi. 

Rapporto sullo stato dei test

Il risultato dei test è documento nell'apposito Rapporto di test (Test Report) dove si riportano le informazioni relative ai casi di prova (es.: numero di casi di prova completati, ancora in esecuzione, bloccati da errori, numero totale di casi di prova previsti dalla fase di test). Si riportano anche le informazioni relative agli errori rilevati in ciascuna fase di test (es.: numero totale di errori rilevati, corretti, testati). Le informazioni sugli errori si riferiscono alle diverse gravità con cui sono classificati (es.: errori bloccanti, gravi, lievi).

Chiusura dei test

Una fase di test si considera chiusa quando: 1) siano stati completati tutti i casi di prova previsti e 2) siano stati corretti e verificati tutti gli errori rilevati . Al termine della fase di test si emette un Rapporto di fine test in cui si dichiara quanto effettuato e i risultati conseguiti.

Rischio associato a test carenti

La mancata esecuzione di quanto descritto in precedenza rappresenta un rischio grave per il progetto: alta probabilità di accadimento (per non dire certezza!) e alto impatto! Le conseguenze sono facili da prevedere e quantificare: difettosità alta del software rilasciato e funzionalità non sempre accettate dagli utenti. La ripercussione sui costi e l'immagine sono altrettanto evidenti: costo di manutenzione correttiva in garanzia alta (con conseguente riduzione del margine di profitto) e soddisfazione bassa degli utenti. Nei casi peggiori si può non superare il collaudo di accettazione e ritardare l'emissione delle fatture relative!

Eseguire test accurati è dunque una buona pratica del software (Best Practice).