Il ruolo del Quality Assurance Specialist (QA) dopo la fase di sviluppo di un’applicazione

Il ruolo del Quality Assurance Specialist, come spiegato in un articolo precedente, è fondamentale in tutte le fasi di sviluppo. È chiaro però che la verifica finale, anche se arriva per ultima, non è mai la meno importante. A essa vanno infatti dedicati tempi, passaggi e strumenti specifici per svolgerla al meglio.

In questo articolo ci concentreremo quindi sulla fase di testing, in particolare sulla quella di UAT, “User Acceptance Testing”. In tale passaggio l’artefatto viene sottoposto a un campione di utenti finali con lo scopo di simulare un utilizzo reale, valutandone il funzionamento.

In fase di UAT, se gli utenti trovano dei bug nell’applicativo o dubbi relativi a qualche funzionalità, essi provvedono a informare il team di sviluppo attraverso piattaforme apposite, utilizzate anche per la pianificazione dei progetti. Per annotare le segnalazioni, si possono utilizzare Redmine o Jira, oppure fogli di calcolo come Microsoft Excel o Google Spreadsheet.

Sicuramente è preferibile l’utilizzo di software dedicati, poiché permettono di controllare le varie segnalazioni in base, ad esempio, allo stato, alla priorità, alla tipologia e alla severità del difetto. Inoltre vengono tracciati i vari cambi di stato di una segnalazione: dal suo stato di “Nuovo”, in fase di creazione, fino a “Chiuso” nel momento in cui il bug è stato risolto e testato dagli utenti. Altro vantaggio, si possono lasciare dei commenti nelle varie segnalazioni per chiedere maggiori dettagli in merito a un difetto dell’applicativo. Molto utile anche l’assegnazione del ticket a uno specifico sviluppatore, incaricato di risolvere l’errore emerso.

Da questo momento il ruolo del QA consiste nel filtrare i ticket aperti dal cliente, attraverso l’attività di gatekeeping:

• per ogni segnalazione verifica l’effettiva veridicità del bug riproducendolo in base agli step indicati dal cliente e alle tecnologie utilizzate, al tipo di browser e, se si tratta di una web application, alla relativa versione. Si considerano invece modello e sistema operativo smartphone se si tratta di un’app;
• controlla che sia stato previsto il relativo scenario per l’errore emerso, per capire come mai non sia stato riscontrato durante il FIT (Framework for Integration Test);
• se il bug non è veritiero, può respingere la segnalazione con la dovuta motivazione o chiedere ulteriori spiegazioni ai tester;
• se il bug è veritiero ha il compito di informare tempestivamente il team di sviluppo dando precise indicazioni su come riprodurre il bug. Questo per permettere ai developer, attraverso il debug, di individuare in quale punto del codice sorgente si dovrà procedere con il fix. Alla fine si programmerà con il cliente un nuovo rilascio con le varie risoluzioni dei bug riscontrati;
• prima di consegnare la release con la risoluzione dei difetti, il QA ricontrolla le funzionalità risolte attraverso il FIT. Infine eseguirà lo Smoke Test per verificare che non ci siano regressioni dopo l’avvenuta risoluzione dei bug.

Riferimento importante per eseguire i test è il documento FDS (Functional Design Specification), precedentemente redatto, che ha lo scopo di descrivere nel dettaglio tutte le principali funzionalità dell’applicazione. Al suo interno si specificano anche le azioni e le informazioni necessarie per ciascun campo delle pagine dell’applicazione e si presenta il flusso generale per ogni specifica funzionalità. Questo documento è importante in fase di gatekeeping, infatti attraverso la consultazione, il QA ha l’autorità di decidere se respingere o meno una segnalazione in fase di UAT.

Ad esempio possono emergere segnalazioni che identificano miglioramenti da apportare in alcune funzionalità che non erano state precedentemente previste, queste vengono identificate come CR (change request). Tali richieste possono comportare un ulteriore sviluppo di funzionalità o personalizzazione di un servizio e devono essere a loro volta analizzate, individuando nuove fasi di sviluppo. Le modifiche dovranno poi essere aggiunte anche nel FDS.

La figura del QA, in quanto filtro tra i tester degli utenti finali e il team di sviluppo, è quindi fondamentale per monitorare nel migliore dei modi eventuali bug e consegnare una soluzione in linea con le specifiche di progetto.