SOFTWARE TESTING FORUM 2018: L’ESPERIENZA DI CHI È RIUSCITO A CAMBIARE UN PROCESSO DI TESTING

Continuous Integration, Automazione, DevOps e… crowd test: questi gli argomenti principali del STF 2018. Temi “caldi” e ampi del mondo del testing che mettono in luce i trends degli ultimi anni: l’adozione di un approccio automatizzato al testing funzionale per velocizzare e aumentare l’accuratezza dei processi di test, affiancato ad un approccio “crowd/human-based” per coprire gli scenari utente.
Ma andiamo con ordine… Che cosa è STF 2018? È il Software Testing Forum, organizzato dall’ISTQB® Conference Network, nello specifico dalla sezione italiana ITA-ISTQB.

Consiste in una tre giorni dedicata allo stato dell’arte, alle strategie, alle tecnologie e alle esperienze messe in atto per ottenere la massima qualità di prodotti e servizi software. L’STF di Milano è uno degli eventi chiave del testing a livello nazionale, e noi di IDS, non potevamo mancare.
L’introduzione di un processo di testing è spesso affiancato a un meccanismo di resistenze al cambiamento: utilizzare una prospettiva diversa e variare il modo di lavorare non è facile, soprattutto se si tratta di abitudini radicate nel tempo e nelle persone. Ingo Philipp, Product Management di Tricentis, ci ha invece dimostrato come il cambiamento sia possibile se applicato con passi piccoli ma costanti. Nel suo case study ci ha illustrato come sia riuscito a passare da più di 4700 casi di test manuali, con un tempo di esecuzione di 10 settimane e un tasso di copertura pari al 37% dei rischi di business, a circa 1200 casi di test manuali, con una copertura del 87% dei rischi di business e 5 settimane di esecuzione. Un assessment iniziale ha permesso l’eliminazione delle ridondanze e delle sovrapposizioni dei test case manuali presenti e, allo stesso tempo, l’introduzione di nuovi test case per estendere la percentuale di rischi coperti.
Tempi di esecuzione di 5 settimane risultano ancora eccessivi al fine di fornire feedback utile agli sviluppatori: è necessaria l’introduzione della automazione. In meno di due mesi, il team di Ingo è riuscito ad implementare un meccanismo di continuous integration e automazione dei test dove a fronte di un’esecuzione di soli 34 minuti (con test in parallelo) vengono coperti il 53% dei rischi di business. In questo modo gli sviluppatori del team di Ingo possono ottenere feedback più accurato (dal 37% al 53% di copertura) e di gran lunga più veloce (da 10 settimane a 34 minuti). Il numero di casi di test eseguito in questa fase è pari al 7% dell’ammontare totale: un numero esiguo ma sufficiente a garantire il funzionamento del sistema nelle sue parti principali.
Un processo di cambiamento come quello descritto, è più efficace se monitorato nel tempo con le appropriate metriche. Nello specifico:

copertura dei rischi di business. I rischi sono fattori che potrebbero avere conseguenze negative future per questo, una volta individuati, si attuano strategie per mitigare quelli più probabili e impattanti. Avere una copertura pari al 35% significa che su 100 rischi definiti solo 35 hanno dei casi di test associati. Più questo valore si avvicina al 100% più il rischio è mitigato e sotto controllo;

numero di casi di test. Non fatevi ingannare dalla semplicità di questa metrica, è importante monitorare il numero di casi di test stimati in fase di pianificazione, quanti ne sono stati realmente implementati e, infine, quanti ne sono stati eseguiti;

il tempo di esecuzione. In un’ottica di sviluppo agile (ma non solo), il tempo di esecuzione è un fattore discriminante per decidere quali test eseguire e di conseguenza che tipo di feedback ottenere.

Tutto questo cambiamento, che risultati ha portato? La riduzione del 72% di difetti con alta priorità riscontrati in produzione. Un bel risultato, che ne dite? E voi siete pronti ad iniziare il vostro processo di cambiamento?
Vi lascio riportando una frase di Ingo “The future doesn’t just happen, it gets happened, so make it happen”. Facciamolo assieme!