Dipende dal flusso di lavoro che si utilizza e essenzialmente dalle relazioni tra sviluppatori e clienti.
In Extreme Programming, appartiene al rappresentante del cliente per decidere cosa fare con il biglietto. Potrebbe considerare che è una priorità elevata e dovresti lavorarci su, o con priorità bassa, o dovrebbe essere rimossa. Se il bug è riproducibile è una storia diversa e dovrebbe diventare una preoccupazione primaria se e quando il rappresentante del cliente ritiene che il team dovrebbe lavorare sul problema.
Se, invece, nel tuo flusso di lavoro, appartiene agli sviluppatori o al project manager per considerare la priorità di un bug report, allora, hai una scelta. Senza alcun interesse da parte del cliente a lavorare più a lungo (o del tutto, spesso accade per progetti in cui qualsiasi cliente può inviare un bug report, soprattutto quando i report sono inviati per lo più automaticamente), puoi decidere:
-
Per continuare a controllare il bug, provare a riprodurre e alla fine risolvere il problema.
-
Considerare che il ROI di correggere questo bug è probabilmente inferiore allo zero. Questo può accadere su base frequente, come quando il bug riguarda una versione obsoleta del prodotto.
In questo caso, chiudi il problema come "non riproducibile". Non etichettarlo. Chiudi: non è necessario inquinare il sistema di tracciamento dei bug mantenendo aperti tali bug. Assicurati che il tuo sistema di tracciamento dei bug mantenga tali segnalazioni di bug accessibili anche ai tuoi clienti: tale bug può essere riaperto da un altro cliente che potrebbe essere in grado di riprodurre il problema.