Risposta.

Storia della domanda:

Con lo sviluppo della produzione di software di massa è emersa la necessità di controllare rapidamente e in modo qualitativo la funzionalità dei prodotti senza accesso alla loro implementazione interna. Così è nato il metodo "black box", in cui il tester lavora solo con l'interfaccia pubblica dell'applicazione.

Problema:

Senza comprendere il codice, è possibile perdere alcuni errori interni o non testare particolari ramificazioni dell'esecuzione. Tuttavia, la "black box" permette di testare dal punto di vista dell'utente e di individuare problemi dal punto di vista dell'utente.

Soluzione:

Il metodo della "black box" consiste in:

Il tester valuta gli elementi dell'interfaccia, il comportamento del programma secondo le specifiche.
Non è richiesta la conoscenza del codice o della struttura del sistema.
Vengono testati i dati di input e i risultati in output, anziché il processo di calcolo tra di essi.

Caratteristiche chiave:

Fornisce una valutazione indipendente dal punto di vista dell'utente finale
Copre solo il comportamento esterno del sistema
Non permette di verificare errori interni di implementazione

Domande insidiose.

È necessario conoscere la programmazione per il testing con "black box"?

No, non è richiesta la conoscenza del codice per applicare questo metodo, è fondamentale comprendere i requisiti funzionali.

Garantisce il metodo "black box" una copertura totale di tutti gli errori?

No, poiché non tutti gli errori possono essere rilevati tramite l'interfaccia esterna, parte dei difetti rimane nascosta senza accesso alla logica interna.

È possibile applicare solo la "black box" nel testing di servizi aziendali complessi?

No, è auspicabile combinare con altri metodi ("white box") per raggiungere la massima copertura possibile.

Errori comuni e anti-pattern

Testing solo tramite UI senza verifica dell'API
Ignorare completamente la documentazione (specifiche)
Mancanza di scenari negativi creativi

Esempio dalla vita

Caso negativo

Il tester ha controllato un'applicazione bancaria solo tramite "black box", inserendo dati standard tramite l'interfaccia e non prestando attenzione al lavoro con il saldo interno (l'API non è stata testata).

Pro:

Testing veloce secondo gli scenari utente

Contro:

Dopo il lancio si è scoperto che durante le operazioni ripetute venivano addebitati fondi in eccesso (bug interno, non evidente sulla UI)

Caso positivo

Il tester ha combinato il testing: ha prima condotto un testing funzionale con la "black box", descrivendo gli scenari utente, e poi, insieme allo sviluppatore, ha controllato l'API e i dati nel DB.