Black box testing: come,quando e perché

black box testing

Il test a scatola nera (in inglese B.B.T. Black Box Testing) e 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 ad una scatola chiusa e coperta da un telo scuro…non possiamo aprirla ne possiamo intuire cosa contenga.

Per verificarne la funzione possiamo solo osservare e osservare come reagisce ad azioni esterne. Queste azioni esterne ,nella ingegneria del software, vengono definite input. Ad ogni input il tester dovrà misurare o rilevare il conseguente effetto,(c.d. 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.

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,sia minori maggiori ma anche zero o minori di zero. 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
– 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, rappresenta il valore vuoto. Il test dei valori limite permette di evidenziare bug legati ad una non perfetta definizione delle variabili usate da 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 ed 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 ( e certificare a seconda del contest aziendale oppure del settore di mercato cui ci si rivolge) 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 modo da evidenziare eventuali bug in termini di performance ( la funzionalità e veloce nell’elaborare i dati? È sufficientemente rapida ad esporre i dati?) e di occupazione di memoria ( c.d. memory leaks).
Questo ultimo aspetto presuppone ovviamente un’ opportuna conoscenza dell’applicazione generale in cui verrà rilasciata la singola funzione oggetto di test.

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 a azioni ed output ,ma applicandovi le particolarità tipiche dell”uso 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 ad 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 ad 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, però, il black box non permette una perfetta validazione delle funzionalità sviluppate con tecnologie moderne (programmazione ad 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.