L’esecuzione di più test con meno risorse (esigenza divenuta ormai pressante in tutte le realtà aziendali e nelle software factory) richiede pianificazione e una capacità di esecuzione strategica, obiettivi difficili da raggiungere se ai team Qualità viene costantemente chiesto di fronteggiare situazioni di emergenza, oggi una costante determinata dalla velocità con cui si propagano trend quali mobility e cloud computing che innalzano di molto le aspettative degli utenti rispetto alla fruizione dei servizi applicativi.
Lo scenario più plausibile che si prospetta sul fronte Qa (Quality assurance) è quello che vede i team dedicati alla qualità del software ricorrere a un approccio al testing cosiddetto best effort, ossia fare il massimo possibile con le risorse di cui si dispone, nel tempo consentito, lasciando così poche risorse per l'investimento in strumenti, metodologie e sviluppo delle competenze. Ma è un approccio che, proprio in virtù dei nuovi trend, delle pressanti richieste da parte del business e delle aspettative degli utenti, potrebbe risultare fallimentare perché comporta un elevato rischio legato alla comparsa di problemi in seguito al rilascio in produzione delle applicazioni, situazione che potrebbe causare perdita di clienti, downtime di sistema o addirittura perdita di profitti.
Un framework per i processi di testing
L'automazione dei processi di test risulta un’ottima soluzione per ridurre i tempi di esecuzione, ma tale scelta comporta dei costi, a volte nascosti: con l’automazione, ad esempio, si creano generalmente più software e script di prova che necessitano di codifica, debug e manutenzione; a volte il tempo necessario per queste nuove attività si allunga perché devono essere eseguite da un tecnico più esperto.
Non solo, per comprendere la reale efficacia, è lecito avanzare considerazioni di carattere generale su altri errori comuni relativi ai test automatizzati:
– molti seguono una metodologia ad hoc, in cui ciascun tester utilizza un approccio limitato alle proprie esigenze personali e competenze;
– i test scritti per rispondere a esigenze immediate tendono a essere molto rigidi e benché siano in grado di far fronte correttamente al compito immediato, perdono di efficacia non appena l'applicazione testata necessita di modifiche;
– senza un'architettura di riferimento, i test iniziano a sovrapporsi tra loro nelle operazioni; gli stessi processi, ad esempio, vengono registrati/inseriti nello script ripetutamente comportando un doppio lavoro su cui eseguire attività di manutenzione;
– affinché il processo sia efficiente, è necessario che il software testato sia stabile per l'automazione. Se ci si concentra principalmente sui test di Gui (Graphic user interface), si eseguono solo test sull'ultima fase del ciclo, quando i bug sono più costosi da correggere;
– i business analysts scrivono e distribuiscono la maggior parte dei test manuali. Ciò crea un gap di comunicazione tra gli analisti (che comprendono i requisiti degli utenti) e gli specialisti dei test (che comprendono i requisiti dell'automazione). Inoltre, questo approccio fa sì che la costruzione dei test manuali e la costruzione degli script automatizzati siano due processi indipendenti, con una conseguente duplicazione del lavoro;
– benché l'automazione sia concepita per accelerare l'esecuzione dei test, mentre si scala, è facile che la manutenzione delle risorse di test manuali e automatizzate superi di gran lunga i vantaggi di questo approccio.
Per evitare problematiche di questo tipo, ridurre la manutenzione e accelerare la creazione dei test, molti professionisti scelgono quello che viene comunemente definito come un framework di test basato su componenti. Tale framework comporta la definizione di un processo di business e la relativa segmentazione in “blocchi logici” dove ciascun blocco rappresenta, in genere, un gruppo di azioni per eseguire un'attività. La procedura di login rappresenta, ad esempio, una serie di passaggi indipendenti che vengono utilizzati in molti casi di test. Questo esercizio permette di identificare gruppi di passaggi che possono essere suddivisi in componenti e riutilizzati in più test, allo stesso modo delle librerie condivise e degli oggetti nella programmazione object-oriented.
Il framework consente ai tester che desiderano costruire nuovi test, di “approfittare” del lavoro svolto in precedenza e utilizzare i componenti esistenti per assemblare un nuovo processo di test. Non solo, una metodologia simile consente di ridurre gli sforzi sul fronte della manutenzione. Lo vediamo spiegando un caso concreto: immaginiamo la schermata di accesso in cui viene richiesto il login all’utente; se questa venisse cambiata, tale modifica andrebbe apportata e moltiplicata per tutti i casi di test che si basano sull'accesso utente. Utilizzando un framework basato su componenti, sarà sufficiente aggiornare il componente dell’accesso utente una volta sola (tutti i test che utilizzano quel componente verranno aggiornati automaticamente).
Capire il proprio livello di maturità prima di agire
Nonostante i framework di questo tipo sembrino essere la soluzione ottimale per i problemi legati ai processi di test, la verità è che essi stessi diventano architetture dinamiche che necessitano di manutenzione e gestione costanti, come avviene anche per l’utilizzo dell’automazione che crea script su cui eseguire attività di manutenzione. Proprio come l’automazione, i framework necessitano di lavoro e pianificazione anticipati per funzionare correttamente e risultare efficaci, altrimenti il rischio è che si crei ulteriore complessità. Per affrontare l’automazione o la creazione di un framework è dunque necessario che l'organizzazione abbia raggiunto un buon livello di maturità.
Per comprendere a quale livello si può trovare un’azienda nella curva di maturità dei test funzionali, Hp ha identificato una sorta di tabella che potrebbe essere di supporto anche per trovare spunti al fine di passare eventualmente alla fase successiva e intraprendere un adeguato percorso verso un framework metodologico che risulti efficace rispetto al proprio contesto aziendale (figura 1).
