Pianificazione di test ad hoc

In questo articolo, abbiamo coperto i test ad hoc, i suoi tipi, i suoi vantaggi, i suoi svantaggi, e le migliori pratiche per condurre test ad hoc.

Che cos’è il test ad hoc?

Il test ad hoc, talvolta indicato come “test casuale” o “test della scimmia”, è definito come un tipo di test informale. Lo scopo di questo processo è di rompere il sistema usando metodi non convenzionali. Questo tipo di test del software è generalmente non pianificato e non segue alcuna tecnica di progettazione di test specifica per creare casi di test.

Lo scopo principale del test ad hoc è quello di trovare eventuali difetti attraverso un controllo casuale. Il tester improvvisa i passi eseguendoli arbitrariamente. Questo può scoprire difetti molto specifici e interessanti, che sono facilmente mancati quando si usano altri metodi.

L’aspetto più sorprendente del test ad hoc è che non include alcuna tecnica di progettazione di test. Ciò significa che anche se questo metodo trova difetti che di solito non si trovano, è più difficile da riprodurre, poiché non ci sono casi di test scritti o documentazione.

Il successo del test ad hoc si riduce davvero alla creatività e alla persistenza del tester e a volte è solo dovuto alla pura fortuna. La tecnica di test ad hoc rientra direttamente nella categoria “test non strutturato”.

Structured Vs. Unstructured Testing

Structured Testing

Questo approccio assicura che ogni attività che ha luogo durante la procedura di test sia scriptata, dalla creazione dei casi di test all’esecuzione sequenziale. Il tester seguirà lo script per condurre con successo i test.

Test non strutturato

Questo approccio comporta il test attraverso l’indovinare gli errori. Il tester creerà casi di test durante il processo di test.

Tipi di metodi di test ad hoc

Buddy Testing

Questo tipo di test ad hoc è condotto con un minimo di due persone. Ha luogo dopo che il test unitario di un modulo è stato condotto e completato. Questo tipo di test può anche essere considerato una combinazione di test di sistema e unitario.

Lo scopo principale è che due “compagni” lavorino sull’identificazione di difetti o bug nello stesso modulo allo stesso tempo. Questo team sarà generalmente composto da uno sviluppatore di software e un tester di software.

I due “amici” lavorano insieme su quel modulo per creare casi di test validi. Questo processo assicura che il tester non riporti alcun errore che i casi di test non validi possono aver generato.

Il buddy testing si è dimostrato di successo in quanto aiuta il tester a sviluppare casi di test migliori e permette al team di sviluppo di apportare modifiche al progetto il più presto possibile.

Monkey Testing

A causa della natura casuale del test, questo metodo si è guadagnato il nome di ‘monkey testing’. Il test delle scimmie è più comunemente fatto nel livello di test dell’unità. Qui, i tester testano casualmente l’applicazione o il prodotto senza casi di test. L’obiettivo principale del tester è quello di analizzare i dati o i test in modo completamente casuale, assicurandosi che il sistema sia in grado di resistere a qualsiasi incidente.

I tester forniscono al software degli input casuali e osservano le uscite corrispondenti. Sulla base dei dati in uscita, possono determinare meglio eventuali errori, incongruenze o crash del sistema.

Pair Testing

Simile al ‘buddy testing’ per certi versi, il ‘pair testing’ prevede che una coppia di tester lavori insieme sui moduli da testare. I due tester condivideranno idee, conoscenze e opinioni sulla stessa macchina al fine di identificare difetti o errori.

Questo metodo di test prevede l’utilizzo di tester accoppiati in base alle loro competenze e livelli di conoscenza, consentendo diverse intuizioni per qualsiasi problema che identificano. I due tester condivideranno la stessa configurazione, condividendo anche il lavoro di test e documentando tutte le osservazioni tra di loro. Questo metodo di test permette anche ad un tester di eseguire i test, mentre l’altro può prendere appunti sui risultati.

Leggi anche: Usare il pair-testing per un migliore test di accettazione

Buddy vs. Pair Testing

La differenza principale tra buddy testing e pair testing è che il buddy testing è una combinazione di unit e system testing. Un’altra differenza chiave è che il buddy testing è eseguito da sviluppatori e tester insieme. Il pair testing, invece, è fatto solo da tester che hanno diversi livelli di conoscenza.

Quando e quando non condurre test ad hoc

I test ad hoc sono comunemente condotti quando manca il tempo per eseguire processi di test più lunghi ed esaustivi. Il metodo di test più approfondito include la preparazione di documenti di requisiti di test, casi di test e disegni di casi di test.

Il momento ideale per condurre test ad hoc è dopo il completamento di tutte le tecniche di test formali. Tuttavia, i test ad hoc possono essere condotti anche nel mezzo dello sviluppo del software, dopo lo sviluppo completo del software, o dopo che alcuni moduli sono già stati sviluppati.

È importante prendere nota dei pochi scenari in cui i test ad hoc non sono raccomandati. Alcune condizioni in cui i test ad hoc non dovrebbero essere condotti includono:

Quando vengono condotti test beta

In casi di test che hanno già errori esistenti

Vantaggi dei test ad hoc

Uno dei principali vantaggi dei test ad hoc è che sono in grado di identificare qualsiasi errore che di solito passa inosservato durante i metodi di test formali. Questo può far risparmiare molto tempo perché non richiede la pianificazione che richiedono i test strutturati.

Un altro vantaggio è che i tester possono esplorare l’applicazione liberamente, secondo la loro conoscenza e comprensione dell’applicazione. Possono quindi eseguire vari test man mano che vanno avanti, aiutando a identificare gli errori durante il processo.

In terzo luogo, i tester e gli sviluppatori dell’applicazione possono facilmente testare l’applicazione stessa, poiché non richiede casi di test. Questo permette agli sviluppatori di creare facilmente un codice più efficiente e privo di bug.

I test ad hoc possono anche essere combinati con altre tecniche di test ed eseguiti in seguito per produrre risultati complessivamente più efficaci e informativi.

Svantaggi dei test ad hoc

Uno dei principali svantaggi dei test ad hoc è che il processo di test effettivo non è documentato poiché non segue un particolare test case. Questo rende più difficile per i test rigenerare un errore. Perché, per ottenere quell’errore, il tester dovrà ricordare i passi esatti che ha fatto per arrivarci, il che non è sempre possibile.

Occasione, come risultato di casi di test non validi che sono sviluppati dal tester, vengono riportati errori non validi. Questo può diventare un problema nei seguenti processi di correzione degli errori. Se il tester non ha una conoscenza preliminare della funzionalità dell’applicazione sotto test, il test ad hoc non sarà utile e non sarà in grado di identificare alcun errore.

Il test ad hoc inoltre non garantisce che tutti gli errori saranno trovati. Il successo dei test ad hoc dipende dall’abilità e dalla conoscenza del tester. Poiché non ci sono casi di test creati o documentati in precedenza, la quantità di tempo, sforzo e risorse che vanno in questi test rimane indeterminata. Trovare un errore potrebbe richiedere da pochi minuti a qualche ora o più.

Pratiche migliori nella conduzione dei test

I test che non sono condotti nel modo giusto possono causare inutili perdite di tempo. Con questo in mente, è cruciale sapere come ottimizzare il processo al fine di eseguire efficientemente test ad hoc di successo.

Le seguenti migliori pratiche garantiranno che il tempo speso nel processo sia speso saggiamente con la migliore possibilità di ottenere i risultati desiderati.

Avere familiarità con il software

E’ imperativo che il tester che conduce il test ad hoc abbia una solida conoscenza e tenuta dell’applicazione. È importante che il tester abbia familiarità con tutte le caratteristiche principali dell’applicazione per garantire una migliore ‘indovinatura degli errori’. Con la giusta conoscenza, il tester sarà in grado di trovare più bug, errori e incongruenze generali.

Identificare le aree suscettibili di avere errori

Se i tester non hanno familiarità con l’applicazione, allora si raccomanda loro di identificare le aree a rischio di errore delle applicazioni e iniziare da lì. Selezionare aree sensibili per condurre test ad hoc permetterà ai tester di trovare errori con più facilità.

Privilegiare le aree a cui l’utente finale accede più facilmente

Iniziare a testare le aree dell’applicazione che sono più utilizzate dai clienti e dagli utenti finali. Così facendo, valuteranno prima le caratteristiche importanti, il che permette loro di segnalare eventuali bug in anticipo.

Formulare liberamente il piano di test

Sebbene i test ad hoc non richiedano alcuna pianificazione o documentazione precedente, è utile fare una pianificazione approssimativa in anticipo. Prendere nota delle aree principali che richiedono test aiuterà il tester a coprire il più possibile nel minor tempo possibile.

Aumentare l’efficienza con gli strumenti giusti

E’ cruciale usare gli strumenti giusti, come i task monitor, i debugger e i profiler, per assicurare che il processo funzioni in modo efficiente. Essi completano la capacità dei tester di isolare gli errori, poiché ci possono essere casi in cui le eccezioni non vengono identificate durante il test.

Conclusione

I test ad hoc non richiedono una pianificazione elaborata, documentazione e disegni di test-case. Invece, risparmia tempo grazie alla sua natura ad hoc, e selezionando tester che sono creativi e hanno una conoscenza preliminare della funzionalità dell’applicazione. Questo test può aiutare a trovare più difetti rispetto ai test pianificati.

Unisciti agli oltre 60.000 abbonati

Per gli ultimi blog, gli aggiornamenti del settore e i consigli esclusivi.

*La tua email è al sicuro con noi, odiamo lo spam