Test ad-hoc: Come trovare difetti senza un processo di test formale

Il termine stesso ad-hoc implica la mancanza di struttura o qualcosa che non è metodico. Quando si parla di test ad-hoc, significa che si tratta di una forma di scatola nera o di test comportamentali eseguiti senza alcun processo formale in atto.

Il processo formale qui significa avere documentazione come documenti di requisiti, piani di test, casi di test, e una corretta pianificazione dei test in termini di pianificazione e ordine dei test eseguiti. Inoltre, tutte le azioni eseguite durante il test non sono tipicamente documentate.

Questo è fatto principalmente con lo scopo di cercare di scoprire difetti o imperfezioni che non possono essere catturati attraverso i processi tradizionali o formali seguiti durante il ciclo di test.

Come già capito, l’essenza di questo test sta nel non avere un modo formale o strutturato di test. Quando questo tipo di tecniche di test casuali viene eseguito, è evidente che i tester lo eseguono senza alcun caso d’uso particolare in mente con l’obiettivo di rompere il sistema.

Quindi è sicuramente ancora più ovvio che tale metodologia di test intuitiva o creativa richiede che il tester sia estremamente abile, capace e abbia un profondo know-how del sistema. Il test ad-hoc assicura che il test eseguito sia completo ed è particolarmente utile per determinare l’efficacia del test bucket.

Lettura consigliata => Exploratory Testing – Come pensare oltre i confini del test tradizionale?

Iniziamo con un esempio di test ad-hoc

Ecco un esempio di come possiamo eseguire questi test quando si tratta di UI Wizard.

Diciamo che avete bisogno di creare un piano o un modello per qualche tipo di compito da eseguire utilizzando questa UI wizard. La procedura guidata è una serie di riquadri che hanno l’input dell’utente come nome, descrizione, ecc.

Quando la procedura guidata progredisce: diciamo su uno dei riquadri, i dati dell’utente devono essere inseriti che coinvolge la procedura guidata UI per lanciare una casella pop-up di contesto che aggiunge i dati associati per completare la procedura guidata e distribuire/attivare la procedura guidata.

Per testare questo tester fa i suoi test regolari come:

• Completa con successo la procedura guidata con tutti i dati validi e crea il piano.
• Annulla la procedura guidata a metà strada.
• Modificare un piano creato tramite la procedura guidata.
• Cancellare il piano creato e vedere che non ci sono residui di esso.
• Inserire un valore negativo nella procedura guidata e vedere i messaggi di errore appropriati.

Ora, per l’esempio di cui sopra ecco alcuni casi di prova per test ad-hoc che potrebbero essere eseguiti per scoprire più difetti possibili:

• Mentre si cerca di aggiungere dati negativi, aggiungere alcuni caratteri speciali che non sono limitati per vedere se vengono gestiti correttamente. Per esempio, a volte le procedure guidate non limitano le parentesi {o [ ma in certe situazioni, questo può entrare in conflitto con il codice basato sul linguaggio in cui è scritto, e causare un comportamento molto inaffidabile.
• Un altro test è specifico per quanto riguarda i pop-up. Un utente può far partire il pop up e poi provare a premere il tasto backspace sulla tastiera. Molte volte ho osservato che così facendo, il wizard in background scompare completamente e tutti i dati dell’utente che sono stati inseriti fino al punto in cui il pop-up è stato lanciato, vengono persi!

Caratteristiche dei test ad-hoc:

Se notate gli scenari sopra, vedrete alcune caratteristiche molto distinte di questo tipo di test.

Sono:

• Sono sempre in linea con l’obiettivo del test. Tuttavia, sono alcuni test drastici eseguiti con l’intento di rompere il sistema.
• Il tester deve avere una completa conoscenza e consapevolezza del sistema da testare. Il risultato di questo test trova dei bug che tentano di evidenziare le lacune del processo di test.
• Anche guardando i due test di cui sopra, la reazione naturale ad esso sarebbe che – questo tipo di test può essere eseguito solo una volta poiché non è fattibile per un re-test a meno che non ci sia un difetto associato.

Quando facciamo test ad-hoc?

Una domanda da un milione di dollari!

La maggior parte dei team di test del tempo sono sempre gravati da troppe caratteristiche da testare in tempi limitati. In quell’arco di tempo limitato, ci sono molte attività di test che sono derivate dal processo formale che devono anche essere completate. In queste situazioni il test ad-hoc che trova la sua strada nel test è scarso.

Tuttavia, secondo la mia esperienza, un round di test ad-hoc può fare meraviglie per la qualità del prodotto e sollevare molte domande di progettazione.

Siccome il test ad-hoc è più una tecnica di test “wild-child” che non deve essere strutturata, la raccomandazione generale è che deve essere eseguita dopo l’esecuzione del bucket di test corrente. Un altro punto di vista è che potrebbe essere fatto quando i test dettagliati non possono essere eseguiti per mancanza di tempo.

A mio parere, direi che i test ad-hoc possono essere fatti quasi in qualsiasi momento – all’inizio, verso la metà e verso la fine! Semplicemente trova il suo posto in qualsiasi momento. Tuttavia, quando il test ad-hoc deve essere fatto per far emergere il massimo valore è meglio giudicato da un tester esperto che ha una conoscenza approfondita del sistema da testare.

Quando non eseguire?

Se la domanda precedente valeva un milione di dollari, questa dovrebbe valere un miliardo!

Mentre abbiamo stabilito quanto possa essere efficace e fruttuoso il test ad-hoc, come tester abile e capace dobbiamo anche decifrare quando non investire in questo tipo di test. Anche se è a discrezione del tester, ecco alcune raccomandazioni/esempi quando potrebbe non essere necessario.

• Evitare questo test quando c’è un caso di test per il quale esiste un difetto. In una tale situazione c’è la necessità di documentare il punto di fallimento del test case e poi verificare/riesaminare il difetto quando è risolto. Quindi non sarà applicabile in questo caso.
• Ci possono anche essere certi scenari in cui i clienti possono essere invitati a testare la versione beta del software. In questi casi, questo test non dovrebbe essere condotto.
• Un altro scenario è quando c’è una schermata UI molto semplice che viene aggiunta. I tradizionali test positivi e negativi dovrebbero bastare qui per far emergere il massimo dei difetti.

Tipi di test ad-hoc

I test ad-hoc possono essere categorizzati nelle tre categorie seguenti:

#1) Buddy Testing

In questa forma di test, ci sarà un membro di test e uno di sviluppo che saranno scelti per lavorare sullo stesso modulo. Subito dopo che lo sviluppatore ha completato il test dell’unità, il tester e lo sviluppatore si siedono insieme e lavorano sul modulo. Questo tipo di test permette alla caratteristica di essere vista in un ambito più ampio per entrambe le parti.

Lo sviluppatore otterrà una prospettiva di tutti i diversi test che il tester esegue e il tester otterrà una prospettiva di come è il design inerente che lo aiuterà ad evitare di progettare scenari non validi, prevenendo così difetti non validi. Aiuterà uno a pensare come l’altro.

#2) Pair Testing

In questo test, due tester lavorano insieme su un modulo con la stessa configurazione di test condivisa tra loro. L’idea dietro questa forma di test è di avere i due tester che fanno un brainstorming di idee e metodi per avere un certo numero di difetti. Entrambi possono condividere il lavoro di test e fare la documentazione necessaria di tutte le osservazioni fatte.

#3) Monkey Testing

Questo test viene eseguito principalmente a livello di test delle unità. Il tester analizza i dati o i test in modo completamente casuale per assicurarsi che il sistema sia in grado di resistere a qualsiasi crash. Questo test può essere ulteriormente classificato in due categorie:

Benefici del test ad-hoc

Il test garantisce al tester un sacco di potere per essere creativo quanto necessario.

Questo aumenta la qualità e l’efficienza del test come segue:

• Il più grande vantaggio che spicca è che un tester può trovare il numero di difetti che nel test tradizionale a causa dei vari metodi innovativi che può applicare per testare il software.
• Questa forma di test può essere applicata ovunque nel SDLC; non è solo limitato al team di test. Gli sviluppatori possono anche condurre questo test, che li aiuterebbe a codificare meglio e anche a prevedere quali problemi potrebbero verificarsi.
• Può essere accoppiato con un altro test per ottenere i migliori risultati che a volte possono ridurre il tempo necessario per il test regolare. Questo permetterebbe di generare casi di test di migliore qualità e di migliorare la qualità del prodotto nel suo complesso.
• Non obbliga a fare alcuna documentazione, il che evita un carico extra per il tester. Un tester può concentrarsi sull’effettiva comprensione dell’architettura sottostante.
• Nei casi in cui non c’è molto tempo a disposizione per testare, questo può rivelarsi molto prezioso in termini di copertura e qualità dei test.

Svantaggi dei test ad-hoc

I test ad-hoc hanno anche alcuni svantaggi. Diamo un’occhiata ad alcuni degli svantaggi che vengono pronunciati:

Siccome non è molto organizzato e non c’è una documentazione obbligatoria, il problema più evidente è che il tester deve ricordare e richiamare a memoria tutti i dettagli degli scenari ad-hoc. Questo può essere ancora più impegnativo soprattutto negli scenari in cui c’è molta interazione tra i diversi componenti.

• Seguendo il primo punto, questo porterebbe anche a non essere in grado di ricreare i difetti nei tentativi successivi se gli vengono chieste informazioni.
• Un’altra questione molto importante che porta alla luce è la responsabilità dello sforzo. Dal momento che non è pianificato/strutturato, non c’è modo di rendere conto del tempo e dello sforzo investito in questo tipo di test.
• I test ad hoc devono essere eseguiti solo da un tester molto esperto e competente nel team, poiché richiede di essere proattivo e intuitivo in termini di previsione di potenziali aree piene di difetti.

Best Practices To Make This Testing More Effective

Abbiamo discusso a lungo i punti di forza e di debolezza associati a questo test.

In definitiva, il test ad-hoc dovrebbe trovare il suo posto nell’SDLC, tuttavia, se non viene affrontato nel modo appropriato può rivelarsi costoso e uno spreco di tempo prezioso di test. Quindi di seguito ci sono alcune indicazioni per rendere efficaci i test ad-hoc:

#1) Identificare le aree soggette a difetti:

Quando si ha una buona presa sul test di un particolare pezzo di software, si converrà che ci saranno alcune caratteristiche che sono più soggette a errori rispetto alle altre. Se siete nuovi del sistema, allora andate avanti e controllate le caratteristiche v/s difetti aperti contro di loro.

Il numero di difetti in una particolare caratteristica vi mostrerà che è sensibile e dovreste proprio scegliere quell’area per eseguire test ad-hoc. Questo si dimostra un modo molto efficiente in termini di tempo per esporre alcuni difetti gravi.

#2) Costruire la competenza:

Indubbiamente, un tester che ha più esperienza è più intuitivo e può indovinare dove potrebbero essere gli errori, se confrontato con qualcuno che non ha molta esperienza. Direi che, esperto o no, sta all’individuo fare il grande passo e costruire la competenza sul sistema che viene testato.

Sì, i tester esperti hanno un vantaggio perché le loro competenze costruite nel corso degli anni tornano utili, ma i nuovi tester dovrebbero usare questo come una piattaforma per acquisire più conoscenze possibili per progettare migliori scenari ad-hoc.

#3) Creare categorie di test:

Una volta che siete a conoscenza della lista delle caratteristiche da testare, mettete da parte qualche minuto per decidere come classificare queste caratteristiche e testarle. Per esempio, dovreste decidere di testare le caratteristiche che sono più visibili e più comunemente usate dall’utente prima di qualsiasi altra cosa, poiché queste sembrerebbero critiche per il successo del software.

Poi potreste categorizzarle in base alla funzionalità/priorità e testarle segmento per segmento.

Un altro esempio dove questo è particolarmente importante è se c’è integrazione tra componenti o moduli. In questi casi, ci possono essere molte anomalie che possono verificarsi. Usare la categorizzazione aiuterebbe a toccare questo tipo di test almeno una o due volte.

#4) Avere un piano approssimativo:

Sì, sì questo punto potrebbe confondervi un po’ perché abbiamo descritto i test ad-hoc come test che non dovrebbero avere pianificazione o documentazione. L’idea qui è di attenersi all’essenza del test ad-hoc, ma comunque, avere qualche indicazione approssimativa su come si pianifica il test.

Un esempio molto semplice è che a volte non si può essere in grado di ricordare tutti i test che si intende eseguire. Quindi, annotarli vi assicurerebbe di non perdere nulla.

#5) Strumenti:

Prendiamo un esempio affrontato molto comunemente da tutti noi. Molte volte, se si osserva, il test della funzionalità in sé ha successo e non viene segnalata alcuna discrepanza nel suo comportamento. Tuttavia, i registri dietro le quinte potrebbero riportare alcune eccezioni viste che potrebbero essere mancate dai tester in quanto non ostacolano l’obiettivo del test in alcun modo.

Queste potrebbero essere anche di alta gravità. Quindi è molto importante per noi imparare e strumenti che ci aiuteranno a individuarli immediatamente.

#6) Documentazione per più difetti:

Ancora una volta, capisco che questo può sollevare qualche sopracciglio. La documentazione non deve essere dettagliata, ma solo una piccola nota per il proprio riferimento di tutti i diversi scenari coperti, la deviazione nei passi coinvolti e registrare quei difetti per la particolare categoria di caratteristiche di test.

Questo vi aiuterà a migliorare il secchio di test complessivo come anche per cui potreste decidere come migliorare i casi di test esistenti o aggiungerne altri se necessario.

Conclusione

Abbiamo discusso in dettaglio le tecniche di test ad-hoc – i suoi punti di forza, le debolezze, le situazioni in cui potrebbe essere utile o meno.

Questa è una tecnica di test che garantisce di soddisfare la creatività di un tester al massimo. In tutta la mia carriera di tester, ho ottenuto la massima soddisfazione dai test ad-hoc perché non c’è limite all’innovazione e si finisce solo per essere più competenti.

Detto questo, la cosa principale da riprendere da tutte le informazioni di cui sopra sarebbe quella di determinare come sfruttare i punti di forza dei test ad-hoc e farli aggiungere valore al processo generale di test e alla qualità del prodotto.

Sull’autore: Questo è un articolo di Sneha Nadig. Lavora come Test lead con oltre 7 anni di esperienza in progetti di test manuali e di automazione.

Esegui test ad-hoc sul tuo progetto? Quali sono i tuoi suggerimenti per rendere i test ad-hoc di successo?