Menu

Test ad hoc: come trovare i difetti senza un processo di test formale

ad hoc testing how find defects without formal testing process

Prova Il Nostro Strumento Per Eliminare I Problemi

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

Il processo formale qui significa avere documentazione come documenti dei requisiti, piani di test, casi di test e un'adeguata pianificazione dei test in termini di pianificazione e ordine dei test eseguiti. Inoltre, qualsiasi azione eseguita durante il test non viene generalmente documentata.

Test ad hoc

Questo viene fatto principalmente con l'obiettivo di cercare di scoprire difetti o difetti che non possono essere catturati attraverso 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 viene eseguito questo tipo di tecniche di test casuali, è evidente che i tester eseguono questo senza alcun caso d'uso particolare in mente con l'obiettivo di rompere il sistema.

Quindi è decisamente ancora più ovvio che tale metodologia di test intuitiva o creativa richieda il tester deve essere estremamente abile, capace e avere un know-how approfondito del sistema. I test ad hoc garantiscono che il test eseguito sia completo ed è particolarmente molto utile per determinare l'efficacia del bucket di test.

Lettura consigliata=> Test esplorativi: come pensare oltre i confini dei test tradizionali?

Cosa imparerai:

Cominciamo con un esempio di test ad hoc

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

Supponiamo che tu debba creare un piano o un modello per qualche tipo di attività da eseguire utilizzando questa procedura guidata dell'interfaccia utente. La procedura guidata è una serie di riquadri che hanno input dell'utente come nome, descrizione, ecc.

Man mano che la procedura guidata procede: ad esempio su uno dei riquadri, devono essere immessi i dati dell'utente che coinvolge la procedura guidata dell'interfaccia utente per lanciare una finestra a comparsa contestuale che aggiunge i dati associati per completare la procedura guidata e distribuire / attivare la procedura guidata.

Per testare questo tester esegue i suoi test regolari come:

cos'è l'applicazione a pagina singola in angularjs
  • Completa con successo la procedura guidata con tutti i dati validi e crea il piano.
  • Annulla la procedura guidata a metà.
  • Modifica un piano creato tramite la procedura guidata.
  • Elimina il piano creato e verifica che non ne rimanga alcun residuo.
  • Immettere un valore negativo nella procedura guidata e vedere i messaggi di errore appropriati.

Ora, per l'esempio sopra ecco alcuni casi di test per test ad-hoc che potrebbe essere eseguito per scoprire quanti più difetti possibile:

  • Durante il tentativo di aggiungere dati negativi, aggiungi alcuni caratteri speciali che non sono limitati per vedere se sono gestiti correttamente. Per esempio, a volte le procedure guidate non limitano le parentesi graffe {o (ma in determinate situazioni questo può entrare in conflitto con il codice basato sulla lingua in cui è scritto e causare un comportamento molto inaffidabile.
  • Un altro test riguarda specificamente i pop-up. Un utente può avviare il popup e quindi provare a premere il pulsante backspace sulla tastiera. Molte volte ho osservato che così facendo, la procedura guidata in background scompare completamente e tutti i dati utente che erano stati inseriti fino al punto in cui è stato lanciato il pop-up, vengono persi!

Caratteristiche dei test ad-hoc:

Se prendi nota degli scenari sopra, vedrai 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 conoscenza e una consapevolezza complete del sistema da testare. Il risultato di questo test trova bug che tentano di evidenziare le lacune del processo di test.
  • Osservando anche i due test precedenti, la reazione naturale sarebbe che: questo tipo di test può essere eseguito solo una volta poiché non è fattibile per un nuovo test a meno che non sia associato un difetto.

Quando eseguiamo test ad hoc?

Davvero una domanda da un milione di dollari!

La maggior parte delle volte i team di test sono sempre gravati da troppe funzionalità da testare in tempi limitati. In quel periodo di tempo limitato, ci sono molte attività di test che derivano dal processo formale che deve essere completato. In tali situazioni il test ad hoc che trova la sua strada nel test è scarso.

Tuttavia, dalla mia esperienza, un ciclo di test ad hoc può fare miracoli per la qualità del prodotto e sollevare molte domande di progettazione.

Poiché i test ad-hoc sono 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 ciò potrebbe essere fatto quando non è possibile eseguire test dettagliati a causa del minor tempo.

A mio avviso, lo direi i test ad hoc possono essere eseguiti quasi in qualsiasi momento: all'inizio, verso la metà e verso la fine! Trova solo il suo posto in un dato momento. Tuttavia, quando è necessario eseguire test ad hoc per ottenere il massimo valore, è meglio giudicare da un tester esperto che abbia una conoscenza approfondita del sistema da testare.

Quando non eseguire?

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

Sebbene abbiamo stabilito quanto possano essere efficaci e fruttuosi i test ad hoc, in quanto tester abili e capaci dobbiamo anche decifrare quando non investire in questo tipo di test. Sebbene sia a discrezione del tester, eccoli qui alcuni consigli / esempi quando potrebbe non essere necessario.

  • Evita questo test quando c'è un test case per il quale esiste un difetto. In una situazione del genere è necessario documentare il punto di fallimento del test case e quindi verificare / ritestare il difetto una volta risolto. Quindi non sarà applicabile qui.
  • Potrebbero esserci anche alcuni scenari in cui i clienti o i clienti possono essere invitati testare la versione beta del software . In questi casi, questo test non dovrebbe essere condotto.
  • Un altro scenario è quando viene aggiunta una schermata dell'interfaccia utente molto semplice. I tradizionali test positivi e negativi dovrebbero essere sufficienti qui per evidenziare i massimi difetti.

Tipi di test ad hoc

I test ad hoc possono essere classificati in tre categorie di seguito:

# 1) Buddy Testing

In questa forma di test, ci sarà un membro di test e un membro di sviluppo che verranno scelti per lavorare sullo stesso modulo. Subito dopo il lo sviluppatore completa lo unit test , il tester e sviluppatore siedono insieme e lavorare sul modulo. Questo tipo di test consente di visualizzare la funzionalità in un ambito più ampio per entrambe le parti.

Lo sviluppatore acquisirà una prospettiva di tutti i diversi test eseguiti dal tester e il tester acquisirà una prospettiva di come è il design intrinseco che lo aiuterà a evitare di progettare scenari non validi, prevenendo così difetti non validi. Aiuterà uno a pensare come pensa l'altro.

# 2) Test di coppia

In questo test, due tester lavorano insieme su un modulo con la stessa configurazione di test condivisa tra loro. L'idea alla base di questa forma di test è quella di far riflettere i due tester su idee e metodi per avere una serie di difetti. Entrambi possono condividere il lavoro di verifica e rendere necessaria la documentazione di tutte le osservazioni fatte.

# 3) Test delle scimmie

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

software di orologio basato sul web gratuito

Vantaggi dei test ad hoc

Il test garantisce al tester molto potere di essere creativo quanto necessario.

Ciò aumenta la qualità e l'efficienza dei test come di seguito:

  • Il più grande vantaggio che si distingue è che un tester può trovare il numero di difetti rispetto ai test tradizionali a causa dei vari metodi innovativi che possono applicare per testare il software.
  • Questa forma di test può essere applicata ovunque nell'SDLC; non è solo limitato al team di test. Gli sviluppatori possono anche condurre questo test, che li aiuterebbe a programmare 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 i test regolari. Ciò consentirebbe di generare casi di test di migliore qualità e una migliore qualità del prodotto nel suo complesso.
  • Non impone alcuna documentazione da fare che prevenga l'onere aggiuntivo per il tester. Un tester può concentrarsi sulla comprensione effettiva 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à del test.

Inconvenienti dei test ad hoc

Anche i test ad hoc presentano alcuni inconvenienti. Diamo un'occhiata ad alcuni dei inconvenienti che sono pronunciati:

Poiché non è molto organizzato e non è richiesta alcuna documentazione, il problema più evidente è che il tester deve ricordare e ricordare tutti i dettagli degli scenari ad-hoc in memoria. Questo può essere ancora più impegnativo, specialmente negli scenari in cui c'è molta interazione tra i diversi componenti.

  • Seguito dal primo punto, ciò risulterebbe anche nel non poter ricreare difetti nei tentativi successivi se richiesto di informazioni.
  • Un'altra questione molto importante che questo porta alla luce è la responsabilità dello sforzo. Poiché questo non è pianificato / strutturato, non c'è modo di tenere conto del tempo e degli sforzi investiti in questo tipo di test.
  • I test ad hoc devono essere eseguiti solo da un tester molto esperto e competente nel team in quanto richiede essere proattivi e intuizione in termini di previsione di potenziali aree difettose.

Migliori pratiche per rendere questo test più efficace

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

Idealmente, i test ad hoc dovrebbero trovare il loro posto nell'SDLC, tuttavia, se non affrontati nel modo appropriato, possono rivelarsi costosi e uno spreco di tempo prezioso per i test. Di seguito sono riportati alcuni suggerimenti per rendere efficaci i test ad hoc:

# 1) Identifica le aree soggette a difetti:

Quando hai una buona presa sul test di un particolare software, sarai d'accordo sul fatto che ci saranno alcune funzionalità che sono più soggette a errori rispetto ad altre. Se sei nuovo nel sistema, vai avanti e controlla le funzionalità rispetto ai difetti aperti contro di loro.

Il numero di difetti in una particolare funzionalità ti mostrerà che è sensibile e dovresti scegliere esattamente quella stessa area per eseguire test ad hoc. Questo si rivela un modo molto efficiente in termini di tempo per esporre alcuni gravi difetti.

# 2) Competenza nella costruzione:

Indubbiamente, un tester che ha più esperienza è più intuitivo e può indovinare dove potrebbero essere gli errori, rispetto a qualcuno che non ha molta esperienza. Direi che, esperto o meno, spetta all'individuo fare il grande passo e sviluppare le proprie competenze sul sistema che viene testato.

Sì, i tester esperti hanno un vantaggio in quanto le loro competenze acquisite negli anni tornano utili, ma i nuovi tester dovrebbero usarla come piattaforma per acquisire quante più conoscenze possibili per progettare migliori scenari ad-hoc.

# 3) Crea categorie di test:

Una volta che sei a conoscenza dell'elenco delle funzionalità da testare, dedica alcuni minuti per decidere come classificare tali funzionalità e testarle. Per esempio, dovresti decidere di testare le funzionalità più visibili e più comunemente utilizzate dall'utente prima di ogni altra cosa, in quanto sembrerebbero fondamentali per il successo del software.

Quindi potresti classificarli in base alla funzionalità / priorità e testarli segmento per segmento.

Un altro esempio in cui questo è particolarmente molto importante è se c'è integrazione tra componenti o moduli. In questi casi, possono esserci 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 confondere 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 ancora, annotare alcuni suggerimenti approssimativi su come si intende eseguire il test.

Un esempio molto semplice è che a volte potresti non essere in grado di ricordare tutti i test che intendi eseguire. Quindi annotarli ti assicurerebbe di non perdere nulla.

# 5) Strumenti:

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

Questi potrebbero essere anche di gravità elevata. Quindi è molto importante per noi apprendere e strumenti che ci aiuteranno a individuarlo immediatamente.

# 6) Documento per più difetti:

Di nuovo, capisco che questo potrebbe sollevare di nuovo alcune sopracciglia. La documentazione non deve essere dettagliata, ma solo una piccola nota per il tuo riferimento di tutti i diversi scenari coperti, la deviazione nei passaggi coinvolti e registra quei difetti per la particolare categoria di funzionalità di test.

Ciò ti aiuterà a migliorare anche il bucket di test complessivo, grazie al quale potrai decidere come improvvisare i casi di test esistenti o aggiungerne altri se necessario.

Conclusione

Abbiamo discusso in dettaglio delle tecniche di test ad-hoc: i suoi punti di forza, i punti deboli, le situazioni in cui sarebbe e non sarebbe vantaggioso.

Questa è una tecnica di test che garantisce di soddisfare e soddisfare al massimo la creatività di un tester. Nel mio intero prova di carriera , Ottengo la massima soddisfazione dai test ad-hoc poiché non c'è limite all'innovazione e si finisce solo per essere più informati.

Detto questo, la cosa principale da riprendere da tutte le informazioni di cui sopra sarebbe determinare come attingere ai punti di forza dei test ad hoc e fare in modo che aggiungano valore al processo di test complessivo e alla qualità del prodotto.

Circa l'autore: Questo è un articolo ospite 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 garantire il successo dei test ad-hoc?

Lettura consigliata

^