Menu

Che cos'è il test esplorativo nel test del software (una guida completa)

  • Principale
  • Altro
  • Che cos'è il test esplorativo nel test del software (una guida completa)

what is exploratory testing software testing

Prova Il Nostro Strumento Per Eliminare I Problemi

Cos'è il test esplorativo?

'Test esplorativo' - come suggerisce il nome, è un processo simultaneo di apprendimento, progettazione di test ed esecuzione di test. Possiamo dire che in questo test la pianificazione, l'analisi, la progettazione e l'esecuzione dei test vengono eseguiti tutti insieme e istantaneamente.

Questo test riguarda l'esplorazione del sistema e l'incoraggiamento al pensiero pratico e in tempo reale di un tester.

In questa serie abbiamo trattato i seguenti tutorial:

Tutorial n. 1: Che cos'è il test esplorativo nel test del software (Questo tutorial)
Tutorial n. 2: Utilizzo dei tour per garantire un test esplorativo completo
Tutorial n. 3: Test esplorativi vs test con script
Tutorial n. 4: Test esplorativi con HP Sprinter
Tutorial n. 5: I 17 migliori strumenti di test esplorativi

************************************
Test esplorativi

Cosa imparerai:

Panoramica

In parole povere, i test esplorativi implicano la progettazione simultanea di casi di test e l'esecuzione di test di un'applicazione o di un sistema sottoposto a test. Il tester creerà o scriverà un'idea di test per dare una direzione ed esplorerà il sistema durante il test per creare ulteriori test critici, pratici e utili per il test di successo di un'applicazione.

Ciò richiede una pianificazione minima. I tester prendono continuamente una decisione sulla sua prossima fase di azione. Dipende completamente dal processo di pensiero del tester.

A volte questo test può essere più vantaggioso dell'approccio di test formale per trovando alcuni sottili difetti che scompaiono nei test formali.

Consciamente o inconsciamente, ogni singolo tester avrebbe svolto test esplorativi ad un certo punto della propria carriera.

Come tutti sappiamo, uno studente imparerà meglio attraverso l'esperienza pratica piuttosto che stipare la teoria.

Allo stesso modo, un tester conoscerà meglio l'applicazione solo mentre esplora e apprende tutte le funzionalità che fornisce da solo. È sempre utile avere una prospettiva di cliente e di business durante i test per garantire il successo del test di un'applicazione.

Per esempio, se apri un sito web per lo shopping, hai un'idea generale che questo sito web ti permetterà di fare acquisti selezionando un prodotto di tua scelta e poi pagando lo stesso.

Durante questo processo, potresti apprendere che il sito Web ti fornisce un aspetto umano virtuale che ti aiuta nel processo di selezione del prodotto. Hai anche scoperto che puoi ordinare una serie di prodotti per la prova domestica o che puoi effettuare il pagamento tramite i punti fedeltà di alcune banche, ecc.

In qualità di tester, non solo è necessario verificare se un sistema funziona come previsto, ma anche controllare se quel sistema non si comporta in un modo non previsto.

Poche cose da ricordare durante l'esecuzione di questo test:

  • La tua missione dovrebbe essere chiara.
  • Assicurati di creare note e segnalare ciò che stai facendo e come si comporta un sistema, che potrebbe essere un potenziale bug.
  • Impara, osserva e poi crea nuovi casi di test.

Servizio di test esplorativo consigliato

# 1) Digivante Direct

Logo Digivante Direct

Digivante Direct esegue test esplorativi utilizzando la sua rete globale di tester professionisti in modo da poter coprire i test su tutti i principali dispositivi in ​​un lasso di tempo che non è possibile ottenere da qualsiasi altro fornitore di test o team interno.

Rilascia più rapidamente, in modo più sicuro e consenti alle tue piattaforme digitali di offrire una maggiore soddisfazione dei clienti e maggiori ricavi online.

Caratteristiche:

  • 24 giorni lavorativi di test in sole 24 ore o 90 giorni lavorativi in ​​72 ore e un livello di test completo e senza rivali, impossibile da raggiungere con qualsiasi altro mezzo.
  • Basso costo , pacchetti di prezzi di facile comprensione senza extra nascosti.
  • Fai da te portale online che non richiede impegno continuativo.
  • Persone reali che testano su dispositivi reali - Copertura di dispositivi e browser molto maggiore di quella che puoi ottenere internamente e tutto in tempi di consegna più rapidi.
  • Copertura completa dei test esplorativi - ridurre il rischio e migliorare la soddisfazione degli utenti finali e i tassi di conversione aumentando così i ricavi riducendo i costi.
=> Visita il sito web di Digivante Direct

Esempi di test esplorativi

Esempio 1:

Un sito Web di un fornitore di servizi di assistenza domiciliare con i seguenti componenti:

  • Login
  • Servizi
  • Carrello
  • Pagamento
  • Cronologia ordini
  • Riparto tecnico

Un'idea generale per iniziare esplorativo il test sarà quello di accedere o prenotare un servizio.

Come coprire i casi di test?

Casi di test di test esplorativi

come aggiungere elementi di un array

In quanto sopra Esempio, l'idea è di iniziare con funzionalità basate sulla tua conoscenza. Man mano che impari e osservi di più sull'applicazione, puoi governare la tua prossima serie di casi di test.

Esempio n. 2:

Una volta sono stato incluso in un piccolo progetto che prevedeva l'aggiunta di un nuovo fondo comune di investimento nella domanda. Il mio compito era testare l'applicazione per assicurarmi che il nuovo fondo comune di investimento fosse disponibile per l'acquisto da parte degli utenti e verificare se la valutazione associata fosse corretta. Ho avuto solo 2 giorni per completare i miei test.

Considerati i tempi stretti e la severità dei test, ho utilizzato l'approccio esplorativo del test. Il mio obiettivo era testare nuove funzionalità e trovare violazioni dei requisiti di compatibilità.

L'obiettivo di cui sopra è diventato la mia carta per questa sessione di test.

Durante questo test sono stati sviluppati i seguenti casi di test:

  • Test per assicurarsi che il nuovo fondo comune di investimento sia stato aggiunto all'applicazione.
  • Il nuovo MF è stato acquistato con successo.
  • La valutazione del nuovo MF è corretta.
  • Ho provato ad acquistare un nuovo MF per un portafoglio esistente.
  • È possibile aggiungere un nuovo MF a tutti i portfolio?
  • Impatto del nuovo MF su una valutazione dell'esistente.
  • Quindi in altri casi di test si sono evoluti.

Ho preparato note e rapporti durante i miei test per discutere la mia osservazione con il BA e il cliente coinvolto.

La strategia fondamentale del test esplorativo è avere un piano di attacco. Inizia a testare con la tua idea e improvvisa nuovi casi di test basati sulla tua conoscenza e osservazione.

Esempio n. 3:

Test esplorativo del sito web IRCTC

=> Fare clic qui per scaricare i casi di test di esempio di Exploratory Testing del sito web IRCTC.

Approccio al test

  • Utilizza l'euristica per guidare i test.
  • L'esecuzione dei test case e la creazione dei test case vanno di pari passo.
  • I casi di test continuano ad evolversi in base all'osservazione e all'apprendimento dei tester.
  • Diverse tecniche di test come Analisi del valore limite , test di equivalenza, ecc. possono essere applicati a ET.
  • L'ET basato sulla sessione può essere utilizzato per renderlo più strutturato e mirato.
  • I tester possono estendere le idee ma non allontanarsi mai dalla tua missione.
  • Il test ET non utilizza script, dipende invece dall'intuizione, abilità ed esperienza del tester.

Benefici

I vantaggi di questo test includono:

  • Promuove il pensiero in tempo reale e aiuta a scoprire più difetti.
  • Promuovi casi d'uso e test basati su scenari.
  • Documentazione minima, test massimo.
  • L'enfasi è più sull'apprendimento e sull'ampliamento dell'orizzonte di un tester.
  • Evita i doppioni.
  • Utile quando vuoi controllare il lavoro di altri tester.

Demeriti

I demeriti sono arruolati di seguito:

  • Il test dipende dall'esperienza, dall'abilità e dalla conoscenza del tester.
  • Richiede tempo per imparare l'applicazione. È più probabile che il tester perda se ne sa di meno sull'applicazione.
  • Non adatto per progetti con tempi di esecuzione lunghi.

Test esplorativi basati sulla sessione

Durante i test esplorativi, è molto difficile per i tester esprimere a parole quanto ha testato e su quale base.

Fondamentalmente, è difficile quantificare il lavoro e il tempo speso. Tuttavia, in ogni progetto, dobbiamo fornire metriche, stime e report sui progressi ai responsabili del team e ai manager. Come dice il proverbio, 'se non puoi quantificarlo, non puoi gestirlo'.

Il test basato sulla sessione è un approccio basato sul tempo per eseguire questo test che aiuta nella gestione e nel monitoraggio. Include una sessione di test time-box dedicata senza interruzioni da e-mail, telefono, messaggi, ecc.

Approccio:

Le attività di test sono suddivise in sessioni.

Di seguito sono riportati i componenti del test basato sulla sessione (SBT):

  • Missione: La missione esprime lo scopo della sessione e in un certo senso fornisce il focus per il tester. Comprenderà anche una durata della sessione.
  • Carta: Include l'ambito del test. Fondamentalmente, un'agenda che dettaglia gli obiettivi che devono essere completati durante la sessione.

Esempio di Carta di prova per la funzionalità di accesso del sito Web del servizio di assistenza domiciliare:

Esempio di carta di prova per la funzionalità di accesso

  • Sessione: Sessione di test time-boxed predefinita senza alcuna interruzione. Ogni sessione può avere la seguente durata:
    • 'Breve' (60 min)
    • 'Normale' (90 min)
    • 'Lungo' (120 min)
  • Report della sessione: Includi note e report leggeri per fornire metriche a leader e manager. Fornisce dettagli sulla sessione charter rimanente o completata, tempo di configurazione della sessione, scenario testato, sul processo di test, un elenco di bug e problemi rilevati e altre informazioni per le metriche.
  • De-brief della sessione: Un breve incontro o uno stand-up tra il tester e il responsabile / responsabile del test per esaminare i risultati della sessione di test.

I manager possono ottenere le seguenti metriche pratiche in base al rapporto sulla sessione:

  • Il numero di sessioni completate e rimanenti.
  • Il numero di bug segnalati.
  • Tempo dedicato alla configurazione della sessione.
  • Tempo dedicato ai test.
  • Tempo speso per analizzare problemi o problemi.
  • Funzionalità coperte.

Per riassumere quanto sopra:

SBT consente l'accountability è test esplorativo e offre una migliore gestione del tempo speso per i test. Aumenta anche la produttività e fornisce una migliore comprensione del rilevamento dei bug. È un ottimo modo per fornire ai responsabili del team e ai manager le metriche per controllare l'avanzamento del progetto.

Test esplorativo basato su coppie

Il Pair Testing è un approccio in cui due persone testano la stessa cosa / caratteristica dell'applicazione contemporaneamente condividendo un PC. Condividono continuamente i loro pensieri e le loro idee. Durante questo test, una persona si prende cura della tastiera mentre l'altra persona suggerisce casi di test e prende nota.

È sempre utile avere una buona comunicazione tra i partner in modo che entrambi siano consapevoli di ciò che viene fatto e del perché. Una coppia in cui la forza dei tester si integra reciprocamente con la loro debolezza è considerata un gruppo forte.

Tale accoppiamento avvantaggia entrambe le parti e ciascuna può imparare qualcosa dal proprio partner. È anche un buon modo per addestrare nuove risorse abbinandole a risorse esperte.

Vantaggi del test di coppia

  • Aiuta un tester a concentrarsi sul compito da svolgere.
  • Incoraggiare la fiducia e il rispetto reciproci tra i partner.
  • Il brainstorming tra tester accoppiati di solito porta a idee più costruttive.
  • Evita la visione a tunnel.
  • C'è una minore possibilità che altri li interrompano.

Tecniche di test esplorativo

Tour: È una tecnica semplice che consente a un tester di usare la sua immaginazione e pensare a se stesso come un turista che esplora una città che visita. Qui un'applicazione da testare è la città e i tester sono i turisti. È molto difficile esplorare l'intera città a meno che tu non abbia molto tempo e denaro in mano, quindi un turista deve avere un piano con un certo obiettivo in mente.

Un turista può intraprendere i seguenti tour:

  • Tour della guida - Test delle funzionalità evidenziate dell'applicazione. Usa scenari basati sull'utente.
  • Esplorando la storia della città - Prova le vecchie funzionalità di un'applicazione.
  • Money tour, il che significa assicurarsi che tutte le caratteristiche critiche in riferimento al cliente o cliente siano testate e funzionino con successo.
  • Tour del crimine - Immettere input non validi e testare scenari negativi.
  • Tour del vicolo - Prova le funzionalità meno utilizzate dell'applicazione.
  • Tour noioso - Trascorri il tempo minimo su ogni schermata dell'applicazione, riempi i campi minimi e prendi il percorso più breve. Ciò aiuterà con il valore predefinito e il test di convalida.

Durante un tour, hai sempre la possibilità di scegliere qualsiasi percorso. È possibile navigare nel software e trovare un percorso univoco per testare la funzionalità.

Di seguito sono riportati alcuni suggerimenti / trucchi che puoi utilizzare in ET:

  • Dividi l'applicazione in moduli e biforca i moduli in pagine diverse. Inizia il tuo ET dalle pagine. Questo darà la giusta copertura.
  • Fai una lista di controllo di tutte le funzionalità e metti un segno di spunta quando è coperto.
  • Inizia con uno scenario di base e poi miglioralo gradualmente per aggiungere più funzionalità per testarlo.
  • Testare tutti i campi di input.
  • Verifica il messaggio di errore
  • Prova tutti gli scenari negativi.
  • Controlla la GUI rispetto agli standard.
  • Verificare l'integrazione dell'applicazione con altre applicazioni esterne.
  • Verifica la presenza di una logica aziendale complessa.
  • Prova a eseguire l'hacking etico dell'applicazione.

I fattori che influenzano l'ET sono i seguenti:

  • L'obiettivo del progetto
  • Strategia di test
  • L'obiettivo del test di una fase particolare
  • Strumenti e strutture disponibili
  • Ruolo e abilità dei tester
  • Tempo disponibile
  • Supporto alla gestione
  • Supporto tra pari
  • Risorse disponibili (materiali di studio, condizioni di prova ecc.)
  • Interesse dei clienti
  • Comprensibilità del prodotto.
  • L'interfaccia utente dell'applicazione
  • La funzionalità dell'applicazione
  • Risultati dei test precedenti
  • Rischi associati all'applicazione
  • Difetti precedenti
  • Cambiamenti recenti
  • Tipi di dati da utilizzare per i test
  • Tipo di utente che lo utilizzerà

Invece di chiedere ai tester cosa eseguire, lasciamo che sia il giudizio del tester a decidere cosa vogliono testare e come vogliono testare.

Differenza tra test esplorativi e test ad-hoc

Non confondere ET con Test ad hoc .

  • Il test ad-hoc si riferisce a un processo di ricerca dei difetti non programmato, non programmato e improvvisato, mentre il test esplorativo è una metodologia ponderata per il test ad-hoc.
  • Il test ad hoc è un metodo efficace e di prova per trovare un bug mentre ET non lo è. Nell'approccio ET, un tester apprende il sistema mentre esplora e alla fine evolve i test utilizzando la conoscenza acquisita.
  • Il test ad hoc è un'attività non strutturata mentre l'ET è in qualche modo un'attività strutturata.

Test automatizzati esplorativi (EAT)

Il test automatico esplorativo è un metodo che aiuta un tester a semplificare la segnalazione e la riproduzione dei bug, la raccolta di istantanee e la preparazione della futura tuta di regressione. È un processo che combina i test di automazione con i test esplorativi.

Esistono due tipi di approccio EAT:

  • EAT passivo
  • MANGIARE attivo

EAT passivo

Passive EAT può essere eseguito da un singolo tester o anche in coppia. In questa metodologia, di solito, uno strumento che cattura e registra ogni singola attività eseguita da una o più risorse di test e viene installato sul PC della risorsa.

Passive EAT è simile all'ET che viene eseguito manualmente in quanto non vi è alcun cambiamento nel modo in cui i test vengono eseguiti a parte la creazione del risultato del test in base alla sessione acquisita. Questi risultati dei test possono essere utilizzati per riportare e rimettere in atto azioni registrate in un secondo momento.

Lo strumento video installato aiuta un tester con la registrazione dei casi di test e la segnalazione dei difetti.

Ha anche pochi altri vantaggi come:

  • Fornisce passaggi chiari per riprodurre i bug.
  • La riproduzione dei difetti è più facile anche quando il reporter dei difetti non è disponibile.
  • Elimina i conflitti tra il team di test e quello di sviluppo quando viene segnalato un bug intermittente.
  • Aiuta nei test delle prestazioni ottenendo il tempo di risposta del sistema in un momento specifico.

Ecco alcuni altri punti da prendere in considerazione prima di Passive EAT:

  • Si consiglia di eseguire un test pilota prima di adattare completamente lo strumento per Automated EAT. Questo per garantire che il tempo richiesto per la riprogettazione dei registri di test creati durante la sessione di test non sia superiore all'esecuzione del test. In tal caso, il team deve prendere una decisione reciproca su quanto segue:
    • Se mai è necessaria l'automazione del test per il particolare progetto.
    • Se lo strumento utilizzato deve essere cambiato.
    • Se le prestazioni dello strumento utilizzato possono essere ottimizzate.
  • Lo strumento utilizzato per eseguire EAT automatizzato deve essere installato su ogni risorsa di test coinvolta nel test. È anche una buona idea coinvolgere gli sviluppatori, cosa che può essere ottenuta fornendo agli sviluppatori la VPN o l'accesso remoto alle macchine di test o installando lo strumento nell'ambiente di sviluppo.
  • È sempre una buona idea avere l'oggetto GUI dell'applicazione organizzato nello strumento di test in modo che quando arriva il momento di analizzare il bug o un problema, l'oggetto sia riconoscibile grazie a un nome significativo.
  • È un'ottima pratica dare un nome significativo all'oggetto GUI utilizzato in AUT e mantenerlo organizzato per un uso successivo.

Passiamo ora al secondo approccio.

MANGIARE attivo

Si consiglia di eseguire Active EAT con Pair Testing. In questo approccio, il test basato sulle parole chiave viene utilizzato in sincronia con il test della sessione. Un tester crea lo script di test automatizzato e il secondo tester esegue gli script di test creati dal primo tester.

La creazione di script di test di automazione in questo approccio richiede un percorso diverso rispetto ai test convenzionali. Gli script di test automatizzati vengono creati durante il test e ciò che è stato scoperto nei test precedenti determina il loro design.

Al termine della sessione di test viene eseguita una fase di chiusura. E dovrebbe avere le seguenti attività:

  • I tester coinvolti dovrebbero scambiarsi i ruoli in modo che la risorsa di test che ha creato lo script di test abbia la possibilità di rieseguire gli script per confermare l'affidabilità e la robustezza della suite creata.
  • Per ogni script di test automatizzato dovrebbe essere fornita una breve descrizione con poche caratteristiche identificative.
  • È necessario definire un criterio per identificare quali script di test automatizzati possono essere utilizzati per il test di regressione.

Benefici di EAT

  • All'inizio di ogni sessione, vengono eseguiti script di test automatizzati già creati, migliorando ogni volta la copertura del test.
  • Migliore segnalazione e documentazione dei bug per la riproduzione dei difetti.
  • EAT fornisce prove e documentazione sufficienti per consentire a uno stakeholder di vedere i progressi.

Tipi di test esplorativi

Di seguito sono riportati alcuni tipi di ET:

1) Freestyle E:

Esplorazione dell'applicazione in stile ad-hoc.

In questo tipo di ET, non ci sono regole, nessun account per la copertura, ecc. Tuttavia, questo tipo di test è utile quando è necessario familiarizzare rapidamente con l'applicazione, quando si desidera verificare il lavoro degli altri tester e quando si desidera indagare su un difetto o si desidera eseguire un rapido test del fumo.

2) ET basato sullo scenario:

Come suggerisce il nome stesso, i test effettuati sono basati su scenari. Inizia con scenari dell'utente reale, scenari end-to-end o scenari di test. Dopo il test iniziale, i tester possono iniettare variazioni in base al loro apprendimento e osservazione.

Gli scenari sono come una guida generica su cosa fare durante ET. I tester sono incoraggiati a esplorare più percorsi possibili durante l'esecuzione di uno scenario per garantire che tutti i percorsi possibili per il lavoro delle funzionalità. I tester dovrebbero anche assicurarsi di raccogliere il maggior numero possibile di scenari da diverse categorie.

3) StrategiaET basato:

Tecniche di test note come l'analisi del valore limite, la tecnica di equivalenza e la tecnica basata sul rischio che sono combinate con i test esplorativi. Per questo tipo di test viene nominato un tester esperto o un tester che abbia familiarità con l'applicazione.

Test esplorativo agile

Anche se non hai lavorato in un ambiente agile, sono sicuro che devi averlo letto o sentito parlare a causa della sua crescente popolarità. La metodologia Agile ha sprint brevi e scadenze ravvicinate che danno al team un paio di settimane per completare la pianificazione, la stima, lo sviluppo, la codifica, il test e il rilascio.

Il test esplorativo diventa utile in tempi così stretti perché in questo approccio di test l'enfasi è sul risultato rapido e utile. Una volta compreso il requisito, puoi iniziare i test in base alla tua esperienza e conoscenza.

Una volta acquisita familiarità con le funzionalità e il comportamento dell'applicazione, è possibile progettare più casi di test per convalidare la funzionalità dell'applicazione e rilevare bug non pianificati. Poiché si tratta di un approccio di test freestyle, devi documentare tutto. Tuttavia, è necessario mantenere note e un breve rapporto su ciò che è stato testato, bug e problemi rilevati ecc.

Meriti dell'esplorazione in Agile

  • Fornire feedback agli sviluppatori il prima possibile.
  • Viene scoperta una più ampia varietà di difetti.
  • Un gruppo eterogeneo di una risorsa come uno sviluppatore, tester, BA, designer può eseguire ET poiché non ci sono casi di test con script e ognuno porta una prospettiva diversa.
  • Lo scouting svolto in ET aiuta a esplorare nuovi territori e ad esporre bug critici.
  • In caso di codifica iterativa di un'applicazione, ET può concentrarsi sul test di nuove funzionalità mentre l'automazione esegue test di regressione e compatibilità con le versioni precedenti.
  • In caso di requisiti instabili, ET può aiutare a testare nuovi requisiti entro un tempo limitato.

Punti da ricordare:

1. Richiede abilità diverse: I tester che eseguono ET devono avere buone capacità di ascolto, lettura, pensiero e reporting. È richiesta esperienza nel dominio in quanto non ci sono script e casi di test.

2. A volte è difficile segnalare un bug: Durante un flusso ET, potremmo riscontrare un difetto ma potremmo non essere in grado di riprodurlo. Questo perché non stiamo monitorando i passaggi del test e potremmo dimenticare i passaggi esatti per riprodurre il problema.

3. Può essere svolto come attività ricreativa: Personalmente faccio ET quando voglio una pausa dal mio normale ciclo di esecuzione dei test. Ma molti team hanno ET come fase separata del loro ciclo di test.

4. Può essere fatto per tutte le fasi di test: Possiamo implementare ET prima dell'inizio di qualsiasi fase di test. È possibile eseguire ET anche prima della fase di test funzionale.

5. Feedback rapido: ET richiede un rapido feedback sui problemi e sulle eventuali anomalie riscontrate.

6. Pensiero critico e idee diverse: Questo test richiede un pensiero critico. I tester dovrebbero essere in grado di riprodurre, rivedere ed esprimere le loro idee in modo logico. Un tester può implementare la sua esperienza nelle varie tecnologie e domini su cui ha lavorato.

Come pensare oltre i confini dei test tradizionali nei test esplorativi

'Apprezzo molto la tua preoccupazione per il prodotto e il fatto che ci rendi utili in una prospettiva comprensiva dell'utente finale. Sarà molto utile. Grazie per l'ottimo lavoro e continuate così !!! '

Questa è stata l'ultima e-mail di una catena di e-mail con 21 e-mail del nostro cliente. Era mezzanotte e il rilascio del nostro prodotto è stato ritardato a causa di un bug critico che abbiamo trovato. Potresti pensare, cosa c'è di nuovo in questo? Può succedere molte volte. Ma questo era davvero diverso in quanto il bug critico che abbiamo segnalato non era il risultato di alcun caso di test documentato.

Dopo aver completato test di regressione per l'ultima volta quella sera, stavo solo giocando con il prodotto. Cosa significa? Sei libero di fare ciò che non dovresti fare. Sulla base della mia esperienza e conoscenza del progetto, ho avuto alcune idee su come testare il prodotto oltre al nostro tipico repository di test, chiamato Test esplorativi .

Il test esplorativo svolto ha rilevato un bug critico relativo a un problema di blocco del server durante l'esecuzione di qualcosa di inaspettato.

Essendo un fan dei test esplorativi, amo esplorare il prodotto in modi diversi. Per me, la definizione di software è:

'Dovrebbe fare quello che dovrebbe fare, e non dovrebbe fare quello che non dovrebbe fare.'

Processo di test esplorativo

come aprire un file apk su Android

Limitare i limiti dei test per verificare se i prodotti che dovrebbero funzionare stanno funzionando ti rende un tester incompleto. In effetti, la vita di un tester inizia quando i test di regressione documentati terminano e i risultati vengono aggiornati. Guardare i prodotti da diverse prospettive e comprendere i requisiti degli utenti finali in diversi scenari fa una grande differenza. Quindi oggi, vediamo insieme come si può fare la differenza:

Come guardare un prodotto da diverse prospettive?

test esplorativi

# 1. Comprendere il cliente / utente finale

Il test del software consiste nel controllare la qualità del prodotto in termini di soddisfazione del cliente. Come conosci il punto di vista di un cliente? La risposta è semplice: devi essere il cliente. OK, fammi fare una correzione. Essere clienti non sarà sufficiente. Devi capire come il cliente vuole gestire il prodotto. Non esistono due clienti che hanno acquistato le stesse materie prime prepareranno la stessa ricetta. Sì, il prodotto che sviluppiamo / forniamo è una materia prima per le attività dei clienti e hanno una mentalità diversa mentre lo utilizzano.

In qualità di tester di software, dobbiamo verificare lo scopo del prodotto e non l'oggetto o l'aspetto di esso.

Lascia che ti dia alcuni esempi pratici di vita reale:

  • Le forbici non si sono mai limitate a tagliare solo la carta. Il taglio è lo scopo e non la carta (oggetto).
  • I telefoni cellulari non si sono mai limitati a chiamare, ma 'in grado di chiamare' è sempre stato lo scopo fondamentale.
  • Le scatole di immagazzinaggio sono usate per immagazzinare, ma la sicurezza del materiale immagazzinato è importante quanto la conservazione.

La comprensione degli stakeholder e un'ampia gamma delle loro aspettative dovrebbe essere la base dei test esplorativi.

# 2. Una mentalità

Mentre cerchi (diciamo) un annuncio di lavoro, vedi quel jackpot e tra le pagine con il carattere in grassetto? La maggior parte di noi non lo fa (credimi, è vero). Perché abbiamo istruito la nostra mente a cercare ciò che è utile o da controllare. Qualsiasi altra cosa è inutile, quindi la mente ci nega di riconoscerla.

Apri la tua mente e non impostare aspettative quando inizi a esplorare un prodotto . Ricorda sempre, non va bene se il prodotto sta facendo quello che dovrebbe fare. È anche importante che non faccia ciò che non dovrebbe fare.

Ricordo un classico esempio:

In Linux, il comando 'cat' viene utilizzato per controllare il contenuto di un file e il comando 'ls' serve per controllare il contenuto della directory. Lavorando con Linux e testando software da cinque anni, non ho mai pensato di fare cat perché la mia mente era pronta; se ho bisogno di contenuti dir, devo usare 'ls'. Ha funzionato, ma il rovescio dell'aspettativa è che il prodotto non avrebbe dovuto comportarsi come non avrebbe dovuto, era sbagliato. Uno dei nostri clienti, che non conosceva bene Linux, ha commesso un errore e il sistema si è bloccato. Abbiamo pagato per questa mentalità.

Sii sempre pronto a commettere errori con il software perché questo è ciò che farà l'utente finale. Per testare il software, sei stato addestrato, ma l'utente finale non lo sarà come te oppure non sarà un esperto tecnico come te. Inoltre, farà qualsiasi cosa con il software quando sono nei guai.

Pensa a questi scenari e fornisci feedback sui test. La vita del software e la tua (come tester) saranno fantastiche.

# 3. Conosci i concorrenti

Durante il test di un'applicazione software per il tuo cliente, hai mai tentato di conoscere e comprendere altro software con lo stesso scopo? Hai mai suggerito alcune funzionalità utili che hai osservato in un prodotto della concorrenza? Non rientra nella nostra descrizione del lavoro, è la risposta tipica. Ma conosci il vantaggio di farlo?

Ecco alcuni esempi di vita reale per farti capire il punto:

  • Non ti piace lo stilista che non solo cuce il tuo vestito, ma ti fornisce anche suggerimenti per abbinare gli accessori?
  • Non ti piace il marchio di pizza che non solo fa ottime pizze ma consegna a casa la maggior parte in tempo?
  • Non ti piace il fotografo che non solo scatta buone fotografie ma suggerisce un diverso tipo di fotogrammi per il servizio fotografico?

Tutti vogliono avere qualcosa in più per quello per cui pagano. La nostra analisi del software competitivo può funzionare allo stesso modo per noi. Al cliente piace sempre ricevere suggerimenti preziosi, principalmente suggerimenti comparativi per rendere il prodotto più utile o commerciabile.

Inoltre, questo tipo di confronto e analisi della stessa gamma di prodotti rende la nostra analisi più potente e alla fine creiamo un tesoro a cui possiamo tornare in qualsiasi momento e trovare qualcosa di utile.

Conclusione

L'esplorazione non rientra in un modo convenzionale di test, ma è comunque un modo molto potente di test.

Fa emergere il pensiero fuori dagli schemi di un tester e lo incoraggia a trovare casi di test pratici e in tempo reale per trovare un difetto. La sua natura freestyle gli conferisce un vantaggio rispetto agli altri tipi di test e può essere eseguito ovunque, sia che si tratti di un progetto che utilizza Agile o cascata o qualsiasi altro progetto che richiede una documentazione minima.

Il successo dei test esplorativi dipende da numerosi intangibili come l'abilità di un tester, la capacità di creare casi di test efficaci, la loro esperienza e l'abilità di seguire il loro istinto.

È imperativo ricordare che ET è un processo adattivo piuttosto che predittivo ed è essenziale mantenere un sano equilibrio tra test esplorativi e test programmati o regolari.

Sei un tester che ha esperienze tipiche di test esplorativi? Stiamo aspettando di sentire i tuoi pensieri. Sentiti libero di condividerli nella sezione commenti qui sotto.

Prossimo tutorial n. 2: Come utilizzare i tour per garantire un test esplorativo completo

Lettura consigliata

^