L’approccio tradizionale al Software Testing.

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.

Dal Testing alla Quality Assurance.

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:

  • Valutazione dei deliverable: la qualità della documentazione di progetto, spesso trascurata, si riflette nella qualità del Software e favorisce minori costi nei successivi interventi evolutivi
  • Verifica della copertura dei requisiti degli stakeholder
  • Riduzione della difettosità del sistema in esercizio e conseguente incremento della fiducia degli stakeholder rispetto al livello di qualità fornito
  • Verifica della sicurezza, con l’adozione di strategie di Security Testing adeguate alla sensibilità dei dati trattati e all’accessibilità dall’esterno delle applicazioni sviluppate

Ciò richiede quindi un processo industrializzato in cui le fasi precedenti e seguenti l’esecuzione del test sono altrettanto importanti:

  • Analisi e progettazione
  • Implementazione dei test e data preparation
  • Esecuzione
  • Monitoring e reporting

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.

Third Party Software Quality Assurance.

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.

metodologia Waterfall del software testing

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.

A cura di

Gianluca Costa

Project Manager




Vuoi Saperne di più?

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, :

  • ERP Doctor e supporto nella scelta della Transition Strategy
  • Gestione del progetto di implementazione dell’ ERP (Project Management)
  • Testing Indipendente con JIRA software by Atlassian(*) - Third Party Software Quality Assurance
  • Formazione Dedicata

(*): i marchi appartengono ai legittimi proprietari


Articoli Recenti: