I NUMERI IMPORTANTI NELL’AUTOMAZIONE DEI TEST DI ACCETTAZIONE

In questo articolo, descrivo alcune metriche relative al processo di testing che abbiamo realizzato e che stiamo mantenendo ed estendendo per un nostro cliente.

I numeri dimostrano che un processo sostenibile può essere basato anche su automazione dei test di accettazione.

Ti sei mai chiesto quanto si può ottenere automatizzando i test di accettazione degli utenti? Qui presento i dati su un caso di studio basato su un nostro cliente.

Il sistema in prova (SUT) è un’applicazione web nel settore finanziario.

Al momento, per questo progetto, stiamo mantenendo ed estendendo una raccolta di suite di test automatizzate che girano sulla nostra architettura CUTE. Ogni test case implementa un possibile scenario di utilizzo, scelto sulla base di una valutazione dei rischi che viene effettuata di routine insieme al cliente.

Questi dati riflettono ciò che è accaduto nelle ultime settimane, che sono rappresentativi dello stato attuale del processo di automazione dei test.

Ogni notte questi test vengono eseguiti per un totale di 30 ore di test (ovviamente, vengono eseguiti in canali di esecuzione paralleli).

Ogni notte coinvolgono 2 su una serie di 5 possibili piattaforme utente: Windows10 con Chrome, Firefox, IE11, Edge o Safari. Ogni piattaforma viene utilizzata più volte alla settimana.

I test vengono eseguiti su 4 diversi ambienti di test, in cui il SUT differisce per la sua base di codice o perché vengono utilizzati dati di test diversi. Un ambiente è quello di pre-produzione in cui vengono utilizzati test di fumo automatizzati.

Ogni notte vengono generati automaticamente almeno 50 diversi rapporti di prova.

In totale ci sono più di 230 casi di test, che “toccano” il SUT in almeno 1750 punti di contatto unici. Sono punti di controllo, in cui il test case guida il SUT, o test oracoli, in cui il test case controlla alcune proprietà del SUT.

Durante ogni esecuzione del test, per ogni touch point esercitato, viene automaticamente prodotto uno screenshot della GUI del SUT e inserito nel report di esecuzione del test. In totale vengono raccolti più di 24000 screenshot per notte.

I casi di test sono stati sviluppati seguendo l’approccio “Specificazione per esempio” e forniscono la base per definire una documentazione vivente della logica del SUT. Questi casi di test possono essere estratti automaticamente per alimentare un libro di prova di 334 pagine. I test sono correlati ai requisiti che testano e anche il libro di test li include.

Il test harness utilizzato per supportare questi casi di test astratti, scritto in Java, comprende un totale di 469.000 righe di codice sorgente. La maggior parte viene aggiornata automaticamente grazie all’approccio model-driven che stiamo seguendo.

Questo stato del processo di test è stato raggiunto dopo aver lavorato per questo cliente negli ultimi 24 mesi. Attualmente, mese dopo mese, seguiamo un approccio di sviluppo agile guidato dai rischi, quei numeri continuano ad aumentare:

– Ogni mese il numero di ore di test viene esteso di almeno 2 ore.

– Ogni mese vengono aggiunti circa 100-120 nuovi punti di contatto a quelli esistenti.

– Ogni mese i casi di test aumentano di 10-20.

Questo tasso di sviluppo del test ware è controbilanciato da un inolvement relativamente leggero del personale del cliente. Negli ultimi mesi, lo sforzo del cliente è stato fondamentalmente di una persona al giorno al mese per fare le valutazioni dei rischi e circa mezz’ora al giorno per ispezionare i rapporti di prova; quindi un totale di 3 giorni-persona al mese. Non sono necessarie modifiche sul SUT, che trattiamo totalmente come una scatola nera.

Se dovessimo confrontare questo volume di test con un equivalente manuale (il cosiddetto “Estimated Manual Test Effort”), il cliente dovrebbe supportare questo tipo di sforzo:

– 3 equivalenti a tempo pieno (FTE) per eseguire l’esecuzione dei test, ogni notte;

– 6 FTE per scrivere i rapporti di prova dettagliati, ogni notte;

– almeno 0,5 FTE per aggiornare la documentazione vivente incorporata nel test book, una al mese.

Una delle metriche che il client sta monitorando è il numero di hot-fix che vengono creati dopo ciascuna delle versioni (che si verificano almeno una volta al trimestre). Il numero di hot-fix per versione era 5-7 quando è iniziato il processo di test, ed è ora sceso a 0-1 per le ultime 5 versioni (che è una diminuzione almeno dell’80%).

La nostra conclusione è che, nonostante diversi miti, l’automazione dei test di accettazione degli utenti può essere eseguita in modo sostenibile.

In un prossimo post presenterò i dati riguardanti lo specifico approccio model-driven che stiamo adottando.