art bug reporting
Perché è necessario commercializzare un bug?
Le prime cose che mi vengono in mente quando inizio a scrivere questo articolo sono le parole di Cem Kaner - 'Il miglior tester non è quello che trova il maggior numero di bug o che mette in imbarazzo la maggior parte dei programmatori. Il miglior tester è quello che ottiene la maggior parte dei bug corretti. '
Ora - Qual è la differenza tra trovare la maggior parte dei bug e ottenere la maggior parte dei bug risolti ?
Non è ovvio che qualsiasi bug registrato in un file sistema di gestione dei bug dovrebbe essere risolto dallo sviluppatore? La risposta è No. Fattori come il tempo per commercializzare il prodotto, il tempo per completare il progetto nei tempi previsti e gli sviluppatori che lavorano orari poco pratici ecc. costringono le aziende a rilasciare il prodotto con pochi bug che non influenzeranno ampiamente gli utenti.
[Immagine fonte ]
Chi dà fiducia alla direzione affermando che i bug presenti nel prodotto non avranno un impatto sulla fiducia del cliente, l'affidabilità e l'interesse delle parti interessate? - L'ingegnere di test o il team di test: è compito di ciascun ingegnere di test ottenere la correzione dei bug che potrebbero avere un impatto negativo sulla qualità del prodotto.
La priorità del bug , a mio parere, dipende in gran parte da come un problema viene presentato dal tester ai team di sviluppo e gestione.
Pensa a come pubblicizzare o commercializzare il problema - questo prevede 2 passaggi:
- Scrivi o segnalare i bug correttamente
- Sapere tutto sul bug, quindi ogni ulteriore dettaglio può essere spiegato meglio
Cosa imparerai:
- L'arte della segnalazione dei bug
- Partecipazione efficiente alle riunioni di controllo della versione del software
- Impatto della mancata commercializzazione di un bug
- Conclusione
- Lettura consigliata
L'arte della segnalazione dei bug
Sì, la segnalazione di bug è un'arte . Il modo in cui viene scritto un bug mostra l'abilità tecnica, l'esperienza del dominio e le capacità di comunicazione di un ingegnere di test.
In genere, un bug dovrebbe contenere le seguenti informazioni:
- Riepilogo dei bug
- Passaggi per riprodurre
- Allegati (istantanea, file di registro ecc.)
- Riproducibilità dei bug
- Gravità dei bug
- Versione software, informazioni sull'ambiente
- Altre informazioni in base ai requisiti organizzativi.
Una nota importante: Scavare sempre più a fondo per trovare la causa principale del problema e segnalarlo. Ad esempio, un semplice errore di accesso con la corretta combinazione di nome utente e password può essere correlato a vari motivi come:
- Credenziali di accesso non convalidate affatto
- Problemi di timeout di rete in caso di accessi remoti
- Il sistema può considerare tutte le maiuscole come non maiuscole.
Quindi, come tester dovresti essere in grado di decifrare le differenze mentre segui le dichiarazioni di riepilogo dei bug:
- 'Impossibile accedere con il nome utente e la password corretti'
- 'Impossibile accedere con il nome utente e la password corretti, quando il nome utente o la password contengono una combinazione di lettere maiuscole e non maiuscole.'
Quest'ultima è una descrizione molto chiara del problema e non è ambigua. Con questo, non solo aumenti la tua credibilità come tester, ma stai anche segnalando il problema reale invece di un sintomo.
Ora, diamo un'occhiata a ogni campo coinvolto in una segnalazione di bug e discutiamo gli aspetti importanti di ciascuno di essi:
# 1. Riepilogo dei bug
Un riepilogo dei bug dovrebbe fornire una rapida istantanea di quale sia esattamente il problema. Deve essere preciso e ben diretto.
Esempio :
A parte la teoria, cercherò di spiegare con esempi.
Supponiamo che un semplice modulo di accesso. Supponiamo che il problema si verifichi poiché un nuovo utente che visita un sito web non è in grado di accedere con la sua password predefinita. Quando ho presentato lo stesso scenario a molti degli studenti che ho formato durante la fase iniziale della formazione, c'erano diverse risposte come riepilogo dei bug. Di seguito sono riportati alcuni esempi di come appariva il riepilogo:
domande e risposte dell'intervista di prova manuale per 3 anni di esperienza
' Il nuovo utente non è in grado di accedere '
'L'accesso utente non funziona come previsto'
'L'utente non è in grado di accedere con la password corretta'
Dagli esempi precedenti, puoi scegliere un'affermazione che descriva effettivamente il problema? Non credo proprio. Il riepilogo dovrebbe sempre fornire informazioni complete sullo scenario di errore.
Considera la seguente dichiarazione:
'Il nuovo utente non è in grado di accedere con la password predefinita fornita tramite e-mail o SMS'
Come puoi vedere, dalla dichiarazione di cui sopra uno sviluppatore può capire chiaramente qual è il problema e dove si trova.
Quindi, prova a trovare le parole giuste per descrivere il riepilogo che darebbe le informazioni direttamente. Dichiarazioni generiche come 'non funziona correttamente', 'non funziona come previsto' ecc., Devono essere evitate.
# 2. Passaggi da riprodurre e allegati
Gli insetti irreproducibili passano sempre in secondo piano anche se possono essere significativi. Pertanto, fare molta attenzione a scrivere i passaggi in modo corretto e descrittivo.
I passaggi dovrebbero essere accurati ed esattamente uguali a quelli che hanno portato al problema. Per i bug relativi alla funzionalità, il seguente esempio è il miglior esempio.
Esempio :
Considera lo stesso problema indicato nella sezione precedente.
- Crea un nuovo utente utilizzando l'opzione Registrati nella home page. (Nome utente di esempio: HelloUser)
- Riceverai un'e-mail e un SMS con una password predefinita. L'ID e-mail e il numero di cellulare per gli SMS vengono forniti durante la creazione dell'utente nel passaggio 1. (E-mail di esempio: HelloUser@hello.com , Esempio di numero di cellulare: 444-222-1123)
- Seleziona l'opzione Login nella home page.
- Nel campo di testo del nome utente, fornire il nome utente di esempio fornito nel passaggio 1.
- Nel campo della password, fornire la password predefinita ricevuta tramite e-mail o SMS.
- Fare clic sul pulsante Accedi
- Risultato atteso: L'utente dovrebbe essere in grado di accedere con il nome utente e la password forniti e accedere alla pagina dell'account utente.
- Risultato attuale: Viene visualizzato il messaggio 'Nome utente / password non valido'.
Se una qualsiasi delle informazioni non viene fornita nel campione precedente, lo farà provocare lacune nella comunicazione e lo sviluppatore non sarà in grado di riprodurre il problema. I passaggi devono essere specifici e dettagliati con i dati di esempio utilizzati durante il test.
Se possibile o laddove applicabile, fornire a istantanea di ciò che vedi esattamente sullo schermo. In questo modo, non solo fornirà una buona visione del problema agli sviluppatori, ma anche una prova del risultato del test.
Il non funzionale casi di test come stress, stabilità o casi di test delle prestazioni oltre ai dettagli di cui sopra, le informazioni sullo scenario che causa lo stress al sistema possono essere riportate così come sono. Inoltre, ci sono pochi sistemi che riportano i log per ogni operazione eseguita. I log sono in genere istruzioni di stampa fornite dagli sviluppatori nel loro codice. Ogni volta che viene eseguito un modulo, i log corrispondenti verranno stampati o visualizzati. Quando i registri sono disponibili, ciò aiuterebbe gli sviluppatori in larga misura a riprodurre il problema.
# 3. Riproducibilità dei bug
Un problema grande o piccolo avrà la priorità in base alla riproducibilità. Può essere visto sempre, a volte, raramente o anche solo una volta. Un problema che viene riprodotto come 'sempre' avrà una priorità più alta rispetto al resto.
Quindi, è compito di un ingegnere di test tracciare lo scenario esattamente per il problema che viene sempre riprodotto. A volte potrebbero esserci pochi problemi fuori dal controllo di un ingegnere che comporterebbe la riproduzione di un problema solo poche volte ma in più prove. In questi casi, menzionare sempre il numero di prove, uno scenario particolare viene eseguito insieme al numero di volte in cui il problema viene visto durante quelle prove.
Questo, a sua volta, aggiungerebbe credibilità alla segnalazione di bug da te menzionata. Ancora una volta, questo migliorerebbe la tua reputazione come tester. Più tardi ti spiegherò i motivi per avere una buona reputazione.
# 4. Gravità dei bug
La gravità è senza dubbio uno dei maggiori influencer per dare la priorità al Bug.
Di seguito sono riportate le diverse categorie di gravità. Si prega di notare che questi sono solo esempi generali e variano da azienda ad azienda.
- Gravità 1 - Show Stopper - per i bug che sono catastrofici, senza essere corretti l'utente non sarà in grado di continuare a utilizzare il software e non ci sono soluzioni alternative
- Gravità 2 - Alta - per bug simili a Severità 1, ma esiste una soluzione alternativa
- Gravità 3 - Media
- Gravità 4 - Bassa
- Gravità 5 - Banale.
Ad esempio, confrontiamo due problemi simili.
Nei nostri set-top box, pochi fornitori di servizi forniscono le informazioni sulla frequenza del servizio attualmente sintonizzate. Supponiamo che la frequenza venga visualizzata come 100 MHz invece di 100,20 MHz. Ciò potrebbe non influire sulla visualizzazione dei servizi da parte dell'utente, ma potrebbe influire in termini di monitoraggio della diagnostica dei set-top. Quindi questo può essere presentato come un problema di Gravità 3.
Supponendo un problema simile nel dominio bancario: se il saldo del tuo account viene visualizzato come $ 100, invece di $ 100,20, immagina l'impatto del problema. Deve essere un difetto di gravità -1. Come puoi vedere in entrambi i casi, il problema è molto simile al fatto che l'interfaccia utente non mostra le cifre dopo il punto decimale. Tuttavia, l'impatto varia a seconda del dominio coinvolto.
Partecipazione efficiente alle riunioni di controllo della versione del software
Di solito, ogni organizzazione ha il proprio processo per indagare e assegnare priorità ai bug. In genere, si verifica un incontro a intervalli specifici durante il progetto per discutere i bug e dare la priorità agli stessi.
Il processo durante tali riunioni è il seguente:
- Interroga l'elenco dei bug dal sistema di gestione dei bug in base alla gravità.
- Guarda il riepilogo e discuti l'impatto del bug sull'esperienza dell'utente nell'utilizzo di un prodotto software.
- Sulla base della valutazione del rischio e dell'impatto, impostare la priorità e assegnare il bug a uno sviluppatore appropriato per risolverlo.
Durante il passaggio n. 2, è imperativo che ogni ingegnere di test sostenga l'impatto del bug sull'esperienza utente se il bug non riceve la priorità che merita. Dopotutto, siamo noi ingegneri che prendono in considerazione il punto di vista di un utente per scrivere casi di test e testare il prodotto.
Considera il problema di esempio precedente di non visualizzare le cifre dopo il punto decimale in un dominio bancario. A uno sviluppatore, può sembrare un problema meno grave. Potrebbe sostenere che invece di dichiarare la variabile come un numero intero, lo dichiarerebbe come virgola mobile per risolvere il problema e quindi meno grave.
Ma come tester, il tuo ruolo è spiegare la situazione del cliente. Il tuo punto dovrebbe essere il modo in cui l'utente si lamenterebbe in questo scenario. Il tester dovrebbe dire che ciò causerà il panico tra gli utenti poiché il cliente perde i suoi soldi in centesimi.
Impatto della mancata commercializzazione di un bug
Se un bug non viene commercializzato correttamente, creerà problemi come:
- Priorità del difetto errata
- Ritardo nella risoluzione delle questioni importanti
- Rilascio del prodotto con gravi difetti
- Feedback negativo dei clienti
- Svalutazione del valore del marchio
A parte tutti i motivi sopra menzionati, è molto importante costruire il tuo file reputazione come ingegnere collaudatore . È più come sviluppare un valore del marchio per te stesso.
Nella fase iniziale della tua carriera, se riesci a mantenere il numero di 'Impossibile riprodurre' o 'Sono necessarie ulteriori informazioni' o 'Non un bug valido' o le modifiche di gravità il più basso possibile, a un certo punto i tuoi bug non verranno esaminati del tutto e verrebbero assegnati direttamente allo sviluppatore appropriato da correggere.
Per sviluppare tale valore del marchio e conquistare la fiducia del tuo team e dei team di sviluppo / o gestione, devi sviluppare alcune abilità tecniche in termini di verifica delle conoscenze, dominio e capacità di comunicazione.
Conclusione
Qualsiasi prodotto o servizio, grande o piccolo, è sempre destinato a fallire senza una pubblicità adeguata. Una volta stabilito un marchio, qualsiasi piccolo prodotto può essere un grande successo con il pubblico.
Detto questo, la pubblicità eccessiva di un prodotto può anche causare danni alla reputazione.
Quindi, un bug dovrebbe sempre essere scritto in modo chiaro, conciso e preciso in modo da fornire una posizione esatta del bug nella mappa software estesa / esaustiva. Ribadisco che questo non solo migliora la qualità del software, ma riduce anche in larga misura i costi di test e sviluppo del software.
Non è troppo tardi adesso! Andiamo avanti e risolviamo subito i bug!
come aprire il file jnlp in Windows 10
Lettura consigliata
- Perché la segnalazione dei bug è un'arte che dovrebbe essere appresa da ogni tester?
- Come si risolvono tutti i bug senza l'etichetta 'Bug non valido'?
- Esempio di segnalazione di bug
- Esempi di report di bug per applicazioni Web e di prodotto
- 3 peggiori abitudini di segnalazione dei difetti e come romperli
- 10 motivi per cui i tuoi bug vengono rifiutati e cosa puoi fare come tester!
- Come scrivere una buona segnalazione di bug? Suggerimenti e trucchi
- Come trovare un bug nell'applicazione? Suggerimenti e trucchi