Nella nostra quotidiana attività sul mercato, ci confrontiamo spesso con questo tema: la percezione della qualità del software e di tutto ciò che è ad essa correlata. Siamo da una parte circondati da autorevoli studi di settore, che da oltre 20 anni ripetono quanto sia determinante, per garantire un abbattimento dei costi e dei rischi nei propri progetti software, adottare un processo strutturato di definizione dei requisiti e del testing. Dall'altra parte, dal confronto reale con le diverse organizzazioni sul territorio nazionale, si riscontra spesso una visione del problema “di dover effettuare i test”, e non un’opportunità di risparmio e di successo.
Il fatto è che gli effetti della “non qualità” sono evidentemente non tracciati e documentati a sufficienza; si ha solo, e non sempre, una percezione dell'impatto e dei costi, a volte con evidenze drammatiche, ed una estrema difficoltà nel ricondurre tale percezione alle vere cause, senza riuscire ad innescare un più che economicamente giustificabile processo di miglioramento continuo della qualità.
Invece di impostare la massima attenzione a tutte le attività di verifica e validazione nel corso dei propri progetti, con la convinzione che “ci vuole meno tempo a fare bene una cosa che a spiegare perché la si è fatta male” si ricade nel circolo vizioso per cui “non c’è mai tempo per fare bene le cose, ma c’è sempre tempo per rifarle”, parafrasando quanto il poeta educatore, linguista Henry W. Longfellow (Portland 1807 – Cambridge 1882) scriveva più di un secolo fa.
Il test, come ben documentato nel Syllabus Istqb, dovrebbe sempre perseguire tre obiettivi:
- trovare difetti;
- acquisire confidenza circa il livello di qualità e ottenere opportune informazioni;
- prevenire i difetti.
Il test considerato come un task da concepire a fine sviluppo può assolvere, faticosamente e parzialmente, alla ricerca dei difetti, ma certamente non garantisce né confidenza né tantomeno prevenzione, le attività assolutamente più remunerative per abbassare il costo della 'non qualità'.
Se a questo aspetto sommiamo un’attitudine al confronto, da parte dei committenti (gli 'stakeholder'), su quanto richiesto da un progetto software (i famigerati requisiti), solo quando si ha realmente qualcosa da “vedere”, ossia da “testare”, capiamo come siano ampi i rischi e i relativi margini di miglioramento e abbattimento dei costi.
"Ho risolto il problema con l'outsourcing …"
Una delle situazioni più comuni che riscontriamo è lo sviluppo in outsourcing, nelle sue varie sfumature, dove l'affidamento dello sviluppo software a ditte specializzate nasconde in sé l'auspicio che chi fa di mestiere l'ingegnere del software sia dotato di robusti processi di verifica e validazione, efficienti ed efficaci, in grado di garantire elevata qualità a costi contenuti.
Il rischio in questi casi risiede nel livello di capacità di controllo in mano al committente e alla definizione delle regole del gioco in termini di standard, processi e deliverable.
La presenza di un deliverable contrattuale come il “test asset” non deve mai mancare; esso infatti induce necessariamente alla realizzazione del processo per produrlo, come avviene per il software, soddisfacendo in questo modo i requisiti di base per la realizzazione di un adeguato processo di assicurazione della qualità.
"Abbiamo definito una nostra metodologia… e strumenti”
Molti clienti sono oggi disillusi e pessimisti sul test “in house” perché non sono riusciti in passato ad ottenere dei benefici reali rispetto agli investimenti fatti, sia per una oggettiva complessità delle tecnologie adottate sia per troppa poca attenzione alle competenze specifiche e agli aspetti organizzativi.
Solo qualche anno fa correva l'idea che la tecnologia a supporto del test, in particolare per l'automazione, potesse “magicamente'” rappresentare la soluzione perfetta. Peccato che l'automazione consente di “far andare più veloce il test”, ma se dietro abbiamo il caos avremo solo l'effetto di un caos più veloce.
Nei casi dove sono state adottate o definite proprie metodologie per il test, spesso basate su standard documentali, si riscontrano aspettative poi disattese, normalmente per attività troppo onerose da seguire.
I punti chiave
Per arrivare a dei risultati concreti è necessaria una nuova consapevolezza dei reali benefici, superando la diffusa apatia o rassegnazione al tema della qualità, come se tutto fosse stato già provato e nulla più fosse possibile.
Spesso non si tratta di investire di più, ma di lavorare per fare meglio e di più con lo stesso investimento: si tratta di accorciare i tempi tra le diverse fasi di sviluppo, di recuperare le informazioni necessarie al momento giusto, e sfruttarle fino in fondo, di organizzare il lavoro per quando ci saranno i momenti di picco.
Serve sviluppare un approccio graduale, adatto alla propria realtà, supportato da professionisti del test e da un confronto con realtà che hanno già ottenuto e continuano ad ottenere i risultati sempre auspicati.
I temi a cui prestare l'attenzione maggiore sono:
- definire il cosa e il come “testare”, i propri standard, approcci e linee guida;
- sviluppare una comunicazione e confronto continuo;
- abilitare il controllo e trasparenza sulle esecuzioni dei test;
-tracciare i risultati e valorizzare ogni asset prodotto, soprattutto in termini di efficienza e riusabilità;
- introdurre l'automazione a fronte di benefici oggettivi;
- acquisire e coltivare le specifiche competenze.
Un approccio diverso della tecnologia
Cosa si richiede oggi dalla tecnologia a supporto? Riprendendo l'ultimo report di Gartner sul tema si evince come gli aspetti di punta siano la maggiore produttività e facilità d’uso (si ha sempre meno tempo e risorse), la capacità di riuso, il supporto alle nuove piattaforme, la completezza della soluzione, la sua flessibilità di impiego (ad esempio attraverso il cloud) e capacità di rispondere alle reali esigenze.
La fase di definizione dei requisiti è la prima a necessitare un approccio diverso della tecnologia, la quale deve innanzitutto offrire l'opportunità di 'toccare con mano' quanto desiderato e compreso, intervenendo al tempo stesso della loro definizione e superando qualsiasi barriera che ostacoli la comunicazione e collaborazione (linguaggio, tempo, …).
Agli strumenti di Test Management è riservato un ruolo centrale, con una particolare attenzione al massimo riuso e controllo del test, adeguandosi ai modelli di sviluppo utilizzati e consentendo di impostare il proprio progetto con metodologie basate sul controllo dei requisiti e del rischio e su obiettivi misurabili.
L'automazione del test oggi diventa un'opportunità solo se fruibile e realizzabile secondo i diversi profili professionali coinvolti, attraverso sia modalità di “scripting” avanzate sia modalità “visuali”, alla portata di tutti gli analisti e tester.
Il test prestazionale rimane sempre una delle necessità più evidenti, dove la tecnologia è essenziale. Oggi si richiede maggior flessibilità di impiego (ad esempio attraverso il cloud), a costi meno sostenuti, con sempre più facilità di utilizzo e continua evoluzione nel supporto alle piattaforme utilizzate, in particolar modo verso le applicazioni web 2.0 ed i sistemi Crm ed Erp, senza tralasciare le applicazioni del mondo legacy.
* = Application Management & Quality Specialist di Micro Focus Italia
