L’11 e 12 giugno si è svolto a Milano la seconda edizione del Software Testing Forum , l’unico evento in Italia di livello internazionale dedicato all’aggiornamento su modelli organizzativi, metodologie e tecnologie dedicate alla qualità di prodotti e servizi software.
Sono stati programmati interventi di esperti mondiali del Testing e della Qualità , CIOs, produttori di tecnologie, i fornitori di servizi e gli Utenti in una Conferenza ricca di contenuti sia nell’ambito delle applicazioni business sia dei prodotti con software embedded, come i mobile device.
La mia partecipazione per ABS quest’anno è stata molto concreta e finalizzata ad acquisire conoscenze dai guru del testing, in particolare seguendo 2 tutorial di Vipul Kocher, di New Dehli, Presidente dell’ Indian Testing Board, l’ ISTQB® board Indiano , più di 15 anni di esperienza professionale nel Testing, prima in Adobe poi alla guida della propria società PureTesting.
Il primo tutorial ha trattato le tecniche di Software Testing Estimation .
La prima “lesson learend” deriva direttamente dalla definizione stessa dell’attività di estimation: valutare il tempo necessario per ottenere “il livello di qualità desiderato”. Se non è definito e condiviso “il livello di qualità desiderato” l’attività di estimation è inutile.
La seconda lezione è riassunta in uno slogan “Trust but verify” : le stime si basano molto su dati raccolti da fonti che non sempre sono attendibili 100%, non necessariamente in cattiva fede, per cui ogni informazione va tenuta in conto ma verificata.
L’effort di un’attività di test può essere valutato con una delle seguenti metodologie:
Test poin analysis basata sul calcolo a monte dei Function Point
% del tempo di sviluppo
Metodologia MoSCoW per la Risk-based analysis
Three poin estimation
Planning poker
Wideband Delphi
WBS
Tutte hanno una validità condizionata da tante variabili di contesto che non sono totalmente note , per cui il processo di stima prevede una prima fase di indagine per definire al meglio il contesto , una prima stima che vede l’uso di 3 delle metodologie prima elencate, e , se possibile, la revisione delle stime via via che i contorni diventano più chiari e definiti.
La prima fase di indagine è dedicata a chiarire gli aspetti che impattano sulle stime , quali la metodologia di sviluppo software (waterfall o agile), il tipo di test richiesto (Unit, integration, acceptance, performance,…) , la qualità media del delivery (se nota), le attività richieste (test book, review, regression etc) .
Sulle metodologie le considerazioni del tutor e dell’aula davano come inutilmente complessa la valutazione dei Test point, come molto critica la valutazione come % dello sviluppo (gli sviluppatori stimano a loro volta in maniera non scientifica ) , e come utile e affidabile la metodologia Risk based.
Il secondo tutorial ha trattato le metriche del test.
Le metriche sono necessarie per controllare e successivamente migliorare. Sono anche strumento di comunicazione (ad es. stati di avanzamento) e di confronto (ad es. con esperienze precedenti) .
Una volta stabilito l’obiettivo delle misure vanno classificate le voci da misurare e per ciascuna è necessario determinare un valore desiderato o una soglia, insomma un termine di riferimento per valutare le misure effettuate Oltre alla mappa concettuale con le 5W1H (Who, When,Why ,Why not, What, How) delle Metriche , la documentazione raccolta ha fornito una classificazione dei tipi di metriche , in relazione agli oggetti misurati. Le metriche possono essere relative al processo o al progetto, al prodotto o alle persone. Quelle più interessanti sono le metriche di prodotto che spaziano da misure del rischio (ogni requisito viene posizionato su un quadrante High/Low le cui dimensioni sono Probablitià e Damage), alla densità dei difetti.
Interessanti anche le metriche di processo. Il processo di sviluppo dei prodotti software prevede le fasi di Requisiti – Progettazione – Codifica – Test. E’ interessante misurare l’efficienza delle singole fasi misurando ad esempio quanti errori dovuti a requisiti sbagliati vengono rilevati in nelle fasi di Progettazione, Codifica o Test, e cosi via.
Strumento molto utile è la matrice dei Testcase per Requirements, in modo da coprire tutti i Requirements col minimo numero di testcase. Per questo viene consigliato uno strumento di testmanagement quale Testlink.
Sono stati forniti esempi di metriche Agile e non, collezionando informazioni in situazioni diverse, al momento disponibili solo in cartaceo. Al piu presto verrà resa disponible in formato elettronico.
La nota finale è stata “Data can be made to sing any song you want. Be ethical”
Gabriella Lo Conte
photo by pigliapost