Come segnalare i bug in modo intelligente [chiuso]

Question

Voglio scrivere (o trovare) una guida per un'efficace segnalazione dei bug in uno stile simile a quello dell'ESR Come porre domande in modo intelligente

Quali sono i tuoi migliori consigli per segnalazioni efficaci di bug?

Answer 1

• Istruzioni dettagliate su come ricreare il bug
• Assicurati di aver tentato di isolare il bug da ciò a cui stai effettivamente scrivendo un bug, invece di qualcos'altro che potrebbe essere la causa.
• L'elenco tenta di isolare il bug in qualcosa di diverso dal software contro cui stai scrivendo un bug
• Renditi disponibile per rispondere alle domande ed essere disponibile per aiutare a risolvere / ricreare il bug

La linea di fondo è che devi affrontare un certo livello di pensiero critico quando viene riscontrato il bug. Una volta esaurite tutte le possibilità che potrebbe essere colpa tua, scrivi un bug. Se scopri che è colpa tua, ma il software che stai utilizzando / test avrebbe potuto fare qualcosa di più utilizzabile per indicare la sua colpa, scrivi ancora un bug.

Inoltre, per essere un ottimo reporter di bug, devi avvalerti di coloro che testano il bug per aiutarli a ricrearlo. È probabile che tu abbia appena " ottenuto il talento " per ricreare quel bug e potrebbero esserci dei passaggi di cui non sei consapevole. Non puoi semplicemente lamentarti e andartene, partecipare al processo e aiutare il team testando, ricreando e risolvendo i problemi.

Answer 2

Segnala i fatti osservabili e quindi la tua interpretazione di tali fatti.

A volte le migliori segnalazioni di bug includono qualcosa che è una sensazione di comprensione del problema. La segnalazione di bug a soli fatti sconta questa preziosa risorsa umana.

Answer 3

• Procedura utilizzata per ricreare il bug, incluso ciò che veniva fatto, quale area dell'applicazione veniva utilizzata e quale evento stava accadendo in quel momento.
• Dichiarazione di riproducibilità (affidabile, non) - aiuta lo sviluppatore a sapere quanto dovrebbe essere difficile riprodurre in modo che non si arrendano rapidamente
• Schermate o documentazione del messaggio di errore / traccia dello stack prodotta
• Criticità / Priorità del bug (può essere evitamento, passaggi da evitare, è catastrofico, ha un impatto aziendale, qual è il rischio aziendale, ecc.)
• Ambiente: in quale ambiente si trova il bug. Remoto, locale, ecc.

Troppo spesso, i nostri addetti al QA pensano di poter semplicemente mettere un ticket dicendo: ecco la mia eccezione senza alcuna documentazione di backup. È quasi impossibile riprodurlo e tanto meno risolvere il problema senza ulteriori informazioni.

Answer 4

Non dare per scontato che il lettore della segnalazione di bug conosca il software così come lo sai tu . Anche la persona che ha scritto il software potrebbe non sapere di cosa stai parlando se è passato abbastanza tempo da quando lo hanno scritto. Scrivilo in modo che chiunque possa capire e riprodurre il problema.

Answer 5

Consiglia questo articolo: Come segnalare efficacemente i bug

Answer 6

Per tutte le persone che non guarderanno qualcosa senza passaggi per riprodurre:
Al mio primo lavoro di programmazione cooperativa mi è stato assegnato un bug che era essenzialmente una condizione di gara casuale che rendeva instabile il sistema. Accadde in qualsiasi momento nell'esecuzione del sistema, e tutto ciò che avevamo erano alcune tracce dello stack che puntavano a una sezione di codice che era ovviamente ovvia. Da qualche parte un altro thread stava confondendo con i dati che non dovrebbero essere e se questo thread fosse nel punto giusto si bloccherebbe. Il nostro QA ha avuto crash circa una volta al mese. Sono state necessarie due settimane di esplorazione del sistema per trovare il colpevole (sì, accesso non controllato alle risorse condivise, circa una correzione di 2 righe) e risolverlo. Non ci sono mai stati passi decenti per riprodursi perché non c'era un modo generale per riprodurlo (salvo spingere un mucchio di rendimenti () nel posto giusto). Se hai intenzione di lavorare su un sistema multithread, è meglio essere pronti a gestire i bug che non possono essere riprodotti in modo affidabile, potrebbero non avere passaggi stabili per la riproduzione e non solo lamentarsi con il QA perché non è possibile riprodurre il bug .

Nota che quanto sopra non è una scusa per il QA per non includere quanti più dettagli possibile quando possibile, sottolineando che non è sempre possibile sui software moderni.

Answer 7

Scrivi i passaggi per riprodurre il bug. Se non riesci a riprodurlo, non verrà corretto.

Answer 8

• Segnala sempre il numero di versione del software in prova
• Segnala sempre le versioni di qualsiasi altro software (browser, sistema operativo, ecc.)
• Elenca sempre tutto l'hardware
• Passaggi per riprodurre
• Sintomi dell'errore
• Schermate, tracce, registri, altri allegati (se presenti)
• Critico: crash, UI, ecc.
• Segnala se riproducibile
• Qualunque altra cosa provata, che ha riprodotto o meno il bug