Glossario del Testing

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:

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.

Finalità del test:

  • validazione
  • verifica

Oggetto sottoposto al test:

  • 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

Aspetti sottoposti a test:

  • test funzionali e non funzionali
  • test di usabilità
  • test prestazionale – performance test
  • test di carico (load)
  • stress test
  • test di installazione

Modalità di test:

  • 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