Il test a scatola nera (in inglese B.B.T. Black Box Testing) è una metodologia di test che ha come presupposto il fatto di non conoscere gli strumenti o le funzioni di codice o programma che hanno permesso l’implementazione della funzionalità in fase di verifica. Per usare un’immagine visuale pensiamo a una scatola chiusa e coperta da un telo scuro. Non possiamo aprirla ne possiamo intuire cosa contenga.
Per verificarne la funzione possiamo solo osservare come reagisce ad azioni esterne. Queste azioni, nell’ingegneria del software, vengono definite input. Ad ogni input il tester dovrà misurare o rilevare il conseguente effetto (l’output) e capire se esso rispetti la specifica convenuta, realizzi un determinato caso di test e sia funzionalmente consono ad uso e consumo dell’utilizzatore finale.
Le tipologie di input e il test dei casi limite
Gli input più comuni possono suddividersi in tre tipologie:
- importi numerici;
- date;
- azioni da tastiera o tramite altri device connessi alla applicativo o alla periferica hardware su cui esso è installato.
Per i primi due elementi normalmente occorre considerare sia valori strettamente compresi nelle specifiche e sia valori minori o maggiori di essi. Rendiamo l’ idea con un esempio: si ipotizzi di avere una maschera che preveda l’introduzione di importi. Da specifiche i valori devono essere compresi fra 1 e 100, Oltre che digitare valori compresi nell’intervallo indicato, è particolarmente utile inserire:
- il valore zero;
- valori minori di zero;
- valori maggiori di zero;
- valori superiori al massimo previsto dal tipo di dato (esempio 32767);
- valori casuali o volutamente alti o “assurdi” (es 999999999999). Verificare queste casistiche prende il nome di test dei valori limite.
Discorso analogo anche nel caso di date: qui, però, occorre prestare particolare attenzione alla data 30/12/1899, che su un database relazionale come SQL od Oracle, può rappresentare il valore vuoto. Il test dei valori limite permette di evidenziare bug legati a una non perfetta definizione delle variabili usate nel codice, pur mantenendo un approccio a scatola chiusa ossia non conoscendo nel dettaglio le query e i metodi/funzioni utilizzate dal team di sviluppo per l’implementazione della funzionalità.
Una terza famiglia di input è rappresentata dalle azioni da tastiera che possono interagire con il programma. Quelle tipiche sono ESC, TAB e INVIO. In questo caso particolare attenzione va posta a comportamenti di output che derivano da richiami doppi (esempio ho il cursore posizionato su un campo e simulo un errore dell’utilizzatore finale che in modo fortuito preme più volte i tasti funzione) anche frapposti a posizionamento manuale mouse.
Tutte queste azioni, siano esse singole oppure in sequenza, non devono mai originare comportamenti inattesi dell’applicazione, sia in termini di aderenza alle specifiche che di facilità di utilizzo e immediatezza delle informazioni, oppure più banalmente in termini di memorizzazione del dato su DB (chiavi doppie).
Una volta verificato puntualmente che il comportamento è aderente alle specifiche utente, per affermare con ragionevole sicurezza che la funzionalità oggetto di test abbia superato la fase di validazione interna, occorre mixare sapientemente questi input e aumentare gradualmente la quantità di dati introdotti. In questo modo possiamo evidenziare eventuali bug in termini di performance (la funzionalità è veloce nell’elaborare i dati ed è sufficientemente rapida a esporli?) e di occupazione di memoria (memory leaks).
Questo ultimo aspetto presuppone ovviamente un’opportuna conoscenza dell’applicazione generale in cui verrà rilasciata la singola funzione oggetto di test.
Il test esplorativo: simulare la user experience
Rientra nel test a scatola nera anche una tipologia particolare di validazioni che rientrano nella definizione di “test esplorativo“. Con esplorativo si intende una specifica tipologia di verifiche che, attraverso l’utilizzo continuo della funzionalità permette di comprenderne l’affidabilità senza peraltro avere a disposizione specifiche o altra documentazione cartacea di dettaglio.
Si tratta infatti di simulare la “user experience” ossia utilizzare l’applicazione o la funzionalità con un approccio utente senza badare ad azioni e output, ma applicandovi le particolarità tipiche delluso quotidiano: utilizzo massiccio della tastiera (pensiamo ad esempio al data entry nei settori assicurativo o bancario, alla gestione delle pratiche nelle agenzie di viaggio), uso di lettori ottici di carte (pensiamo ad esempio agli alberghi oppure alle catene della grande distribuzione), iterazione con applicativi esterni del mondo office oppure open source (pensiamo ad esempio al mondo bancario o al settore avionico).
Il black box testing rappresenta per definizione il tipico approccio di validazione adottato dal tester funzionale che, pur non avendo basi di programmazione o conoscenza di linguaggi di accesso a un database relazionale tipo T-SQL, è in grado di verificare l’aderenza alle specifiche e la copertura dei casi di test. Si rivolge quindi anche a un pubblico di professionisti assai ampio e variegato che può comprendere anche personale con lunga seniority di servizio.
Fermo restando la necessità di un costante aggiornamento professionale, il black box non permette una perfetta validazione delle funzionalità sviluppate con tecnologie moderne (programmazione a oggetti, utilizzo di librerie dinamiche, incapsulamento) oppure a contesti di tipo web o mobile (in cui è importante la comprensione dello strato sottostante al mero aspetto della maschera o al rispetto della specifica). Per questi ambiti si addice una tipologia di validazione differente che descriveremo diffusamente nel prossimo articolo.
Articoli correlati
Leggi l’articolo successivo sul white box testing.