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

Is it common practice to set the status to fixed and the solution to open, to indicate to the testers, that "it's probably fixed, but needs more attention to make sure"?

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

indica ai tester che "è probabilmente corretto, ma richiede più attenzione per essere sicuro"

Nota a margine anche se un particolare bug tracker non ha campi come quelli che descrivi come solution , lo sviluppatore può almeno aggiungere un commento in formato libero che spieghi in precedenza.

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

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 dello sviluppatore, allora è meglio contrassegnarlo come fisso.

There are types of bugs which are very hard to reproduce, happen very rarely and seemingly by random. It can happen, that I find a possible cause, fix it, test the program, and can't reproduce the bug.

In realtà, se non ci sono scenari di test riproducibili, non proverei nemmeno a correggere un bug in anticipo. Se vuoi che il tester prenda più attenzione, dà loro la possibilità di creare uno scenario riproducibile.

Ad esempio, supponiamo che tu cambi il programma e un tester investa 1 ora per provare a riprodurre il bug, e il bug non compare: è bastata un'ora? O sta testando ulteriormente una perdita di tempo perché il bug era già stato risolto?

D'altra parte, quando non cambi il programma e il bug non compare in 1 ora, molto probabilmente il tester dovrebbe investire un'altra ora nel provare cose diverse. E quando il tester investe un giorno e non può più riprodurre il bug, vale davvero la pena provare a ripararlo?

Detto questo, puoi pensare a come modellare quel processo nel tuo sistema di tracciamento dei bug: non provare a risolverlo e passarlo ai tester potrebbe essere uno stato di bug come "open". Se i tester non possono riprodurlo, è ovviamente "non riproducibile". Speriamo che questo non accada, che trovino uno scenario riproducibile, che tu possa trovare la causa principale del tuo bug, correggerlo e impostare lo stato su "corretto". Cerca di evitare di entrare in qualcosa del tipo "non so se è stato risolto".

A volte l'unica prova che hai è puramente statistica, ad es. si verifica una volta o due volte al mese, ma altrimenti apparentemente non connesso a nulla. Questi sono in generale il peggior tipo di bug da diagnosticare e risolvere che io abbia mai incontrato, perché non si può sapere se le correzioni hanno un effetto con certezza. L'ultimo di questi che ho dovuto risolvere si è concluso con una soluzione statistica: la frequenza dei sintomi è scesa al 10% con cui abbiamo iniziato. L'ultimo pezzo non è mai stato trovato, o forse lo era, ma nessuno aveva modo di dirlo.

Due consigli che ho sono (1) assumere che più cause potrebbero essere in effetto finché non si sa diversamente, e (2) ipotizzare come potrebbero esistere i sintomi, quindi distruggere ogni logica che è anche lontanamente coinvolta. Le procedure dettagliate sono a volte l'unico mezzo per un fine soddisfacente.