Hanno partecipato:

• Christian Alexander Graf, Statistical Consultant & Coach - Qualitätssicherung und Statistik
• Simone Pancaldi, Channel Manager Southern Europe - Atlassian
• Ernesto Centrella, Responsabile metodologie di lavoro e Delivery manager - Credito Emiliano
• Massimo Crubellati, Senior Vice President e Country Manager Italia - CAST
• Keith Yorkston, Director - Quality Risk Management UK
• Davide Bedin, Senior Cloud Solution Architect - Microsoft
• Salvatore Reale, Responsabile Programmi e Marketing - ITA-STQB

Overview

L'Institute of Electrical and Electronics Engineers (IEEE) definisce il software testing come "il processo di valutazione di un sistema attraverso strumenti manuali o automatici, col fine di determinare se il sistema soddisfa i requisiti specificati oppure se il suo comportamento verificato differisce da quello atteso". A differenza di un comune prodotto non informatico, lo sviluppo di un software può dipendere da altri sistemi o da altri software, pertanto il testing può essere fatto più volte durante le fasi del ciclo di vita del software in base al modello di sviluppo adottato. Al fine di installare in produzione un software finito, lo scopo del testing è quello di rilevare i difetti tramite i malfunzionamenti per poterli correggere prima che venga utilizzato dall'utente finale.

Teorema di Dijkstra (anno 1969): "il test di un programma può rilevare la presenza di malfunzionamenti, ma mai dimostrarne l'assenza".

Il test del software è un processo di esecuzione di un programma o di un'applicazione con l'intento di trovare i bug del software. Questo può anche essere indicato come il processo di convalida e verifica che un programma software, un'applicazione o un prodotto:
• soddisfa i requisiti tecnici e aziendali che ne hanno guidato la progettazione e lo sviluppo
• funziona come previsto
• può essere implementato con la stessa caratteristica

In pratica, il test del software è una parte importante dello sviluppo del software. Se il test del software non viene eseguito correttamente, le applicazioni possono contenere errori che possono portare a rilavorazioni, guasti costosi o, peggio, perdite di vite umane.

Sempre l'IEEE afferma che ci sono diversi punti nel processo di sviluppo del software in cui l'errore umano può portare a software che non soddisfa i requisiti dei clienti. Alcuni di loro sono elencati di seguito:
• Il cliente o la persona che fornisce i requisiti per conto dell'organizzazione del cliente potrebbe non sapere esattamente cosa è richiesto o potrebbe dimenticare di fornire alcuni dettagli, il che potrebbe portare a funzionalità mancanti
• La persona che sta raccogliendo i requisiti può interpretare erroneamente o perdere completamente un requisito quando li documenta
• Durante la fase di progettazione, se ci sono problemi nella progettazione, potrebbe portare a bug in futuro
• I bug possono essere introdotti durante la fase di sviluppo durante l'errore umano, la mancanza di esperienza, ecc.
• I tester possono perdere i bug durante la fase di test a causa di errori umani, mancanza di tempo, esperienza insufficiente, ecc.
• I clienti potrebbero non avere la larghezza di banda per testare tutte le funzionalità del prodotto e potrebbero rilasciare il prodotto ai propri utenti finali, il che può portare gli utenti finali a trovare errori nell'applicazione

Inoltre, il business e la reputazione di un'organizzazione dipendono dalla qualità dei suoi prodotti e in alcuni casi anche le entrate possono dipendere dalle vendite del prodotto software.
Gli utenti potrebbero preferire acquistare un prodotto concorrente rispetto a un prodotto di scarsa qualità e questo può comportare una perdita di entrate per l'organizzazione. Nel mondo di oggi, la qualità è una delle massime priorità per qualsiasi organizzazione.

Test specializzati possono essere condotti concentrandosi sulle vulnerabilità che potrebbero essere sfruttate per condurre attacchi dall'interno o dall'esterno della rete in cui è attestato il sistema (da ricordare che un attacco dall'interno può essere condotto dal personale interno o da esterni che sfruttano un sistema interno già compromesso in precedenza). I test di sicurezza possono essere condotti da personale interno o da fornitori. Nel caso di fornitori è sempre necessario stipulare un contratto per stabilire le responsabilità reciproche e i limiti dei test (per esempio, i valutatori si impegnano a non condurre attacchi che possano compromettere i sistemi, ma a spingere l'analisi solo per dimostrare la presenza e l'utilizzabilità, da parte di un malintenzionato, delle vulnerabilità).


A cura di Gian Carlo Lanzetti