Il test ad hoc è un tipo di test del software che gli sviluppatori e le aziende di software attuano quando controllano l’iterazione corrente del software. Questa forma di test offre un livello maggiore di comprensione del programma, individuando problemi che i test convenzionali potrebbero non essere in grado di evidenziare.
È fondamentale che i team di testing abbiano una comprensione completa del processo di testing ad hoc, in modo da sapere come aggirare le sue sfide e assicurarsi che il team possa implementare con successo questa tecnica.
Sapere esattamente come funzionano i test ad hoc e quali strumenti possono facilitarne l’implementazione consente a un’azienda di migliorare continuamente le proprie procedure di garanzia della qualità. Il processo di test formale segue regole molto specifiche, che potrebbero far sì che il team si lasci sfuggire alcuni bug: i controlli ad hoc possono aggirare questi punti ciechi e testare rapidamente ogni funzionalità del software.
In questo articolo esaminiamo da vicino i test ad hoc e come utilizzarli a proprio vantaggio nello sviluppo di un prodotto software.
Significato dei test ad hoc: Che cos’è il test ad hoc?
Il test ad hoc è un processo di garanzia della qualità che evita regole e documentazione formali, aiutando i tester a trovare errori nell’applicazione che gli approcci convenzionali non sono in grado di identificare. Ciò richiede in genere una conoscenza completa del software prima dell’inizio del test, compresa la comprensione del funzionamento interno del programma. Questi controlli ad hoc mirano a rompere l’applicazione in modi che riflettono l’input dell’utente, tenendo conto di varie situazioni potenziali in modo che gli sviluppatori possano correggere eventuali problemi esistenti.
La mancanza di documentazione è il punto centrale di questa tecnica, che non prevede liste di controllo o casi di test per guidare i tester attraverso le funzionalità di un’applicazione. Il test ad hoc consiste nel testare il software nel modo in cui il team decide di essere efficace in quel momento specifico. Questo potrebbe tenere conto di test formali preesistenti, ma potrebbe anche semplicemente comportare la conduzione del maggior numero possibile di test nel tempo (probabilmente limitato) assegnato a questa tecnica.
1. Quando e perché è necessario eseguire test ad hoc nel testing del software?
Il motivo principale per cui le aziende conducono test ad hoc è la capacità di scoprire errori che gli approcci tradizionali non sono in grado di individuare. Ciò potrebbe essere dovuto a diverse ragioni, come ad esempio il fatto che i casi di test convenzionali seguono un processo particolarmente standardizzato che non può tenere conto delle idiosincrasie di un’applicazione.
Ogni tipo di test può offrire nuove prospettive e approcci interessanti all’assicurazione della qualità, mostrando anche i problemi della strategia di test abituale. Ad esempio, se i test ad hoc possono identificare un problema che i casi di test del team non affrontano, ciò suggerisce che potrebbe essere utile ricalibrare la metodologia di test.
I tester possono effettuare controlli ad hoc in qualsiasi momento del processo di test. In genere questo serve come complemento alla tradizionale (e più formale) assicurazione della qualità e, in quest’ottica, i tester possono eseguire ispezioni ad hoc mentre i loro colleghi conducono esami più formali. Tuttavia, è possibile che preferiscano conservare i controlli ad hoc fino a dopo il processo di test formale, come follow-up che si rivolge specificamente ai potenziali punti ciechi.
I test ad hoc possono essere utili anche quando il tempo a disposizione è particolarmente limitato a causa della mancanza di documentazione – il momento giusto dipende dall’azienda e dal suo approccio preferito.
2. Quando non è necessario eseguire test ad hoc
Se non c’è tempo sufficiente per eseguire sia i test ad hoc che quelli formali, è importante che il team dia priorità a questi ultimi, in quanto assicurano una copertura di test sostanziale, anche se esistono ancora delle lacune.
Se i test formali del team trovano bug che devono essere risolti, in genere è meglio aspettare che gli sviluppatori completino le modifiche necessarie per effettuare controlli ad hoc. Altrimenti, i risultati che forniscono potrebbero diventare presto obsoleti, soprattutto se i test si riferiscono a componenti già affetti da bug.
Inoltre, prima della fase di beta testing, devono essere eseguiti test ad hoc.
3. Chi è coinvolto nei test ad hoc?
Nel processo di test Ad-Hoc sono coinvolti diversi ruoli chiave, tra cui:
– I tester software sono i principali membri del team che effettuano controlli ad hoc. Se si esegue il buddy o il pair testing, diversi di questi tester lavoreranno insieme sugli stessi componenti.
– Gli sviluppatori possono utilizzare autonomamente questi controlli prima della fase formale di garanzia della qualità per ispezionare rapidamente il proprio software, anche se in modo meno approfondito rispetto ai test ad hoc.
– I responsabili dei team o dei reparti autorizzano la strategia di test complessiva, aiutando i tester a determinare quando iniziare i test ad hoc e come eseguirli senza interrompere gli altri controlli.
Vantaggi dei test ad hoc
I vantaggi dei test ad hoc nel testing del software includono:
1. Risoluzioni rapide
Poiché questi test non richiedono una documentazione frequente prima, durante o dopo le verifiche, i team possono identificare i problemi molto più rapidamente. Questa semplicità offre un’enorme libertà ai tester.
Ad esempio, se si testa un componente e non si riesce a identificare alcun errore, il team può semplicemente passare al test successivo senza annotarlo in un documento.
2. Completa altri tipi di test
Nessuna strategia di test è perfetta e il 100% di copertura è solitamente impossibile da raggiungere, anche con un programma completo. Ci saranno sempre delle lacune nei test convenzionali, quindi è importante che le aziende integrino più approcci.
I test ad hoc mirano specificamente a trovare i problemi che i test formali non sono in grado di coprire, garantendo una più ampia copertura complessiva dei test.
3. Esecuzione flessibile
I test ad hoc possono essere eseguiti in qualsiasi momento del processo di garanzia della qualità prima del beta testing, consentendo alle aziende e ai team di decidere quando è meglio eseguire questi controlli. Si può scegliere di eseguire test ad hoc insieme a quelli convenzionali o di aspettare fino a un secondo momento: in ogni caso, il team trae vantaggio dalle scelte a sua disposizione.
4. Maggiore collaborazione
Gli sviluppatori sono maggiormente coinvolti in questo processo rispetto a molte altre forme di test, soprattutto se l’azienda utilizza il buddy e il pair testing.
Di conseguenza, gli sviluppatori ottengono una migliore comprensione delle proprie applicazioni e potrebbero essere in grado di risolvere i bug con uno standard più elevato. Ciò contribuisce a migliorare ulteriormente la qualità complessiva del software.
5. Prospettive diverse
I test ad hoc possono mostrare l’applicazione da nuove angolazioni, aiutando i tester a confrontarsi con queste funzionalità in modi nuovi. Ulteriori prospettive sono fondamentali durante i test, poiché i controlli formali spesso presentano lacune minime.
Se i tester ad hoc utilizzano il software con l’intento specifico di romperlo, saranno in grado di individuare più facilmente i limiti del programma.
Le sfide dei test ad hoc
Il processo di test ad hoc presenta anche diverse sfide, quali:
1. Difficoltà di segnalazione
La mancanza di documentazione rende i test ad hoc molto più veloci, ma può anche rendere difficile la segnalazione di problemi diversi da quelli più gravi.
Ad esempio, un controllo condotto in precedenza potrebbe diventare più rilevante in un secondo momento, nonostante inizialmente non abbia portato a risultati significativi. Senza una documentazione completa, il team potrebbe non essere in grado di spiegare questi test.
2. Meno ripetibile
Analogamente, i tester potrebbero non essere pienamente consapevoli dell’esatta condizione necessaria per provocare le reazioni che osservano. Ad esempio, un controllo ad hoc che restituisce un errore potrebbe non avere informazioni sufficienti per consentire al team di intervenire. Potrebbero non sapere come ripetere il test e ottenere lo stesso risultato.
3. Richiede esperienza nel software
Poiché la velocità è fondamentale in tutti i test ad hoc e di solito comporta il tentativo di rompere l’applicazione, è importante che questi tester abbiano una conoscenza approfondita del programma.
Sapere come funziona permette ai tester di rompere e manipolare il software in più modi, ma questo potrebbe aumentare significativamente la richiesta di competenze per i test ad hoc.
4. Responsabilità limitata
La mancanza di documentazione può causare più di un semplice problema di reportistica scadente; può anche allungare inavvertitamente il processo di test, compromettendo l’utilità di singoli test rapidi ad hoc.
I tester possono avere difficoltà a tenere traccia dei loro progressi senza una documentazione sufficiente in ogni fase. Questo può anche portarli a ripetere un controllo che altri tester hanno già completato.
5. Può non riflettere l’esperienza dell’utente
L’obiettivo di quasi tutti i tipi di test è quello di individuare gli errori che influiscono in qualche modo sugli utenti finali. I test ad hoc si basano principalmente su un tester esperto che tenta di emulare un utente inesperto e questo dovrebbe essere coerente in ogni verifica, compresi i tentativi di rompere l’applicazione.
Caratteristiche dei test ad hoc
Le caratteristiche principali dei test ad hoc di successo sono:
1. Investigativo
La priorità principale dei test ad hoc è quella di identificare gli errori dell’applicazione utilizzando tecniche che i controlli convenzionali non tengono in considerazione. Esami ad hoc setacciano il software con l’esplicito scopo di trovare falle nella procedura di test del team, compresa la copertura dei casi di test.
2. Non strutturato
I controlli ad hoc di solito non hanno un piano prestabilito, se non quello di condurre il maggior numero possibile di test al di fuori dei limiti tipici dell’assicurazione formale della qualità. In genere i tester raggruppano i controlli per componente per comodità, ma anche questo non è necessario: potrebbero addirittura ideare i controlli mentre li eseguono.
3. Guidati dall’esperienza
I tester ad hoc utilizzano la loro esperienza preesistente nel software per valutare quali sono i test che possono apportare i maggiori benefici e affrontare i punti ciechi comuni nei test formali.
Sebbene il processo di test sia ancora completamente destrutturato, i tester applicano la loro conoscenza dei precedenti controlli ad hoc, tra gli altri, mentre decidono la loro strategia.
4. Ampio raggio
Non esistono indicazioni precise su quali controlli il team debba eseguire durante i test ad hoc, ma in genere coprono una serie di componenti, possibilmente concentrandosi maggiormente sugli aspetti più sensibili dell’applicazione. Questo aiuta i tester a garantire che i loro esami siano in grado di integrare pienamente i test formali.
Cosa testiamo nei test ad hoc?
I team di garanzia della qualità di solito verificano i seguenti aspetti durante i test ad hoc:
1. Qualità del software
Questi controlli mirano a identificare gli errori dell’applicazione che i test convenzionali non sono in grado di individuare; ciò significa che il processo verifica principalmente la salute generale dell’applicazione.
Più bug riescono a individuare i test ad hoc, più miglioramenti possono essere implementati dagli sviluppatori prima della scadenza.
2. Casi di test
In genere, i test ad hoc non implementano i casi di test, proprio per consentire al team di verificare quanto siano efficaci nel fornire un’ampia copertura. I casi di test sono probabilmente inadeguati se i controlli ad hoc possono trovare errori che i processi di test convenzionali non riescono a trovare.
3. Personale addetto ai test
L’obiettivo potrebbe anche essere quello di verificare le competenze e le conoscenze del team di test, anche se i casi di test sono adeguati. Ad esempio, la loro metodologia di implementazione dei casi potrebbe essere insufficiente e i test ad hoc potrebbero essere fondamentali per colmare le lacune risultanti nella copertura dei test.
4. Limiti del software
I test ad hoc cercano anche di capire i limiti dell’applicazione, ad esempio come risponde a input inaspettati o a carichi di sistema elevati. I tester potrebbero analizzare in modo specifico i messaggi di errore del programma e le prestazioni dell’applicazione in caso di pressione significativa.
Per chiarire un po’ di confusione:
Test ad hoc e test esplorativi
Alcuni considerano i test ad hoc e quelli esplorativi come sinonimi, anche se la verità è più complicata.
1. Che cos’è il test esplorativo?
I test esplorativi si riferiscono a procedure di garanzia della qualità che analizzano il software da un punto di vista olistico e combinano in modo specifico i processi di scoperta e di test in un unico metodo. Si tratta in genere di una via di mezzo tra i test completamente strutturati e i controlli ad hoc completamente liberi.
I test esplorativi funzionano meglio in scenari specifici, ad esempio quando è necessario un feedback rapido o se il team deve affrontare casi limite. Questo tipo di test di solito raggiunge il suo pieno potenziale quando il team lo affianca con test scriptati.
2. Differenze tra test esplorativi
e test ad hoc
La principale distinzione tra i test ad hoc e quelli esplorativi è l’uso della documentazione per registrare e facilitare i controlli, mentre i test ad hoc li evitano completamente. I test esplorativi pongono maggiore enfasi sulla libertà di test, ma mai allo stesso livello di un approccio ad hoc, completamente destrutturato.
I test esplorativi comportano anche l’apprendimento dell’applicazione e del suo funzionamento interno durante questi controlli – i tester ad hoc invece hanno spesso una conoscenza completa delle funzionalità del software prima di iniziare.
Tipi di test ad hoc
Esistono tre forme principali di test ad hoc nel testing del software, tra cui:
1. Test sulle scimmie
Forse il tipo più popolare di test ad hoc, i monkey test sono quelli che coinvolgono un team che esamina casualmente diversi componenti.
Questo avviene tipicamente durante il processo di test unitario e mette in atto una serie di controlli senza alcun caso di test. I tester analizzano in modo indipendente i dati in maniera completamente destrutturata, consentendo loro di esaminare il sistema nel suo complesso e la sua capacità di resistere alle intense sollecitazioni degli input degli utenti.
L’osservazione dell’output di queste tecniche non scritte aiuta il team di testing a identificare gli errori che altri test unitari hanno mancato a causa delle carenze dei metodi di testing convenzionali.
2. Test del compagno
In un contesto ad hoc, i buddy test utilizzano un minimo di due membri dello staff – tipicamente un tester e uno sviluppatore – e si svolgono principalmente dopo la fase di unit testing. I “compagni” lavorano insieme sullo stesso modulo per individuare gli errori. Le loro diverse competenze e la loro vasta esperienza li rendono un team più efficace, che contribuisce ad alleviare molti dei problemi che sorgono a causa della mancanza di documentazione.
Lo sviluppatore potrebbe addirittura suggerire lui stesso alcuni dei test, consentendo di identificare i componenti che potrebbero necessitare di maggiore attenzione.
3. Test a coppie
Il test a coppie è simile in quanto coinvolge due membri del personale, ma di solito si tratta di due tester separati, uno dei quali esegue i test veri e propri mentre l’altro prende appunti.
Anche senza una documentazione formale, l’annotazione può consentire al team di tenere informalmente traccia di singoli controlli ad hoc. I ruoli di tester e scriba possono essere scambiati a seconda del test, oppure la coppia può mantenere i ruoli assegnati durante l’intero processo.
Il tester con maggiore esperienza è in genere quello che esegue i controlli veri e propri, anche se il lavoro viene sempre condiviso tra loro.
Test ad hoc manuali o automatizzati?
I test automatizzati possono aiutare i team a risparmiare ancora più tempo durante la fase di garanzia della qualità, consentendo ai tester di inserire più controlli nella loro agenda. Anche senza una struttura definita, è essenziale che i tester lavorino per massimizzare la copertura e l’automazione incoraggi ispezioni più approfondite di questo software.
I controlli automatici ad hoc sono in genere più accurati dei test manuali grazie alla loro capacità di evitare l’errore umano durante le attività routinarie, il che è particolarmente utile quando si eseguono gli stessi test in iterazioni diverse. Il successo di questa procedura dipende solitamente dallo strumento di test automatico scelto dal team e dalle sue funzionalità.
Tuttavia, i test automatizzati presentano alcune limitazioni. Ad esempio, il principale punto di forza dei test ad hoc è la capacità di emulare l’input dell’utente e di eseguire controlli casuali man mano che il tester li propone. Questi test potrebbero perdere la loro casualità se il programma di test dell’organizzazione è alle prese con controlli complessi.
Il tempo necessario per automatizzare queste attività altamente specifiche potrebbe anche limitare il risparmio di tempo tipico di questo processo. È importante che i team analizzino a fondo gli strumenti di automazione disponibili per trovarne uno adatto al progetto della loro azienda.
Di cosa avete bisogno per iniziare i test ad hoc?
Ecco i principali prerequisiti dei test ad hoc:
1. Personale qualificato
Poiché i test ad hoc sono ispezioni rapide e casuali del funzionamento interno del software, in genere è utile avere tester che abbiano esperienza con il software. Dovrebbero inoltre avere una conoscenza pratica dei principi chiave del testing, che consenta loro di identificare facilmente i controlli più efficaci.
2. Un approccio non strutturato
I tester devono essere disposti ad abbandonare le loro strategie abituali di test ad hoc; questa mentalità è fondamentale quanto i controlli di qualità stessi. Questo metodo può avere successo solo senza struttura o documentazione ed è fondamentale che i tester lo ricordino in ogni fase.
3. Software di automazione
Anche se i test ad hoc si basano maggiormente sulla verifica di input e condizioni casuali, l’automazione è comunque una tecnica molto efficace in qualsiasi contesto.
Per questo motivo, i controlli ad hoc dovrebbero comunque implementare, ove possibile, strumenti di test automatizzati, poiché l’applicazione giusta può semplificare notevolmente il processo.
4. Altre forme di test
I test ad hoc funzionano meglio insieme ad altri controlli che adottano un approccio più formale, aiutando il team a garantire una copertura sostanziale del software. È fondamentale che i tester mescolino varie tecniche, anche se questo può avvenire prima, durante o dopo aver completato i test ad hoc.
Processo di test ad hoc
I passi abituali che i tester dovrebbero seguire quando eseguono test ad hoc nel test del software sono:
1. Definizione di obiettivi di test ad hoc
Questa fase è limitata a causa della mancanza di documentazione e struttura, ma è comunque fondamentale che il team abbia un obiettivo chiaro. I tester possono iniziare a condividere idee vaghe sui test da eseguire e sui componenti a cui dare priorità.
2. Selezione del team di test ad hoc
Mentre il team elabora una serie di potenziali controlli ad hoc, si cerca anche di capire quali sono i tester più adatti a questo tipo di verifiche. Di solito selezionano tester che conoscono a fondo l’applicazione e possono anche affiancarli a uno sviluppatore.
3. Esecuzione di test ad hoc
Dopo aver deciso quali tester sono adatti a questa fase, questi membri del team iniziano i loro controlli in un punto concordato del test. Il loro obiettivo è quello di eseguire il maggior numero possibile di controlli ad hoc, che i tester potrebbero non concepire fino a questa fase.
4. Valutazione dei risultati del test
Al termine dei test (o anche tra un controllo e l’altro) i tester valutano i risultati, ma senza documentarli formalmente in un caso di test. Se scoprono problemi con l’applicazione, li registrano in modo informale e discutono i passi successivi del team.
5. Segnalazione di eventuali bug scoperti
Una volta valutati i risultati, i tester devono informare gli sviluppatori degli errori presenti nel software, in modo che abbiano tutto il tempo di risolverli prima del rilascio.
Il team di test utilizza le informazioni anche per determinare come migliorare i processi di test formali.
6. Se necessario, ripetere i test
Il team di test probabilmente ripeterà il processo ad hoc per le nuove iterazioni dell’applicazione, per verificare la capacità di gestire gli aggiornamenti. Poiché i tester avranno risolto molte delle lacune precedentemente identificate nei loro casi di test, i futuri controlli ad hoc potrebbero richiedere un approccio diverso.
Migliori pratiche per i test ad hoc
Ci sono alcune pratiche che i team di test dovrebbero attuare durante i test ad hoc, tra cui:
1. Individuare le potenziali lacune dei test
Sebbene i test ad hoc comportino una pianificazione molto minore rispetto ad altri tipi di test, il team mira comunque a colmare le lacune della garanzia di qualità. Se i tester ad hoc sospettano qualche problema specifico con i casi di test del team, devono dare priorità a questo aspetto durante le loro verifiche.
2. Considerare il software di automazione
Le strategie di automazione come l’iperautomazione possono offrire molti vantaggi alle aziende che desiderano condurre test ad hoc.
Il successo dipende da diversi fattori chiave, tra cui lo strumento scelto dall’azienda e la complessità generale dei test ad hoc.
3. Prendere appunti completi
La mancanza di documentazione nei test ad hoc serve soprattutto a snellire ulteriormente questo processo: il team potrebbe trarre vantaggio dal prendere appunti informali mentre procede. In questo modo i collaudatori hanno una chiara registrazione di questi controlli e dei loro risultati, aumentando la ripetibilità complessiva.
4. Continuare a perfezionare i test
I tester ad hoc affinano continuamente il loro approccio per tenere conto dei cambiamenti nella strategia di test del team. Quando si esaminano le nuove versioni del software aziendale, ad esempio, si possono adattare questi controlli in risposta a nuovi e più completi casi di test formali.
7 errori e trabocchetti nell’implementazione
Test ad hoc
Come in ogni processo di test, esiste un’ampia gamma di potenziali errori che il team deve lavorare per evitare, come ad esempio:
1. Tester inesperti
Per mantenere il ritmo previsto dei test ad hoc, il team leader deve assegnare i tester in base alle loro conoscenze e competenze. Mentre molte forme di test possono essere eseguite da personale di assicurazione della qualità di livello base, i controlli ad hoc richiedono membri del team che conoscano a fondo il software, preferibilmente con esperienza nell’esecuzione di questi test.
2. Controlli non mirati
I test ad hoc possono migliorare significativamente la copertura dei test grazie alla loro rapidità: il team non ha bisogno di compilare un’ampia documentazione prima e dopo ogni verifica.
Tuttavia, i tester ad hoc devono mantenere una forte attenzione; ad esempio, potrebbero decidere di dare priorità ad alcuni componenti con un maggiore rischio di fallimento.
3. Nessuna pianificazione
Evitare qualsiasi piano potrebbe limitare l’efficacia dei test ad hoc. Nonostante la natura non strutturata di questo approccio, è importante che il team abbia un’idea di massima dei test da eseguire prima di iniziare.
Il tempo è limitato durante questo processo e sapere come procedere può offrire molti vantaggi.
4. Eccessivamente strutturato
All’estremo opposto, questo approccio si basa tipicamente sulla mancanza di pianificazione, in quanto aiuta i tester a sovvertire attivamente i casi di test e a trovare errori nascosti.
I test ad hoc sono noti anche come test casuali e la forzatura di una struttura potrebbe impedire a questi controlli di individuare i bug.
5. Nessuna modifica a lungo termine
Lo scopo dei test ad hoc è quello di identificare eventuali punti deboli nei casi di test del team; in questo modo si esamina la loro strategia complessiva tanto quanto il software stesso.
Tuttavia, ciò significa che i test ad hoc sono generalmente efficaci solo se il team utilizza queste informazioni per affinare i controlli formali nel tempo.
6. Insiemi di dati incompatibili
Praticamente ogni forma di test richiede una forma di dati simulati per valutare la risposta dell’applicazione; alcuni strumenti consentono ai tester di popolare automaticamente un programma con dati simulati.
Tuttavia, questo potrebbe non rispecchiare il modo in cui un utente utilizzerebbe il software: i controlli ad hoc richiedono set di dati che il software probabilmente incontrerà.
7. Silos informativi
È essenziale che i tester e gli sviluppatori siano in costante comunicazione tra loro, anche se questi ultimi non fanno parte del processo di test ad hoc.
Questo aiuta tutti a capire quali test sono stati eseguiti, indicando le azioni successive da intraprendere e impedendo ai tester di ripetere inutilmente alcuni controlli.
Tipi di risultati dei test ad hoc
I controlli ad hoc producono diversi output distinti, tra cui:
1. Risultati del test
I singoli test producono risultati diversi a seconda dell’esatto componente e dell’approccio coinvolto, che può assumere diverse forme.
Di solito è responsabilità del tester determinare se i risultati costituiscono un errore, anche se la mancanza di documentazione rende difficile il confronto con le aspettative. Il team trasmette questi risultati agli sviluppatori se nota qualche problema.
2. Registri di prova
Il software stesso utilizza un complicato sistema di registri interni per monitorare gli input dell’utente ed evidenziare una serie di problemi di file o database che potrebbero emergere.
Questo potrebbe indicare un errore interno, compresa la parte specifica del software che causa il problema. Con queste informazioni, i tester e gli sviluppatori ad hoc possono affrontare i problemi che scoprono molto più facilmente.
3. Messaggi di errore
Molti controlli ad hoc mirano specificamente a rompere il software e ad esporne i limiti, il che significa che i messaggi di errore dell’applicazione sono uno dei risultati più comuni di questi test.
Provocando deliberatamente messaggi di errore, il team può mostrare ciò che l’utente finale medio vede ogni volta che le azioni inaspettate che compie hanno un effetto negativo sul funzionamento del programma.
Esempi di test ad hoc
Ecco tre scenari di test ad hoc che mostrano come un team potrebbe implementarli per diverse applicazioni:
1. Applicazione web di commercio elettronico
Se un’azienda desidera testare un’applicazione web basata sull’ecommerce, può utilizzare test ad hoc, in particolare il monkey test, per verificare la capacità della piattaforma di gestire le interazioni impreviste degli utenti.
I tester possono cercare di spingere ogni funzione al limite, ad esempio aggiungendo articoli al carrello in quantità non realistiche o cercando di acquistare prodotti non disponibili. Non sono vincolati dai casi di test del team e ci sono pochi limiti ai controlli che possono eseguire; i tester potrebbero anche cercare di completare gli acquisti utilizzando URL obsoleti.
2. Applicazione desktop
I tester ad hoc possono anche implementare queste tecniche per le applicazioni desktop, concentrandosi eventualmente su macchine diverse e sulla loro capacità di accogliere il programma.
I membri del team potrebbero eseguire questi controlli ripetutamente per vedere come la modifica delle impostazioni hardware o software influisce sulle prestazioni complessive di un’applicazione. Ad esempio, una scheda grafica specifica potrebbe avere difficoltà a renderizzare l’interfaccia.
In alternativa, questi tester potrebbero semplicemente dare al programma input impossibili e vedere come risponde, ad esempio se è in grado di visualizzare correttamente messaggi di errore che spieghino adeguatamente il problema all’utente finale.
3. Applicazione mobile
Un modo in cui i tester ad hoc potrebbero esaminare un’applicazione mobile è quello di verificarne i protocolli di sicurezza: potrebbero provare ad accedere direttamente agli strumenti di sviluppo dell’applicazione, ad esempio.
Il team può cercare di capire se è in grado di eseguire azioni non autorizzate trovando falle ed exploit comuni; potrebbe chiedere specificamente ai membri del personale con esperienza nella sicurezza delle app di facilitare questa operazione.
Questo potrebbe anche comportare un test in coppia con gli sviluppatori, grazie alla loro conoscenza del design dell’applicazione, consentendo a un tester di rompere il software e di mostrare esattamente dove la sicurezza è carente.
Tipi di errori e bug rilevati
attraverso test ad hoc
I controlli ad hoc possono portare alla luce molti problemi di un programma, ad esempio:
1. Errori di funzionalità
L’utilizzo di test ad hoc per esaminare le funzionalità di base di un’applicazione potrebbe rivelare gravi bug che influenzano il modo in cui gli utenti finali possono interagire con essa.
Ad esempio, il test delle opzioni di pagamento di un sito di e-commerce illustrerà le condizioni che impediscono la transazione.
2. Problemi di prestazioni
I tester possono lavorare specificamente per creare problemi di prestazioni nel programma, ad esempio riempiendo il database con vari input di spam.
Questo potrebbe manifestarsi come un ritardo significativo o addirittura un’instabilità generale del software, che probabilmente porterà a un crash (potenzialmente a livello di sistema).
3. Problemi di usabilità
Questi controlli potrebbero anche evidenziare difetti dell’interfaccia e dell’esperienza generale dell’utente. L’interfaccia utente di un’applicazione mobile, ad esempio, potrebbe presentarsi in modo diverso su un altro sistema operativo o risoluzione dello schermo. Un’interfaccia scadente può portare gli utenti ad avere difficoltà nell’utilizzo dell’applicazione.
4. Difetti di sicurezza
La natura casuale dei test ad hoc consente di coprire una serie di problemi di sicurezza comuni e rari; un tester potrebbe usare questi controlli per trovare le backdoor amministrative di un programma.
In alternativa, la loro ispezione può mostrare che il software non ha alcuna crittografia dei dati.
Metriche comuni di test ad hoc
I test ad hoc utilizzano varie metriche per facilitare i risultati, tra cui:
1. Efficienza di rilevamento dei difetti
Questa metrica analizza l’efficacia del processo di testing nel trovare i difetti in ogni forma di testing, compresi i test ad hoc. L’efficienza del rilevamento dei difetti è la percentuale di difetti scoperti divisa per il numero totale di problemi, che mostra l’efficacia dei test.
2. Tasso di copertura del test
Una funzione ausiliaria dei test ad hoc è quella di aumentare la copertura controllando i componenti in un modo che i casi di test non tengono in considerazione. Ciò significa che i tester mireranno anche ad aumentare radicalmente la copertura dei test in ogni controllo, per quanto possibile.
3. Durata totale del test
I test ad hoc sono molto più rapidi di altri processi di garanzia della qualità ed è essenziale che i tester lavorino per mantenere questo vantaggio. Le metriche sulla durata dei test mostrano ai membri del team come possono risparmiare tempo e come possono aumentare ulteriormente i vantaggi delle strategie ad hoc.
4. Tasso di incidenti
Questi test spesso mirano a rompere il software e a causare un crash o un errore grave, consentendo di andare oltre le tipiche strategie di test e di trovare problemi inaspettati. A tal fine, può essere utile sapere quanto spesso il software si blocca e quali sono le cause di questi problemi.
5 migliori strumenti di test ad hoc
Esistono molti strumenti di test gratuiti e a pagamento per l’esecuzione di test ad hoc nel collaudo del software: i cinque migliori sono i seguenti:
1. ZAPTEST Edizione gratuita e aziendale
ZAPTEST è un programma completo per il test del software che offre un livello elevato di funzionalità di test e RPA sia nella versione gratuita che in quella aziendale.
Questa suite full-stack di automazione del software e RPA consente di eseguire test completi su diverse piattaforme desktop e mobili; la tecnologia 1SCRIPT del software consente inoltre agli utenti di eseguire gli stessi controlli ripetutamente con facilità. Inoltre, lo strumento sfrutta lo stato dell’arte della computer vision, che consente a ZAPTEST di eseguire test ad hoc da una prospettiva umana.
2. BrowserStack
BrowserStack è una piattaforma cloud che può facilitare i test su oltre 3.000 macchine diverse, con la caratteristica aggiuntiva di automatizzare gli script Selenium. Sebbene fornisca una forte copertura per i progetti software, funziona meglio con le applicazioni per browser e per dispositivi mobili.
Le soluzioni di testing BrowserStack includono anche una prova gratuita con 100 minuti di test automatizzati, anche se l’uso potrebbe essere limitato.
Sebbene l’approccio basato sul cloud possa essere utile, influisce negativamente sui tempi di risposta della piattaforma.
3. LambdaTest
LambdaTest utilizza una tecnologia basata sul cloud e pone una forte enfasi sui test dei browser, il che potrebbe limitare la sua efficacia per altre applicazioni, anche se si adatta bene ai programmi iOS e Android. È una piattaforma utile quando la scalabilità è un problema e si integra con molti altri servizi di hosting di test.
Tuttavia, alcuni utenti hanno avuto reazioni contrastanti riguardo ai prezzi dell’applicazione tra le varie opzioni non di prova disponibili, limitando potenzialmente l’accessibilità per le organizzazioni più piccole.
4. TestRail
TestRail è generalmente abbastanza adattabile grazie all’esecuzione interamente in browser e, nonostante la forte attenzione ai casi di test efficienti, vanta anche funzionalità dirette ad hoc. L’analisi che fornisce dopo ogni test può anche aiutare i team che evitano attivamente di creare la propria documentazione indipendente, consentendo loro di convalidare il processo di test.
Tuttavia, le suite più grandi potrebbero avere problemi con il formato basato su browser, che può limitare in modo significativo il risparmio di tempo dei test ad hoc.
5. Zefiro
Zephyr è una piattaforma di gestione dei test di SmartBear che aiuta i team di assicurazione della qualità a migliorare la visibilità dei test, integrandosi bene con altri software di bug-tracking.
Tuttavia, questa funzione è limitata ad alcune applicazioni, tra le quali Confluence e Jira sono quelle che traggono i maggiori benefici da Zephyr, che potrebbe non essere la soluzione più efficace per tutte le aziende. Con il marchio Zephyr sono disponibili diversi programmi scalabili a prezzi diversi.
Lista di controllo, suggerimenti e trucchi per i test ad hoc
Ecco altri suggerimenti che i team devono tenere in considerazione quando conducono test ad hoc:
1. Privilegiare i componenti sensibili
Alcune caratteristiche o componenti sono naturalmente più a rischio di errore di altre, soprattutto se sono importanti per il funzionamento complessivo del programma.
Ogni approccio ai test dovrebbe identificare le parti di un’applicazione che possono beneficiare di un’attenzione più approfondita. Questo è particolarmente utile quando il tempo a disposizione per i test è limitato.
2. Esaminare i diversi strumenti di test
Lo strumento che un’organizzazione implementa per facilitare i suoi test potrebbe influenzare la copertura e l’affidabilità di questi controlli.
Con i test ad hoc, vale la pena di esaminare il maggior numero possibile di programmi per trovare quelli che soddisfano l’aspetto incentrato sull’utente. I software che utilizzano la tecnologia di visione artificiale, come ZAPTEST, possono affrontare i test ad hoc con una strategia simile a quella umana.
3. Adottare una mentalità ad hoc
I test ad hoc offrono un’enorme libertà nella fase di garanzia della qualità, ma il team deve impegnarsi per ottenere i vantaggi principali della strategia.
Ad esempio, i tester ad hoc devono rinunciare a tutti i documenti abituali, al di là della semplice presa di appunti, e devono ispezionare il software da una prospettiva completamente nuova.
4. Fidarsi del proprio istinto
L’esperienza con i test ad hoc o con i controlli generali del software può aiutare a evidenziare i punti comuni di guasto, aiutando i tester a determinare come individuare gli errori di tutti i tipi.
È fondamentale che i tester si fidino del proprio istinto e che usino sempre questa conoscenza a proprio vantaggio, in modo da intuire quali controlli ad hoc sarebbero più utili.
5. Registrare completamente i bug scoperti
Anche se i test ad hoc non hanno una documentazione formale e si basano per lo più su note informali, è comunque essenziale che il team sia in grado di identificare e comunicare la causa di un errore del software.
Devono registrare tutte le informazioni che il test fornisce e che sono rilevanti per gli sviluppatori, come ad esempio le potenziali cause di questi problemi.
6. Tenere sempre conto dell’utente
Ogni forma di test intende adattarsi in qualche modo all’esperienza complessiva dell’utente, e i test ad hoc non fanno eccezione. Anche se spesso esamina più a fondo il funzionamento interno dell’applicazione e persino il suo codice interno, i tester ad hoc dovrebbero cercare di rompere il software in modi che gli utenti potrebbero teoricamente fare.
7. Migliorare continuamente il processo
I team di collaudo dovrebbero affinare il loro approccio ai test ad hoc tra più iterazioni dello stesso software e da un progetto all’altro.
Possono raccogliere i feedback degli sviluppatori per vedere quanto i loro test ad hoc abbiano aiutato la fase di garanzia della qualità e se siano stati in grado di aumentare significativamente la copertura dei test.
Conclusione
I test ad hoc possono aiutare le organizzazioni di tutti i tipi ad autenticare la loro strategia di test del software, ma il modo in cui implementano questa tecnica può essere un fattore significativo per la sua efficacia.
Bilanciare i diversi tipi di test è la chiave per ottenere i massimi benefici dai controlli ad hoc, soprattutto perché questa forma di test intende integrare le altre colmando una lacuna strategica.
Con un’applicazione come ZAPTEST, i team possono condurre test ad hoc con maggiore sicurezza e flessibilità, soprattutto se implementano l’automazione. Indipendentemente dall’approccio specifico del team, il loro impegno nei test ad hoc potrebbe rivoluzionare l’intero programma o progetto.
