Corso ISTQB — Modulo 2: Fondamenti del testing

Questo modulo copre il primo capitolo del syllabus, quello che pone le basi concettuali su cui poggia tutto il resto dell’esame. È materia tanto concettuale quanto pratica: distinzioni come quella tra verifica e validazione, o tra difetto e malfunzionamento, ritornano in moltissimi quiz e vengono sbagliate spesso, perché nel linguaggio quotidiano usiamo questi termini come fossero sinonimi. Imparare il vocabolario ISTQB con precisione qui ti fa guadagnare punti facili su tutto il compito. Il capitolo pesa parecchio sul totale, perché concentra molti obiettivi di apprendimento di livello K1/K2.

Cos’è il testing e perché lo facciamo

Molti pensano che testare significhi semplicemente eseguire il programma e guardare se funziona. In realtà è solo una piccola parte. Il testing è un insieme di attività che accompagnano l’intero ciclo di vita del software: pianificare, analizzare, progettare i casi di test, eseguirli, ma anche esaminare un documento dei requisiti per scovare ambiguità prima ancora che venga scritta una riga di codice. Per questo il testing comprende sia attività dinamiche (che richiedono l’esecuzione del software) sia attività statiche (che lavorano su documenti, modelli e codice senza eseguirlo).

Gli obiettivi del testing sono molteplici e convivono. Tra i principali:

valutare prodotti di lavoro come requisiti, storie utente e codice;
provocare malfunzionamenti e individuare difetti, così da poterli rimuovere;
verificare che i requisiti specificati siano stati soddisfatti;
confermare che l’oggetto del test si comporti come l’utente si aspetta;
accrescere la fiducia nel livello di qualità del prodotto;
fornire informazioni agli stakeholder, per decisioni consapevoli (per esempio se rilasciare o no);
ridurre il rischio che una qualità inadeguata arrivi fino in produzione;
rispettare requisiti contrattuali, legali o normativi.

Un esempio concreto: immagina un’azienda che sviluppa l’app di una catena di pizzerie per gli ordini online. Il testing serve a scovare il bug per cui il carrello somma male gli sconti (individuare difetti), ma anche a dare al responsabile di prodotto la sicurezza che il flusso di pagamento regga il venerdì sera (accrescere la fiducia e fornire informazioni per la decisione di rilascio). Gli obiettivi precisi cambiano da contesto a contesto: dipendono dal componente o sistema sotto test, dal livello di test e dal modello di ciclo di vita adottato.

Testing e debugging non sono la stessa cosa

Questa distinzione cade spesso all’esame. Il testing può mostrare che esiste un malfunzionamento causato da un difetto nel software. Il debugging, invece, è un’attività di sviluppo: localizza la causa del malfunzionamento nel codice, la analizza e la corregge. In breve: il testing dice “qui c’è qualcosa che non va”, il debugging dice “ecco da dove nasce e l’ho sistemato”.

Esempio: il tester segnala che, inserendo una data di nascita futura, l’app accetta comunque la registrazione. Questo è testing. Lo sviluppatore scopre che manca un controllo sulla data, aggiunge la validazione e ricontrolla: questo è debugging. Quando il testing è dinamico, dopo la correzione il tester eseguirà un confirmation test per verificare che il difetto sia stato effettivamente eliminato e, in genere, un regression test per accertarsi che la modifica non abbia introdotto nuovi problemi altrove.

Verifica e validazione

Altra coppia insidiosa. La verifica risponde alla domanda “stiamo costruendo il prodotto nel modo giusto?”, cioè: rispetta le specifiche e i requisiti scritti? La validazione risponde a “stiamo costruendo il prodotto giusto?”, cioè: soddisfa davvero i bisogni reali dell’utente nel suo contesto d’uso?

Si può superare la verifica e fallire la validazione: il software fa esattamente ciò che il documento dei requisiti chiede (verifica OK), ma quel documento descriveva la funzione sbagliata, così l’utente non ottiene ciò che gli serve (validazione KO). Esempio: il requisito imponeva di mostrare gli orari in formato 12 ore, lo sviluppo lo rispetta alla lettera, ma gli operatori del trasporto pubblico ragionano in formato 24 ore e trovano lo strumento inutilizzabile.

Errore, difetto e malfunzionamento (e la causa radice)

Questa è una catena causale che devi saper ricostruire a memoria:

una persona commette un errore (in inglese error o mistake): per esempio un programmatore distratto, sotto pressione di una scadenza;
l’errore introduce un difetto (defect, chiamato anche fault o bug) in un prodotto di lavoro, per esempio una riga di codice errata;
se quel difetto viene raggiunto durante l’esecuzione e si verificano le condizioni adatte, può produrre un malfunzionamento (failure): il software si comporta in modo diverso da quanto atteso.

Attenzione: non tutti i difetti producono malfunzionamenti. Un difetto in un ramo di codice che non viene mai eseguito resta latente. Inoltre, un malfunzionamento può non dipendere affatto da un difetto del software: anche condizioni ambientali (radiazioni, campi elettromagnetici, inquinamento, variazioni di temperatura) possono alterare l’esecuzione dell’hardware su cui gira il software.

La causa radice (root cause) è la ragione di fondo che ha originato l’errore. Esempio: il malfunzionamento è che la fattura mostra un’IVA errata; il difetto è un’aliquota sbagliata nel codice; l’errore è che lo sviluppatore ha frainteso la specifica; la causa radice può essere una specifica scritta in modo ambiguo o una formazione carente sul dominio fiscale. Analizzare le cause radici serve a prevenire interi gruppi di difetti futuri, non solo a tappare il singolo buco.

Quality Assurance (QA) e Quality Control (QC)

Anche qui il linguaggio comune crea confusione. Il Quality Control è orientato al prodotto: raccoglie attività che supportano il raggiungimento di livelli di qualità adeguati, e il testing è una di queste; il testing rientra quindi nel QC. La Quality Assurance è invece orientata al processo: punta a far seguire e a migliorare i processi, partendo dal presupposto che un buon processo, applicato correttamente, tenda a produrre un buon prodotto.

Esempio: introdurre la regola “ogni pull request deve essere revisionata da un secondo sviluppatore” è QA (miglioro il processo). Eseguire i casi di test sulla release candidate è QC (controllo il prodotto). Il testing contribuisce a entrambe, ma “è” parte del QC, mentre “supporta” la QA fornendo dati e informazioni sul prodotto.

I sette principi del testing

Sono quasi una garanzia di domanda d’esame. Conviene impararli con un esempio ciascuno:

1. Il testing evidenzia la presenza di difetti, ma non può dimostrarne l’assenza. Trovare difetti riduce la probabilità che ne restino di nascosti, ma nessuna quantità di test prova che non ce ne siano più.
2. Il testing esaustivo è impossibile. Provare tutte le combinazioni di input e di condizioni è impraticabile, salvo nei casi più banali. Per questo si usano analisi del rischio, priorità e tecniche di test per decidere su cosa concentrarsi.
3. Testare presto fa risparmiare. È il principio dell’early testing (lo “shift left”): più tardi si scopre un difetto, più costa correggerlo. Individuare un’ambiguità nei requisiti costa molto meno che scoprirla a sistema in produzione.
4. I difetti tendono a raggrupparsi. Di solito pochi moduli concentrano la maggior parte dei difetti rilevati prima del rilascio o causano la maggior parte dei malfunzionamenti operativi. Conviene indirizzare lì gli sforzi di test.
5. Attenzione al paradosso del pesticida. Ripetere sempre gli stessi test, alla lunga, smette di trovare nuovi difetti, proprio come un insetticida usato sempre uguale perde efficacia. I casi di test vanno perciò rivisti e arricchiti nel tempo.
6. Il testing dipende dal contesto. Si testa in modo diverso un’app di e-commerce e il software di controllo di un treno: il diverso livello di rischio cambia approccio, tecniche e intensità.
7. La fallacia dell’assenza di errori. Un software privo di difetti noti non è automaticamente buono: se non soddisfa i bisogni e le aspettative degli utenti, resta un prodotto fallito.

Il processo di test e le sue attività

Non esiste un unico processo di test valido per tutti: la sua forma dipende dal contesto. Il syllabus descrive però un insieme di gruppi di attività che ricorrono comunemente e che, pur non essendo strettamente sequenziali, possono sovrapporsi o ripetersi nel tempo:

Pianificazione del test: definire obiettivi, approccio e risorse, in coerenza con gli obiettivi di business e del progetto.
Monitoraggio e controllo: confrontare di continuo l’avanzamento reale con quanto pianificato e intervenire per riportarlo in linea; qui entrano in gioco i criteri di completamento (in inglese exit criteria o, nella terminologia agile più diffusa, definition of done).
Analisi del test: esaminare la base di test (requisiti, storie utente, rischi) per stabilire cosa testare, cioè per individuare le condizioni di test.
Progettazione del test: stabilire come testare, derivando i casi di test e individuando i dati di test necessari.
Implementazione del test: preparare tutto ciò che serve all’esecuzione (procedure di test, suite, ambiente, dati).
Esecuzione del test: lanciare i test, confrontare i risultati ottenuti con quelli attesi e registrare esiti e anomalie.
Completamento del test: raccogliere i risultati, archiviare il testware riutilizzabile, redigere un report di sintesi e capitalizzare le lezioni apprese.

Il contesto del test (modello di ciclo di vita, rischi del prodotto e del progetto, vincoli normativi, competenze del team, scadenze) influenza quali attività si svolgono e come.

Testware e tracciabilità

Il testware è l’insieme dei prodotti di lavoro generati durante il processo di test: piani di test, condizioni di test, casi di test, dati di test, procedure, script automatizzati, report e log. Sono asset che vanno gestiti, mantenuti e versionati con la stessa cura del codice.

La tracciabilità (in inglese traceability) collega tra loro gli elementi del processo: dalla base di test alle condizioni di test, dalle condizioni ai casi, dai casi ai risultati di esecuzione. Una buona tracciabilità permette di valutare la copertura (“ogni requisito è coperto da almeno un test?”), di stimare l’impatto di una modifica e di rendere il reporting comprensibile agli stakeholder. Esempio: se il requisito R-17 cambia, la matrice di tracciabilità indica subito quali casi di test rivedere.

Ruoli, competenze e indipendenza

Il syllabus distingue, in modo semplificato, due ruoli principali (nella pratica spesso assegnati alla stessa persona o sovrapposti): il ruolo di gestione del test (test management), responsabile del processo di test nel suo insieme, della pianificazione e della guida delle attività; e il ruolo di testing in senso operativo, responsabile della parte ingegneristica, cioè analisi, progettazione, implementazione ed esecuzione.

Le competenze di un buon tester non sono solo tecniche. Servono: conoscenza del dominio applicativo, padronanza degli strumenti e delle tecniche di test, ma anche soft skill come pensiero critico, attenzione al dettaglio, buona capacità di comunicazione (saper riportare un difetto senza colpevolizzare lo sviluppatore) e curiosità nello scovare i casi limite.

Infine, l’indipendenza del testing. Chi ha scritto un prodotto di lavoro tende a non vederne gli errori (è una forma di cecità da autore, dovuta anche a presupposti dati per scontati). Esistono gradi crescenti di indipendenza: dall’autore che testa il proprio lavoro, a un collega dello stesso team, a un team di test dedicato dentro l’organizzazione, fino a soggetti esterni all’organizzazione. Una maggiore indipendenza porta tipicamente a individuare difetti diversi e a un giudizio più obiettivo, ma comporta anche svantaggi: possibile isolamento dal team di sviluppo, comunicazione più lenta, eventuali attriti e rischio di colli di bottiglia. Non esiste un livello “giusto” in assoluto: la scelta dipende dal contesto e dal rischio.

Termini chiave

Testing = insieme di attività, statiche e dinamiche, volte a valutare la qualità del software e a fornire informazioni a supporto delle decisioni.
Debugging = attività di sviluppo che localizza, analizza e corregge la causa di un malfunzionamento nel codice.
Verifica = controllo che il prodotto rispetti le specifiche (“costruito nel modo giusto”).
Validazione = controllo che il prodotto soddisfi i bisogni reali dell’utente (“costruito il prodotto giusto”).
Errore = azione umana che produce un risultato non corretto.
Difetto = imperfezione in un prodotto di lavoro che può causare un malfunzionamento; sinonimi: fault, bug.
Malfunzionamento = comportamento osservato, durante l’esecuzione, diverso da quello atteso.
Causa radice = ragione di fondo all’origine di un errore; rimuoverla previene difetti analoghi.
Quality Assurance (QA) = orientata al processo, mira ad accrescere la fiducia che i requisiti di qualità saranno soddisfatti.
Quality Control (QC) = orientato al prodotto, comprende il testing tra le proprie attività.
Testware = prodotti di lavoro generati dal processo di test (piani, condizioni, casi, dati, procedure, script, report, log).
Tracciabilità = collegamento tra base di test, condizioni, casi e risultati; utile per copertura e analisi d’impatto.
Indipendenza del testing = grado di separazione tra chi produce un prodotto di lavoro e chi lo testa.

Errori comuni all’esame

Confondere testing e debugging: ricorda che il debugging è un’attività di sviluppo, non di test.
Invertire verifica e validazione: la verifica guarda alle specifiche, la validazione ai bisogni dell’utente.
Usare errore, difetto e malfunzionamento come sinonimi: la domanda chiede spesso proprio di distinguerli lungo la catena causale.
Affermare che il testing dimostra l’assenza di difetti: il principio 1 sostiene esattamente il contrario.
Ritenere che un software senza difetti noti sia di certo buono: è la fallacia dell’assenza di errori (principio 7).
Credere che il testing “sia” QA: il testing è parte del QC e contribuisce alla QA.
Pensare che più indipendenza sia sempre meglio: porta vantaggi ma anche svantaggi, e la scelta dipende dal contesto.
Confondere il paradosso del pesticida (principio 5) con il raggruppamento dei difetti (principio 4): il primo riguarda i test che invecchiano, il secondo la concentrazione dei difetti in pochi moduli.

In sintesi

Il testing è molto più della sola esecuzione: comprende attività statiche e dinamiche, con obiettivi che spaziano dall’individuare difetti all’accrescere la fiducia per le decisioni di rilascio.
Tieni ben distinte le coppie insidiose: testing/debugging, verifica/validazione, errore/difetto/malfunzionamento, QA/QC.
I 7 principi vanno saputi a memoria, ciascuno con un esempio: sono punti quasi garantiti.
Il processo di test si articola in gruppi di attività (dalla pianificazione al completamento) che dipendono dal contesto e non sono rigidamente sequenziali.
Testware e tracciabilità sono asset da gestire: permettono di misurare la copertura e l’impatto delle modifiche.
L’indipendenza migliora l’obiettività ma ha pro e contro: il livello adatto dipende dal rischio e dal contesto.