Corso ISTQB — Modulo 5: Tecniche black-box: equivalenza, valori limite, tabelle delle decisioni e transizioni di stato

Le tecniche black-box (dette anche tecniche basate sulle specifiche) sono fra gli argomenti su cui l’esame CTFL torna con maggiore frequenza, sia con domande teoriche sia con piccoli esercizi di calcolo. Il nome è già una guida: i casi di test si progettano osservando che cosa il software deve fare (input previsti, output, comportamenti descritti nei requisiti), senza esaminare come è realizzato internamente il codice. La “scatola” resta chiusa: conta solo l’interfaccia visibile dall’esterno.

In questo modulo affrontiamo le quattro tecniche che il syllabus v4.0 chiede di conoscere e saper applicare al livello Foundation: il partizionamento di equivalenza, l’analisi dei valori limite, le tabelle delle decisioni e il test delle transizioni di stato. Per ciascuna proponiamo un esempio numerico svolto passo passo, perché all’esame non basta riconoscere una definizione: spesso occorre contare quante classi o quanti valori limite servono, oppure interpretare correttamente una tabella.

Il principio comune: ridurre i test mantenendo la copertura

Tutte queste tecniche rispondono allo stesso problema pratico. Immaginiamo un campo che accetta un numero intero da 1 a 100: provare uno per uno tutti i valori (più quelli fuori intervallo) sarebbe dispendioso e di scarsa utilità. Le tecniche black-box offrono un criterio razionale per selezionare pochi input capaci di rappresentare molti casi, in modo da aumentare le probabilità di individuare difetti con il minor numero possibile di casi di test.

Un concetto trasversale è la copertura: per ogni tecnica esiste un modo di misurare quanta parte del modello è stata esercitata (quante classi sono coperte, quante transizioni percorse). Di norma la copertura si esprime in percentuale, come rapporto fra gli elementi coperti e il totale degli elementi da coprire.

Partizionamento di equivalenza (equivalence partitioning)

L’idea è suddividere l’insieme dei possibili valori di input (o di output) in classi (o partizioni) di equivalenza: gruppi di valori che il software dovrebbe trattare allo stesso modo. Il presupposto è che, se un valore di una classe rivela un difetto, è plausibile che lo rivelino anche gli altri valori della stessa classe; e che se uno è gestito correttamente, lo siano anche gli altri. Per questo è sufficiente provare un solo rappresentante per ciascuna classe.

Le classi si distinguono in valide (valori che il sistema deve accettare ed elaborare correttamente) e non valide (valori che il sistema deve respingere o trattare come errore). Indicazione utile per l’esame: i rappresentanti di più classi valide possono talvolta essere combinati in un unico caso di test, mentre ogni classe non valida va verificata in un caso separato, così che un input scorretto non finisca per mascherare la gestione di un altro.

Esempio svolto. Un negozio online applica uno sconto in funzione della quantità di pezzi acquistati di un articolo, secondo questa regola:

quantità da 1 a 9: nessuno sconto;
quantità da 10 a 49: sconto del 5%;
quantità da 50 a 100: sconto del 10%;
quantità massima ammessa: 100.

Il campo accetta numeri interi. Individuiamo le classi sulla dimensione “quantità”:

C1 (non valida): quantità inferiore a 1 (es. 0 o numeri negativi);
C2 (valida): da 1 a 9 → nessuno sconto;
C3 (valida): da 10 a 49 → sconto 5%;
C4 (valida): da 50 a 100 → sconto 10%;
C5 (non valida): quantità superiore a 100.

Abbiamo 5 classi. Per coprirle tutte (100%) basta scegliere un rappresentante per ciascuna, ad esempio: 0, 5, 30, 75, 150. Cinque casi di test coprono così un numero virtualmente illimitato di input. Se il campo accettasse anche caratteri, “input non numerico” costituirebbe un’ulteriore classe non valida da verificare a parte (es. “abc”).

La copertura si calcola come classi coperte / classi totali. Provando solo 0, 5 e 30 copriremmo 3 classi su 5, cioè il 60%.

Analisi dei valori limite (boundary value analysis)

L’esperienza mostra che i difetti tendono a concentrarsi ai bordi degli intervalli: un classico è usare maggiore al posto di maggiore o uguale, oppure sbagliare di una unità (errore “off-by-one”). L’analisi dei valori limite completa il partizionamento di equivalenza: una volta individuate le classi dotate di un ordinamento (intervalli numerici, date, lunghezze), si verificano i valori posti sui confini di tali classi. È applicabile solo a partizioni i cui valori possono essere ordinati.

Il syllabus v4.0 descrive due varianti che occorre saper applicare.

Analisi a 2 valori

Per ciascun confine si considerano due valori: il valore che sta sul limite e il valore immediatamente adiacente che cade nella classe vicina. In sostanza, per ogni bordo si prendono i due valori più prossimi che appartengono a classi diverse.

Esempio svolto (variante a 2 valori). Riprendiamo lo sconto e concentriamoci sulla classe C3 “da 10 a 49”. I suoi confini sono 10 (limite inferiore) e 49 (limite superiore).

Confine inferiore (10): si verificano 9 e 10 (9 appartiene a C2, 10 a C3);
Confine superiore (49): si verificano 49 e 50 (49 appartiene a C3, 50 a C4).

Per questa sola classe la variante a 2 valori genera 4 test di confine: 9, 10, 49, 50. Estendendo l’analisi all’intero sistema si esaminano anche i bordi a 1 (con 0 e 1) e a 100 (con 100 e 101).

Analisi a 3 valori

Più rigorosa: per ogni confine si considerano tre valori, cioè il valore sul limite e i due valori immediatamente adiacenti (uno appena prima e uno appena dopo). Si esercitano quindi il limite stesso e i suoi vicini da entrambi i lati.

Esempio svolto (variante a 3 valori). Sempre sulla classe C3 “da 10 a 49”:

Confine inferiore 10: si verificano 9, 10, 11;
Confine superiore 49: si verificano 48, 49, 50.

Per questa classe la variante a 3 valori genera 6 test: 9, 10, 11, 48, 49, 50. Questa variante può intercettare alcuni difetti che quella a 2 valori non rileva (ad esempio una condizione errata proprio sul valore interno adiacente al bordo), al prezzo di un numero maggiore di casi di test.

Suggerimento d’esame: i valori limite hanno senso solo per classi ordinabili. Per una partizione come “input non numerico” non esiste un confine da analizzare.

Tabelle delle decisioni (decision tables)

Quando il comportamento del software dipende da combinazioni di condizioni, classi ed intervalli non bastano: serve uno strumento che renda esplicite le combinazioni rilevanti e le azioni che ne conseguono. È ciò che fa la tabella delle decisioni, strutturata in:

condizioni: gli input o gli stati che influenzano la decisione (spesso espressi come vero/falso);
azioni: gli output o i comportamenti del sistema;
regole: le colonne, ciascuna delle quali associa una combinazione di valori delle condizioni alle azioni risultanti.

Con n condizioni booleane le combinazioni teoriche sono 2 elevato a n. La copertura minima richiede almeno un caso di test per ogni regola (colonna) della tabella.

Esempio svolto. Una banca online concede l’accesso all’area riservata in base a due condizioni: credenziali corrette e account bloccato. Le azioni possibili sono concedi accesso e mostra errore. Con 2 condizioni booleane abbiamo 2² = 4 regole:

Regola 1: credenziali corrette = V, account bloccato = F → azione: concedi accesso;
Regola 2: credenziali corrette = V, account bloccato = V → azione: mostra errore;
Regola 3: credenziali corrette = F, account bloccato = F → azione: mostra errore;
Regola 4: credenziali corrette = F, account bloccato = V → azione: mostra errore.

Dalla tabella ricaviamo 4 casi di test, uno per colonna. Osserviamo un dettaglio importante: nelle regole 3 e 4 le credenziali sono già errate, quindi il valore della condizione “account bloccato” diventa irrilevante ai fini dell’azione. Le tabelle delle decisioni consentono di marcare questi casi con un trattino (“non interessa”, spesso indicato con “—” o “N/A”) e di fondere le regole equivalenti. Le regole 3 e 4 si fondono in un’unica regola “credenziali = F → mostra errore”, riducendo la tabella collassata a 3 regole. All’esame può capitare di dover scegliere se ragionare sulla tabella completa (tutte le combinazioni) o sulla tabella collassata.

Test delle transizioni di stato (state transition testing)

Alcuni sistemi rispondono in modo diverso a seconda dello stato in cui si trovano: lo stesso input produce esiti differenti in base a ciò che è avvenuto in precedenza. Si pensi a un tornello, a uno sportello automatico o a un ordine che evolve da “in attesa” a “pagato” a “spedito”. Per questi casi si ricorre a un diagramma (o tabella) delle transizioni di stato, composto da:

stati: le situazioni in cui il sistema può trovarsi;
eventi: gli stimoli che possono provocare un cambiamento;
transizioni: i passaggi da uno stato a un altro innescati da un evento;
azioni: ciò che il sistema produce durante una transizione (elemento opzionale).

Esempio svolto. Un servizio di streaming gestisce un abbonamento con tre stati: Attivo, Sospeso, Cancellato. Gli eventi sono: pagamento ricevuto, pagamento fallito, richiesta di disdetta.

Da Attivo, se il pagamento fallisce → passa a Sospeso;
Da Attivo, se l’utente disdice → passa a Cancellato;
Da Sospeso, se arriva un pagamento → torna ad Attivo;
Da Sospeso, se l’utente disdice → passa a Cancellato;
Da Cancellato nessun evento riattiva l’abbonamento (stato finale).

Da questo modello si possono progettare test a diversi livelli di copertura. Il syllabus distingue in particolare:

Copertura di tutti gli stati: i test devono far raggiungere almeno una volta ciascuno stato (Attivo, Sospeso, Cancellato).
Copertura di tutte le transizioni valide (nota anche come copertura 0-switch): ogni transizione prevista dal modello deve essere percorsa almeno una volta. È il criterio comunemente adottato ed è più forte della sola copertura degli stati.

Punto frequente d’esame: coprire tutti gli stati non garantisce di coprire tutte le transizioni. Si possono attraversare tutti e tre gli stati con un unico percorso (Attivo → Sospeso → Cancellato) lasciando però non verificate transizioni come “Sospeso → Attivo”. Le transizioni non previste dal modello (per esempio tentare un pagamento su un account Cancellato) costituiscono materiale per i test negativi.

Termini chiave

Tecnica black-box = metodo di progettazione dei test fondato sulle specifiche e sul comportamento esterno del software, senza considerarne la struttura interna.
Classe (partizione) di equivalenza = insieme di valori di input (o output) che il sistema dovrebbe trattare allo stesso modo, tanto da rendere sufficiente provarne un solo rappresentante.
Classe valida / non valida = gruppo di valori che il sistema deve rispettivamente accettare ed elaborare correttamente, oppure respingere o trattare come errore.
Valore limite = valore posto sul confine di una classe ordinabile, dove i difetti tendono a presentarsi più spesso.
Analisi a 2 valori = per ogni confine verifica il valore sul limite e quello immediatamente adiacente appartenente alla classe vicina.
Analisi a 3 valori = per ogni confine verifica il valore sul limite e i due valori adiacenti, uno per lato.
Tabella delle decisioni = strumento che mette in relazione combinazioni di condizioni con le azioni attese, organizzato in regole (colonne).
Regola (di una tabella delle decisioni) = una specifica combinazione di valori delle condizioni con le azioni che ne derivano.
Condizione “non interessa” = condizione il cui valore non incide sull’azione risultante; consente di fondere regole equivalenti.
Diagramma delle transizioni di stato = modello composto da stati, eventi, transizioni ed eventuali azioni, impiegato per software il cui comportamento dipende dallo stato corrente.
Copertura delle transizioni (0-switch) = criterio che richiede di percorrere almeno una volta ogni transizione valida del modello.

Errori comuni all’esame

Riunire più input non validi in un unico test. Le classi non valide vanno verificate una per volta, altrimenti un errore può nasconderne un altro. I rappresentanti delle classi valide, invece, possono essere combinati.
Confondere le due varianti di analisi dei valori limite. A 2 valori sono due punti per confine, a 3 valori sono tre. Se il testo non lo specifica, leggere con attenzione cosa chiede la domanda: il numero di casi cambia.
Applicare i valori limite a classi non ordinabili. Per categorie come “tipo di pagamento” o “input non numerico” non esistono confini: in questi casi si usa solo l’equivalenza.
Tralasciare il valore sul limite. Nell’analisi dei valori limite il bordo va sempre incluso, non soltanto i suoi vicini.
Contare male le regole di una tabella delle decisioni. Con n condizioni booleane le combinazioni complete sono 2 elevato a n; va considerata anche l’eventuale tabella collassata.
Ritenere che coprire tutti gli stati copra tutte le transizioni. Sono due criteri distinti: la copertura delle transizioni è più forte e va verificata a parte.
Pensare che le tecniche black-box richiedano di leggere il codice. Per definizione lavorano sulle specifiche; la struttura interna riguarda le tecniche white-box.

In sintesi

Le tecniche black-box progettano i test a partire dalle specifiche, riducendo il numero di casi senza compromettere la copertura del comportamento atteso.
Il partizionamento di equivalenza suddivide gli input in classi valide e non valide e prova un rappresentante per classe; le classi non valide si verificano separatamente.
L’analisi dei valori limite rafforza l’equivalenza esaminando i confini: due valori per confine nella variante a 2, tre valori nella variante a 3.
Le tabelle delle decisioni gestiscono le combinazioni di condizioni: con n condizioni booleane si hanno 2 elevato a n regole, riducibili fondendo le condizioni irrilevanti.
Il test delle transizioni di stato modella sistemi dipendenti dallo stato; coprire tutti gli stati non equivale a coprire tutte le transizioni.
Saper contare classi, valori limite e regole è importante quanto conoscerne le definizioni: gli esercizi numerici sono ricorrenti.