Fondamenti del test del software

Il test del software riguarda molti ambiti e settori. Ogni progetto presenta una nuova sfida. Prima di iniziare a testare, occorre comprendere il punto di vista del cliente e il suo settore. Inoltre, i metodi di test possono cambiare da un progetto all’altro. Una solida conoscenza dei fondamenti è quindi il primo requisito per ottenere buoni risultati.

Perché il test del software è necessario?

Durante lo sviluppo si possono introdurre per errore difetti, bug o altre imperfezioni. Il software moderno è complesso. Fraintendimenti possono quindi portare a logica e codice errati.

I test identificano i problemi così che si possano correggere e migliorare la qualità del software. L’obiettivo è sviluppare e consegnare applicazioni prive di bug. Quando un’azienda si impegna a sviluppare software per un cliente, il lavoro è guidato da requisiti legali, contrattuali e di settore. Un’azienda attenta alla qualità include i test tra le sue buone pratiche.

È difficile stabilire quanti test siano sufficienti. Una pianificazione accurata e casi di test ben progettati rendono possibile una consegna di alta qualità.

Chi esegue i test del software?

Chi dovrebbe testare il software? Gli sviluppatori spesso controllano più volte il proprio codice prima di consegnarlo. Possono comunque rimanere dei difetti, perché è difficile accorgersi dei propri errori.

Chi esegue i test adotta un punto di vista imparziale, quello del cliente, e si concentra su specifiche e requisiti. Può così scoprire problemi che lo sviluppatore non ha notato. I test dovrebbero quindi essere sempre svolti da persone indipendenti da chi ha sviluppato il software.

Separare i team di sviluppo e di test comporta anche svantaggi. Possono crearsi problemi di comunicazione. Se gli sviluppatori considerano la qualità responsabilità del team di test, possono trascurare la revisione del codice, aumentando il carico di lavoro di quel team.

A volte gli sviluppatori testano il lavoro dei colleghi. Questa pratica si chiama test tra pari, o buddy testing. Ogni team di sviluppo dovrebbe avere persone dedicate ai test. Un progetto conta in genere almeno un team di test dedicato. Alcune aziende formano team distinti per usabilità, prestazioni, sicurezza e altri tipi di test. Altre affidano il lavoro ad aziende specializzate, tester indipendenti o consulenti.

Che cosa occorre davvero testare?

Comprendi i requisiti del progetto e il contesto reale in cui verrà usato il software. Questo ti aiuta a decidere che cosa testare e a definire una strategia di test adatta.

Apri il diagramma a grandezza naturale ↗

Che cosa occorre davvero testare?

Quando si eseguono i test del software?

Iniziare presto i test aiuta gli sviluppatori a rispettare le scadenze e fa risparmiare tempo, denaro e fatica. Correggere i difetti trovati nelle ultime fasi può essere costoso. Dividi lo sviluppo in fasi e testa il lavoro di ogni fase prima di proseguire. Questo favorisce la consegna puntuale e risultati migliori. Anche l’integrazione diventa più semplice quando ogni modulo è già stato testato singolarmente rispetto alle sue specifiche.

Con quale frequenza bisogna testare?

Esegui i test in parallelo allo sviluppo e cerca di trovare il maggior numero possibile di difetti nelle prime fasi. La frequenza dei test dipende dal livello di qualità richiesto. I risultati iniziali permettono di modificare il progetto quando è più semplice ed economico farlo. Più avanti le modifiche importanti diventano difficili e costose.

Apri il diagramma a grandezza naturale ↗

Con quale frequenza bisogna testare?

Che cosa sono gli standard per il test del software?

Gli standard di test sono importanti sia per i clienti sia per chi produce software. I clienti investono nel software e vogliono essere sicuri che la sua qualità giustifichi l’acquisto.

Le aziende affidabili governano la qualità dei prodotti tramite standard riconosciuti pubblicamente. Rispettarli offre garanzie sul prodotto e sul suo comportamento atteso. I clienti possono così fidarsi del livello qualitativo del software che acquistano.

Per chi produce software, gli standard aiutano a migliorare il prodotto finale. Una volta scelti, l’azienda può riutilizzare la stessa base per i progetti successivi. Molti standard di test aiutano a valutare la qualità e a rendere i test più efficaci. Nessuno standard, però, copre tutti gli aspetti del test del software.

Possono guidare il lavoro sia gli standard che includono i test in un insieme più ampio di requisiti sia quelli pensati per i test in modo specifico.

Che cos’è la testabilità del software?

La testabilità indica quanto è facile sottoporre a test un sistema software. Valutala presto per stimare le risorse necessarie ai test. I test scoprono i difetti. La testabilità aiuta a capire dove potrebbero rimanere nascosti. Una testabilità elevata facilita i test, mentre una testabilità bassa richiede più impegno. Considera i seguenti fattori.

1. La controllabilità permette di tenere sotto controllo il processo di test e di ottimizzarlo.
2. L’osservabilità richiede che il comportamento e i fattori che influiscono sui risultati siano visibili e quindi verificabili.
3. La disponibilità significa poter accedere al sistema per testarlo.
4. Un progetto coerente, funzionalità chiare e pratiche di programmazione semplici riducono la complessità dei test. Un software più complesso è più difficile da testare.
5. La stabilità aiuta i test. Cambiamenti frequenti al progetto possono ostacolarli.
6. Le informazioni disponibili sul software influiscono molto sull’efficienza dei test.

Tieni presenti le relazioni seguenti tra testabilità e difetti.

1. Una testabilità più elevata favorisce test migliori e un numero minore di difetti.
2. Una testabilità più bassa può ridurre la qualità dei test e lasciare più difetti nel sistema.

Verifica e validazione del software

Verifica e validazione sono due tipi diversi di analisi. La validazione chiede se stai costruendo il sistema giusto. Soddisfa i requisiti del cliente?

La verifica chiede se stai costruendo correttamente il sistema. Riguarda la qualità tecnica e il rispetto degli standard richiesti.

La validazione accerta che le specifiche rispondano alle esigenze del cliente. La verifica accerta che lo sviluppo segua gli standard di qualità del software e le pratiche ingegneristiche dell’organizzazione.

Apri il diagramma a grandezza naturale ↗

Verifica e validazione del software

Alcuni approcci prevedono la verifica in ogni fase dello sviluppo ma concentrano la validazione all’inizio e alla fine, durante l’analisi dei requisiti e i test di accettazione. Nella pratica è difficile seguire questo schema. All’inizio è difficile raccogliere tutti i requisiti del cliente, che spesso cambiano dopo l’avvio dello sviluppo. Gli stessi team di sviluppo possono chiedere modifiche. Per rispondere a queste esigenze, svolgi sia la verifica sia la validazione durante tutto lo sviluppo.

Chi esegue i test ricorre alla verifica e alla validazione, o V&V, per esaminare diversi aspetti della qualità del software.

Test del software e debugging

Test e debugging hanno scopi diversi. I test fanno emergere i difetti. Il debugging interviene dopo il rilevamento di un difetto ed elimina la sua causa.

Dopo che i tester hanno segnalato un difetto, gli sviluppatori ne cercano la causa alla radice. Esaminano i moduli coinvolti, individuano il problema nel codice e lo correggono. Il debugging identifica e risolve la causa passo dopo passo.

Comprendi le possibili cause di un difetto prima di tentare una correzione. Fare debugging senza informazioni sufficienti può introdurre un altro difetto in un modulo collegato. Evita i tentativi senza metodo. Dopo la correzione, restituisci il modulo a chi esegue i test per un controllo approfondito.

1. I test fanno emergere i difetti. Il debugging ne individua e corregge le cause.
2. I test sono una parte importante dello sviluppo. Il debugging affronta i difetti messi in luce dai test.
3. I test iniziano nelle prime fasi dello sviluppo. Il debugging inizia quando si segnalano dei difetti.
4. I test comprendono la verifica e la validazione (V&V). Il debugging indaga e corregge la causa di un difetto.

Che cos’è un difetto?

Un difetto è uno scostamento dalla specifica dei requisiti del software. Può verificarsi nel codice o nel progetto e causare risultati errati quando viene eseguito il programma.

1. Il codice con molti difetti viene spesso descritto come pieno di bug.
2. Una segnalazione di bug descrive la natura di un difetto.
3. Gli strumenti di tracciamento dei bug aiutano a tenere traccia dei difetti in un sistema.
4. Una tecnica di test consiste nell’introdurre deliberatamente difetti nel codice. Si osserva poi il risultato per verificare se il sistema risponde a quei problemi come previsto.

Apri il diagramma a grandezza naturale ↗

Che cos’è un difetto?

Che cosa sono gravità e priorità?

La gravità descrive l’impatto di un difetto sul sistema. Le categorie seguenti classificano tale impatto.

1. Un difetto critico impedisce all’applicazione di funzionare correttamente a causa di un guasto del sistema o del danneggiamento dei dati. L’utente non può proseguire.
2. Con un difetto grave, il sistema può non funzionare, ma l’utente può ottenere il risultato in un altro modo, senza ulteriore formazione. Questi difetti sono meno gravi di quelli critici.
3. Con un difetto moderato, il sistema continua a funzionare ma produce risultati errati o contraddittori.
4. Un difetto lieve non causa guasti né incide sull’usabilità e può essere corretto con facilità.
5. Un difetto estetico influisce sull’aspetto del sistema.

Una segnalazione di difetto riporta sia la priorità sia la gravità. La priorità indica agli sviluppatori in quale ordine risolvere i difetti.

1. Un difetto a priorità bassa si corregge dopo quelli a priorità superiore. Non richiede attenzione immediata.
2. Un difetto a priorità media si corregge subito dopo quelli a priorità superiore.
3. Dedica attenzione immediata a un difetto a priorità alta e risolvilo al più presto.

Valuta insieme la gravità e la priorità segnalate per decidere quanto sia urgente intervenire.

Apri il diagramma a grandezza naturale ↗

Che cosa sono gravità e priorità?

1. Con priorità e gravità alte, un problema in una funzione di base impedisce all’utente di usare il sistema. Risolvilo immediatamente.
2. Con priorità alta e gravità bassa, un errore nel nome dell’azienda o un problema nel logo incide poco sul funzionamento, ma deve essere corretto subito.
3. Con gravità alta e priorità bassa, un difetto grave riguarda un modulo di cui l’utente non ha bisogno immediato. La correzione può quindi aspettare.
4. Con priorità e gravità basse, in genere si correggono per ultimi i difetti estetici che non compromettono il funzionamento.