Testing software: Tempi e schedulazione delle attività di test

Stima del testing

Nell’ambito del testing software, il problema delle stime è ben noto, ovvero nessuna stima, per quanto accurata, può ritenersi sufficientemente esatta. Tuttavia, le stime sono necessarie per poter pianificare le attività. Metodi e tecniche di stima possono aiutare ad eseguire valutazioni accurate. Le stime, quindi, influenzano pesantemente i piani e alla loro scarsa precisione viene spesso attribuito il mancato raggiungimento degli obiettivi del progetto. Per questo, e non solo, non ci si può esimere dall’effettuare stime accurate.

In altre parole, la stima, come attività di gestione, è la creazione di un obiettivo indicativo dei costi e delle date di completamento in relazione alle attività coinvolte in un particolare progetto. Le migliori stime:

Rappresentano la saggezza collettiva di esperti professionisti e hanno il sostegno dei partecipanti coinvolti
Forniscono liste specifiche e dettagliate di costi, risorse, attività e persone coinvolte
Presentano, per ciascuna attività stimata, il costo, lo sforzo e la durata più probabili

Nell’ingegneria del software, è noto da tempo che la stima è di elevata complessità, sia a livello di tecniche che politiche, anche se diverse pratiche ottimali di stima nella gestione dei progetti sono state create e diffuse. La stima del testing è perciò l’applicazione di queste pratiche ottimali alle attività di testing di un progetto o di manutenzione.

La stima dovrebbe riguardare tutte le attività coinvolte nel processo di testing. D’altronte, la stima dei costi, degli sforzi e, soprattutto, della durata di esecuzione dei test è spesso quella di maggior interesse per il Management, in quanto l’esecuzione dei test si trova tipicamente sul cammino critico del progetto. Tuttavia, le stime di esecuzione dei test tendono ad essere difficili da produrre e comunque inaffidabili, quando la qualità complessiva del software è bassa o sconosciuta. All’opposto, la familiarità e l’esperienza con il sistema possono probabilmente influire positivamente sulla qualità della stima. Una pratica comune è quella di stimare il numero di test case necessari durante l’esecuzione, ma essa funziona solo se si può supporre che il numero di difetti nel software da testare sia basso. Le ipotesi fatte durante la stima devono essere sempre documentate come parte della stima.

La stima del testing dovrebbe prendere in considerazione tutti i fattori che possono influenzare il costo, lo sforzo e la durata delle attività di test. Questi fattori includono sicuramente i seguenti elementi:

livello di qualità del sistema richiesto
dimensioni del sistema da testare
dati storici su progetti di test precedenti, che possono essere corretti con dati di settore o dati di riferimento di altre organizzazioni
fattori di processo, tra cui la strategia dei test, il ciclo di vita dello sviluppo o della manutenzione, maturità dei processi, nonché la precisione della stima del progetto
fattori materiali, tra cui l’automazione dei test con i relativi strumenti, l’ambiente ed i dati di test, ambienti di sviluppo, documentazione di progetto (ad esempio, specifiche dei requisiti, ecc.), e prodotti di lavoro di test riutilizzabili
fattori personali, tra cui manager e leader tecnici, impegno e aspettative del senior management, esperienza e attitudini del team di progetto, sua stabilità e inter-relazioni, supporto all’ambiente di test e di debug, disponibilità di consulenti qualificati e la conoscenza del dominio
complessità del processo, tecnologia, organizzazione, numero di stakeholder nel testing, numerosità dei team di test, specialmente quando i team siano geograficamente separati
necessità significative di formazione, di apprendimento e di guida
assimilazione o sviluppo di nuovi strumenti, tecnologie, processi, tecniche, hardware e software personalizzato o numerosità del testware
necessità di un alto grado di specifiche di testing dettagliate, in particolare in presenza di uno standard di documentazione non familiare
complessità dei tempi di arrivo dei componenti, in particolare per i test di integrazione
caducità dei dati di test (per esempio, dati la cui validità decade nel tempo)

La qualità del software fornito è un fattore importante, che Responsabili del Test dovrebbero prendere in considerazione nella loro stima. Ad esempio, se gli sviluppatori hanno adottato delle “best practice” quali lo unit testing automatizzato e l’integrazione continua, almeno il 50% dei difetti verrà rimosso prima della consegna del codice al team di test.

Detto ciò, la stima può essere fatta sia bottom-up che top-down. Le seguenti tecniche possono essere utilizzate nelle stime del testing:

intuizione, congetture ed esperienza passata
work breakdown structure del progetto (WBS)
sessioni di stima del team
standard e norme aziendali
percentuali dello sforzo di progetto complessivo o dei livelli di personale (ad esempio, rapporto tester-sviluppatore)
storia organizzativa e metriche, compresi i modelli che stimano il numero di difetti, il numero di cicli di test, il numero di test case, lo sforzo medio di ciascun test, ed il numero di cicli di regressione coinvolti
medie di settore e modelli predittivi, quali function points, linee di codice, sforzo di sviluppo stimato, o altri parametri di progetto.

Nella maggior parte dei casi, le stime, una volta redatte, devono essere consegnate al management, insieme ad una loro giustificazione. Spesso, ne conseguono approcci di negoziazione, che si traducono in una rielaborazione della stima. Idealmente, la stima finale del testing rappresenta il miglior equilibrio possibile, fra obiettivi organizzativi e progettuali, nelle aree della qualità, della tempificazione, del budget e delle caratteristiche del prodotto.