Esistono molti tipi diversi di test del software, ciascuno con obiettivi e strategie specifici:

• Test di accettazione: verifica se l'intero sistema funziona come previsto.
• Test di integrazione: garantisce che i componenti o le funzioni del software funzionino insieme.
• Test dell'unità: conferma che ogni unità software funzioni come previsto. Un'unità è il componente testabile più piccolo di un'applicazione
• Test funzionale: verifica le funzioni emulando gli scenari dell'azienda, in base ai requisiti funzionali. Il test black-box è un modo comune per verificare le funzioni.
• Test delle prestazioni: verifica le prestazioni del software quando sottoposto a diversi carichi di lavoro. Il test di carico, ad esempio, viene utilizzato per valutare le prestazioni in condizioni di carico reali.
• Test di regressione: verifica se le nuove funzioni interrompono o peggiorano la funzionalità. Il test di integrità può essere utilizzato per verificare menu, funzioni e comandi a livello superficiale, quando non c'è tempo per un test di regressione completo.
• Test di sforzo: verifica lo sforzo che può sostenere il sistema prima di riportare un errore. Viene considerato un tipo di test non funzionale.
• Test di fruibilità: valuta la facilità di utilizzo, da parte di un cliente, di un sistema o un'applicazione web per completare un'attività.

In ciascun caso, la conferma dei requisiti di base è una valutazione fondamentale. Altrettanto importante, il test esplorativo aiuta un tester o un team di test a scoprire scenari e situazioni difficili da prevedere che possono portare a errori del software.

Anche una semplice applicazione può essere soggetta a un gran numero e a una grande varietà di test. Un piano di gestione dei test aiuta ad assegnare priorità ai tipi di test che forniscono il maggior valore, dato il tempo e le risorse disponibili. L'efficacia dei test viene ottimizzata eseguendo il minor numero di test per trovare il maggior numero di difetti.

I test del software sono nati insieme allo sviluppo del software, che ha avuto inizio nel secondo dopoguerra. All'informatico Tom Kilburn è attribuita la scrittura del primo elemento di software, che è stato presentato il 21 giugno 1948, presso l'Università di Manchester in Inghilterra. Eseguiva calcoli matematici utilizzando le istruzioni del codice macchina.

Il debugging è stato il principale metodo di test a quel tempo e lo è rimasto per i due decenni successivi. Negli anni '80, i team di sviluppo hanno guardato oltre l'isolamento e la correzione dei bug del software per testare le applicazioni nelle impostazioni del mondo reale. È iniziata così la fase di una visione dei test più ampia, che comprendeva un processo di controllo di qualità come parte del ciclo di vita dello sviluppo del software.

"Negli anni '90 c'è stata una transizione dai test a un processo più completo denominato controllo di qualità, che copre l'intero ciclo di sviluppo del software e riguarda i processi di pianificazione, progettazione, creazione ed esecuzione di casi di test, supporto per casi di test esistenti e ambienti di test", afferma Alexander Yaroshko nella sua pubblicazione sul sito per sviluppatori uTest.

"I test avevano raggiunto qualitativamente un nuovo livello, che ha portato all'ulteriore sviluppo di metodologie, alla nascita di potenti strumenti per la gestione del processo di test e a strumenti di automazione dei test". ¹

Test continui

I test del software sono stati tradizionalmente separati dal resto dello sviluppo. Sono stati spesso eseguiti nella parte avanzata del ciclo di vita di sviluppo del software, dopo la fase di creazione o esecuzione del prodotto. Un tester ha solo un periodo di tempo breve per testare il codice, a volte immediatamente prima che l'applicazione venga messa sul mercato. Se vengono rilevati difetti, potrebbe esserci poco tempo per la ricodifica o un nuovo test. Non è raro rilasciare il software in tempo, ma con bug e correzioni necessarie. Oppure, un team di test può correggere gli errori ma non rispettare una data di rilascio.

Fare attività di test all'inizio del ciclo consente di mantenere il lavoro di test in primo piano piuttosto che come un'attività successiva allo sviluppo.

Molti team di sviluppo ora usano una metodologia nota come test continuo. È parte di un approccio DevOps, laddove sviluppo e operazioni collaborano per l'intero ciclo di vita del prodotto. L'obiettivo è quello di accelerare la fornitura del software, bilanciando al tempo stesso i costi, la qualità e i rischi. Con questa tecnica di test, i team non hanno bisogno di attendere che il software venga creato prima di iniziare il test. Possono eseguire i test molto prima nel ciclo per rilevare i difetti quando sono più facili da correggere.

Pochi possono contestare la necessità del controllo della qualità nello sviluppo del software. I ritardi nella consegna o i difetti del software possono danneggiare la reputazione di un marchio, creando frustrazione nei clienti e determinando il loro abbandono. In casi estremi, un bug o un difetto possono degradare sistemi interconnessi o causare gravi malfunzionamenti.

La Nissan, ad esempio, ha dovuto richiamare oltre 1 milione di auto a causa di un difetto di software nei rilevatori dei sensori degli airbag. O un bug del software che ha causato il fallimento del lancio di un satellite militare da 1,2 miliardi di dollari. ²   I numeri parlano chiaro. I malfunzionamenti del software negli Stati Uniti sono costati all'economia 1,1 trilioni di dollari in risorse nel 2016. Inoltre, hanno avuto un impatto su 4,4 miliardi di clienti. ³

Anche se i test in sé sono costosi, le aziende possono risparmiare milioni all'anno in sviluppo e supporto, se applicano una buona tecnica di test e processi di QA. Il test precoce del software rivela i problemi prima che un prodotto vada sul mercato. Prima i team di sviluppo ricevono il feedback dei test, prima possono affrontare problemi come:

• Difetti architettonici
• Decisioni di progettazione inadeguate
• Funzionalità non valide o non corrette
• Vulnerabilità di sicurezza
• Problemi di scalabilità

Quando lo sviluppo lascia ampio spazio per il test, migliora l'affidabilità del software e applicazioni di alta qualità vengono consegnate con pochi errori. Un sistema che soddisfa o addirittura supera le aspettative del cliente porta potenzialmente a più vendite e a una maggiore quota di mercato.

I test del software seguono un processo comune. Le attività o fasi includono la definizione dell'ambiente di test, lo sviluppo di casi di test, la scrittura di script, l'analisi dei risultati dei test e l'invio di report sui difetti.

I test possono richiedere molto tempo. Il test manuale o il test ad-hoc può essere sufficiente per build piccole. Tuttavia, per sistemi più grandi, vengono in genere utilizzati strumenti per automatizzare le attività. I test automatizzati consentono ai team di implementare diversi scenari, testare i differenziatori (come lo spostamento di componenti in un ambiente cloud) e ottenere rapidamente un feedback su cosa funziona e cosa no.

Un buon approccio di test include l'API (Application Programming Interface), l'interfaccia utente e i livelli di sistema. Inoltre, più i test sono automatizzati ed eseguiti presto, meglio è. Alcuni team creano strumenti di automazione dei test interni. Tuttavia, le soluzioni dei fornitori offrono funzionalità che possono semplificare le attività chiave di gestione dei test, tra cui:

• Test continui: i team di progetto testano ogni build non appena diventa disponibile. Questo tipo di test del software si basa sull'automazione del test, che è integrata nel processo di implementazione. Consente di convalidare il software in ambienti di test realistici nella prima fase del processo, migliorando la progettazione e riducendo i rischi.
• Gestione della configurazione: le organizzazioni mantengono centralmente le risorse di test e tengono traccia delle build di software da testare. I team guadagnano l'accesso a risorse quali codice, requisiti, documenti di progettazione, modelli, script di test e risultati di test. I sistemi efficaci includono l'autenticazione utente e tracce di verifica per consentire ai team di soddisfare i requisiti di conformità con il minimo sforzo di gestione.
• Virtualizzazione del servizio: gli ambienti di test possono non essere disponibili, soprattutto nelle prime fasi dello sviluppo del codice. La virtualizzazione del servizio simula i servizi e i sistemi che risultano mancanti o non ancora completati, consentendo ai team di ridurre in anticipo dipendenze e test. Possono riutilizzare, implementare e modificare una configurazione per testare i diversi scenari senza dover modificare l'ambiente originale.
• Traccia di difetti o bug: il monitoraggio dei difetti è importante sia per i team di test che per quelli di sviluppo per valutare e migliorare la qualità. Gli strumenti automatizzati consentono ai team di tenere traccia dei difetti, misurare il loro ambito e impatto e rivelare i problemi correlati.
• Metriche e report: i report e l'analytics consentono ai membri dei team di condividere stato, obiettivi e risultati dei test. Gli strumenti avanzati integrano le metriche dei progetti e presentano i risultati in un dashboard. I team controllano rapidamente l'integrità generale di un progetto e possono monitorare le relazioni tra test, sviluppo e altri elementi del progetto.