Test del Software: Incrementare i livelli di copertura tagliandone del 50% costi ed effort con un Approccio Pragmatico ed una Suite Specializzata

I risultati illustrati in questo articolo sono frutto di esperienze maturate direttamente sul campo e dall'analisi di vari dati estratti da uno studio sul Software Testing pubblicato su IEEE Explore da Rudolf Ramler, Theodoric Kopetzky, Wolfgang Platz, con il titolo "Value-based coverage measurement in requirements-based testing: Lessons learned from an approach implemented in the TOSCA testsuite - Proceedings of the 38th Euromicro Conference on Software Engineering and Advanced Applications (SEAA 2012)"

Introduzione al Software Testing

Nello sviluppo software gli effort del testing sono molto significativi e spesso in conflitto con le pianificazioni e risorse imposte dai vincoli di business e time-to-market sempre più pressanti. I team di testing combattono per completare in modo efficace le attività nei limiti di tempo e di budget assegnati.

Il conflitto può essere attenuato con successo se il testing viene progettato, pianificato, e vengono definite le priorità secondo il diverso “valore per il business” delle funzionalità del prodotto. Ricerche hanno dimostrato che l’80% del “valore” spesso è associato al 20% delle funzionalità. Quindi il Ritorno dall’investimento (ROI) del Software testing può essere migliorato focalizzando gli sforzi sugli aspetti del prodotto software che contribuiscono maggiormente al Valore di Business.

In genere, però, le strategie di testing sono definite secondo logiche neutrali al valore, nelle quali ogni requisito, use-case, oggetto, test case, sono trattati come di uguale importanza, risultando il testing “agnostico” rispetto alle considerazioni di “valore”. Anche la maggior parte dei metodi, tecniche e tools sono neutrali al valore e risultano deficitari di linee guida e supporto per definire le relazioni del testing con il valore di business del prodotto. Lo stato di avanzamento delle attività di testing viene inoltre valutato e documentato in termini di numero di Test Case (TC) disponibili, eseguiti, falliti e passati.

Il significato e valore di questi report è però limitato. Questi numeri “value-neutral” non forniscono sufficienti informazioni ne sulla reale copertura ne sul rischio qualitativo rimanente. Nell’approccio “value-based” il conteggio dei TC è in relazione con le funzionalità e il valore del prodotto. 

Software Testing “Value-Based”

TOSCA è una suite completa per la gestione e l’automazione del software testing: dalla gestione delle attività (test management) , alla progettazione e automazione dei TC, al reporting e valutazione dei risultati; supporta diversi approcci al testing sia per l’esecuzione manuale dei test cases che la loro automazione, per una vasta gamma di applicazioni con e prive di Interfaccia Utente (UI).

I progetti di testing in TOSCA sono strutturati in un processo che prevede la (1) definizione della struttura dei requisiti basata sul rischio (risk-based), (2) la progettazione dei test cases associati ai requisiti , (3) l’implementazione e automazione dei test cases progettati, (4) l’ esecuzione dei test cases e infine (5) la correlazione dei risultati del test nella struttura “risk-based” dei requisiti .

L’approccio al testing “value-based” deve essere “radicato” nei requisiti che definiscono le peculiarità del sistema condivisi dagli “stakeholder. Ogni unità funzionale dovrà essere strutturata Top-down ad albero, con i requsiti reali al livello più basso. I TCs, derivati dalle specifiche di test, sono poi associati alle diverse funzionalità.

I risultati dei test eseguiti permettono una valutazione statistica dei requisiti che forniscono una panoramica completa dello stato del progetto di test. In Figura 1 un es. delle informazioni aggregate dove “Coverage Specified” è lo stato di progettazione dei TCs.

La copertura calcolata (in giallo) è confrontata con il livello che sarà raggiunto se i TCs pianificati ma non ancora definiti saranno definiti (in bianco) . “Execution State” (%) fornisce una rappresentazione dello stato di sviluppo ed esecuzione dei TCs , con la % dei passati (in verde), falliti (in rosso), non eseguiti (in bianco) e non eseguibili perchè non specificati (in grigio) .

I TCs riproducono gli scenari d’uso, sono pertanto definiti dai dati di input e dalla sequenza di interazione tra l’utente e l’applicazione. I valori rilevanti dei dati sono determinati applicando tecniche quali “equivalence-partitioning”, “boundary value analysis” e altri e sono combinati applicando tecniche combinatorie. In funzione del numero di combinazioni possibili, per ogni scenario d’uso devono essere associati generalmente più test cases. In TOSCA l’insieme dei dati di input è modellato definendo degli attributi che rappresentano per es. campi di input in una form, colonne di tabelle in un DB e sono mantenuti in un insieme di valori rappresentativi (istanze) . Dall’insieme dei dati di input è possibile generare i TCs che soddisfano vari criteri di copertura, ottenendo così una significativa riduzione del numero dei TCs. La tecnica “Linear Expansion” implementata in TOSCA permette un accurato bilanciamento tra i requisiti di test sistematici e basati sul valore; essa soddisfa il criterio di copertura “base choice” poiché produce sistematicamente tutte le variazioni di una combinazione base definita, come riportato in Figura 2.

Misure di copertura “Value-Based”

L’obiettivo delle misure di copertura è determinare la portata della verifica di una applicazione mediante l’esecuzione di TCs; esse forniscono informazioni essenziali per gestire le attività di testing e per indirizzarle verso le aree ancora non coperte dei requisiti. L’approccio “value-based” tiene conto che non tutte le funzionalità abbiano lo stesso “valore di business” . Focalizzandosi sulle funzionalità a più alto valore, l’effort investito nel testing viene ripagato in un periodo di tempo inferiore ottenendo un migliore Ritorno dall’investimento (ROI).

Il contributo di un singolo TC alla copertura è determinato dalla combinazione di due fattori; il valore di business del requisito a cui il TC è associato ed i dati di input che costituiscono lo scenario d’uso verificato/testato. Questi due fattori riflettono la prospettiva interna ed esterna che sono rilevanti per il testing “value based”. La dimensione esterna è riferita all’assicurazione degli obiettivi di valore per gli stakeholder esterni. La dimensione interna, invece riguarda l’organizzazione del test in modo che contribuisca efficacemente al miglioramento della qualità del software.

Un requisito è legato ad uno o più TCs necessari alla sua verifica , che coprono un insieme di valori dei dati di input identificati per gli attributi dei dati rilevanti nello scenario d’uso.

I rischi costituiscono la minaccia alla realizzazione del valore di business di un requisito. La probabilità del rischio e il danno potenziale determinano il livello di influenza. La copertura sistematica degli attributi dei dati ed i relativi valori del dato influenza l’importanza (valore) di un TC. Il peso dei valori e degli attributi del dato determinano il livello di influenza. 

Implementazione in un progetto di Software Testing

Negli esempi che seguono, riferiti al calcolo di un premio assicurativo per una polizza di veicoli, vengono illustrate le modalità con cui si determina la copertura del testing in TOSCA.

La Figura 2 mostra sei test cases (TC1, .. , TC6) generati per l’oggetto di business “Named Insurant” dalla funzione/metodologia “Linear Expansion”. Questi TCs non forniscono nessuna informazione sul’importanza di ogni TC in relazione con gli altri TCs. Nella pratica però l’importanza dei vari TCs varia molto : il caso standard (TC3) è il più frequente caso d’uso e solitamente quello che ha associato la più importante delle combinazioni dei valori dei dati. L’importanza degli altri test cases diminuisce in modo netto. 

Poichè le polizze sottoscritte sono nella percentuale di 3 donne ogni 8 uomini, il valore del dato “male” rappresenta il 72.7% e anche lo stesso livello di rischio ; il valore “female” rappresenta poi il 27.3% del valore di rischio. Questa distribuzione è incorporata nella determinazione del valore del test case impostando i pesi dei valori dei dati.

L’influenza degli attributi varia in modo differente; ad esempio l’attributo Age determina una variazione del prezzo della polizza finale per un massimo del 30% a seconda delle età .

L’attributo Sex determina una variazione del 5% tra i valori Male e Female , e l’attributo Residence determina una variazione del 15% per il contraente che abita in città o in campagna Queste % di variazione diventano i pesi degli attributi (Figura 4).

Combinando il peso relativo delle istanze individuali dei valori dei dati con il relativo peso degli attributi, si ottiene il contributo di tutti i valori dei dati (Figura 5). 

Il valore di un test case ed il relativo contributo alla copertura è uguale alla somma dei contributi dei valori dei dati associati . Inoltre, il contributo dei singoli è dipendente dalle ridondanze tra i TCs e, come conseguenza, dal loro ordine di esecuzione. Il test dello scenario standard (TC3) è eseguito per primo e quindi porta al più alto valore di copertura (56.5%) . Il contributo degli altri test cases è ridotto in relazione al contributo dei valori dei dati rimanenti. Il contributo di TC2 è uguale a 10.59% che deriva dal contributo di “Age=18-23”; tutte le altre istanze dei valori dei dati sono già state testate nel contesto del TC3.

La valutazione della copertura è ottenuta attraverso l’associazione dei TCs e il loro relativo contributo, alla struttura dei requisiti con il loro rischio di business associato. Sulla parte destra del report viene mostrato il livello di copertura e lo stato di esecuzione dei test cases (65% passati, 27% falliti, il resto non ancora eseguiti e specificati).

Risultati e discussione

L’approccio “value-based” per la misura della copertura dei test rispetto ai requisiti è stato introdotto ed utilizzato in parecchi progetti di test reali. Mediante l’esempio di un progetto di test semplice viene confrontato il livello di copertura e gli effort nel caso dell’approccio “value-based” rispetto all’approccio “value-neutral” , mediante la prioritizzazione dell’esecuzione dei test cases basata sull’assegnazione del peso/valore ai singoli TCs. 

La Tabella 1 riporta i livelli relativi dei costi di investimento, dei benefici raggiungibili, e del ritorno dell’investimento (ROI = (benefici – costi)/costi ) per i due differenti approcci.

La colonna %TC riporta i livelli relativi di copertura del testing. I corrispondenti costi di investimento in percentuale sono riportati nella colonna Costs (%) , i corrispondenti valori di beneficio ottenibili con i due approcci sono riportati nella relativa colonna Value (%) . La prioritizzazione “value-based” mostra una crescita del ROI più rapida , che raggiungerà un valore positivo dopo soli 4 test (il 3.5% di tutti i test cases); questi TCs sono quelli dello scenario d’uso standard. Al contrario, l’approccio “value-neutral” considera tutti i TCs con la tessa priorità e il ROI positivo sarà raggiunto solo dopo 31 tests (27,2% di tutti i test cases). Inoltre nell’approccio “value-based” il ROI maxROI = 1.104 si raggiunge dopo 79 tests, cioè con solo il 69,3% di tutti i test cases. 

La Figura 7 riporta le curve dei costi e benefici, la Figura 8 i corrispondenti valori di ROI. In quest’ultima il punto di break-even dei due differenti approcci è raggiunto quando le corrispondenti curve ( verde per l’approccio basato sul valore e rosso per l’approccio neutrale) incrociano la linea dello zero. La linea tratteggiata blu è stata aggiunta per mostrare la linea base minima ottenibile con una definizione random della priorità. L’approccio random raggiunge il punto di break-even dopo il 50% dei tests. Con l’approccio “value-neutral”, il valore max di ROI è raggiunto quando tutti i test sono stati eseguiti (100%). Con l’approccio “value-based” il valore max di ROI (indicato dalla freccia verde) è raggiunto dopo l’esecuzione di circa il 70% dei test.

Sintesi e lessons learned per migliorare costantemente i risultati del Software Testing

Le misure di copertura definite in questo studio sono state implementate come estensione all’approccio al testing “value-based”, supportato dalla Suite di Test TOSCA. Esso ha il suo fondamento sui concetti del testing basato sui requisiti e sul rischio di business, cosi come sulla tecnica di test combinatoria (Linear Expansion) che è in grado di generare i TCs relativi agli scenari standard d’uso e alle relative variazioni. Dall’esperienza si possono sintetizzare le seguenti considerazioni: 

• Supporto al test design “value-based”. I TCs sono associati alla verifica dei requisiti e quindi le priorità sono calcolate sulla base del valore e dei rischi associati. I TC di verifica degli scenari d’uso standard hanno una maggiore importanza rispetto ai TC relativi a variazioni che riguardano scenari particolari o scenari invalidi .
• Supporto del tool e facilità d’uso. Il beneficio ottenuto da un approccio che prevede la valorizzazione e la prioritizzazione dei test è fortemente dipendente dalla sua adeguata e corretta applicazione da parte del team di testing. Il calcolo e i report sui dati di copertura diventano problematici quando questo processo non è integrato negli strumenti di supporto regolarmente utilizzati.
• Facilità di comprensione. Fortemente collegate al punto precedente sono anche la facilità di comprensione dell’approccio alle misure e la reportistica prodotta. L’effetto della attribuzione dei pesi alle differenti entità (cioè requisiti, attributi e valori dei dati) sul calcolo dei valori aggregati deve essere trasparente e di facile interpretazione per gli utenti.
• Supporto per lo sviluppo selettivo di insiemi di test (portfoli di test). I responsabili del testing si trovano spesso a dovere prendere decisioni in relazione a quali parti del sistema sottoporre al testing e con quale livello di estensione perfino prima di pianificare, progettare e realizzare i test cases. Un approccio per determinare il contributo alla copertura può fornire un valido contributo nel fornire stime sul numero dei TCs necessari e sul loro contributo relativo.
• Supporto per la manutenibilità. Nell’evoluzione di un sistema software i test subiscono dei cambiamenti nell’implementazione, nelle funzionalità e nel valore di business. Un ricalcolo dei contributi alla copertura deve rivelare i cambiamenti strutturali nella distribuzione del valore associato al testing.

Chiara Ballari, insignita del premio europeo "Donna Terziario" nell'ottobre 2012, è laureata in matematica, esperta di informatica, software e computer. Si é fatta le ossa in Ibm dove é entrata all'età di 22 anni come esperta di database relazionali. Per la multinazionale americana girava l'Europa e gli Stati Uniti in cerca di novità insieme a un gruppo di altri specialisti.  A trent'anni tenta la sua prima esperienza imprenditoriale. In seguito diventa direttore dei sistemi informativi di un colosso francese e dal 2003 inizia con il temporary management. Oggi Chiara Ballari guida Athirat (azienda sestese all’interno dell’incubatore Lib) con un team di giovani collaboratori al di sotto dei trent'anni. Sviluppa soluzioni Mobile, aiutando le piccole aziende a innovarsi tecnologicamente e prestando consulenze informatiche. È stata fra i fondatori di «Manager Associati», dell’associazione imprenditrici all’interno di Assintel (associazione nazionale imprese Ict) e fra le promotrici dello sportello «Donne at work».

Mariagrazia Brunetti, laureata in Ingegneria Elettronica al Politecnico di Milano, ha maturato oltre 20 anni di esperienza tecnica, commerciale e di sviluppo business nei settori Avionico, Bancario, Telecomunicazioni e su progetti internazionali, ha siglato importanti accordi con multinazionali e gestito la nascita di progetti e soluzioni per il Test Automation di elevata complessità.

E' attualmente il Direttore di athes  (athirat empowering solutions), Business Unit di athirat orientata ad introdurre sul mercato italiano tecnologie e prodotti innovativi, ha recentemente siglato un importante accordo  con Tricentis, per la distribuzione della Suite di Test TOSCA"