Parlando di testing, accade spesso che non ci sia accordo sul significato delle parole. I termini usati nel campo della disciplina del testing sono tanti, e sono molte anche le possibilità di confusione.
Nel seguito, alcuni tra i termini più comuni, tratti da riferimenti autorevoli a livello internazionale:
- [Swebok] – Software Engineering Body of Knowledge 3.0 (SWEBOK), pubblicato dalla IEEE Computer Society
- [ISO/IEC/IEEE 29119-1:2022] – Standard for Software Testing
- [Kaner Bach 2005] – Cem Kaner, James Bach: Black Box Software Testing – Fall 2005 – Overview for Students
Nota: in alcuni casi si è preferito utilizzare due definizioni per un singolo termine, perché ciascuna ne mette in luce un aspetto in modo più chiaro. Le due definizioni vanno quindi intese come complementari, non come alternative.
Questo mini glossario è organizzato per macro argomenti, che contengono le voci individuali.
Poiché a volte vengono usati anche termini inglesi, tali termini sono riportati dopo quelli italiani.
- validazione
- verifica
- test unitari – unit test
- test di integrazione – integration test
- test di sistema – system test
Livello di effettuazione dei test:
- alpha test
- beta test
- test di accettazione – acceptance test
- test funzionali e non funzionali
- test di usabilità
- test prestazionale – performance test
- test di carico (load)
- stress test
- test di installazione
- test a scatola nera – black box test
- test a scatola trasparente – glass box test
- test di regressione – regression test
- testing guidato – scripted
- testing esplorativo
Documenti tipici delle attività di test:
- piano di test
- specifiche di test
- report di test
Finalità del test
La verifica e la validazione sono processi distinti, che utilizzano entrambi il testing come pratica importante
- La verifica si concentra sulla conformità dell’elemento testato alle specifiche, ai requisiti specificati o ad altri documenti
- La validazione si concentra sull’accettabilità dell’elemento testato per soddisfare le esigenze delle parti interessate
[ISO/IEC/IEEE 29119-1:2022]
Oggetto dei test
Test unitari
Il testing di unità verifica il funzionamento isolato delle parti software che sono testabili separatamente. In funzione del contesto, le parti testate possono essere singoli moduli, oppure un componente di dimensioni maggiori, costituito da unità strettamente correlate tra loro. Tipicamente, il testing di unità viene effettuato con accesso al codice testato e con il supporto di strumenti per il debugging. [Swebok]
Il testing a livello unitario è focalizzato su unità isolate del prodotto (moduli, classi, funzioni). [Kaner Bach 2005]
Test di integrazione
Il testing di integrazione è il processo di verifica dell’interazione tra componenti software. Le strategie classiche di test di integrazione, top-down o bottom-up, vengono utilizzate con il software tradizionale, strutturato in modo gerarchico. Le strategie moderne di integrazione sistematica sono invece guidate dall’architettura, cioè i componenti e sottosistemi software vengono integrati sulla base delle funzionalità identificate.
Il testing a livello di integrazione è un’attività continuativa. Tranne i casi di software molto piccoli e semplici, le strategie di test di integrazione sistematiche ed incrementali sono da preferire rispetto alla strategia di mettere tutti i componenti insieme nello stesso momento, in quello che viene chiamato “big bang” testing. [Swebok]
I test di integrazione verificano come due (o più) unità lavorano insieme. [Kaner Bach 2005]
Test di sistema
Il testing a livello di sistema si preoccupa del comportamento di un sistema nel suo complesso. La maggior parte degli errori dovrebbe essere già stato identificato durante il testing unitario e di integrazione. Il test di sistema viene di solito considerato appropriato per verificare il sistema anche rispetto ai requisiti non funzionali, come quelli di sicurezza, velocità, accuratezza ed affidabilità. A questo livello vengono anche testate le interfacce esterne nei confronti di altre applicazioni, componenti standard, dispositivi hardware e ambiente operativo. [Swebok]
Livello di effettuazione dei test
Alfa e Beta test
Prima che il software venga rilasciato, viene a volte reso disponibile per un utilizzo di prova ad un gruppo, limitato ma rappresentativo, di utenti potenziali. Ciò può accadere presso gli sviluppatori (alpha testing) o presso gli utilizzatori (beta testing). Gli utenti che partecipano al test segnalano i problemi riscontrati nell’utilizzo del prodotto. Alpha e beta test sono spesso svolti in modo poco controllato, e non vengono sempre esplicitati nel piano di test. [Swebok]
Test di accettazione
Il testing di accettazione controlla il comportamento del sistema rispetto ai requisiti (comunque espressi) del committente. I clienti effettuano, o specificano, attività tipiche di uso del sistema, per controllare che i loro requisiti siano stati soddisfatti. Questa attività di test può coinvolgere o meno gli sviluppatori del sistema. [Swebok]
Aspetti sottoposti a test
Test funzionali e non funzionali
Possono essere progettati dei casi di test per verificare che le specifiche funzionali siano state implementate correttamente. Queste tipologie di test sono chiamate in letteratura test di conformità, o test di correttezza, o test funzionale. In ogni caso, possono essere testate anche numerose altre proprietà non funzionali, tra cui le prestazioni, l’affidabilità e l’usabilità. [Swebok]
Il test funzionale è un tipo di test comportamentale (cioè focalizzato sul comportamento osservabile del prodotto) che guarda al sistema come ad una collezione di funzioni. Chi effettua i test funzionali potrebbe focalizzarsi esclusivamente sulla presenza e l’affidabilità delle funzioni, tralasciando le caratteristiche non funzionali, come usabilità, scalabilità, mantenibilità, velocità, sicurezza, adattabilità a condizioni locali, esigenze di supporto, eccetera. [Kaner Bach 2005]
Test di usabilità
Il test di usabilità valuta la facilità di uso e di apprendimento del software da parte degli utilizzatori finali. Vengono presi in considerazione la documentazione per l’utente, l’efficacia di funzionamento del software nel supportare le attività dell’utente, le possibilità che il software offre all’utente di porre rimedio ai propri errori. [Swebok]
Test di accessibilità
Tipo di testing di usabilità che serve a misurare il grado in cui l’elemento testato può essere usato da utenti con la più ampia gamma possibile di caratteristiche e abilità. [ISO/IEC/IEEE 29119-1:2022]
Test prestazionale
Tipo di testing condotto per valutare il grado in cui l’elemento testato svolge le sue funzioni entro determinati vincoli di tempo e altre risorse. [ISO/IEC/IEEE 29119-1:2022]
Test di carico (load)
Tipo di testing delle prestazioni condotto per valutare il comportamento dell’elemento testato in condizioni previste di carico variabile, solitamente tra utilizzo basso, tipico e di picco. [ISO/IEC/IEEE 29119-1:2022]
Test di stress
Tipo di testing prestazionale condotto per valutare il comportamento dell’elemento testato in condizioni di carico superiori ai requisiti previsti, o di disponibilità delle risorse al di sotto dei requisiti minimi specificati. [ISO/IEC/IEEE 29119-1:2022]
Test di installazione
Il test di installazione consiste nella verifica dell’installazione del software nell’ambiente operativo di destinazione (effettuata di solito dopo la conclusione dei test di accettazione). Il test di installazione può essere visto come un test di sistema condotto in conformità con i requisiti di configurazione hardware. [Swebok]
Modalità di test
Test a scatola nera
Il test è a scatola nera se ci si basa solo sul comportamento riscontrabile analizzando input ed output. [Swebok]
Chi effettua test a scatola nera lavora senza conoscere il codice. Progetta il test a partire dalla specifica (se esiste) e dalla propria conoscenza dei bisogni e delle caratteristiche degli utenti del prodotto, del dominio in cui si opera, dell’ambiente hardware / software e di altri rischi. [Kaner Bach 2005]
Test a scatola bianca (o trasparente)
Il test è a scatola bianca (white-box) se si basa su informazioni relative a come il software è stato progettato o codificato. [Swebok]
Chi effettua test a scatola trasparente (glass-box) lavora conoscendo il codice. Agisce come un programmatore, che diventa esperto nell’implementazione del prodotto testato o nell’implementazione delle relazioni del prodotto con il mondo esterno. [Kaner Bach 2005]
Test di regressione
Test eseguiti a seguito di modifiche all’elemento testato o al suo ambiente operativo, per identificare se si verificano guasti nelle parti non modificate dell’elemento testato. [ISO/IEC/IEEE 29119-1:2022]
Il test di regressione consiste nella riesecuzione selettiva di test su un sistema o un componente modificato, per verificare che le modifiche non abbiano provocato effetti indesiderati. In pratica, l’idea è di dimostrare che il software che aveva passato i test prima delle modifiche continua a farlo anche dopo.
Naturalmente è necessario un bilanciamento tra il livello di assicurazione fornito dall’esecuzione dei test di regressione per ogni singolo cambiamento ed il consumo di risorse necessario per eseguirla. Il test di regressione può essere effettuato ad ognuno dei livelli di test (unitario, di integrazione, di sistema), sia per gli aspetti funzionali che per quelli non funzionali. [Swebok]
Testing guidato (scripted)
Testing eseguito sulla base di uno script di test documentato in precedenza. [ISO/IEC/IEEE 29119-1:2022]
Testing esplorativo
Testing in cui un tester con esperienza progetta ed esegue test basati sulle proprie conoscenze, previa esplorazione dell’elemento da testare (inclusi i risultati di test precedenti) e “regole empiriche” euristiche riguardanti comportamenti software e tipi di errore comuni. [ISO/IEC/IEEE 29119-1:2022]
Documenti tipici delle attività di test
Piano di test
Descrizione dettagliata degli obiettivi di test da raggiungere e dei mezzi e dei tempi per raggiungerli, organizzati per coordinare le attività di testing.
Un progetto può avere più di un piano di test, ad esempio un piano di test per il progetto (“master test plan”) che comprende tutte le attività di testing; poi altri piani di test particolari (ad esempio un piano di test di sistema o un piano di test delle prestazioni).
[ISO/IEC/IEEE 29119-1:2022]
Specifiche di test
Documentazione completa del test design, dei casi di test e delle procedure di test per uno specifico elemento da testare.
Una specifica di test può essere dettagliata in un documento, in un insieme di documenti o in altro modo, ad esempio in una combinazione di documenti e voci di database.
Può assumere la forma di una procedura (per l’esecuzione manuale) o di uno script automatico (per l’esecuzione automatica).
[ISO/IEC/IEEE 29119-1:2022]
Rapporto di esecuzione dei test
Le attività di testing possono essere inserite in un log di test per identificare quando un test è stato eseguito, chi lo ha eseguito, quale configurazione software è stata usata per il test, ed altre informazioni rilevanti.
Risultati di test non previsti o scorretti possono essere registrati in un sistema di reporting dei problemi, i cui dati costituiscono la base per il successivo debugging e per la correzione dei problemi che erano stati riscontrati come errori durante il testing. Inoltre potrebbe essere utile registrare anche anomalie non classificabili come errori, nell’ipotesi che ad un successivo esame risultino più serie di quanto sembrava. I report di test sono anche input al processo di gestione delle richieste di cambiamento. [Swebok]
Formazione sulle tecniche di analisi dei sistemi
Corso: Test di sistema e di accettazione
Tutti i miei corsi di formazione: corsi.analisi-disegno.com