Un'errata percezione comune è che il Software Testing consista nel verificare il funzionamento di un sistema controllando che avvenga senza errori o comunque nel rispetto dei risultati attesi. Per questo motivo nei Dipartimenti IT spesso il collaudo del software è quindi demandato in larga parte al System Integrator o comunque lasciato al team che ha effettuato lo sviluppo, delegando agli utenti finali la certificazione finale del sistema spesso sulla base di casi di test preparati dal team medesimo. In molti casi viene quindi meno uno dei principi del Controllo Qualità di matrice industriale, secondo il quale la verifica di un prodotto deve essere effettuata da personale tecnico specializzato “terzo” rispetto a chi si occupa di progettazione e di produzione.
La principale conseguenza di questo approccio che potremmo definire “Development Driven”, è una progettazione dei test approssimativa il più delle volte perchè il team di sviluppo dell’azienda, avendo come principale obiettivo il rispetto delle tempistiche (e dei costi) del progetto, utilizza il tempo da destinarsi al test come ammortizzatore dei ritardi delle precedenti fasi progettuali. Approssimazione che si riflette nel disegno di casi di test non esaustivi e di una Data Preparation inadeguata, nel sacrificio del Regression Test, nell’esecuzione di Integration Test parziali, spesso limitati alla sola verifica tecnica del funzionamento di uno scambio di dati.
Tutto ciò determina la messa in produzione di software ad elevata difettosità, con il trasferimento dell’onere della correzione e del re-testing all’Application Maintenance; i costi non sostenuti per gestire ritardi nel progetto di sviluppo, sono quindi non solo differiti ad un’altra fase del ciclo di vita (e spesso ad un’altra unità organizzativa), ma risultano anche maggiorati perchè è più complesso intervenire in correzione su un sistema in produzione. Questo procura inoltre un danno di immagine per l’azienda e per il Dipartimento IT, poiché l’utente finale ha la percezione di bassa qualità del software sviluppato.
Un approccio industriale al Software Testing richiede molto di più di una semplice verifica del funzionamento delle applicazioni: è una gestione a 360° di tutti gli aspetti che contribuiscono a garantire la qualità del software prodotto:
Ciò richiede quindi un processo industrializzato in cui le fasi precedenti e seguenti l’esecuzione del test sono altrettanto importanti:
Avviene quindi un passaggio dal Software Testing alla Software Quality Assurance, e ciò richiede un assetto organizzativo diverso rispetto a quello impiegato nel ciclo di vita software tradizionale.
Che si utilizzi una metodologia Agile o Waterfall, diventa fondamentale il principio del controllo qualità industriale enunciato in precedenza: il team incaricato alla Software Quality Assurance deve essere “terzo” rispetto al team di progettazione e sviluppo.
Un team di specialisti del test in grado di seguire ogni fase del processo di Quality Assurance, in stretta collaborazione con i Team di Sviluppo e con gli utenti finali con l’obiettivo della qualità complessiva dei deliverable di progetto. Ciò può essere ottenuto con team ingaggiati ad hoc sul singolo progetto di sviluppo, ma è senz’altro più efficace impostare la Software Quality Assurance come un servizio continuativo che interviene, al pari dell’Application Maintenance, sull’intero ciclo vita delle applicazioni.
L’introduzione di un Team di Software Quality Assurance dovrà essere accompagnata dall’adozione di tool che consentano di supportare passo passo il ciclo di vita del testing, dalla progettazione, all’esecuzione, al defect management, alla raccolta delle evidenze.
Si può pensare che introdurre un terzo attore in un contesto già complesso, e dove spesso i tempi sono ristretti, possa introdurre entropia ed aumentare i costi complessivi.
Questo è senz’altro vero nel breve termine e bisogna quindi adottare un approccio di introduzione graduale, teso a raggiungere quick-win (ad esempio una nuova applicazione) che aiutino ad aumentare la fiducia nella nuova organizzazione e nel nuovo approccio.
Nonostante ciò, nel medio e lungo termine il costo della qualità del software sarà ampiamente ripagato dai ritorni in termini di immagine ed affidabilità percepita dall’utente finale, dalla riduzione dei costi indotti da malfunzionamenti del software (per esempio downtime di produzione), dai minori costi di Application Maintenance e, laddove qualità vuol dire anche documentazione di progetto esaustiva e strutturata, riduzione dei costi di progettazione delle evoluzioni future dell’applicazione.
DOTS supporta la tua impresa, sia nella fase decisionale e strategica, sia nella gestione del progetto di innovazione in modo indipendente ad attento ai bisogni della tua azienda, :
(*): i marchi appartengono ai legittimi proprietari