Il processo di qualità nell’attività di testing funzionali Web.UP

Se ti sei perso la prima puntata, clicca qui.

La richiesta di una modifica o di un’integrazione a Web.UP implica la definizione delle funzionalità da modificare o delle nuove funzionalità da aggiungere all’applicazione. Per fare questo si segue un processo di qualità dei testing funzionali.

Il programmatore addetto al task in questione prepara quindi una nuova scheda di test visibile nel sistema o ne modifica quella già presente, in modo da poter verificare innanzitutto manualmente questi nuovi comportamenti attesi.

Supponiamo che si debba aggiungere la funzionalità Y al componente X. Allora il programmatore crea sotto la scheda del componente X la sottoscheda relativa alla funzionalità Y.

Quando lo sviluppo è terminato e la funzionalità è verificata manualmente (o anche prima dello sviluppo nel caso in cui venga seguita la modalità di sviluppo TDD, la quale prevede che la stesura dei test automatici avvenga prima di quella del software che deve testato) lo sviluppatore scrive il test automatico associato a quella particolare sottoscheda Y.

Il codice della funzionalità e il codice del testing vengono fatti rifluire nel codice versionato dell’applicazione.

In laboratorio è stato installato e configurato un particolare software di continuous integration denominato Jenkins in grado di attivare ogni X ore l’esecuzione di tutti i test automatici dell’applicazione. Se esistono test falliti Jenkins avvisa tramite mail del fallimento oltre a mostrare graficamente che qualcosa non è andato bene con un pallino giallo associato all’esecuzione dei test, che altrimenti risulterebbe blu in caso di test tutti positivi.

Tramite la webapp di Jenkins è anche possibile vedere con quale errore il test fallisce.

In questo modo eventuali regressioni di funzionalità sono individuate precocemente. Jenkins infatti gira tutti i test del pacchetto, quindi vengono eseguiti non solo i nuovi test ma anche tutti quelli scritti precedentemente. A volte capita che modificando una parte dell’applicazione si generino effetti indesiderati in un’altra parte del sistema. Girare il pacchetto di test automatici più volte al giorno permette di tenere sott’occhio eventuali errori introdotti in tutto il sistema testato.

In caso di errori dei test verrà eseguita una correzione del codice dell’applicazione o a volte anche del codice del test dato che anche lo stesso test può non essere scritto correttamente. La correttezza di queste modifiche nel codice versionato verrà valutata durante l’esecuzione successiva del pacchetto di test.

Chiara Zambelli
Responsabile CI/CD – smeup
My LinkedIn Profile