I test adhoc vengono solitamente eseguiti per rompere il sistema e utilizzando modi non convenzionali. La caratteristica più stupefacente del test Adhoc è che non ha nessuna tecnica di progettazione di test per creare casi di test.

Il processo viene solitamente eseguito per trovare le falle di un software. Dal momento che il test Adhoc non ha casi di test viene spesso eseguito senza alcuna documentazione.

Guarda il processo in dettaglio

Il test Adhoc è una tecnica che rientra nella categoria ‘Test non strutturati’.

Cos’è il testing strutturato e non strutturato?

Structured Testing

In questo approccio, ogni attività che avviene durante la procedura di testing, dalla creazione dei casi di test alla loro esecuzione sequenziale, tutto è scriptato. I tester seguono questo script per condurre i test in base ad esso.

Test non strutturato

In questo approccio, il test è comunemente fatto attraverso l’indovinare gli errori, dove i tester creano i casi di test, durante il processo di test stesso.

Che cos’è il test adhoc?

Come discusso sopra, è un tipo di approccio di test non strutturato, dove nessun piano organizzato viene creato prima di iniziare il processo di test.

Quindi, prima del test, non viene fatta alcuna documentazione dei requisiti o pianificazione e progettazione dei casi di test.

Il test ad hoc è di solito condotto da un tester che ha una forte conoscenza del software sotto test, riguardo a cosa fa e come funziona.

Questo test è fatto creando casualmente casi di test attraverso l’indovinare gli errori ed eseguendoli, senza seguire alcun requisito per il test.

Una parte importante di questo test è scoprire le aree potenziali del software, dove potrebbero essere presenti errori.

Questo è il motivo per cui a volte è anche conosciuto come Monkey Testing o Random Testing. Ecco perché è importante che solo i tester che hanno una buona conoscenza del software conducano questo test.

Un vantaggio dell’Ad-Hoc testing è che fa risparmiare molto tempo, che altrimenti va nella creazione di documenti come i requisiti di test, la pianificazione dei test case, la progettazione, ecc.

E’ anche generalmente condotto dopo che il test strutturato è già stato eseguito. Questo viene fatto, in modo da trovare difetti non comuni nel software che non potrebbero essere rilevati seguendo i casi di test scritti in precedenza.

Tipi di test ad hoc

1) Buddy Testing

In questo tipo di test ad hoc, i test sono condotti con lo sforzo di squadra di almeno due persone. Questo team è solitamente composto da almeno un tester di software e uno sviluppatore di software.

Questo tipo di test ha luogo dopo che la conduzione del test unitario di un modulo è stata completata.

Il team dei due “amici” lavora insieme su quel modulo per creare casi di test validi.

Questo viene fatto in modo che il tester non finisca per riportare errori generati attraverso casi di test non validi. Questo tipo di test può anche essere considerato come la combinazione di test di unità e di sistema.

2) Monkey Testing

La casualità dell’approccio usato in questo test è il motivo per cui viene definito “test della scimmia”.

Qui, il software sotto test viene fornito da input casuali, per i quali vengono osservati i loro output corrispondenti.

Sulla base degli output ottenuti, viene determinato qualsiasi verificarsi di errori, incongruenze o crash di sistema.

3) Pair Testing

Questo test è molto simile al buddy testing. Tuttavia, qui, una coppia di soli tester lavora insieme sui moduli da testare.

Loro lavorano insieme per condividere idee, opinioni e conoscenze sulla stessa macchina per identificare errori e difetti.

I tester sono accoppiati secondo i loro livelli di conoscenza e competenza, per ottenere una visione diversa di qualsiasi problema.

Caratteristiche del Test Adhoc

• Questo test viene fatto dopo che le tecniche di test formali sono già state condotte sul software. La ragione di questo è che i test ad-hoc sono fatti per trovare le anomalie nell’applicazione, che non possono essere previste prima del test.
• Questo test può essere condotto solo da quei tester che hanno una buona e approfondita conoscenza del funzionamento dell’applicazione. Questo perché un efficace ‘indovinare gli errori’ può essere fatto solo quando il tester conosce cosa fa l’applicazione e come funziona.
• La tecnica di test ad-hoc è più adatta per trovare bug e incongruenze che danno origine a lacune critiche in un’applicazione. Tali errori sono di solito molto difficili da scoprire.
• Questo test richiede relativamente meno tempo di altre tecniche di test. Questo perché viene fatto senza pianificazione, progettazione e strutturazione precedenti.
• I test ad-hoc vengono condotti solo una volta, poiché qualsiasi errore trovato richiede di essere ritestato.

Esempi di test ad-hoc

• Testare il corretto funzionamento di un’applicazione quando le impostazioni del browser sono diverse. Per esempio, identificare gli errori che si verificano quando l’opzione per JavaScript è disabilitata in diversi browser, ecc.
• Testare l’applicazione attraverso le piattaforme. È essenziale verificare se l’applicazione sviluppata può essere eseguita senza problemi in diversi sistemi operativi o browser.
• Fornire input al sistema che sono al di fuori della gamma di input validi, per verificare se l’azione risultante presa dall’applicazione è appropriata o meno.
• Copiare l’URL dell’applicazione e manipolarlo per eseguirlo su un browser diverso. Questo viene fatto per accertare che qualsiasi utente non autorizzato non sia in grado di ottenere un accesso non autenticato al sistema.
• Seguendo una serie di passi casuali o navigando in modo casuale attraverso l’applicazione in modo da controllare i risultati ottenuti passando attraverso una certa combinazione di input insoliti.

Quando condurre test ad hoc

Di solito, i test ad hoc sono condotti quando non c’è abbastanza tempo per eseguire test esaustivi e approfonditi che includono la preparazione di documenti di requisiti di test, casi di test e disegni di casi di test.

Il momento perfetto per condurre questo tipo di test è dopo il completamento delle tecniche di test formali.

Tuttavia, i test ad-hoc possono essere condotti anche nel mezzo dello sviluppo del software.

Può essere eseguito dopo lo sviluppo completo del software, o anche dopo che alcuni moduli sono stati sviluppati.

Può essere condotto anche durante il processo dei metodi di test formali.

Ci sono alcune situazioni in cui questo test, tuttavia, non deve essere condotto. Pertanto, ogni tester deve sapere quando evitare questo test.

Di seguito ci sono alcune condizioni in cui il test ad-hoc non deve essere condotto:

• Il test ad-hoc non deve essere condotto quando viene effettuato il beta testing. Questo perché il Beta testing coinvolge i clienti, che testano il software sviluppato per fornire suggerimenti per nuove caratteristiche che devono essere aggiunte o per cambiare i requisiti per esso.
• Questo test è anche consigliato di non essere condotto nei casi di test che hanno già errori esistenti in essi. Gli errori devono essere prima adeguatamente documentati prima di essere eliminati dal sistema. Dopo che sono stati corretti, i casi di test devono essere nuovamente testati, per assicurare il loro corretto funzionamento.

Quali sono i vantaggi dei test ad-hoc?

• Un vantaggio dei test ad-hoc è che molti errori, che di solito non vengono rilevati quando si usano solo metodi di test formali, possono essere trovati testando l’applicazione in modo casuale.
• I tester possono esplorare l’applicazione liberamente, secondo la loro intuizione e comprensione dell’applicazione. Possono poi eseguire i test man mano che vanno, aiutandoli a trovare gli errori durante questo processo.
• I tester e gli sviluppatori dell’applicazione possono facilmente testare l’applicazione, poiché non è necessario pianificare e progettare i casi di test. Questo aiuta gli sviluppatori a generare facilmente codici più efficaci e senza errori.
• Questo test può anche aiutare nella creazione di casi di test unici che possono rilevare inefficacemente gli errori. Pertanto, tali casi di test possono essere aggiunti ai test formali con altri casi di test pianificati.
• I test ad hoc possono essere condotti in qualsiasi momento durante il ciclo di vita dello sviluppo del software perché non seguono alcun processo formale.
• Può essere combinato con altre tecniche di test ed eseguito per produrre risultati più informativi ed efficaci.

Quali sono gli svantaggi dell’Adhoc Testing?

• Siccome il processo di test non è documentato e nessun caso di test particolare è seguito, diventa molto difficile per il tester rigenerare un errore. Questo perché il tester ha bisogno di ricordare i passi esatti che ha seguito per ottenere quell’errore, il che non è possibile ogni volta.
• A volte, a causa dell’esecuzione di casi di test non validi sviluppati casualmente dal tester, vengono riportati errori non validi, il che diventa un problema nei successivi processi di correzione degli errori.
• Se i tester non hanno una conoscenza preliminare del funzionamento dell’applicazione sotto test, allora eseguire test ad hoc non sarà in grado di scoprire molti errori. Questo perché i tester devono lavorare attraverso l’indovinare gli errori e creare ed eseguire intuitivamente i casi di test sul posto.
• I test ad-hoc non forniscono la garanzia che gli errori saranno trovati. L’indovinare l’errore proattivo per i test dipende totalmente dall’abilità e dalla conoscenza del tester.
• Siccome non ci sono casi di test precedentemente creati e documentati, la quantità di tempo e sforzi che vanno in questo test rimane incerta. A volte, trovare anche un solo errore potrebbe richiedere un’enorme quantità di tempo.

Pratiche migliori per condurre test ad hoc

Per condurre efficacemente la tecnica di test ad hoc, è importante conoscere i modi più efficaci ed efficienti per farlo.

Questo perché se i test non sono condotti in modo adeguato, allora lo sforzo e il tempo messi nei test saranno sprecati.

Pertanto, per condurre questo tipo di test, si devono conoscere le migliori pratiche che possono aiutare in un approccio più completo al test:

1) Buona conoscenza del software

Assicurarsi che il tester assegnato per il test dell’applicazione attraverso l’approccio ad-hoc abbia una buona conoscenza dell’applicazione.

Il tester deve avere familiarità con tutte le caratteristiche dell’applicazione in modo da facilitare un migliore ‘indovinare gli errori’ sull’applicazione.

Con una conoscenza sufficiente a sostenere il processo di test del tester, trovare più errori, bug e incongruenze diventa più facile.

2) Scoprire le aree a rischio di errore

Se i tester, come non hanno familiarità con l’applicazione, allora la pratica migliore per loro per iniziare il loro processo di test è controllare la parte dell’applicazione dove si trova la maggior parte degli errori.

Scegliere tali aree sensibili per eseguire test ad-hoc può aiutarli a trovare gli errori più facilmente.

3) Dare priorità alle aree di test

È sempre meglio iniziare i test dalle aree dell’applicazione che è la più utilizzata dagli utenti finali o dai clienti. Questo aiuta a garantire le caratteristiche importanti e a segnalare qualsiasi bug in anticipo.

4) Pianificare approssimativamente il piano di test

Anche se i test adhoc non richiedono alcuna pianificazione o documentazione preventiva, si dimostrano molto utili ed efficienti se un piano approssimativo viene creato in anticipo.

Solo annotando i punti principali e le aree che richiedono test può aiutare i tester a coprire la massima parte dell’applicazione in un breve lasso di tempo.

5) Strumenti

È essenziale fare uso del giusto tipo di strumenti come debugger, task monitor e profiler per facilitare il processo di test.

Questo perché ci sono volte in cui specifici bug ed eccezioni non possono essere visti e non vengono catturati durante i test.

Tuttavia, usare gli strumenti giusti può aiutare ad isolare l’errore in poco tempo.

Test ad hoc vs test esplorativo

Test ad hoc	Test esplorativo
I tester devono avere una chiara idea del flusso di lavoro dell’applicazione	I tester imparano a conoscere applicazione in movimento
Più sul perfezionamento del processo di test	È un metodo di apprendimento per conoscere l’applicazione
Una forma di test positivo	Una forma di sistema negativo
Non c’è un piano	Sarà usato un piano basato su una carta
Non c’è un limite di tempo proposto	Vettore di tempo/carattere
Può essere eseguito dall’ingegnere di test del software	Deve essere fatto dall’esperto
Il focus è sul processo di applicazione	Le aree di inserimento dati saranno il focus principale
La complessità dei test non disturberà molto questo processo	Le sfide coinvolte