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 (es. test di integrazione), 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
  • 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

Documenti tipici delle attività di test:

  • piano di test
  • specifiche di test
  • report di test

Finalità del test

Validazione

Conferma (tramite esame e fornitura di evidenza oggettiva) che i requisiti particolari per uno specifico utilizzo sono stati soddisfatti. In progettazione e sviluppo, la validazione è il processo che esamina un prodotto per determinarne la conformità con le esigenze utente. [IEEE Stds Glossary]

Verifica

Conferma (tramite esame e fornitura di evidenza oggettiva) che i requisiti specificati sono stati soddisfatti.
In progettazione e sviluppo, la verifica è il processo che esamina il risultato di una attività per determinarne la conformità con i requisiti formulati per l’attività stessa. [IEEE Stds Glossary]

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 2004]

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 2004]

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 2004]

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 2004]

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 2004]

Testing condotto in un ambiente operativo reale per determinare se un sistema soddisfa i propri criteri di accettazione (ad esempio i requisiti iniziali, e le attuali esigenze dei suoi utenti) e per permettere al cliente di determinare se accettare o meno il sistema [IEEE Stds Glossary]

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 2004]

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 2004]

Test prestazionale

Il test prestazionale è specificamente effettuato per verificare che il software soddisfi i requisiti di prestazioni specificati, ad esempio i livelli di capacità di utilizzo ed i tempi di risposta. [Swebok 2004]

Test di stress

Lo stress test sollecita il software al livello massimo di carico progettato, ed oltre. [Swebok 2004]

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 2004]

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 2004]

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 2004]

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

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 2004]

Documenti tipici delle attività di test

Piano di test

Un documento che descrive l’ambito, l’approccio, le risorse e la schedulazione delle attività di testing che si intendono effettuare. Identifica gli elementi da testare, le caratteristiche da verificare, le singole attività di testing, chi le deve svolgere, e tutti i rischi che richiedono verifiche specifiche. [IEEE 829-1998]

Specifiche di test

Comprendono [IEEE 829-1998]:

  1. Specifica di progettazione del test – Un documento che specifica i dettagli dell’approccio usato per testare una caratteristica software (o un insieme di caratteristiche), ed identifica i test ad essa associati
  2. Specifica del caso di test – Un documento che specifica input, risultati previsti, ed un insieme di condizioni di esecuzione per un elemento da testare
  3. Specifica di procedura di test – Un documento che specifica una sequenza di azioni per l’esecuzione di un test.

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 2004]

Formazione sulle tecniche di analisi dei sistemi

I miei corsi di formazione: corsi.analisi-disegno.com