Testing software: Tipologie e come scegliere la strategia di test

Strategia di Test

Nel processo di testing, la strategia di test descrive la metodologia di test generale dell’organizzazione. Essa include le modalità con cui il testing viene utilizzato per gestire i rischi di prodotto e di progetto, la suddivisione dei test in livelli e le attività di alto livello associate al testing. La strategia di test, nonché i processi e le attività in esso descritti, deve essere coerente con la politica di test. Essa infatti dovrebbe fornire i criteri generali di entrata ed uscita dal testing per l’organizzazione o per uno o più prodotti software.

Le strategie di test spesso includono elementi sia preventivi che reattivi. In particolare, gli elementi preventivi della strategia di test sono quelli che utilizzano le attività di testing sui primi prodotti di lavoro, ad esempio utilizzando l’analisi e la progettazione dei test per trovare i difetti nei documenti di test basilari, quali le specifiche dei requisiti. Gli elementi reattivi della strategia di test sono quelli che assicurano che le attività di test siano coerenti con il software oggetto del testing.

Tipologie e scelta della strategia

Come menzionato sopra, le strategie di test descrivono le metodologie generali di test, che tipicamente includono:

1. Strategie analitiche, come il testing basato sul rischio, in cui il team di test analizza la base di test per identificare le condizioni di test da coprire. Ad esempio, nel testing basato sui requisiti, l’analisi del test deriva le condizioni di test dai requisiti ed i test vengono poi progettati e realizzati per coprire tali condizioni. I test sono poi eseguiti, spesso usando la priorità del requisito per determinare l’ordine in cui i test saranno eseguiti. I risultati dei test sono poi riportati in termini di stato dei requisiti, ad esempio: requisito testato e superato, requisito testato e fallito, requisito non ancora completamente testato, requisito con test bloccato, ecc.
2. Strategie basate sul modello, come i profili operativi, dove il team di test sviluppa un modello (basato su situazioni reali o previste) dell’ambiente che ospita il sistema, degli input e delle condizioni a cui il sistema è sottoposto, e di come il sistema dovrebbe comportarsi. Ad esempio, nel testing delle prestazioni basato sul modello di un’applicazione per dispositivi mobili in rapida crescita, si potrebbe sviluppare:
   1. modelli di traffico di rete in entrata e in uscita, degli utenti attivi e inattivi, e del conseguente carico di elaborazione, sulla base dell’utilizzo attuale e della crescita del progetto nel tempo;
   2. modelli dell’ambiente di produzione corrente con hardware, software, capacità di dati, di rete e delle infrastrutture;
   3. modelli per (con valori target, previsti e minimi) il tasso di throughput, il tempo di risposta e l’allocazione delle risorse.
3. Strategie metodologiche, come quella basata su caratteristica di qualità, in cui il team di test adotta un set predeterminato di condizioni di test, come uno standard di qualità, una checklist od un insieme generalizzato di condizioni di test, relative ad un particolare dominio, una certa tipologia di test (ad esempio, test di sicurezza), ed utilizza poi tale insieme di condizioni di test da una iterazione alla successiva o da una versione a quella successiva. Ad esempio, nel testing di manutenzione di un semplice e stabile sito ecommerce, i tester potrebbero utilizzare una checklist che identifica le funzionalità chiave, gli attributi ed i link per ogni pagina e attenersi a tali elementi ogni volta che viene effettuata una modifica al sito.
4. Strategie di conformità a processi o standard, come i sistemi medicali soggetti alla norma US FDA, dove il team di test segue una serie di processi definito da un comitato di standardizzazione o di altro gruppo di esperti, dove i processi prescrivono la documentazione, la corretta identificazione e l’utilizzo della base di test e degli oracoli, nonché l’organizzazione del team di test. Ad esempio, in progetti che seguono le tecniche Scrum Agile, in ogni iterazione i tester analizzano le “user stories” che descrivono particolari funzionalità, valutano lo sforzo di test per ogni funzione come parte della pianificazione dell’iterazione, identificano le condizioni di test (spesso chiamate “criteri di accettazione”) per ogni “user story”, eseguono i test che coprono tali condizioni, e riportano lo stato di ogni “user story” (non testata, fallita, superata) durante l’esecuzione dei test.
5. Strategie reattive, come l’utilizzo di attacchi basati sui difetti, dove il team di test attende per progettare e implementare i test fino a quando il SW sia stato loro consegnato, reagendo poi al primi risultati del sistema in test. Ad esempio, utilizzando il testing esplorativo in base ad una idonea applicazione PC, potrebbero essere sviluppate una serie di carte di test corrispondenti alle caratteristiche, schermate e selezioni di menu. Ad ogni tester è assegnato un insieme di carte di test, che egli utilizza per strutturare le propria sessione di test esplorativo. I testers relazionano periodicamente i risultati delle sessioni di test al test manager, che può rivedere i piani in base ai risultati.
6. Strategie consultive, quali l’uso del testing guidato dall’utente, dove il team di test si basa sugli input di uno o più stakeholder per determinare le condizioni di test da coprire. Ad esempio, nel test di compatibilità in outsourcing per un applicazione web, una azienda può dare al fornitore di servizi di test in outsourcing, un elenco prioritizzato di versioni del browser, di software antivirus, di sistemi operativi, di tipi di connessione e di altre opzioni di configurazione che si desiderano testare per la propria applicazione. Il fornitore può quindi utilizzare tecniche come il testing pairwise (per le opzioni ad alta priorità) ed il partizionamento di equivalenza (per le opzioni con priorità più bassa) per generare i test.
7. Strategie di testing di regressione, come ad esempio l’automazione estesa, dove il team di test utilizza diverse tecniche per gestire il rischio di regressione, in particolare con l’automazione di test di regressione funzionali e non-funzionali ad uno o più livelli. Per esempio, per un testing di regressione di un applicazione web, i tester possono utilizzare uno strumento GUI-based per automatizzare i casi d’uso tipici ed anomali. Tali test vengono quindi eseguiti ogni volta che si modifichi l’applicazione.

Diverse strategie possono essere combinate fra loro. La specifica strategia selezionata deve essere adeguata alle esigenze dell’organizzazione, e le organizzazioni possono adattare le strategie per adeguarsi a particolari situazioni e progetti.

La strategia di test può descrivere i livelli di test da effettuare. In tali casi, dovrebbe essere una guida generale sui criteri di ingresso e di uscita di ogni livello e sulle relazioni tra i diversi livelli (ad esempio la ripartizione degli obiettivi di copertura del testing).

Infine, potrebbero essere necessarie differenti strategie di test per il breve e lungo termine, nonché per diverse organizzazioni e progetti. Per esempio, in presenza di applicazioni critiche per la sicurezza (safety application), una strategia più intensiva può essere più appropriata che in altri casi. Inoltre le strategie di testing possono variare a seconda dei modelli di sviluppo adottati.