Una cosa che non riesco a trovare da nessuna parte è: questo approccio è limitato al software non critico? Perché in situazioni critiche (o solo quando il cliente vuole che noi seguiamo le sue regole) non abbiamo alcuna libertà di test e seguiamo semplicemente le procedure. Ho ragione?
Dipende da cosa intendi per "libertà".
Il test non riguarda necessariamente la "libertà". I test servono a scoprire se il software fa quello che dovrebbe fare. Nella maggior parte dei "contesti", ciò significa determinare se il software soddisfa i requisiti del cliente. Quindi qualsiasi test che si verifica sarà "guidato" da quell'obiettivo, e qualsiasi test che non porti avanti tale obiettivo è una perdita di tempo. Questo è vero indipendentemente dalla metodologia di test utilizzata.
In alcune metodologie di test come TDD, i test stessi fanno parte dei requisiti. Ogni test identifica un requisito e il superamento di tale test verifica che il requisito sia soddisfatto.
Quindi esaminiamo in particolare alcune delle attività suggerite da Context-Driven Test :
I test vengono eseguiti per conto degli stakeholder al servizio dello sviluppo, della qualificazione, del debugging, dell'indagine o della vendita di un prodotto.
Gli artefatti dei test valgono [solo] nella misura in cui soddisfano i requisiti pertinenti dei loro stakeholder.
Il valore di qualsiasi pratica [di test] dipende dal suo contesto.
Consider two projects:
One is developing the control software for an airplane. What “correct behavior” means is a highly technical and mathematical subject. FAA regulations must be followed. Anything you do — or don’t do — would be evidence in a lawsuit 20 years from now. The development staff share an engineering culture that values caution, precision, repeatability, and double-checking everyone’s work.
Another project is developing a word processor that is to be used over the web. “Correct behavior” is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters — 20 months from now, it will all be over, for good or ill. The development staff decidedly do not come from an engineering culture, and attempts to talk in a way normal for the first culture will cause them to refer to you as “damage to be routed around”.
Testing practices appropriate to the first project will fail in the second.
Practices appropriate to the second project would be criminally negligent in the first.
Come puoi vedere, il Test guidato dal contesto si adatta al progetto, non viceversa. Ma questo non dovrebbe sorprendere, dato che tutti i test del software sono (o dovrebbero essere) per dimostrare che le aspettative dei clienti sono soddisfatte, non per conformarsi ad una metodologia arbitraria solo perché.
Test basati sul contesto sono meno relativi a una metodologia, e altro su alcune linee guida e principi che guidano tutti i test. Fondamentalmente dice che le tue metodologie di test, il tuo rigore, la tua cultura di testing, sono tutti basati sulla natura, il carattere e la cultura del progetto software e dei suoi partecipanti.
In tal senso, consideralo la filosofia della "libertà". Sei libero di adattare i tuoi metodi di test per soddisfare al meglio le esigenze del progetto software sotto test.