Come gestire i bug che penso di aver corretto, ma non sono del tutto sicuro

13

Ci sono alcuni tipi di bug che sono molto difficili da riprodurre, accadono molto raramente e apparentemente per caso. Può succedere che trovo una possibile causa, la risolvo, collaudo il programma e non riesco a riprodurre il bug. Tuttavia, poiché era impossibile riprodurre in modo affidabile il bug ed è accaduto così raramente, come posso indicarlo in un bugtracker? Qual è il modo comune di farlo?

Se imposto il statussu fisso e il solutionsu fisso, significherebbe qualcosa di completamente corretto, no?

È pratica comune impostare il statussu fisso e il solutionsu aperto, per indicare ai tester, che "è probabilmente riparato, ma ha bisogno di più attenzione per essere sicuro"?

Modifica: la maggior parte dei bugtracker (se non tutti) hanno due proprietà per lo stato di un bug, forse i nomi non sono gli stessi. Con statusVoglio dire nuovo, assegnato, fisso, chiuso, ecc , e solutionintendo aperta (nuovo), fisso, irrisolvibile, non riproducibili, duplicare, non è un bug , etc.

testing issue-tracking

— VSZ
fonte

3

Questo è in qualche modo specifico per il tuo bug tracker. Quali altri valori puoi assegnare a stato e soluzione ?

— scarfridge il

In alcuni tracker di bug, esiste uno stato risolto e un altro stato chiuso. Solo le persone addette al controllo qualità possono impostare lo stato su chiuso, ma gli sviluppatori possono impostare lo stato su risolto.

— Brian,

8

È pratica comune impostare lo stato su fixed e la soluzione da aprire, per indicare ai tester, che "è probabilmente riparato, ma necessita di più attenzione per essere sicuro"?

Comune o no, questa è la cosa giusta da fare comunque, e tu hai spiegato perché: non importa come, è un buon approccio a

indica ai tester che "è probabilmente riparato, ma necessita di maggiore attenzione per essere sicuro"

Nota a margine anche se un particolare tracker di bug non ha un campo come quello che descrivi come solution, lo sviluppatore può almeno aggiungere un commento in forma libera che spiega sopra.

_{... e se il tracker dei bug non consente di aggiungere commenti al problema, è necessario sostituirlo con uno che lo faccia. La possibilità di aggiungere chiarimenti in forma libera è una caratteristica di fondamentale importanza poiché i problemi variano troppo per adattarsi a una forma predefinita.}

— moscerino
fonte

6

Il team di test deciderà se il problema è stato risolto e se può essere chiuso. Se ci sono altre regressioni, effetti collaterali della correzione o se la correzione stessa non è efficace in un altro scenario, il problema verrà riaperto. Ma se hai fatto abbastanza test per gli sviluppatori, allora meglio contrassegnarlo come fisso.

— eminemence
fonte

+1 - Questa è la risposta più semplice. Se hai fatto del tuo meglio e la suite di test dei team di test è abbastanza forte, cosa puoi fare di più?

— ozz,

3

Ci sono tipi di bug che sono molto difficili da riprodurre, accadono molto raramente e apparentemente per caso. Può succedere che trovo una possibile causa, la risolvo, collaudo il programma e non riesco a riprodurre il bug.

In realtà, se non ci fosse uno scenario di test riproducibile, non proverei nemmeno a risolvere un tale bug in anticipo. Se vuoi che il tester prenda più attenzione su di esso, dai loro la possibilità di creare uno scenario riproducibile.

Ad esempio, supponiamo che modifichi il programma e un tester investe 1 ora nel tentativo di riprodurre il bug e il bug non viene visualizzato: è bastata un'ora? O testare ulteriormente è una perdita di tempo perché il bug è già stato corretto?

D'altra parte, quando non si modifica il programma e il bug non viene visualizzato in 1 ora, molto probabilmente il tester dovrebbe investire un'altra ora nel provare cose diverse. E quando il tester investirà un giorno e non sarà più in grado di riprodurre il bug, allora vale davvero la pena provare a risolverlo?

Detto questo, puoi pensare a come modellare quel processo nel tuo sistema di tracciamento dei bug: non tentare di risolverlo e consegnarlo ai tester potrebbe essere uno stato di bug come "aperto". Se i tester non possono riprodurlo, è ovviamente "non riproducibile". Speriamo che ciò non accada, trovano uno scenario riproducibile, puoi trovare la causa principale del tuo bug, risolverlo e impostare lo stato su "risolto". Cerca di evitare di entrare in qualcosa come "non so se è stato risolto".

— Doc Brown
fonte

4

Per alcuni tipi di bug semplicemente non esiste uno scenario di test riproducibile. Ad esempio, un errore relativo al tempismo potrebbe verificarsi in media 1 volta su un milione , ma è impossibile prevedere se sarà al 3 ° o al 532454 ° giro. Tuttavia, tali bug sono bug e devono essere corretti.

— Joonas Pulakka,

3

@Joonas Pulakka: sono d'accordo. E tali bug possono dipendere da circostanze esterne. In caso di incorporazione, possono dipendere da sbalzi di tensione causati da qualcosa che è fuori dal tuo controllo. Non cercare di risolverlo non è sempre la soluzione migliore, soprattutto se trovo un odore di codice che sospetto possa essere la causa di quel bug. In questo caso, perché non dovrei ripararlo?

— vsz,

2

@JoonasPulakka: alla mia esperienza su scenari riproducibili, nella maggior parte dei casi in cui le persone dicono "non è possibile", mancano solo l'idea giusta per rendere le cose possibili. Nel tuo esempio, si potrebbe impostare uno scenario con un ciclo "10 milioni di esecuzione", rendendo almeno molto probabile la visualizzazione del bug in un ragionevole lasso di tempo.

— Doc Brown,

2

@vsz: dovresti risolverlo, ovviamente, ma quello che sto suggerendo è che si dovrebbe prima creare un test (o dare ai tester un suggerimento su cosa testare), e poi aggiustarlo, non viceversa.

— Doc Brown,

2

@DocBrown ha ragione, un altro modo di pensarci è che a volte i bug richiedono un approccio statistico per "riprodurli". Potrebbe benissimo essere che esiste un set molto specifico di input / circostanze che riproduce il bug, ma potresti NON avere idea di cosa siano questi input e il set di possibili input potrebbe essere troppo grande per poter scorrere. In questi casi, un approccio consiste nel raccogliere statistiche sull'occorrenza di bug ogni volta che si tenta di risolverlo. Potrebbe richiedere molto tempo e i risultati potrebbero non darti il 100% di "fiducia" in senso statistico, ma a volte tutto ciò che hai.

— Angelo,

0

A volte l'unica prova che hai è puramente statistica, ad esempio si verifica una o due volte al mese, ma apparentemente non collegata a nulla. Questi sono nel complesso il peggior tipo di bug da diagnosticare e risolvere che io abbia mai riscontrato, perché non si può dire se le correzioni abbiano un effetto con certezza. L'ultima di queste che ho dovuto risolvere è terminata con una correzione statistica: la frequenza del sintomo è scesa al 10% con cui abbiamo iniziato. L'ultimo pezzo non fu mai trovato, o forse lo era, ma nessuno aveva modo di dirlo.

Due consigli che ho sono: (1) presumere che possano essere in vigore cause multiple fino a quando non si saprà diversamente, e (2) ipotizzare come potrebbero eventualmente esistere i sintomi, quindi separare ogni linea di logica che è persino coinvolta in remoto. Le procedure dettagliate sono talvolta l'unico mezzo per un fine soddisfacente.

— Chris Cochran
fonte