Il processo di testing software

Il processo di testing software

Il processo di testing si sviluppa in varie fasi, ad ognuna delle quali è associata una ricca produzione e consultazione di documentazione di vario tipo.
Alcuni di questi documenti a volte vengono redatti, per la volontà di coloro che si occupano del testing, perché il collaudo possa avvenire in modo formale e rigoroso, ma nella maggior parte dei casi risulta indispensabile e necessaria per una buona riuscita del processo.

Il processo di testing software
Il processo di testing software

Pianificazione e controllo dei Test

Il processo di testing del software viene avviato con la fase di pianificazione delle attività di test, che solitamente è orientata alla produzione di un documento chiamato “Piano di Test”.
Il piano di test solitamente riguarda tutte le tipologie di testing che si intendono sviluppare per l’applicativo.
In tale documento si fornisce una descrizione e la tipologia dell’applicativo, le funzionalità e i moduli da sottoporre ai test e quelli per cui non è previsto, le tipologie di testing da eseguire, l’ordine di realizzazione e il livello di priorità dei test, gli ambienti di test e le risorse hardware e software necessarie alla loro realizzazione.
La fase di pianificazione incomincia con la raccolta dei requisiti dell’applicazione e delle specifiche di progetto, utili a determinare l’approccio generale al testing e le risorse necessarie, come ad esempio, nel caso dei test di unità, l’adozione di particolari framework o altro software.
Si arriva poi a produrre quello che viene comunemente chiamato schedule generale, ovvero una lista di attività di testing in un certo ordine temporale e con un indice di priorità associato ad ognuna.
La determinazione dello schedule considera le caratteristiche da testare e le relative tipologie di testing associate, come ad esempio: test di accettazione degli utenti, test di sicurezza, stress test, test prestazionali, altri test di sistema e test di integrazione.
I test di unità, in questa fase, vengono solitamente presentati attraverso la suddivisione in moduli applicativi, senza entrare nel dettaglio, ma allo stesso tempo cercando di definirne gli ambienti di test e le caratteristiche generali dei dati in input e output ad esse associati.
Mentre per le altre tipologie di testing, i documenti da cui si estraggono e si elaborano le informazioni per definire il piano di test, sono prevalentemente i requisiti funzionali, per i test di unità vengono usati ampiamente anche le specifiche architetturali del progetto.
Dopo aver richiesto eventuali chiarimenti sui requisiti, si passa al raffinamento delle informazioni ricavate da questa fase del processo di testing.
I dati acquisiti possono quindi essere quindi inseriti in modo dettagliato nel piano di test (plan test).

Analisi e Progettazione dei Test

Questa fase segue alla pianificazione dei test, perciò i principali documenti e informazioni utilizzate provengono dal piano di test, ma anche dalla definizione dei requisiti e dalla specifiche formali dell’applicazione.
Lo scopo della progettazione è quello di acquisire tutti i dati necessari per poter procedere all’implementazione dei test.
Per fare ciò è possibile procedere in due modi: ampliare il piano di test esistente, oppure produrre altri documenti in relazione con esso.
Tali documenti, sia nel caso in cui si decida di mantenerli separati oppure di integrarli nel piano di test, sono: le specifiche dei test, le specifiche dei casi di test e le procedure di esecuzione.
Le specifiche dei test si basano su un ulteriore frazionamento in gruppi delle attività di testing già previste nello schedule del piano di test.
Ogni raggruppamento indica una tipologia o un particolare test operato, e ne viene descritto l’ambiente di test ed un elenco di casi di test appartenenti, completi di attributi generali e motivazione.
La specifica di un caso di test, invece, è un documento che identifica una particolare configurazione di test, descrivendone gli input inseriti, i risultati attesi, le condizioni di esecuzione, l’ambiente hardware e software.
Infine, un documento relativo alle procedure di esecuzione può essere associato ad una specifica di test o ad uno o più casi di test, e descrive i passi da fare per eseguirli.
In questo tipo di documenti può essere specificato come avviare la procedura di test, come effettuare le misure e rilevazioni, gli eventi imprevisti che possono accadere durante l’esecuzione e come comportarsi nel caso in cui si verifichino.

Implementazione dei Test

L’insieme dei documenti precedentemente descritti costituisce l’input necessario per la fase di implementazione dei test, che porterà alla realizzazione vera e propria di quanto emerso nella fase di progettazione. Proprio in questa fase, infatti, vengono valutati i singoli casi di test e implementati come previsto nelle specifiche.
Solitamente per fare questo vengono create delle procedure in grado di eseguire automaticamente i test, in modo da poterli eseguire ogni qual volta se ne presenti la necessità.
Tali procedure devono verificare la presenza di condizioni che siano in grado di stabilire il superamento con successo del test oppure un suo fallimento, in base al confronto tra il risultato atteso per il caso di test ed il valore effettivamente ottenuto dall’applicazione.
L’introduzione di procedure automatiche permette anche un alto grado di riusabilità dei test, che, a seguito di qualsiasi cambiamento del prodotto, dovranno solo essere modificati in maniera marginale.
E’ il caso, ad esempio, dei test di regressione.
L’implementazione tiene conto anche dei documenti relativi alle procedure di esecuzione precedentemente definite, che indicano il modo con cui devono essere eseguiti i test.
Tali documenti possono ovviamente essere modificati durante questa fase, nel caso in cui sorgano complicazioni nella realizzazione delle procedure oppure nel momento in cui si identifichino soluzioni più appropriate.
Al termine dell’implementazione, i singoli test realizzati vengono spesso inseriti all’interno di una o più “test suite”, ovvero collezioni di test.
Una test suite è una struttura in grado di lanciare l’esecuzione di tutti i test in essa contenuti, senza doverli richiamare uno ad uno.
Assegnare gruppi di test omogenei alla stessa test suite offre anche la possibilità di strutturare e ordinare i test in maniera più efficiente.
Una volta implementate le test suite questa fase può ritenersi conclusa, ma al termine di essa viene solitamente generata la documentazione tecnica del codice realizzato.
Tale documento, comunemente chiamato “API specifications” (Application Programming Interface), presenta mediante un’astrazione l’insieme delle procedure create dallo sviluppatore.
Questo tipo di documentazione risulta particolarmente importante per capire il funzionamento e la struttura dei casi di test, per comprendere eventuali errori ed eccezioni sollevate durante la loro esecuzione, per l’analisi dei risultati ottenuti e nel processo di debugging.
Infatti, al termine della fase di implementazione i test verranno eseguiti, valutati ed analizzati nel dettaglio.

Esecuzione e Valutazione dei Test

Al termine dell’implementazione e dopo aver allestito le configurazioni e gli ambienti di test necessari, possono finalmente essere eseguiti i test.
Solitamente è sufficiente eseguire una o più test suite contenenti tutti i test implementati per l’applicativo.
Ogni caso di test lanciato può portare a tre risultati: il superamento, il fallimento, oppure un errore durante l’esecuzione del test.
Quando tutti le condizioni specificate per il superamento di un caso di test, indicano che per ogni input fornito sono stati ottenuti esattamente i risultati attesi, il test risulterà superato con successo.
Quando, invece, una o più condizioni identificano valori ottenuti diversi da quelli attesi, il test rileva un fallimento e indica che probabilmente è presente un difetto nel codice, che viene opportunamente segnalato.
Indipendentemente dai risultati ottenuti dalla valutazione delle condizioni fino a quel momento, quando si presenta un evento imprevisto nell’oggetto del test o nel test stesso, viene segnalata una eccezione non gestita e il test restituisce errore come risultato.
L’esecuzione dei test genera in primo luogo il cosidetto “Log”, ovvero una raccolta strutturata di tutti i dettagli inerenti l’esecuzione dei test in ordine cronologico, come ad esempio: il nome del test eseguito, il tempo di esecuzione, data e ora di inizio e il risultato ottenuto.
Studiando poi il test log e incrociando i risultati ottenuti con i requisiti di completezza e terminazione, definiti in fase di pianificazione e progettazione, è possibile eseguire il “check dei test”.
Questa operazione di verifica vuole stabilire se tutte le funzionalità siano state testate e se la totalità dei test siano sufficienti per coprire l’intero codice e le diverse classi di input identificati in precedenza.
In generale il check effettua una stima del grado con cui i test siano esaustivi rispetto agli obbiettivi previsti nel piano di test.
Nel caso in cui venga riscontrata la mancanza di test o la ridondanza di alcuni di essi, si provvede a effettuare eventuali modifiche all’insieme dei test esistenti.
Una volta eseguito l’insieme completo dei test per l’applicativo considerato si procede quindi verso la valutazione dei risultati ottenuti.
La prima cosa da fare è quella di salvare i log dei test eseguiti in appositi repository o database.
La memorizzazione persistente di tali informazioni è importante per vedere l’evoluzione di un prodotto e risulta fondamentale nella valutazione di diverse versioni nei test di regressione.
Secondariamente è necessario effettuare una prima analisi dei difetti riscontrati nell’applicativo, che solitamente avviene durante la creazione del “Test Summary Report”, ovvero un insieme di valutazioni rispetto ai fallimenti o gli errori riscontrati nei test, che necessitano di ulteriori approfondimenti.
Per i test di unità questo documento costituisce solitamente l’input per il processo di debugging dell’applicativo e contiene il log dei test che evidenziano difetti o che sono andati in errore, delle possibili cause o soluzioni e i limiti riscontrati nei test.
Dopo il processo di debugging, l’esecuzione e la valutazione dei test possono essere reiterati più volte, per accertare il corretto funzionamento delle unità testate.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Una risposta a “Il processo di testing software”

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *