L'importanza della validazione software nei prodotti

Negli ultimi 20 anni abbiamo assistito ad un aumento esponenziale della potenza di calcolo dei microcontrollori. Questo ha portato alla digitalizzazione di molti oggetti quotidiani e sono sempre di più gli oggetti che abbiamo in casa che hanno un software a bordo.

Se come me lavori da molti anni in aziende di progettazione ti sarai reso conto di come i tempi e costi dello sviluppo della parte software dei prodotti è esplosa. Il software è diventato la parte più importante e costosa di molti progetti industriali.

Inoltre tra nuove funzionalità e manutenzione lo sviluppo software non finisce con la SOP (Start of production) ma continua in tutto il ciclo di vita del prodotto.

Con queste considerazioni puoi immaginare come la validazione software sia diventata una delle fasi più importanti del progetto sia per assicurare che l’oggetto soddisfi le specifiche cliente sia per evitare alti costi di manutenzione del software e di reclami da parte dei clienti.

In alcuni mercati la validazione software è da sempre un punto cardine della progettazione elettronica di sistemi complessi. Si tratta di ambiti che possono permettersi costi di sviluppo elevati e richiedono un alto livello di qualità del prodotto (automotive, biomedicale, difesa, etc).

Negli ultimi anni altri settori come industriale e Iot hanno preso in presto alcune delle metodologie utilizzate.

Per assicurare uno standard di qualità e una metodologia comune molte aziende preferiscono formare un team di validazione software che abbia una certificazione. In italia l’associazione più famosa che permette uno schema di certificazioni internazionali per i professionisti del testing software si chiama ISTQB®.

Nell’immagine seguente puoi vedere tutti i livelli di certificazione che si possono ottenere:

Il percorso di certificazione passa sempre dal livello “Foundation” in cui il validatore impara le basi metodologiche del testing. In base alla metodologia di sviluppo software applicata in azienda si può proseguire sul percorso “Core” o “Agile”.

Ci sono poi tutta una serie di certificazioni che si possono fare per specializzarsi in alcuni settori (automotive, mobile application, AI, etc).

L’associazione fa gli esami, rilascia i certificati e fornisce materiale di studio consultabile gratuitamente sul sito web mentre i corsi sono tenuti da aziende accreditate.

Le basi della validazione software: “Foundation Level” di ISTQB

Voglio parlarti

La cosa che ho trovato più interessante nella parte introduttiva sono stati i principi del testing:

• Il testing evidenzia dei bug software ma non può assicurarci la loro assenza.
• Il testing non può essere esaustivo
• Testare un software può farci risparmiare tempo e denaro
• Il principio di Pareto vale anche nel testing (l’80% dei difetti si trova nel 20% dei componenti software)
• I test vanno variati nel tempo per evitare che perdano di efficacia (i sviluppatori software diventano bravi a correggere una tipologia specifica di errori se non si variano i test)
• Non esiste un modo giusto di fare test, esistono delle metodologie che vanno applicate a contesti diversi
• Il testing può comunque portare a rilasciare un software che non soddisfa tutte le esigenze del cliente

Dati questi principi si evince che il testing del software sia una delle possibilità di migliorare l’analisi del rischio di un progetto ma non assicura in alcun modo che il rilascio sia privo di bug e che non ci siano malfunzionamenti nell’utilizzo da parte del consumatore.

L’attività del team di validazione è (più di ogni altra attività di progetto) in continua evoluzione e deve necessariamente migliorare nel tempo.

I compiti del validatore software non sono solo relativi alla sola esecuzione dei test ma anche a tutte quelle attività che permettono di migliorare il processo di sviluppo:

• Pianificazione dell’attività di test
• Monitoraggio e controllo dell’avanzamento e dei risultati dei test
• Analisi dei requisiti e definizione del test plan
• Progettazione e implementazione dei test
• Esecuzione e redazione della reportistica necessaria

Livelli di test

Il test sul software può essere fatto a vari livelli e spesso anche da persone diverse all’interno del team di progetto:

• Testing di componente (unit test) – si tratta di un software di test che deve validare un componente specifico in modo isolato. Spesso vengono utilizzati dei framework di test e normalmente viene eseguito dagli sviluppatori stessi nei loro ambienti di sviluppo
• Testing di integrazione di componenti (unit integration testing) – si tratta del test delle interfacce e di come i vari blocchetti software interagiscono tra di loro
• Testing di sistema – viene eseguito sul sistema complessivo dal team di validazione. E' importante che il team sia indipendente da quello di sviluppo in modo da essere efficaci nel trovare difetti
• Testing di integrazione di sistema – viene eseguito su quei progetti in cui più sistemi interagiscono tra di loro. L'ambiente di test deve assomigliare quanto più possibile all’ambiente operativo che ci sarà in campo
• Testing di accettazione – per aziende che commercializzano i loro prodotti può essere svolto da chi rappresenta le esigenze di business del cliente (marketing, program management, qualità). Nel caso il progetto sia svolto da una società e commercializzato da un’altra spesso i test di accettazione vengono definiti a contratto e svolti dalla società cliente che da benestare al progetto

Dalla mia esperienza in alcuni segmenti di mercato il time-to-market del progetto è troppo stringente per poter testare il software su tutti i livelli descritti. Quando non è possibile strutturare una campagna di test completa ad ogni livello non bisognerebbe prescindere dal fare i test di sistema. Il testing di sistema è quello dove vengono fuori la maggior parte dei difetti.

La validazione di sistema riesce a scovare i difetti che generano dei failure che sono quelli che l’utente finale vedrà. Fare solo i test di sistema tuttavia potrebbe essere costoso perché alcuni tipi di errori intercettabili molto in anticipo vengono trovati sul sistema e ci vuole un debug approfondito per capire quale componente software genera il problema.

Quello che consiglio se non si può testare il software a tutti i livelli è fare unit test sui componenti software e test di sistema, in questo modo errori grossolani vengono identificati e sistemati dallo sviluppatore software durante la scrittura del codice mentre i test di sistema intercettano tutti quei problemi che vengono fuori dall’integrazione di tutti i componenti hardware e software del dispositivo sotto test

Tipologie di test

Il Livello Foundation identifica poi varie tipologie di test che si possono applicare ai vari livelli di test appena visti:

• Testing funzionale – valuta che il sistema funzionalmente risponda alle specifiche, la funzionalità deve essere completa, corretta e appropriata
• Testing non funzionale – valuta “quanto bene si comporta un sistema” aldilà delle funzionalità specifiche, può valutare l’affidabilitò, le prestazioni, la sicurezza, l’usabilità etc. (un esempio di test non funzionale per un dispositivo connesso in WiFi è quale velocità riesce a raggiungere in connessione)
• Testing black-box – E’ un test basato sulle specifiche, il validatore analizza i requisiti di progetto e da questo definisce un piano di test senza conoscere com’è stato strutturato il software
• Testing white-box – Chi esegue il test conosce la struttura software e deriva i test dall’implementazione del sistema (architettura, flussi di dati, codice, etc)

Queste definizioni non sono univoche, per fare un esempio possiamo considerare un test non funzionale svolto in modalità black-box.

Anche sulla tipologia di test vorrei darti la mia opinione, il test funzionale in modalità black-box è fondamentale e secondo me non può non essere fatto. Questo serve per verificare che il progetto risponda ai requisiti e il modo migliore per farlo efficacemente è farlo a livello di sistema.

Il test non funzionale è molto utile se si vuole raggiungere standard di qualità elevati, se il prodotto sotto test è un prodotto premium è necessario fare una campagna di test di performance dell’oggetto da tutti i punti di vista. Spesso i test derivano da quelli funzionali, ma si verifica che durante l’esecuzione della funzione si soddisfi un vincolo non funzionale (es. una funzionalità potrebbe essere connettersi al WiFi quando c’è un input, il test non funzionale potrebbe verificare se la connessione avviene entro un certo tempo prestabilito).

Ci possono essere altre due tipologie di test che vengono utilizzate quando viene rilasciato un aggiornamento software per risolvere dei bug o aggiungere delle funzionalità:

• Testing confermativo – quando la validazione ha individuato un bug e questo viene fissato su una release software successiva è necessario fare dei test che verificano che il bug sia effettivamente risolto. Questo può esser fatto rieseguendo tutti i test che fallivano in precedenza o aggiungendo dei test specifici per coprire le modifiche necessarie a coprire il difetto
• Testing di regressione - quando c'è una modifica sul software per una nuova funzionalità o per correggere dei bug è buona norma ripetere parte dei test già svolti su rilasci precedenti per verificare che la modifica non ha impattato parti che precedentemente funzionavano

Analisi e progettazione dei test di sistema

I test software di sistema possono essere classificati in tre tecniche di test:

• Tecnica di test black box - Il validatore parte da un documento di requisiti e senza conoscere come sono implementate le funzionalità software redige ed esegue un piano di test che soddisfa i requisiti analizzati.
• Tecnica di test white box - Il validatore studia prima l'architettura software e ne capisce a fondo la struttura. I test case dipendono quindi da come è stato implementato il codice.
• Tecnica di test basate sull'esperienza - Può essere complementare alle altre due tecniche di test, si basa molto sull'esperienza del tester quindi il livello di copertura del test dipende molto da chi sviluppa i test case

Se devi decidere quale tecnica utilizzare per il tuo team io ti suggerisco di provare a utilizzare una modalità di test in black box. Questa tecnica richiede più attenzione nella definizione e manutenzione dei requisiti ma presenta diversi aspetti positivi. I test possono essere sviluppati durante lo sviluppo del prodotto perché si basano sui requisiti e non sull'implementazione, inoltre il tester non si fa condizionare da come il software è stato sviluppato ma tratta l'oggetto dall'esterno come farà poi il cliente finale.

Nei prossimi paragrafi ti illustrerò brevemente le diverse tecniche di test black-box del livello "Foundation".

Partizionamento di equivalenza

La tecnica del partizionamento di equivalenza si basa sull'assunzione che i dati che possono essere categorizzati sotto una data partizione siano equivalenti tra loro a livello di test. Questo significa che se un valore all'interno della partizione rileva un difetto questo difetto è rilevabile testando qualsiasi valore all'interno della partizione stessa.

Le partizioni di equivalenza possono essere fatte per ogni tipologia di dato del software sotto test: input, output, item di configurazione, valori temporali etc.

Con questa tecnica la copertura del test è espressa in termini di partizioni testate, quindi un test che copre il 100% dei casi svolge il test su tutte le partizioni.

La difficoltà di questa tecnica consiste nell'individuare le partizioni, infatti considerare equivalenti dei dati che in realtà non lo sanno può portare il test a non rilevare dei difetti.

Analisi ai valori limite

L'analisi ai valori limite consiste nel testare i valori al confine della partizione. Se per esempio un determinato input può assumere un valore numerico intero tra 10 e 90, l'analisi al valore limite consiste nel testare solamente lo '10' e il '90'. In realtà l'analisi ai valori limite per essere efficacie va fatta su 2 (valore limite e adiacente) o ancora meglio su 3 valori (valore limite, valore adiacente nel range, valore adiacente fuori range).

Un'analisi a 3 valori del range 10-90 consiste nel testare: 9, 10, 11, 89, 90, 91.

Testing della tabella delle decisioni

La tecnica della tabella delle decisioni è molto utile per testare quei comportamenti del sistema in cui diverse combinazioni di condizioni producono diversi output del sistema.

La tecnica consiste nel fare una tabella con diverse colonne dei possibili input del sistema e una colonna di output, poi sviluppare tante righe quante le possibili combinazioni.

In questo modo si testano tutte le possibili condizioni senza trascurare corner case meno probabili. Se il numero di combinazioni è molto elevato per minimizzare i tempi di test si può sviluppare una tabella delle decisioni semplificate o ancor meglio sviluppare un piano di test basato su analisi di rischio che privilegia le condizioni più significative o più probabili sul campo.

Testing delle transizioni di stato

Questa tipologia di tecnica è molto comoda quando il sistema può essere modellato come una macchina a stati in cui vengono ben definite le condizioni che generano transizioni da uno stato all'altro. Ci sono molti modi utilizzabili per testare un diagramma a stati di un sistema ma le più utilizzate sono le seguenti:

• Copertura di tutti gli stati - Il test consiste nel mandare il sistema nello stato da testare e verificare che si comporta come definito dai requisiti
• Copertura delle transizioni valide - Il test consiste nel verificare che le transizioni valide
• Copertura di tutte le transizioni - Il test consiste nell'esercitare tutte le transizioni valide e tentare di eseguire quelle non valide

Note metodologiche

Se lavori in una grande azienda che sviluppa prodotti avrai sicuramente un manuale della qualità in cui viene definito il ciclo di sviluppo del prodotto e quindi anche del software. Se invece sei in una piccola azienda o stai costruendo un team di sviluppo ti potrebbero essere utili queste indicazioni.

1. Prima di cominciare lo sviluppo bisogna definire il comportamento atteso attraverso dei requisiti. I requisiti saranno utilizzati sia dagli sviluppatori per realizzare il software sia dai validatori per sviluppare i test case.
2. I rilasci software devono essere corredati da una release note che indica sia le nuove funzionalità che i bug corretti in quel rilascio
3. Per ogni validazione è indispensabile archiviare il test plan che contiene tutte le informazioni sui test svolti e un test report che riporta i risultati del test. Vanno indicati gli oggetti testati e in quale configurazione hardware/software
4. Ogni difetto riscontrato va tracciato nel percorso di correzione. In qualsiasi momento devi poter vedere quanti bug sono stati aperti, quanti sono stati corretti dallo sviluppatore e quanti sono stati chiusi (corretti e ri-verificati dalla validazione).

Esistono dei software che possono aiutare a seguire un corretto flusso di progetto dalla gestione dei requisiti fino al tracking dei bug. Uno dei più utilizzati e semplici da portare in azienda è JIRA, software pensato per sviluppi con metodo "Agile" che però ho visto utilizzare anche su progetti "waterfall". Con JIRA è possibile gestire l'interno progetto software anche pianificando i rilasci e assegnando i task a diversi sviluppatori/validatori.