9 tipi di test del software nell’ingegneria del software

Il testing del software è un'arte. Un tester del software, come un artigiano, deve avere una solida conoscenza degli strumenti per il testing del software a sua disposizione. Abbiamo compilato un elenco di 9 diversi tipi di testing del software e degli strumenti utilizzati da ciascun tipo, per aiutare gli analisti QA e chiunque altro lavori nel settore del testing del software a comprendere meglio il proprio mestiere.

Perché abbiamo bisogno del testing del software?

A volte è importante ricordare perché ciò che si fa è importante. Il semplice fatto è che ogni software sviluppato finora che ha avuto successo lo ha ottenuto con l'aiuto dei tester del software, che hanno lavorato instancabilmente per garantire che il prodotto raggiungesse gli standard più elevati possibili. Ecco tre motivi per cui il testing del software è importante. 

1. Soddisfazione del cliente: Durante lo sviluppo di un progetto, è facile perdersi nella complessità del codice e dimenticare che anche l'utente deve essere soddisfatto del funzionamento del software. Gli analisti QA e gli altri membri del team QA svolgono proprio questo ruolo. 
2. Qualità del prodotto: Ogni professione in cui un team o un individuo crea qualcosa da zero richiede un altro team che individui i suoi errori. Gli scrittori hanno bisogno di editor. Anche i registi cinematografici hanno bisogno di editor. Gli sviluppatori software non hanno bisogno di editor, ma hanno bisogno di un team QA che fornisca un punto di vista obiettivo e individui eventuali errori. 
3. Sicurezza: Con il passare dei giorni, questo aspetto sembra diventare sempre più importante. I clienti vogliono la tranquillità di sapere che le informazioni inserite nel software e il lavoro svolto al suo interno rimangano privati. Una parte del lavoro QA consiste nel garantire che i clienti possano avere questa fiducia. 

Metodologie di testing del software

Ogni tipo di tecnica di testing del software menzionata in questo articolo appartiene a una delle due categorie principali: testing statico e testing dinamico. Prima di esaminare i dettagli specifici delle nove diverse tecniche di testing del software, spiegherò la differenza tra queste due metodologie e il punto del ciclo di sviluppo del software in cui entrano in gioco. 

Testing statico

Il testing statico è un tipo di testing del software eseguito nelle prime fasi del ciclo di sviluppo. È un modo conveniente per individuare i bug prima che diventino problemi importanti per il team di sviluppo. I test statici vengono eseguiti nelle prime fasi del ciclo di sviluppo perché possono essere effettuati senza disporre di un software completamente funzionante. Esatto, il software può essere sottoposto a debug prima ancora di essere vicino al completamento. Vedi quanto può essere utile? 

I test statici vengono eseguiti in due modi:

• Esami manuali: il codice viene analizzato da un analista QA o da un tester. 
• Analisi automatica: uno strumento di testing controlla automaticamente il documento del programma e annota eventuali errori.

Il testing statico è:

• Eseguito senza eseguire il codice.
• Conveniente.
• Utile per garantire che il software soddisfi le specifiche di verifica.
• Un modo per determinare la causa principale dei bug.

La maggior parte dei test statici viene condotta sotto forma di revisioni dei documenti. In questo scenario, un documento è una descrizione scritta di un prodotto (nota come documento di progettazione del software) oppure il codice sorgente del programma. Ecco alcune tecniche di testing statico che ogni analista QA dovrebbe conoscere:

• Revisione informale:  non esistono linee guida rigide per la revisione informale. Il team esamina i documenti di test e commenta ciò che osserva. Non viene prodotta alcuna documentazione.
• Procedura dettagliata: l'autore del codice illustra il proprio documento e il team QA pone domande e solleva dubbi. Le procedure dettagliate sono generalmente molto informali e rappresentano un buon modo per discutere gli argomenti con persone esterne al settore del software. 
• Revisione tecnica: gli esperti tecnici si riuniscono e revisionano le specifiche tecniche del codice. Eseguire questa attività nelle prime fasi del processo di sviluppo garantisce che il prodotto finale soddisfi le specifiche richieste.
• Ispezioni: la più formale di tutte le revisioni. Un team di moderatori formati ispezionerà accuratamente i documenti durante la riunione. Eventuali bug individuati verranno documentati formalmente e registrati per la revisione. Successivamente verrà effettuato un controllo per verificare che i bug documentati siano stati risolti. 

Nella maggior parte dei casi, le revisioni dei test statici sono utili perché l'intero team QA analizzerà il prodotto e proporrà modifiche basate sui problemi rilevati e sui problemi previsti. Oltre al vantaggio di coinvolgere nella conversazione un'ampia varietà di opinioni, ciò offre anche il vantaggio di aggiornare tutti i membri del team riguardo ai progressi e alla progettazione del progetto. 

Utilizzate i test statici se il vostro team:

• Si trova nelle prime fasi del processo di sviluppo.
• Cerca un modo conveniente per individuare i bug.
• Dispone di software non ancora pronto per essere eseguito.
• Vuole individuare gli errori nelle prime fasi dello sviluppo.

Test dinamici

A differenza dei test statici, i test dinamici sono un tipo di test del software che richiede l'esecuzione del codice. Naturalmente, ciò richiede che lo sviluppo sia più avanti nel ciclo di produzione. Il vantaggio di testare codice eseguibile è che gli analisti QA possono osservare il comportamento del software durante l'esecuzione in una situazione reale. È un ottimo modo per verificare il comportamento funzionale del software e altri aspetti, come l'utilizzo della CPU. I test dinamici verificano che il risultato atteso corrisponda al risultato reale. L'obiettivo principale dei test dinamici è verificare che il prodotto soddisfi i requisiti di progettazione e funzionali stabiliti prima dell'inizio del progetto.

In genere, quando il software di sistema viene sottoposto a test dinamici, sono previste quattro fasi che gli analisti QA dovrebbero conoscere:

• Test unitari: quando il software viene sottoposto a test unitari, viene suddiviso nei componenti più piccoli possibili e testato individualmente. Testando in questo modo, gli analisti QA possono avere la certezza che ogni singola parte del software funzioni come previsto. Inoltre, se viene rilevato un bug, sarà più facile correggerlo in questa fase dello sviluppo, poiché sarà possibile isolare rapidamente il codice problematico. In genere, quando il team QA inizia i test dinamici (anche se a volte questa fase viene gestita dal team di sviluppo), comincia con i test unitari.
• Test di integrazione: dopo che il software è stato completamente suddiviso nei suoi componenti e testato tramite test unitari, viene assemblato in gruppi e sottoposto nuovamente a test. Se i test unitari verificano che ogni singola parte funzioni correttamente, i test di integrazione verificano che tali parti comunichino tra loro come previsto. Pensate all'assemblaggio di un'auto. In ogni fase dell'assemblaggio, i componenti dell'auto (il motore, i pedali, il volante) vengono testati individualmente. Poi l'auto viene assemblata e testata nel suo insieme, per verificare che il pedale dell'acceleratore comunichi correttamente con il motore (e che lo facciano anche i freni!). Volete garantire un'integrazione perfetta tra i moduli? I nostri strumenti di test del software consigliati possono aiutarvi a raggiungere proprio questo obiettivo.
• Test di sistema: il test di sistema è il terzo livello dei test del software. In questa fase viene testato un software completo e pienamente integrato. Lo scopo del test di sistema è garantire che il software soddisfi i requisiti, ovvero che faccia ciò per cui è stato progettato. 
• Test di accettazione: la fase finale dei test dinamici. Il test di accettazione consiste nel verificare nuovamente la conformità ai requisiti e nell'assicurarsi che il software sia perfezionato fino a raggiungere uno standard accettabile. Viene eseguito per assicurarsi che nessun errore sia sfuggito alle altre fasi di test. In sostanza, si tratta di un doppio controllo effettuato per motivi di sicurezza. 

Fasi dei test dinamici

1. Test unitari
2. Test di integrazione
3. Test di sistema
4. Test di accettazione
   

Suggerimento rapido: test di verifica e test di convalida 

I test di verifica condividono tutte le caratteristiche principali dei test statici. Lo scopo di un test di verifica è verificare tutti i documenti e il codice, e viene raggiunto attraverso gli stessi metodi utilizzati nei test statici

Analogamente, i test di convalida condividono tutte le caratteristiche principali dei test dinamici. Un test di verifica mira a confermare che il software sia di alta qualità, che è esattamente l'obiettivo dei test di sistema e di accettazione.

Ora che abbiamo esaminato alcuni concetti chiave relativi ai test del software, esploriamo i 9 tipi di test del software che ogni analista QA dovrebbe conoscere.

9 tipi di test del software che ogni analista QA dovrebbe conoscere:

1. Scatola nera
2. Scatola bianca
3. Scatola grigia 
4. Automatizzato 
5. Unitario
6. Di regressione
7. Esplorativo
8. Test funzionali
9. Test di usabilità

1. Test della scatola nera

Il test della scatola nera è una strategia di test del software in cui il tester non conosce la progettazione del sistema software sottoposto a test.

Ricordate la scena alla fine di Pulp Fiction, quando Samuel Jackson apre la valigetta e il suo volto si illumina? Come spettatori, sappiamo cosa significa e rappresenta la valigetta nel contesto del film, ma non scopriamo mai cosa contiene. Un tester della scatola nera è come uno spettatore: sa cosa dovrebbe fare l'elemento in questione (che si tratti di una valigetta o di un sistema software), ma non sa come è stato realizzato.

Un tester incaricato di eseguire il test della scatola nera di un software per il monitoraggio del tempo aprirà il programma senza conoscere la progettazione interna del software e proverà le diverse funzionalità e i menu per assicurarsi che funzionino come previsto. Il motivo per cui si esegue il test della scatola nera è che, senza una conoscenza approfondita della progettazione del software, il tester si approccerà al software con aspettative simili a quelle dell'utente finale. 

Alcuni vantaggi del test della scatola nera sono:

• I tester non hanno bisogno di una conoscenza approfondita dei linguaggi di programmazione, perché utilizzano il software dal punto di vista dell'utente.
• Offre una valutazione imparziale del software, perché il test viene eseguito dal team QA anziché dagli sviluppatori del software.
• I tester non devono conoscere in dettaglio lo sviluppo dei sistemi software, il che significa che è necessario pochissimo tempo di preparazione prima di poter eseguire i test.

Articolo correlato: I 10 migliori strumenti per il test della scatola nera

2. Test della scatola bianca

Nel test della scatola bianca, il membro del team QA conosce completamente la struttura interna e la progettazione del software sottoposto a test. Affronterà il test come un ispettore, assicurandosi che ogni parte del programma funzioni correttamente. Il test della scatola bianca viene talvolta definito test della scatola trasparente, perché il tester osserva le interazioni tra le unità mentre testa il software. A differenza del test della scatola nera, un tester della scatola bianca non è particolarmente interessato all'esperienza dell'utente. 

Alcuni vantaggi del test della scatola bianca sono:

• I test possono essere eseguiti nelle prime fasi dello sviluppo. L'interfaccia grafica utente (GUI) non deve essere completamente funzionante. 
• I test sono più approfonditi e metodici rispetto ai test della scatola nera.

Nell'esempio di Pulp Fiction, il tester della scatola bianca è il personaggio interpretato da Tim Roth, che guarda direttamente cosa c'è dentro la valigetta. 

3. Test della scatola grigia

Nel test della scatola grigia, il tester possiede una certa conoscenza della struttura e della progettazione interna del software (scatola bianca), ma esegue comunque il test dal punto di vista dell'utente finale (scatola nera). È proprio così che è nato il test della scatola grigia. Nel test della scatola grigia, la progettazione del test viene sviluppata esaminando la struttura interna del software, mentre il test vero e proprio viene eseguito utilizzando l'interfaccia utente.

Ancora una volta, se questa fosse la famosa scena di Pulp Fiction, il tester della scatola grigia non sarebbe né il pubblico né Tim Roth. Questa volta, il tester è Quentin Tarantino in persona.  

4. Test automatizzati

I test automatizzati utilizzano software per eseguire attività senza le istruzioni manuali di un tester.

Nel test manuale, il tester scrive il codice che desidera eseguire o pianifica il percorso del software di cui vuole verificare il corretto funzionamento. I test automatizzati si occupano di questi aspetti al posto dei tester. Ecco un breve elenco di software e strumenti QA automatizzati che gli analisti QA dovrebbero conoscere:

• Selenium 
• Cucumber
• Katalon Studio

Per una recensione più approfondita degli strumenti per i test automatizzati, consulta l'elenco dei migliori strumenti per i test automatizzati che dovresti utilizzare.

5. Test unitari

Gli strumenti per i test unitari assicurano che ogni singola parte del software funzioni correttamente. È estremamente importante assicurarsi che i test unitari vengano eseguiti correttamente, altrimenti il team di sviluppo subirà una grave battuta d’arresto quando si renderà conto in seguito che una parte fondamentale del software non funziona. 

6. Test di regressione

Gli strumenti per i test di regressione eseguono i vecchi test sulle nuove build per assicurarsi che il software continui a funzionare come previsto. Eseguire test di regressione protegge gli sviluppatori dagli effetti latenti, assicurandosi che una modifica al software nel punto A non abbia accidentalmente causato un malfunzionamento in un punto molto distante, come il punto D. 

Per un analista QA, due passi avanti e uno indietro non dovrebbero essere considerati negativamente. Facendo occasionalmente un passo indietro, ci si assicura di non essere destinati a farne cinquanta indietro in seguito.

7. Test esplorativi

I test esplorativi sono adatti alle persone a cui non piace pianificare. Nella maggior parte delle altre situazioni, il caso di test viene pianificato accuratamente prima dell’esecuzione. Qui no. Quando un tester esegue un test esplorativo, esplora il software senza alcun piano predefinito, utilizzando strumenti specializzati per i test esplorativi.

Il vantaggio dei test esplorativi è che consentono al tester di adattarsi in tempo reale ai risultati ottenuti, senza dover scrivere un altro caso di test. I test esplorativi consentono inoltre di collaborare, elaborare teorie e collaborare, tutto in tempo reale.

Con la crescente diffusione della teoria agile dello sviluppo, sono diventati più diffusi anche i test esplorativi. Consentendo ai tester QA di usare il proprio intuito, vengono individuati molti bug interessanti che un’esecuzione dei test tradizionale potrebbe non aver cercato. 

Attenzione: i test esplorativi possono richiedere una grande dose di creatività. 

8. Test funzionali

I test funzionali vengono eseguiti per assicurarsi che il software di sistema corrisponda ai requisiti del progetto definiti prima dell’inizio dello sviluppo.

Il tester del software verifica che gli input corrispondano all’output previsto. Viene eseguito durante una delle fasi finali dei test, nel corso dei test di sistema o di accettazione, ed è esclusivamente una forma di test a scatola nera, poiché non si occupa di come funziona il software, purché funzioni. 

9. Test di usabilità

I tester di usabilità si assicurano che le scelte progettuali siano funzionali e intuitive.

Se prevedi che molti utenti del tuo software vorranno eseguire il backup dei propri documenti ogni mezz’ora, è meglio collocare la funzione di backup in un punto facilmente accessibile anziché nasconderla dietro quattro sottomenu. 

In molte occasioni è stato sviluppato un software che funziona perfettamente e soddisfa un’importante esigenza del mercato, ma che dal punto di vista dell’utente è completamente impossibile da navigare. Ciò può essere spiegato dalla mancanza di test di usabilità durante la fase di test del software.

In fin dei conti, per quanto un software possa essere tecnicamente valido, sarà difficile trovare un mercato se agli utenti non piace utilizzarlo.

Vuoi saperne di più?

Il settore dei test del software è in continua evoluzione e gli analisti QA devono rimanere aggiornati sulle tendenze attuali. Esistono infinite risorse sui test del software, tra cui podcast, libri, newsletter e molto altro.

Iscriviti alla newsletter di The CTO Club per ricevere aggiornamenti sui prodotti, recensioni di strumenti e altre raccolte di risorse.