Menu

3 strategie per affrontare un difetto bloccante

3 strategies dealing with blocker defect

Prova Il Nostro Strumento Per Eliminare I Problemi

I difetti di blocco aggiungono tonnellate di dramma a giorni di test altrimenti regolari.

In questo articolo, voglio coprire alcuni passaggi che un tester può intraprendere quando li gestisce.

Presumo che i nostri cari lettori comprendano già profondamente la gravità e la priorità dei difetti. Hai bisogno di un breve riepilogo? Controllalo.

Ora, significa sempre che dobbiamo interrompere completamente i test se riscontriamo un problema di blocco?

In alcuni casi 'Sì', ma forse non sempre. Potrebbero verificarsi casi in cui è possibile eseguire alcune attività di test.

Affronta il difetto del bloccante

Immagine fonte

Di seguito sono riportate alcune situazioni che ho vissuto nella mia carriera di tester. Credo fermamente che i passaggi descritti di seguito (successivamente consolidati in un diagramma di flusso) debbano essere seguiti per rendere questo processo più semplice.

Facciamo subito un salto.

Passaggi da eseguire quando si verifica un difetto di blocco

Passo 1: Quando incontri un problema, investi tempo per trovare la causa principale.

Credo fermamente che come tester il nostro lavoro non finisca a segnalazione di difetti . Se il tempo lo consente, dovremmo esplorare cosa potrebbe aver causato il problema. Potremmo non essere sempre in grado di indicare l'esatta area del problema, ma cerca di risolverlo il più possibile. Gli stessi dettagli possono essere aggiornati nel difetto come commenti aggiuntivi.

L'ho fatto molto nei miei progetti e questo ha portato a una soluzione rapida. I vantaggi dell'analisi della causa principale siamo:

  • Essendo un valore aggiunto, questo può sicuramente fornire una migliore direzione allo sviluppatore per la risoluzione dei bug.
  • Inoltre, il tester QA può riconoscere se questo problema è auto-creato (immissione di dati o problemi di utilizzo umano) e, in tal caso, può essere risolto dal tester stesso. Quando tali errori vengono segnalati agli sviluppatori senza che noi controlliamo dalla parte del QA, lo sono considerato un non problema e potrebbe creare una reputazione negativa per il tester.

Quindi, suggerisco di ricontrollare sempre alla nostra fine prima di registrare un difetto.

Ecco alcuni esempi in tempo reale dei miei progetti che rafforzeranno i punti precedenti:

Ho lavorato a un progetto in cui i nostri test richiedevano di rilasciare un file in una posizione specificata. Rinominalo in modo che corrisponda al nome nella configurazione. Un lavoro pianificato preleverà il file di dati e caricherà i dati nel sistema. Dopodiché, convalideremo i dati nel database e nel front-end.

quale programma aprirà un file eps

Ci siamo imbattuti in problemi in cui il lavoro veniva eseguito ma i dati non venivano caricati e, dopo un'analisi, è stato perché il tester non ha cambiato il nome mentre rilasciava il file nella posizione.

Questo era un blocco per noi ma non qualcosa che richiedeva l'attenzione degli sviluppatori. Abbiamo dovuto prestare attenzione ai dettagli ed evitare piccoli errori.

Di seguito sono riportate alcune categorie comuni, cause principali e rimedi:

# 1) File host Problema - Diciamo, il tuo file hosts ha parametri che non sono corretti e stanno causando il problema. In questo caso, puoi aggiornare tu stesso il file host o chiedere aiuto a qualcuno con accesso per l'aggiornamento e continuare l'esecuzione del test.

Un difetto per lo stesso dovrebbe essere sollevato in modo che gli sviluppatori possano indagare, ma con la soluzione alternativa il test funzionale può ancora essere continuato.

Nota: Verificare con i team di progetto se è consentito al team di controllo qualità apportare queste modifiche prima di farlo.

# 2) Configurazione - Spesso, abbiamo notato problemi di configurazione come il mancato riferimento all'ambiente corretto o altri problemi di configurazione, che bloccano i problemi. Anche in questi casi i tester possono apportare modifiche e procedere con i test.

Nota: Ancora una volta, chiedi il permesso prima di farlo.

# 3) Emissione del codice - Se ritieni che il problema sia dovuto al codice, i tester non possono fare molto. Registra un difetto di blocco e attendi che la correzione proceda con il test.

# 4) Problema di distribuzione - Una cattiva distribuzione è un'altra causa comune di problemi di blocco e questi possono essere rilevati durante il test di integrità. Anche qui, il test dovrebbe essere interrotto immediatamente fino a quando non viene ricevuta una nuova build.

# 5) Ambiente in calo - Se l'ambiente è inattivo, dire che il database non si connette al server o l'URL non funziona in caso di siti web; i tester non possono fare molto in questi casi se non segnalare un difetto e attendere che il sistema sia attivo e funzionante.

Pertanto, se esiste una soluzione alternativa, utilizzarla per continuare il test. L'unico modo per trovare, se esiste tale soluzione alternativa, è indagare la causa principale. Il più delle volte, potrebbe esserci un'alternativa.

Passo 2: È molto facile cadere in un ciclo infinito quando si studia la causa principale. Quindi, assicurati che non stia consumando tutto il giorno e tutti gli sforzi.

Ecco alcuni suggerimenti:

  • Trova un equilibrio e riconosci il punto di arresto quando arrivi.
  • L'esperienza e la competenza di un tester sono fondamentali per un RCA di successo. Tuttavia, è una buona idea coinvolgere il team e il team lead, quando necessario.
  • Quando ritieni che l'RCA richieda molto tempo, segnala immediatamente il problema e fornisci quante più informazioni possibile. Uno screenshot è sempre utile.
  • Se necessario, follow-up. Invia un'e-mail al manager o allo sviluppatore per portare l'attenzione sul problema critico.
  • Continua la risoluzione dei problemi dopo aver avvisato le parti necessarie.

Motivo per cui i difetti del blocco devono essere segnalati immediatamente:

  • La direzione deve essere informata di tutti i tempi di inattività se il problema è un difetto che si ferma. Queste informazioni devono essere inoltrate al cliente e possono anche richiedere aggiornamenti del piano di progetto (scadenze QA), modifiche ai risultati finali, ecc.
  • Qualsiasi ritardo nei risultati del QA deve essere supportato da prove. Quindi è sempre meglio comunicare il prima possibile invece di aspettare fino alla fine della giornata.

Passaggio 3: Ora, passando all'ultimo passaggio da quando abbiamo finito di analizzare il problema e comunicarlo, qual è il passo successivo?

test end-to-end vs test di regressione
  • Se il problema sta bloccando l'accesso a un'area funzionale, controlla se ciò ha un impatto su altre aree
  • Se l'app front-end è inattiva, controlla se è possibile continuare il test di backend / middleware / database.
  • Se non è possibile eseguire attività di test, provare a farlo lavorare su un po 'di documentazione relativo al tuo progetto.
  • Puoi anche provare a identificare le aree per l'automazione se stai ripetendo manualmente molto lavoro. L'automazione non deve sempre utilizzare uno strumento. Supponiamo che la generazione di report sia un'attività monotona per te, ovvero un'area che può essere automatizzata da semplici macro Excel e simili.
  • Dedica del tempo alla conoscenza degli strumenti open source che possono essere implementati nel tuo progetto
  • Ultimo ma non meno importante , lavora per l'innovazione, il mantra che governa il mondo attualmente!

Infine , il diagramma di flusso che riassume l'intera discussione!

Diagramma di flusso: passaggi per gestire un difetto di blocco

difetto bloccante

Autore : Questo fantastico articolo è stato scritto dal membro del team STH Priya R.

Quali passi fai quando incontri un difetto di blocco?

Lettura consigliata

^