Disabilita un bug se non esiste alcun caso di test riproducibile? [duplicare]

Penso che la risposta dipenderà da ciò che la tua organizzazione e i suoi programmatori vogliono fare. Se siete in una società con offerte di prodotti grandi e complessi utilizzati da milioni (diciamo, Microsoft, anche se non ho idea di come la società funzioni effettivamente internamente), potrebbe essere che nessuno avrà mai il tempo di prestare attenzione al bug che non ha passaggi da riprodurre. Se sei un negozio più piccolo, potrebbe essere che qualcuno avrà un po 'di tempo per sedersi e provare a riprodurre il bug.

Sei in una posizione in cui potresti potenzialmente provare a riprodurre il bug e fornire passaggi per la riproduzione nella segnalazione di bug? Se è così, e hai tempo, potresti voler seguire quella strada.

In caso contrario, raccomanderei almeno di registrare il bug nel sistema di tracciamento dei bug (ne hai uno, giusto?), anche se contrassegnare immediatamente con lo stato di "impossibilità di riprodurre" o simili. In questo modo, se lo stesso bug si verifica nello stesso cliente o in un altro client tra qualche mese, potresti essere in grado di individuare un pattern che aiuterà a correggere il bug.

Infine, la sfortunata realtà è che alcuni bug non saranno considerati validi per il tempo necessario per il personale. Se questo bug rappresenta un incidente isolato o riguarda una percentuale molto piccola di client, potrebbe non essere considerato valido dal punto di vista aziendale, specialmente se è disponibile una soluzione alternativa.

Spero che questo aiuti.

No

Cliente - > "Ho questo problema"

Sviluppatore - > "Non riesco a riprodurlo, quindi non esiste"

Mi dispiace ma non è accettabile . Ancora di più se è una parte critica di un'applicazione.

Ignorare bug è un "testa nella sabbia" l'approccio porterà inevitabilmente a una situazione negativa nel lungo periodo.

Prima di tutto, non puoi correggere un bug se non riesci a riprodurlo, perché non puoi assicurarti che la correzione risolva il problema.

Questo non significa che devi risolvere il problema, poiché devi tenere le informazioni per un secondo momento per avere quante più informazioni possibili QUANDO puoi riprodurre la situazione in un secondo momento. In altre parole, contrassegnalo nel tracker del problema come "Impossibile riprodurre".

Ci sono molte strade da percorrere, e si riduce a un equilibrio tra costi e benefici.

Una possibilità sta mettendo in atto alcune funzionalità di registrazione e tracciamento per semplificare la riproduzione. Quindi potresti non essere in grado di riprodurre il bug ora, ma forse tra poche settimane o mesi, il problema potrebbe diventare chiaro.

Una seconda possibilità è l'adozione di misure per recuperare e preservare informazioni, metodi per rilevare le informazioni perse e ripristinarle.

Se il cliente sta pagando, potresti spiegare come la ricerca su un problema non riproducibile avrà un costo. Quindi il cliente deve decidere se vale la pena indagare e risolvere. (Questo potrebbe accadere se le azioni complicate eseguite dal cliente non fossero mai state previste.)

Anche se il cliente non paga, puoi spiegare come non puoi prometterti di risolverlo, ma puoi promettere di impegnarti a minimizzare gli effetti di esso.

Se puoi ignorare bug difficili da riprodurre o meno dipende dal tipo di software che stai sviluppando. Se stai sviluppando videogiochi, probabilmente ignorerai questi problemi. Hai già i soldi del cliente, e fintanto che il problema è abbastanza raro da non influenzare le valutazioni dei prodotti, perché preoccuparsi. All'altro capo della scala, se questo "problema raro" significa perdita di denaro o addirittura perdita di vite umane, ti consigliamo di indagare. Se hai clienti abituali e vuoi mantenerli felici, probabilmente lo esaminerai anche tu.

Se decidi che ha senso risolvere il problema, il primo passo sarebbe probabilmente quello di cambiare il codice per ottenere maggiori informazioni sul problema: Ad esempio, aggiungi la registrazione al codice che è probabilmente la ragione del bug.

Hai qualcosa che descriva il processo di bugfix della tua azienda? Ad esempio, come vengono assegnati gli errori agli sviluppatori, ciò che costituisce "abbastanza fisso" per invocare un cambiamento di stato (ovvero, una transizione al team di test formale o ad una sorta di ciclo di rilascio formale). Anche se lavori in un'azienda con un processo leggero, qualcuno dovrebbe essere in grado di tracciare un diagramma di flusso su come i bug entrano ed escono dal sistema. Spesso una spiegazione di come funziona darà qualche idea su cosa fare con i bug. Quasi ogni processo di correzione degli errori ha qualche modo per lo sviluppatore di rifiutare il bug, perché è abbastanza possibile finire con i duplicati, o bug che sono stati corretti come effetto collaterale di una correzione precedentemente introdotta.

Di solito c'è anche un livello di gravità: i bug ad alta severità (che mandano in crash il sistema, introducono errori irrecuperabili o impediscono a una funzione di funzionare completamente) di solito richiedono più diligenti tentativi di risoluzione dei bug di bassa severità. Se il bug non può essere replicato e quindi non rallenta più il tuo cliente, potresti essere in grado di eseguire il downgrade della sua gravità e inserirlo nel pool "lo sistemeremo un giorno ... ma non oggi ..." . Questo ha il vantaggio che è ancora attivo e attivo nel caso in cui altri bug simili vengano a fornire ulteriori informazioni.

Inoltre, qual è il protocollo per tracciare il bug con il cliente? Hai avuto l'opportunità di comunicare direttamente con il cliente? A volte l'accordo reciproco è sufficiente per dare motivo di rifiutare il bug.

Se sei uno sviluppatore abbastanza nuovo, questa è una domanda assolutamente appropriata da porre alla tua gestione: dovrebbero essere in grado di parlarne con te, ascoltare ciò che hai provato e darti una sentenza su cosa fare fare alla luce sia della natura del cliente che del bug.

Un test case riproducibile è la prova che esiste effettivamente un bug. Una segnalazione di bug senza prova non è altro che dicerie. Potrebbe essere un bug reale, o potrebbe essere causato da un errore dell'utente, da un problema hardware sul loro sistema o persino da raggi cosmici che capovolgano dei bit nella RAM da qualche parte.

Se ricevo un bug report e ho familiarità con il codebase, di solito riesco a farmi un'idea di cosa succede in un report di tipo "Ho provato a fare X e ha fatto saltare". In caso contrario, chiederò ulteriori informazioni, una delle seguenti:

• Un report di errore automatico, se applicabile. (Avete un logger di eccezioni, giusto?)
• Un elenco dettagliato dei passaggi di riproduzione.
• Una copia dei loro dati
• Se tutto il resto fallisce, un video di screencap che mostra la capacità dell'utente di riprodurre il problema su richiesta.

Se posso usare uno di questi per ottenere una prova certa dell'esistenza di un bug, mi dà un punto di partenza per iniziare a scavare nel codice e rintracciare le cose. Ma se non riesco a riprodurre il bug su richiesta, e nessuno dei due è l'utente, allora non c'è davvero nulla che io possa fare per risolverlo, perché non c'è alcuna prova che esista un bug reale nel primo posto. Questo è il punto in cui dico "Scusa, non posso aiutarti, ma se ti viene in mente un modo per farlo accadere in modo coerente, sentiti libero di aggiornare la segnalazione".

Per fortuna, non devo farlo molto spesso.

Registra il bug. Documenta tutto il possibile su di esso. Cosa stavano facendo quando è successo. < - questo è fondamentale se riesci a trovarlo. (QUANDO è successo può importare troppo.)

Poi, quando lavori su una sezione di codice, qualcuno troverà un bug "latente".

E poi verrà aggiunto al bug tracker. E poi lo sviluppatore penserà al bug; la sua apparenza proiettata. E alla fine i due bug saranno identificati come lo stesso bug.

Storia vera

Se hai un sacco di bug senza passaggi da riprodurre, sono punti dati.

Questo ti dice: Ci sono bug fuori là.

Non accadono spesso.

Quindi più tardi, quando viene rilevato un errore nel codice reale ... potrebbe adattarsi ai punti dati già presenti.

Google "Data mining" ... il tuo bug tracker potrebbe già sapere dove si trova un bug

Ho avuto errori irreprodiabili prima di dove il meglio che potevo fare inizialmente era aggiungere il logging per restringerlo fino a 10.000 righe di codice, ma dopo alcune iterazioni è diventato risolvibile.

Ho anche visto un bug con condizioni che dovrebbero essere impossibili da colpire, in cui tutto ciò che potevo fare era verificare esplicitamente quella condizione impossibile, registrare una traccia stack e restituire cleanly invece di segmentare. Non ho ancora idea di quale sia la causa principale, ma al momento non sta interessando alcun cliente, e se mai lo farò avrò più informazioni per aiutarlo a risolverlo.

Non ho mai avuto un bug in cui non ci fosse qualcosa che potrei fare per avvicinarmi alla risposta, ei clienti sono molto più felici anche se tutto quello che puoi dire è che hai aggiunto qualche codice per evitare che si danneggi troppo se dovesse accadere di nuovo, e codice per darti più informazioni per aiutarti a capirlo la prossima volta.

Quanto è critico in questo caso?

Nel nostro caso, se c'è un bug che è critico, e considerando che i nostri clienti pagano un sacco n 'lotti (tm) per il nostro prodotto, creiamo un team di soluzioni rapide (2 ppl, test + dev) per trovarlo e schiacciarlo.

Altrimenti, se non può essere ripro- dotto, viene chiuso come no repro . Come altri hanno già detto, senza ripro passi, stai solo indovinando e sparando al buio - abbiamo un sacco di altri bug critici su cui lavorare posso correggere.

Dipende da due fattori: la gravità e la probabilità. Se il bug è fatale come la corruzione dei dati o la violazione della sicurezza, dovresti continuare a scavare finché non lo trovi e risolverlo perché causerà una potenziale perdita per il business del cliente. Se non è fatale, ma molto probabile e continua a infastidire il cliente, devi trovarlo in quanto causerà problemi alla tua organizzazione rovinando la reputazione del prodotto in quanto gli utenti diranno che si tratta di un prodotto buggato di bassa qualità. Se si tratta di un caso estremo e non causa alcun danno ai dati e accade raramente, puoi ignorarlo.

Devo anche dire che nella maggior parte di questi casi lo sviluppatore dovrebbe collaborare con i tester per cercare il bug in quanto potrebbe essere difficile trovarlo da solo.