Come chiudere un bug che non è più rilevante

Ci sono sfumature del genere se consideri il problema tracker come mezzo per comunicare lo stato dei problemi che sono stati segnalati nel progetto. A tal fine, ha senso investire qualche sforzo per garantire che la segnalazione di bug sia facile da leggere e comprendere.

Questa situazione diventa molto meno confusa se la si guarda dal punto di vista di un tester. Se la tua squadra non ha un tester, immagina uno (o meglio ancora, noleggia uno ^{1 , 2 , 3} ).

Ok, quindi c'era un bug una volta, il tester può riprodurlo usando vecchie versioni della tua applicazione (nota a margine nel caso improbabile che tu non conservi copie di vecchie versioni, allora hai molto molti problemi più difficili nella tua squadra rispetto ai bug obsoleti). Il tester può vederlo e può dire cosa c'è che non va, cos'è che lo rende un bug.

Ora dici, "il layout è già cambiato e non è più rilevante" - il high-brow non più pertinente trasforma la mente del tester in una dichiarazione molto più semplice: il problema è andato .

• È importante notare qui che il tester professionale dovrebbe essere a suo agio pensando al sistema come scatola nera . Da quella prospettiva, non importa quanto esattamente sia successo quel problema, potrebbe essere il cambio di layout o magia nera o riprogettazione totale, o cambiamento di codice concreto, qualunque cosa.

Dal punto di vista della scatola nera, la tua situazione è piuttosto semplice. C'è stato un problema, è ancora riproducibile nelle versioni precedenti, ora affermi che la versione più recente non ha più problemi simili. Per un tester, questo si riduce a un reclamo che il bug è risolto e, rispettivamente, alla necessità di verificare se il reclamo è vero.

Il tester professionista prenderebbe la tua versione precedente, osserverebbe come è presente il problema, quindi eseguirà una versione più recente e controllerà se è sparita o è ancora lì.

Dall'alto, il modo più accurato per gestire i bug come descrivi, sarebbe chiudere questi come risolti, corretti . Ovviamente non sarebbe male se si chiarisse nei commenti che la correzione si presentava come un effetto collaterale involontario del cambio di layout.

Uno dei JIRA personalizzati con cui ho lavorato in un precedente progetto aveva la risoluzione "Fissa per progetto" per comunicare cambiamenti piuttosto profondi con molte conseguenze, alcune intenzionali, altre no. Per caso come te descrivi, potrebbe anche essere considerato invece di semplice "Fisso", dal momento che suggerisce al lettore di biglietti che è più un effetto collaterale che un cambiamento intenzionale del codice.

Risolviamo problemi come "Obsoleto". Questa non è un'opzione di risoluzione predefinita in JIRA, ma è abbastanza facile da aggiungere.

JIRA (e sono sicuro che altri bug tracker) ti permettono di specificare risoluzioni personalizzate quindi dovresti essere in grado di impostare una risoluzione "Overtaken By Events" o "Irrelavant" o simile per permetterti di esprimere la chiusura come vuoi

Importa? ciò dipende, per noi direi di si poiché il nostro cliente è eccessivamente preoccupato per il numero di problemi aperti nel nostro tracker, quindi per noi è utile poter dire che sono chiusi perché non sono più rilevanti senza eliminare completamente il problema .

Anche senza un cliente interessato dai numeri di emissione, l'eliminazione di vecchi problemi aperti che non sono più rilevanti è sicuramente utile solo per ridurre il disordine nel browser.

Usiamo FogBugz, ma sono sicuro che lo stesso (o simile) si applica qui:

Usiamo solo "Risolto (Risolto)" e commentiamo nella modifica di modifica qualcosa come "Risolto dal caso 12345".

FogBugz corrisponde a "caso \ d +" e collega i due insieme in Casi correlati, ma se Jira non lo fa, dovrebbe essere semplice aggiungere un collegamento.

Questo è IMO meglio di una variante "troppo localizzata" perché era un bug reale, e migliore di solo "Obsoleto" perché è stato corretto, quella funzione non è stata semplicemente rimossa.