Che cosa sono i test del software?
Quando ho iniziato a lavorare in JMP, più di dieci anni fa, se mi avessero chiesto in cosa consistesse il test del software, avrei utilizzato la mia ricerca web preferita (o, in questi giorni, un assistente LLM in intelligenza artificiale) e avrei ottenuto qualcosa del genere: il test del software è il processo di valutazione di un'applicazione o di un prodotto software per garantire che funzioni come previsto e soddisfi i requisiti dell'utente.
Tuttavia, attraverso numerose discussioni con il mio collega Joseph Morgan, ho adottato una definizione di ingegneria del software, succintamente enunciata da Glenford Myers [1]:
"Il test è il processo di esecuzione di un programma con l'intento di trovare errori."
Questa definizione è così diversa? Io direi di sì. Mentre Myers et al. [1] hanno una grande discussione su questo, per la maggior parte delle persone c'è una differenza psicologica tra chiedere a qualcuno di controllare che qualcosa funzioni rispetto al cercare di romperlo. Adottando la definizione di Myers, un test engineer ha il suo obiettivo: trovare gli errori. Ciò non solo fornisce una struttura, ma trovando e correggendo questi errori (o come potremmo pensare, bug) in anticipo e in modo ponderato, il risultato è un software che funziona come previsto e soddisfa i requisiti dell'utente.
Dove sono gli insetti?
Se siete ancora con me e vi sentite a vostro agio con la definizione di testing, la domanda naturale successiva è da dove cominciare a cercare di rompere il software. Per questo possiamo rivolgerci a Boris Beizer [2]:
“Gli insetti si nascondono negli angoli e si radunano ai confini.”
Dividiamolo in due parti: tratteremo un input come una sorta di dati o informazioni che vengono forniti al software per ottenere una reazione o per fare qualcosa con tali informazioni.
I bug si raccolgono ai confini : questo sottolinea che i bug si trovano comunemente ai margini di ciò che il sistema è progettato per gestire. Ad esempio, se una funzione deve accettare input tra 0 e 1, dovremmo testare i confini (0 e 1) e anche appena al di fuori di essi.
I bug si nascondono negli angoli : questo suggerisce che i bug spesso si nascondono nelle parti di un sistema che coinvolgono più di uno degli input. Vale a dire, proprio come pensiamo alle interazioni, non troveremo un bug a meno che non testiamo queste combinazioni.
Dove andiamo adesso?
Nelle prossime settimane, sentirete i miei colleghi e me parlare di diversi argomenti correlati alla convalida (stiamo costruendo il prodotto giusto?) e al testing (trovare bug, assicurarsi che il software funzioni). Ciò che trovo particolarmente interessante è che esiste una profonda connessione tra testing e progettazione di esperimenti (un altro argomento di cui amo parlare).
Che tu stia creando le tue applicazioni, che tu stia affrontando la tua sfida di test o che tu sia semplicemente interessato a questo argomento, spero che tu continui a leggere. Ci sono argomenti che vorresti vedere trattati? Faccelo sapere nei commenti!
E poiché un blog non sembra completo senza una foto, ecco l'immagine del primo "bug informatico", come quello di parte di un team dell'Università di Harvard nel 1947, di cui faceva parte anche Grace Hopper.
Per gentile concessione del Naval Surface Warfare Center, Dahlgren, VA., 1988., Primo bug informatico, 1945 , contrassegnato come di pubblico dominio, maggiori dettagli su Wikimedia Commons
Riferimenti.
- G. Myers, C. Sandler e T. Badgett, The Art of Software Testing, 3a ed. , New Jersey, John Wiley & Sons, Inc, 2011.
- B. Beizer, Tecniche di test del software , Van Nostrand Reinhold Electrical/Computer Science and Engineering Series, 1983
Ciao @Ryan_Lekivetz !
Grazie per questa bella introduzione, non vedo l'ora di saperne di più sull'uso degli array di copertura o di altri metodi di localizzazione degli errori per testare il software.
