Pianificazione ed esecuzione del processo di testing di un'applicazione gestionale

1   Introduzione “Le operazioni di testing possono individuare la presenza di 
errori nel software ma non possono dimostrarne la correttezza” 
(Dijkstra, 1972)
 
Le tecniche di verifica del software possono essere classificate come:
 
Dinamiche (o di testing ), il corretto funzionamento del sistema viene controllato sulla base di prove 
sperimentali che ne verificano il comportamento in un insieme rappresentativo di situazioni;
Statiche (o di ispezione ): il corretto funzionamento del sistema viene verificato analizzando 
direttamente la struttura dei moduli e il codice che li realizza.
Scopo del testing è quello di verificare il comportamento del 
sistema in un insieme di casi ( test set ) sufficientemente ampio 
da rendere plausibile che il suo comportamento sia analogo 
anche nelle restanti situazioni. Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 5
1.1   Il processo di testing
Nel campo del software, il testing è il processo di eseguire programmi con l'intento di trovare errori. 
Esistono varie tipologie d'errore che possono essere ricercate dall'attività di testing e, per questa 
ragione, esistono vari modi di testare un software o un complesso software+hardware. Questo 
processo migliora l'integrità del sistema consentendo di rilevare le difformità dal progetto e gli 
errori. Consente inoltre di migliorare il prodotto conformandolo alle esigenze dell'utente. L'obiettivo 
è di individuare le aree in cui si possono verificare errori e prevenirli. Una volta identificato un 
malfunzionamento, la fase di debugging ha il compito di localizzare gli errori/difetti del codice che 
hanno provocato il malfunzionamento e di procedere alla loro correzione. I difetti del codice non 
sempre si manifestano in malfunzionamenti. Questa situazione si verifica, per esempio, quando 
l'errore è localizzato in una parte del programma che viene raramente eseguita, in presenza di una 
combinazione di dati di ingresso rara o insolita. 
1.1.1   Requirements testing È una verifica volta a verificare che tutti i requisiti siano: 
• rilevanti - il requisito è rilevante per questo progetto? 
• coerenti - il requisito contrasta con altri requisiti? 
• tracciabili - il requisito consente di essere "tracciato" durante lo sviluppo per 
verificarne lo stato di avanzamento? 
• completi - il requisito ha tutte le informazioni necessarie? 
• testabili - esiste un modo inconfutabile per verificare se un certo requisito è 
stato rispettato?
1.1.2   Analysis/design testing • Sono test volti ad individuare errori nelle fasi di analisi e design; 
• Dimostrano che, se realizzato secondo queste analisi, il sistema: 
o non funzionerà correttamente; 
o non farà quanto richiesto nei requisiti iniziali.
1.1.3   Function testing • Il function testing si occupa di trovare discrepanze tra il programma e la sua 
external specification. 
• Di norma è una attività esclusivamente di tipo black-box. 
• Per eseguire questo test è necessario derivare i test case dalla external 
specification usando le consuete tecniche di black boxing (classi di equivalenza, 
causa-effetto, ecc.). 
• Ricordarsi di testare anche condizioni inattese e non valide.
Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 6
1.1.4   System testing • È il compito più difficile da completare. 
• Non è da confondere con il function testing. 
• Il system testing è il tentativo di dimostrare che il sistema non soddisfa gli 
obiettivi definiti nella apposita fase. 
• Questo testing è impossibile se nella fase di definizione degli obiettivi non si 
è prodotto un documento completo di obbiettivi misurabili. 
• Ci si concentra sulla ricerca di errori commessi durante la fase di definizione 
delle specifiche d'interfaccia (external specification). 
• Il documento degli obiettivi, per definizione, non contiene specifiche precise 
e dettagliate, rendendo questo tipo di testing molto difficoltoso. 
• Non esistono metodologie perché testing formali possono essere applicati in 
presenza di interfacce formali, la definizione delle quali è proprio l'oggetto del 
testing. 
• In genere si usa come sorgente per i test la documentazione utente del 
sistema. 
• Questo tipo di test non dovrebbe mai essere eseguito dalla società che ha 
prodotto il software.
Esistono diversi aspetti del system testing. Essi non sempre hanno senso in tutti i 
possibili sistemi. Essi sono: 
• Facility testing - individua funzionalità che, benché presenti negli obbiettivi, 
non sono implementate nel sistema. 
• Volume testing - sottopone al sistema grosse quantità di dati fino ai limiti 
imposti negli obiettivi per saggiarne la robustezza. 
• Stress testing - sottopone il sistema a intensi picchi di lavoro. 
• Usability testing - trova difetti nelle caratteristiche di usabilità del sistema da 
parte dell'utente finale: 
o Le interfacce sono adattate al livello di cultura, abilità e condizioni 
ambientali dell'utente finale? 
o Gli output sono sempre comprensibili all'utente finale? 
o La diagnostica è comprensibile all'utente finale? 
o L'interfaccia è consistente dal punto di vista delle convenzioni, 
sintassi, semantica, formato, stile e abbreviazioni? 
o L'accuratezza degli input è garantita da un’pportuna ridondanza e 
controlli adeguati? 
o Le opzioni offerte sono eccessive e/o creano confusione? 
o Il sistema dà tempestivo cenno di riscontro ad ogni operazione? 
o Il programma è facile da usare?
• Security testing - trova difetti nella sicurezza del sistema, sia accidentale che 
dolosa, sempre nel rispetto degli obbiettivi imposti. 
• Performance testing - Se vi sono degli obbiettivi in termini di performances 
sotto un dato carico, esse vanno verificate. 
• Resources testing - Se vi sono degli obbiettivi che riguardano l'impiego di 
risorse (es. spazio su disco, etc.) vanno verificati. Anche in questo caso bisogna 
cercare di indurre il programma a superare i limiti imposti negli obbiettivi. 
Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 7
• Configuration testing - individua problemi legati ad alcune configurazioni 
hw o sw previste negli obbiettivi. 
• Compatibility/conversion testing - per quei programmi che devono 
garantire compatibilità o upgradeabilità con altre versioni. 
• Installability testing - per trovare errori nella procedura di installazione. 
• Reliability testing - task spesso difficile, serve a trovare un’affidabilità 
inferiore al previsto. 
• Recovery testing - se gli obbiettivi prevedevano una certa capacità di 
recovery in presenza di dati errori, essi vanno forzati nell'intento di trovare 
malfunzionamenti nella procedura di recovery. 
• Serviceability testing - testare la presenza e la validità di strumenti 
aggiuntivi per la manutenzione. 
• Documentation testing - si ottiene in due maniere: 
o usando la documentazione stessa come sorgente per il system testing; 
o eseguendo un'ispezione manuale alla ricerca di errori o parti 
incomprensibili.
• Procedure testing - se il sistema è parte di una procedura più complessa, 
magari che impiega anche attività manuali, questa va testata.
1.1.5   Unit (module/component) testing È un test che viene applicato su sotto-parti del software. Ha le seguenti caratteristiche: 
• verifica che il codice sia conforme al design di dettaglio; 
• controlla tutti i percorsi di esecuzione nel codice; 
• controlla che l’interfaccia e la messaggistica sia corretta; 
• controlla gli input e gli output dei singoli moduli/funzioni; 
• verifica che le reazioni in caso d’errore siano corrette; 
• controlla la correttezza degli algoritmi; 
• verifica che il codice non contenga errori di implementazione che possano 
causare accessi illegali alla memoria, memory leak, eccetera.
1.1.6   Acceptance testing È un test per verificare la corrispondenza del prodotto finito con quello richiesto.
Viene eseguito dal cliente finale e non è responsabilità delle società impegnate nello 
sviluppo. 
1.1.7   Installation testing È un test fornito dalla società che sviluppa il software. È volto a trovare errori 
d'installazione.
Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 8
1.2   Cause degli errori 
Le cause di errore più frequenti sono: 
• Comunicazione inadeguata tra lo sviluppatore e i dirigenti aziendali 
Una comunicazione inadeguata tra lo sviluppatore e i dirigenti aziendali è dovuta, di 
solito, a sottili divergenze di opinione. Ad esempio, un imprenditore con un background in 
marketing finanziario desidera configurare un sito per la vendita online di azioni. Lo 
sviluppatore con un background tecnico potrebbe non avere alcuna nozione dei 
meccanismi complessi del mercato finanziario, pertanto è possibile che non sappia come 
incorporare quelle funzionalità che possono risultare utili per i visitatori del sito, ad 
esempio i prezzi dei fondi comuni di investimento a capitale variabile.
• Poco tempo a disposizione dello sviluppatore per completare il progetto 
Una causa frequente di errori nei progetti deve essere individuata nelle scadenze imposte 
allo sviluppatore per la consegna del prodotto. Nel migliore dei casi, la pianificazione di 
un progetto rappresenta una supposizione ragionevole basata sulle conoscenze attuali. Nel 
peggiore, la pianificazione riflette una stima irreale basata sui desideri dei dirigenti 
aziendali. Durante le fasi di sviluppo e testing si possono presentare problemi non previsti 
anche dalla migliore pianificazione. Per rispettare le scadenze, nonostante tali problemi, è 
possibile ridurre il numero di funzionalità da implementare, oppure mantenere le 
funzionalità modificando la pianificazione. Se non si adotta una delle due alternative, si 
assisterà a un'accelerazione del lavoro e il prodotto finale risulterà scadente.
• Assunzione eccessiva di impegni da parte dello sviluppatore 
Lo sviluppatore può essere portato ad accettare un numero eccessivo di commesse. In 
questi casi, diventa impossibile rispettare le scadenze o assicurare una qualità ottimale a 
causa della mancanza di risorse o delle competenze necessarie all'interno del team.
• Test e controlli della qualità insufficienti 
I processi di testing eseguiti in modo inadeguato rappresentano la causa principale di 
interruzione di funzionamento.
• Raccolta inadeguata di requisiti 
Tempi di realizzazione del prodotto ridotti spingono gli sviluppatori a iniziare lo sviluppo 
senza comprendere a fondo i requisiti tecnici e aziendali necessari. Ad esempio, la 
complessità del calcolo delle imposte erariali può impedire una comprensione reale del 
meccanismo dei costi di spedizione che verranno pertanto calcolati in modo scorretto. 
• Aggiornamento alla tecnologia di e-commerce in rapido cambiamento 
 Si assiste all'introduzione costante di nuove tecnologie, spesso con poco tempo a 
disposizione degli sviluppatori per acquisire la dovuta competenza. Ciò può rappresentare 
un problema per due motivi: in primo luogo, è possibile che le nuove tecnologie non 
vengano implementate in modo corretto; in secondo luogo, l'integrazione della nuova 
tecnologia nell'ambiente esistente può risultare inadeguata.
Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 9
1.3  Obiettivi del processo di Testing 
I test sono indispensabili in relazione ai fattori seguenti: 
• Affidabilità del software 
La raccolta di dati dei clienti e l'implementazione di gateway di pagamento. Il software 
utilizzato a questo scopo deve funzionare correttamente. Il processo di testing garantisce 
all'organizzazione la qualità e l'integrità delle soluzioni. 
• Qualità del software 
La qualità del software è caratterizzata dalla correttezza della logica e 
dell'implementazione del programma, pertanto il software deve essere sottoposto ai test 
già durante la fase di sviluppo. 
Lo sviluppatore deve eseguire, durante la scrittura o la modifica, i test di ogni modulo per 
garantirne il corretto funzionamento. È necessario inoltre verificare i valori dei test e le 
condizioni limite. Infine, è necessario sottoporre i moduli ai test di interfaccia per 
individuare errori funzionali. Solo quando risulta che i moduli funzionano correttamente, è 
possibile avviare i test in un sistema di dimensioni maggiori. L'individuazione tempestiva 
degli errori consente di evitare rifacimenti del codice nonché l'aggravamento dei problemi. 
Il rilevamento degli errori durante il funzionamento di un sistema comporta, infatti, costi 
diretti e indiretti più elevati.  
• Garanzia del funzionamento del sistema 
L'obiettivo principale della garanzia del funzionamento del sistema è di consegnare un 
prodotto di qualità. La conformità ai requisiti aumenta la fiducia dell'organizzazione nel 
sistema.  
• Prestazioni e utilizzo ottimale delle risorse 
Un altro scopo del testing è di assicurare alte prestazioni e utilizzo ottimale delle risorse 
dei componenti del sistema. La pianificazione e i test di stress o di capacità hanno 
l'obiettivo di assicurare che sia in grado di mantenere un livello accettabile di prestazioni 
nei momenti di massimo utilizzo. 
• Costi di non conformità 
Lo scopo principale del testing è di rilevare gli errori e le aree del sistema in cui 
potrebbero verificarsi. Il processo di testing deve essere approfondito e ben pianificato. Un 
sistema collaudato solo parzialmente è inaffidabile quanto un sistema non collaudato 
affatto e il rischio di incorrere in costi elevati sussiste in entrambi i casi. 
Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 10
1.4   Casi di Test
Lo svolgimento dell’attività di testing si basa sull’identificazione dei cosiddetti casi di test . Un caso 
di test è un insieme di dati forniti in ingresso ad un programma, allo scopo di verificare la 
corrispondenza dei risultati ottenuti con quanto previsto dalle specifiche. Normalmente, un caso di 
test è insufficiente a verificare la qualità di un programma. Il problema è identificare un insieme di 
casi di test "appropriato". Il termine "appropriato" rimanda ai due principali aspetti critici 
dell'attività di test. In primo luogo, il costo dell'attività di test è proporzionale alla qualità del 
risultato che si vuole ottenere. E' necessario modulare il volume di test che si decide di effettuare in 
funzione del costo di tale attività alla luce dei requisiti del programma e dell'utente. Per esempio, è 
evidente che un software per la gestione di un sistema di avionica richiederà un'attività di testing 
diversa da quanto necessario per un video-game. Il secondo punto critico è la necessità di 
identificare casi di test non ridondanti . Due casi di test possono essere equivalenti, in quanto 
stimolano il programma allo stesso modo. In questo caso diviene inutile includerli entrambi 
nell'insieme di casi di test. 
E’ possibile classificare i concetti relativi al test di un programma secondo diversi fattori:
1.4.1   Tipologia di Testing è possibile avere due differenti approcci:
1. Black-Box: i casi di test derivano dall'analisi delle specifiche dei requisiti e di 
progetto. Il Black-Box testing è anche detto testing funzionale ed è basato sulle 
specifiche che descrivono il comportamento del programma (o di una sua porzione).
  Specifiche dei 
       requisiti 
    Input Output attesi
            Output ottenuti 
       Modulo da testare
       
Come esemplificato in figura, il programma viene considerato come una scatola nera. I casi 
di test vengono identificati studiando la specifiche del programma. 
Alcuni esempi di applicazione dell'approccio black-box:
Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 11
• Testing guidato dalla sintassi Quando il programma da realizzare deve interpretare un linguaggio descritto tramite 
una sintassi formale quale la BNF, un possibile criterio per la scelta dei casi di testing 
è dato dal generare input di stringhe derivate dalla stessa specifica del linguaggio, 
applicando tutte le regole della grammatica che lo descrive. Per esempio, un 
compilatore viene normalmente testato utilizzando delle test suite derivate dalla 
sintassi/semantica del linguaggio.
• Testing guidato dagli scenari d’uso Spesso è possibile derivare tali i casi di test dalla specifica degli scenari d’uso (si pensi 
agli Use Case Diagram dell’UML). Posso infatti, per ogni singolo scenario d’uso, 
listare tutti i possibili ingressi che lo caratterizzano e provare quindi il comportamento 
del programma a fronte di tali casi.
• Testing guidato da boundary conditions Il testing, sia White-Box sia Black-Box, cerca solitamente di suddividere il dominio 
dei possibili ingressi in classi significative ed omogenee dal punto di vista del 
comportamento, in modo che scegliendo un elemento all’interno di ciascuna classe si 
possano coprire tutti i comportamenti del programma previsti. Spesso già le specifiche 
suggeriscono tale classificazione. Alcuni errori tipici, tuttavia, si manifestano in 
prossimità dei confini di tali classi. Tra i vari casi di test è dunque opportuno, 
soprattutto nel Black-Box testing, introdurre degli input che vadano a verificare una 
corretta implementazione per i casi che costituiscono "boundary conditions".
• Derivazione semiautomatica dei casi di test alle specifiche Esistono oggi linguaggi di specifica (per esempio TRIO) per i quali si è in grado di 
generare in modo (semi) automatico casi di test.
2.  White-Box: i casi di test vengono derivati dall'analisi del codice del programma.
Il White-Box testing è anche detto testing strutturale in quanto i casi di test vengono 
scelti osservando la struttura e l’implementazione del programma. Nell'ambito del 
testing strutturale, esistono diversi criteri di copertura che guidano la scelta dei casi 
di test. Essi sono stati definiti in modo tale da imporre vincoli via via più stringenti e 
quindi aumentare il numero di casi di test necessari per verificare un programma. Al 
crescere del grado di copertura, aumenta la qualità dell'attività di test, ma aumentano 
anche i costi necessari alla sua attuazione.
Consideriamo come primo esempio l'algoritmo di Euclide per la ricerca del MCD tra due 
numeri interi.
begin    read(x);
    read(y);
        while x „ y do 
            if x>y then                x := x-y;
            else                y := y-x; 
            end if;
        end while;
    MCD := x;
end;
Pianificazione ed esecuzione del processo di testing di un’applicazione gestionale                         Pagina 12