Testing software: Come scegliere e selezionare lo strumento di test
Scelta dello strumento
Nel processo di testing software, ci sono una varietà di problematiche diverse che un test manager deve considerare nella scelta di strumenti di test.
La scelta più comune è stata storicamente di acquistare uno strumento da un fornitore, che, in alcuni casi, può essere l’unica scelta praticabile. Tuttavia ci sono altre opzioni praticabili, come ad esempio strumenti open-source e strumenti personalizzati.
Indipendentemente dal tipo di strumento, un test manager deve essere attento a calcolare il “total cost of ownership” dello strumento per tutta la durata prevista, eseguendo una analisi costi-benefici. Questo argomento è trattato in seguito nella sezione sul ritorno degli investimenti (ROI, Return on Investment).
Strumenti open source
Per il testing software, sono disponibili strumenti open-source per quasi ogni aspetto del processo di testing, dalla gestione dei test case al tracciamento dei difetti, all’automazione dei test case, solo per citarne alcuni. Una differenza importante degli strumenti open-source è che, mentre lo strumento stesso non ha generalmente un elevato costo di acquisto iniziale, possono non essere forniti supporti formali per lo strumento stesso. Molti strumenti open-source, tuttavia, hanno persone disposte a fornire un supporto non tradizionale o informale agli utenti.
Inoltre, molti strumenti open-source sono stati originariamente creati per risolvere un problema specifico o indirizzare una singola tematica, per cui lo strumento non può normalmente fornire tutte le funzionalità di uno strumento simile di mercato. Per questo motivo, un’attenta analisi delle reali esigenze del gruppo di test deve essere eseguita prima di selezionare uno strumento open-source.
Uno dei vantaggi dell’utilizzo di strumenti open-source è che in genere possono essere modificati o estesi dai loro utenti. Se l’organizzazione di test ha le competenze di base, lo strumento può essere modificato per funzionare con altri strumenti o esteso per adattarsi alle esigenze del team di test. Più strumenti possono essere combinati per risolvere i problemi che gli strumenti di mercato non possono affrontare. Ovviamente, più numerosi sono gli strumenti utilizzati e più modifiche sono fatte, maggiore sarà la complessità e l’ overhead gestionale. Un test manager deve garantire che il team non inizi a utilizzare strumenti open-source solo per il gusto di usarli, ma, come per altri strumenti, lo sforzo deve essere sempre mirato a ottenere un ROI positivo.
Un test manager deve ben comprendere lo schema di “licensing” dello strumento selezionato. Molti strumenti open-source sono dotati di una variante della General Public License, che specifica che la distribuzione del software debba sottostare alle stessi condizioni del software originariamente ottenuto. Se il team di test dovesse apportare modifiche allo strumento per supportare meglio il loro test, questi cambiamenti dovrebbero essere messi a disposizione di tutti gli utenti esterni dello strumento sotto la licenza. Un test manager dovrebbe verificare le implicazioni legali di ridistribuire il software per la propria organizzazione.
Le aziende che sviluppano software di sicurezza o mission-critical, o che sono soggetti al rispetto di normative, possono avere problemi con l’utilizzo di strumenti open-source. Mentre molti strumenti open-source sono di qualità molto elevata, l’accuratezza di un dato strumento open-source non è probabilmente mai stata certificata. Gli strumenti di mercato sono spesso certificati per la loro accuratezza e idoneità ad un particolare compito. Benché la qualità di uno strumento open-source possa essere già buona, la certificazione, se richiesta, è di responsabilità del gruppo che lo utilizza, e può creare ulteriore overhead.
Strumenti personalizzati
L’organizzazione di testing può constatare di avere una specifica esigenza per la quale nessun strumento open-source o di mercato è disponibile. Le ragioni possono essere una piattaforma hardware proprietaria, un ambiente personalizzato od un processo che è stato modificato in un modo insolito. In questi casi, se nel team esiste la competenza di base, il test manager può prendere in considerazione lo sviluppo di uno strumento personalizzato.
I vantaggi di sviluppare e adottare uno strumento personalizzato sono che lo strumento può esattamente soddisfare le esigenze del team e che può operare in modo efficiente nel contesto richiesto. Lo strumento può essere realizzato per interfacciarsi con altri strumenti in uso e per generare i dati nel formato esatto richiesto dal team. Inoltre, lo strumento può avere utilizzi nell’organizzazione al di là del progetto in oggetto. Tuttavia, prima di pianificare l’esportazione dello strumento ad altri progetti, è importante rivedere in anticipo lo scopo, la portata, i vantaggi e gli svantaggi possibili.
Un test manager quando pensa di creare strumenti personalizzati, deve anche considerare le possibili problematiche negative. Uno strumento personalizzato dipende spesso dalla persona che lo crea. Pertanto, gli strumenti personalizzati devono essere adeguatamente documentati in modo che possano essere manutenuti da altri. Se questo non viene fatto, gli strumenti possono diventare orfani e cadere in disuso quando il creatore dello strumento abbandona il progetto. Nel corso del tempo, gli strumenti personalizzati possono avere il loro campo di applicazione esteso al di là del loro intento iniziale, il che può causare problemi di qualità nello strumento, che portano a segnalazioni di difetti falsi positivi od alla creazione di dati inesatti. Il test manager deve tenere a mente che uno strumento personalizzato non è altro che un ulteriore prodotto software, e come tale, soggetto allo stesso tipo di problematiche dello sviluppo. Gli strumenti personalizzati devono essere progettati e testati per assicurarsi che funzionino come previsto.
Processo di scelta e selezione
Gli strumenti di test sono un investimento a lungo termine, che si estende probabilmente su numerose iterazioni di un singolo progetto e su numerosi altri progetti. Un test manager deve considerare uno strumento da acquisire da diversi punti di vista:
- Per il business, un ROI positivo è necessario. Al fine di ottenere un valore elevato di ritorno degli investimenti, l’organizzazione deve garantire che quegli strumenti che devono interoperare, che possono comprendere sia gli strumenti di test che strumenti non di test, possano effettivamente lavorare insieme. In alcuni casi per realizzare l’interoperabilità occorre migliorare i processi e la connettività di utilizzo dello strumento, e ciò può richiedere un certo tempo.
- Per il progetto, lo strumento deve essere efficace (ad esempio: evitare errori nell’esecuzione di test manuali, come ad esempio errori di battitura durante l’immissione dei dati). Lo strumento può richiedere un rilevante periodo di tempo per iniziare a ottenere un ROI positivo. In molti casi, il ROI positivo può manifestarsi nel secondo rilascio o durante la manutenzione, piuttosto che nel progetto iniziale, in cui è stata attuata l’automazione. Il test manager dovrebbe prendere in considerazione il ciclo di vita totale dello strumento.
- Per l’utilizzatore dello strumento, esso deve supportare il personale del progetto a svolgere il proprio compito in modo più efficiente e più efficace. Pertanto deve essere considerata la curva di apprendimento delle modalità d’utilizzo, altrimenti l’introduzione dello strumento può provocare solo stress e disaffezione. Gli strumenti di test, quando vengono adottati, richiedono una formazione ed un tutoraggio degli utilizzatori.
Al fine di garantire che tutti i punti di vista siano presi in considerazione, è importante creare una roadmap per l’adozione dello strumento di test.
