Il Context Driven Testing è una metodologia agile che si propone di fornire un nuovo tipo di approccio al testing dei prodotti software. Ideata ed esposta inizialmente da Brian Marick (fondatore della Testing Foundations), è poi stata abbracciata da molti altri specialisti del settore.
Questo perché l'approccio tradizionale non si adatta alle metodologie agili, particolarmente nel momento in cui si considera il testing semplicemente un momento di verifica sulla soddisfazione delle specifiche fissati a priori. Il testing invece viene visto ora come parte integrante del processo progettuale (e naturalmente di quello produttivo).
Il maggior sforzo di formalizzazione in questo ambito si deve a Cem Kaner che ne ha descritto motivazioni, pratiche e strumenti.
Rapid testing
[modifica | modifica wikitesto]In tempi recenti ci si è resi conto che un'eccessiva integrazione del testing nelle metodologie leggere ne snaturava il principio base. In pratica, ci si è accorti che effettuare troppi test produceva l'effetto opposto a quello desiderato. Oltre una certa soglia, l'aumentare dei test produce infatti un aumento ingiustificato nella documentazione e una spesa in termini di tempi non controbilanciata da una maggiore stabilità del software prodotto.
Per questo James Bach ha proposto un nuovo approccio al testing, detto Rapid Testing, di aiuto nel discernere fra test da effettuare e test da evitare. Il punto di forza del metodo consiste nell'avere una serie rapidissima di test mirati, da effettuare ciclicamente durante tutte le fasi di sviluppo del progetto.
Principi base
[modifica | modifica wikitesto]Otto i concetti fondamentali da seguire per scegliere al meglio questa serie di test:
- Non perdere tempo - Eliminare tutte le azioni non necessarie, come ad esempio ripetere test già effettuati solo perché repetita iuvant. Basta essere sicuri di avere buone informazioni dai test che si fanno e farli così una volta soltanto;
- Mission - Non si scrivono prima i test cases e poi si prosegue. Si devono ottenere solo risultati su casi importanti. Prima di tutto si deve testare le cose veramente importanti. Il resto può anche essere tralasciato;
- Competenze - Essere veloci non vuol dire che i test possano essere fatti male, anzi. Chi decide e conduce i test deve avere le massime competenze possibili nel campo;
- Rischi - Non si fanno test funzionali o strutturali, ma si individuano le situazioni di rischio e quali di queste potrebbero creare i problemi peggiori. Sono queste ultime quelle da testare;
- Euristiche - Cercare soluzioni euristiche è inteso nel senso di cercare soluzioni tramite algoritmi non esaustivi, in caso contrario non si avrebbe il controllo totale del test e si perderebbe tempo;
- Esplorazione - Oltre a testare rapidamente bisogna imparare rapidamente, cioè bisogna far tesoro delle esperienze accumulate con i precedenti test e riutilizzarle;
- Lavoro di gruppo - Il team permette un lavoro più rapido ed efficiente. Un ottimo metodo, mutuato da Extreme Programming, può essere il Pair Testing. Due persone al lavoro su un solo terminale rendono meglio e più velocemente;
- Esaminare minuziosamente - Il test deve essere veloce, ma preciso. È importante mantenere un forte senso autocritico ed essere sempre pronti a riesaminare i dettagli delle strategie di testing usate.
