Quali sono le tecniche di esecuzione dei test per il testing software
Tecniche per l’esecuzione del test
In questo articolo sul testing software andiamo ad esaminare le tecniche per l’esecuzione dei test. Le tecniche principali prevedono:
- Revisione strutturata (Peer Review);
- Tecnica di test White-Box;
- Tecnica di test Black-Box;
- Tecnica di test Error Guessing.
Revisione strutturata (Peer Review)
Partecipanti
La peer review è una tecnica consolidata di grande efficacia per effettuare revisioni tecniche formali. Sono previsti i seguenti ruoli:
- Autore: chi ha realizzato il materiale da sottoporre a revisione.
- Moderatore: chi ha conoscenza ed esperienza della tecnica delle revisioni strutturate, oltre a conoscenze applicative e tecniche specifiche sull’argomento trattato. Svolge anche il ruolo di revisore/ispettore.
- Revisore/Ispettore: chi ha competenza tecnica per poter eseguire la verifica del materiale revisionato.
Tutti i partecipanti sono considerati alla pari senza gerarchia di ruoli (da cui la denominazione “Peer Review”). L’attività è svolta tra colleghi con lo scopo di aiutarsi a vicenda per verificare la correttezza del materiale prodotto. Ogni collega, a turno, è “revisore” del lavoro di altri ed è anche “revisionato” nel proprio lavoro prodotto. In ottica di aiuto reciproco, è sconsigliata la presenza dei capi.
Modalità di esecuzione
Le modalità per l’organizzazione e la conduzione delle revisioni formali sono le seguenti:
Pianificazione delle revisioni
Il capo progetto pianifica le revisioni formali da eseguire nell’ambito del progetto (quali documenti ispezionare, quali persone coinvolgere come moderatore e revisori, quando effettuare le revisioni, quanto tempo dedicare a tali attività).
Distribuzione del materiale
L’autore distribuisce una copia del materiale da revisionare al moderatore ed ai revisori (in genere una o due persone), in un breve incontro (10 minuti), dove espone i contenuti del materiale fornito. Si concorda la data e l’ora della riunione in cui discutere i commenti.
Revisione del materiale
I revisori ed il moderatore, ognuno per proprio conto, leggono il documento fornito ed apportano sul materiale i propri commenti. L’attenzione è posta sugli eventuali errori, mancanze, particolari importanti e non sulle banalità. Lo scopo è quello di scoprire gli errori prima che si possano propagare nelle fasi successive ed infine nel codice sorgente.
Riunione di revisione
L’autore, il moderatore ed i revisori si riuniscono nel giorno concordato per esporre e commentare gli errori rilevati e le osservazioni fatte sui documenti. è importante segnalare gli errori riscontrati senza entrare in discussioni circa la loro risoluzione. Sarà l’autore a decidere se e come risolverli. La riunione deve durare il tempo prefissato (in genere un paio d’ore). Se necessario, si pianifica una seconda riunione. Qui il moderatore gioca un ruolo importante. Egli deve garantire che la riunione sia efficace (siano realmente segnalati problemi ed errori), duri il tempo previsto (si vada al sodo e non si perda tempo in discussioni inutili) e sia svolta correttamente (si aiuti l’autore a scoprire gli errori senza giudicare la sua capacità e quanto faccia bene il suo lavoro). Il moderatore produrrà una lista dei problemi segnalati che consegnerà all’autore al termine della riunione.
Correzione del materiale
In un tempo successivo, l’autore analizza i problemi segnalati (elencati nella lista) e provvede a risolverli secondo il proprio giudizio tecnico, compreso quello di non indirizzare un problema se ritenuto improprio.
Verifica delle correzioni
L’autore discute con il moderatore la lista dei problemi segnalati e le eventuali soluzioni apportate, senza entrare in un dettaglio tecnico eccessivo. Il moderatore decide se considerare risolti tutti i problemi e verbalizza la chiusura della revisione.
Chiusura della revisione e stesura del verbale
Il verbale di revisione è redatto utilizzando un modulo che contenga, al minimo, le seguenti informazioni: nome del progetto, titolo del documento ispezionato, data della riunione di revisione e partecipanti, elenco dei problemi riscontrati, data di chiusura della revisione.
Tecnica di test White-Box
White-Box è una tecnica di test focalizzata sulla struttura interna di un programma. In questo test si ha piena visibilità del codice. Per eseguire il test si deve seguire il percorso logico del programma. Il test white-box è quindi logic driven, cioè basato sulla logica interna del programma. è un test strutturato, perché è effettuato seguendo la struttura del programma. Per sviluppare i casi di prova relativi, bisogna accedere la codice. è richiesta, quindi, la conoscenza del linguaggio di programmazione utilizzato. Questi test, detti anche test unitari, sono progettati ed eseguiti dagli stessi sviluppatori che conoscono bene il proprio codice. Il codice è rappresentato mostrando i punti di decisione, le condizioni logiche ed i salti. I casi di test devono essere costruiti per verificare ciascuna condizione logica in tutti i suoi possibili valori (vero / falso). Devono essere verificati tutti i possibili cammini. Per definire quali e quanti test effettuare ci si può aiutare con il grafo del controllo dei flussi, utilizzando la complessità ciclomatica.
Vantaggi
- è un test focalizzato;
- Verifica il flusso di controllo;
- Verifica gli algoritmi specifici;
- Verifica i confini / i casi limite del modulo (programma);
- è l’approccio naturale per il test unitario.
Svantaggi
- Non verifica la corrispondenza del programma alle specifiche funzionali;
- Non verifica la soddisfazione dei requisiti del cliente;
- Non verifica i percorsi logici mancanti, ridondanti, inutili (codice inerte);
- Per migliorare i risultati occorre aumentare lo sforzo.
Tecnica di test Black-Box
Black-Box è una tecnica di test focalizzata sugli aspetti esterni della funzione da validare ed è quindi “data driven”. La funzione è vista come una scatola nera dove sono noti solo i dati di input e di output (il codice non è visibile e quindi non è conosciuto il percorso seguito all’interno dei programmi). Non è quindi richiesta la conoscenza del codice interno eseguito. Esso riflette le necessità del business e per costruire i casi di prova è necessario avere conoscenza delle funzioni applicative previste e la relativa importanza rispetto al business.
I casi di prova sono quindi dedotti direttamente dalle specifiche funzionali. Le condizioni per la validazione esaustiva dell’applicazione sono quelle di provare tutte le combinazioni di input valide e provare tutte le concatenazioni logiche di sequenza dei dati. Poiché risulta oneroso eseguire un test esaustivo occorre, quindi, pianificare i test con criteri di economicità (massimo risultato con minimo sforzo) ottimizzando le prove da eseguire. L’efficacia del test Black-Box sta nell’efficacia dei casi di test. Questi dunque saranno progettati perché risultino significativi per il business, adeguati alla complessità delle funzioni da validare e saranno eseguiti da personale con adeguata competenza applicativa. La scelta dei casi di test significativi è effettuata tramite la costruzione di una matrice di test che mappa le funzionalità da validare con i casi di test di eseguire. La tecnica di test Black-Box è l’approccio naturale per i test funzionale (o d’integrazione), i test di sistema ed i collaudi utente (o d’accettazione).
Tecnica di test Error Guessing (previsione degli errori)
Error Guessing è una tecnica di test che si basa sull’esperienza pregressa, con la quale si possono creare dati di test e casi di test anticipare il rilevamento degli errori più comuni. Usando l’esperienza e le conoscenze applicative, si possono simulare gli errori più comuni che gli utenti finali tendono a commettere nell’utilizzo del prodotto per verificare che il software sia in grado di gestire correttamente tali situazioni.
Un tipico esempio di “Error Guessing” è utilizzare il tasto “Alt” invece del tasto “Ctrl” in un’applicazione basata su PC e verificare il comportamento del software.
