No regression test per verificare la qualità e i rilasci del software

La gestione, pianificazione e documentazione dei test

Per effettuare tutti i tipi di testing, visti in precedenza, si necessita di molte risorse; bisogna gestire i test in modo tale da minimizzarne il numero. Molte volte si trovano dei compromessi tra i difetti da riparare prima della consegna e quelli che possono es- sere risolti in una successiva revisione del sistema. Si scelgono i difetti che comportano il malfunzionamento delle funzionalità del sistema.

L’attività di testing è abbastanza costosa, ma attraverso una buona pianificazione dei test permette di ridurne il costo, come per esempio, la selezione dei casi di test anticipata e una parallelizzazione di essi.

Tale attività deve essere documentata per essere consultata quando se nè ha necessità. A tal proposito, ci sono quattro tipi di documenti:

1. Test Plan: si raccolgono aspetti gestionali del testing. Esso documenta lo scopo, l’approccio utilizzato, risorse e lo schedule di testing. I requisiti e i componenti da testare sono documentati nel test plan.
2. Test Case Specifications: tiene traccia, per ogni caso d’uso, gli input, i driver, gli stub, i risultati aspettati e i compiti da svolgere.
3. Test Incident Reports: tiene traccia per quanto riguarda l’esecuzione del test di ogni caso d’uso. Sono trascritti le differenze tra i risultati effettivi e quelli aspettati.
4. Test Summary Report: tiene traccia di tutti i fallimenti evidenziati durante i test che devono essere indagati. Attraverso questo documento, gli sviluppatori analizzano ogni fallimento e selezionano quelli a cui dare priorità per i cambia- menti nel sistema e nei modelli. I cambiamenti da effettuare, a loro volta, possono far subentrare nuovi casi ed esecuzioni di test.

Testing di non regressione

Quando si effettuano modi che e/o implementate nuove funzionalità in una componente, si può scegliere se progettare nuovi casi di test unitari o rieseguire quelli precedentemente e effettuati. Una volta che la componente supera i test ed è quindi esente da difetti, non è detto che il sistema continui a funzionare correttamente. Le modifiche inserite potrebbero essere conseguenze di difetti in altri componenti o rilevarne altri non identificati con il test antecedente.

Il testing di non regressione (in inglese no regression test) è la riesecuzione dei test case esistenti ogni qualvolta si rilevano tali difetti. L’idea è quella di accumulare tutti i test di integrazione e ripeterli ogni qualvolta si rilevano difetti all’aggiunta di un componente modificato. Questo processo richiede agli sviluppatori che i test case si tengano sempre aggiornati, in base a come cambiano le interfacce dei sottosistemi.

Il testing di non regressione è time consuming per cui sono state ideate varie tecniche per selezionare alcuni dei test di non regressione:

1. Ritestare componenti dipendenti: le componenti dipendenti di una componente modificata hanno più probabilità di fallire in un test di non regressione. Se non è fattibile eseguire tutti i test, tale scelta ci permette di ottimizzare la probabilità di trovare difetti.
2. Ritestare casi d’uso a rischio: identificare difetti più catastrofici è più critico che identificarne un alto numero, per cui ci si focalizza sui casi d’uso in modo da ridurre al minimo la probabilità di difetti catastrofi.
3. Ripetere casi d’uso frequentemente: quando si rilascia una nuova versione del sistema, gli utenti si aspettano sia funzionalità nuove che quelle delle versioni precedenti; dunque gli sviluppatori si concentrano sui casi d’uso più utilizzati da essi.

Con il test di non regressione si eseguono molti test più volte. Per aiutare gli sviluppatori in questo processo è possibile automatizzare i test.

Automatizzare i test

Il test manuale implica ad un tester di inserire input predefiniti nel sistema utilizzando l’interfaccia utente, una console a riga di comando o nel debugger. Dopo l’esecuzione dei test, il tester confronta gli output con l’oracolo. L’occhio umano può commettere errori nel fare questo confronto.

Ogni qualvolta i requisiti cambiano, dovrebbe essere possibile ripetere gli stessi test. Non è facile garantire che lo stesso test è eseguito nelle stesse condizioni ogni volta: nel caso in cui si ha il bisogno di ripetere i test molte volte, è possibile automatizzazione la ripetibilità dei test, se invece devono essere eseguiti due, tre volte il test manuale è più ideale.

Grazie all’automatizzazione, soprattutto in caso di refactoring, è possibile ridurre il costo dei test.

Un esempio di infrastruttura che permette i test automatizzati è JUnit; un framework per la scrittura e l’automatizzazione dei unit test per classi Java.