Ho scritto la maggior parte dei test di software per computer oltre 25 anni fa. Da allora ho indicato diverse parti del libro che considero obsolete o semplicemente sbagliate. Vedi http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Puoi vedere di più (visualizzazioni attuali, ma senza riferimenti espliciti a TCS) sul mio sito per il corso di test del software Black Box (video e diapositive disponibili gratuitamente), www.testingeducation.org/BBST
La cultura dei test allora era ampiamente confermativa.
Nei test moderni, l'approccio al test unitario è ampiamente confermato: scriviamo grandi raccolte di test automatizzati che verificano semplicemente che il software continui a funzionare come previsto. I test servono come rilevatori di cambiamenti: se qualcosa in altre parti del codice e questa parte ora presenta problemi, o se i valori di dati che erano impossibili nel mondo reale stanno raggiungendo l'applicazione, allora i rivelatori di cambiamento si attivano, avvisando il programmatore di un problema di manutenzione.
Penso che la mentalità di conferma sia appropriata per i test unitari, ma immagino un mondo in cui tutti i test di sistema fossero confermativi (per le persone che fanno una distinzione, si prega di interpretare "test di integrazione del sistema" e "test di accettazione" come incluso nei miei commenti sul sistema test.) Il punto di test era confermare che il programma soddisfaceva le sue specifiche e l'approccio dominante era quello di costruire un milione di test di regressione a livello di sistema (o almeno qualche centinaio) che mappassero parti delle specifiche ai comportamenti del programma. (Penso che la conferma da specifica al comportamento sia utile, ma penso che sia una piccola parte di un obiettivo più ampio.)
Esistono ancora gruppi di test che funzionano in questo modo, ma non è più la visione dominante. Allora, lo era. Ho scritto con enfasi e ho tracciato contrasti netti per evidenziare le persone che erano costantemente addestrate in questa mentalità. Oggi, alcuni dei forti contrasti (incluso quello citato qui) sono obsoleti. Vengono interpretati erroneamente come attacchi a visioni errate.
A mio avviso, il test del software è un processo empirico per l'apprendimento delle informazioni relative alla qualità di un prodotto o servizio software.
Un test dovrebbe essere progettato per rivelare informazioni utili.
All'epoca, a proposito, nessuno parlava dei test come metodo per rivelare "informazioni". All'epoca, il test era per (alcune versioni di ...) trovare bug o per (alcune versioni di ...) verificare (verificare) il programma rispetto alle specifiche. Non credo che l'affermazione secondo cui i test servono a rivelare informazioni utili sia entrata nel vocabolario dei test fino a questo secolo.
Immagina test di valutazione in termini di valore delle informazioni. Un test che molto probabilmente ci insegnerà qualcosa che non conosciamo sul software avrebbe un valore informativo molto elevato. Un test che molto probabilmente confermerà qualcosa che già ci aspettiamo e che è già stato dimostrato molte volte in precedenza, avrebbe un basso valore informativo. Un modo per dare priorità ai test è quello di eseguire test con valori di informazioni più alti prima di test con valori di informazioni più bassi.
Se dovessi semplificare eccessivamente questa prioritizzazione in modo da attirare l'attenzione di un programmatore, project manager o responsabile di processo che non ha idea dei test del software, direi "UNA PROVA CHE NON È PROGETTATA PER RIVELARE UN ERRORE È UN RIFIUTO DEL TEMPO ". Non è una traduzione perfetta, ma per i lettori che non possono o non capiscono alcuna sottigliezza o qualifica, è il più vicino possibile.
Allora, e lo vedo di nuovo qui, alcune persone che non capiscono i test risponderebbero che un test progettato per trovare casi angolari è una perdita di tempo rispetto a un test di un uso importante di una funzione principale. Non capiscono due cose. In primo luogo, quando i tester del tempo trovano il tempo per controllare i valori limite, gli usi principali delle funzioni principali sono già stati esercitati più volte. (Sì, ci sono eccezioni e la maggior parte dei gruppi di test presterà particolare attenzione a tali eccezioni.) In secondo luogo, il motivo per testare con valori estremi è che il programma ha maggiori probabilità di fallire con valori estremi. Se non fallisce all'estremo, prova qualcos'altro. Questa è una regola efficiente. D'altra parte, se fallisce a un valore estremo, il tester potrebbe arrestarsi e segnalare un bug o il tester potrebbe risolvere ulteriormente, per vedere se il programma fallisce allo stesso modo con valori più normali. Chi esegue la risoluzione dei problemi (tester o programmatore) è una questione di cultura aziendale. Alcune aziende prevedono un budget per il tempo del tester, alcune programmano i programmatori e alcune si aspettano che i programmatori correggano i bug del caso angolare se sono generalizzabili o meno in modo che la risoluzione dei problemi non sia rilevante. Il malinteso comune - che i tester stanno perdendo tempo (piuttosto che massimizzare l'efficienza) testando valori estremi è un'altra ragione per cui "Un test che non è progettato per rivelare un bug è una perdita di tempo" è un messaggio appropriato per i tester. È un contrappunto all'incoraggiamento di alcuni programmatori a (in effetti) non eseguire mai test che potrebbero sfidare il programma. Il messaggio è semplificato, ma l'intera discussione è semplificata.
A proposito, il "valore informativo" non può essere l'unico sistema di definizione delle priorità. Non è mia regola progettare suite di test unitari. Non è la mia regola quando progetto test di verifica della costruzione (ovvero controlli di integrità). In entrambi i casi, sono più interessato ai tipi di copertura che alla potenza dei singoli test. Esistono altri casi (ad esempio test automatizzati ad alto volume che sono economici da installare, eseguire e monitorare) in cui la potenza dei singoli test è semplicemente irrilevante per il mio progetto. Sono sicuro che puoi pensare ad altri esempi.
Ma come regola generale, se potessi dichiarare solo una regola (ad esempio parlare con un dirigente la cui testa esplode se tenta di elaborare più di una frase), sarebbe che un test a basso valore di informazione di solito è una perdita di tempo.