Come chiudere un bug che non è più rilevante

21

Attualmente faccio parte di un team di sviluppatori web di medie dimensioni. Stiamo usando jira per il tracciamento dei bug.

Stiamo lavorando su un prodotto con frequenti modifiche al layout. Molte volte i bug sono archiviati su un bug nel layout in alcuni browser. A volte, quando ci avviciniamo alla gestione di un bug a bassa priorità, il layout è già cambiato e non è più pertinente.

Come dovremmo chiuderlo?
Quello che voglio dire è come dovremmo trattare questi problemi? Mentre Jira è il software di tracciamento dei bug che utilizziamo, sono più interessato a come gestire questo tipo di problemi in generale.
Importa anche? (Si potrebbe tornare al layout più tardi, ma è molto improbabile)

issue-tracking jira

— Benjamin Gruenbaum
fonte

8

Troppo localizzato;)

— yannis

4

non sono d'accordo sul fatto che sia troppo localizzato, potrebbe essere più adatto per SO sebbene sia probabilmente il suo strumento specifico

— jk.

6

@jk. Heh, intendevo "troppo localizzato" come suggerimento / risposta alla domanda, non che la domanda stessa sia "troppo localizzata". Se avessi pensato a quest'ultimo, l'avrei appena chiuso.

— yannis,

2

@YannisRizos doh! forse avrebbe dovuto essere una risposta allora;)

— jk.

6

@jk. Penso che la seconda domanda sia la più interessante (importa?), Ma non ho tempo per rispondere adesso (e non sono davvero sicuro che la risposta che si sta formando nella mia testa sia buona). Per quanto riguarda la prima domanda, se questo thread diventa un "suggerimento parola / frase", potrebbe chiudersi come "non costruttivo". Quindi, risponditori, non ignorare la seconda domanda, per favore, quella sull'argomento e interessante.

— yannis,

26

Le sfumature del genere sono importanti se consideri il tracker dei problemi come un mezzo per comunicare lo stato dei problemi segnalati nel progetto. A tale scopo, ha senso investire alcuni sforzi per garantire che la segnalazione dei bug sia di facile lettura e comprensione.

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, immaginane uno (o meglio ancora, assumine uno ^{1 , 2 , 3} ).

Ok, quindi c'era un bug una volta, il tester può riprodurlo usando versioni precedenti dell'applicazione (nota a margine nel caso improbabile che non conservi copie di versioni precedenti, quindi hai problemi molto più difficili nel tuo squadra di bug obsoleti). 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ù pertinente" - il sopracciglio non più rilevante trasforma la mente del tester in una dichiarazione molto più semplice: il problema è andato .

È importante notare qui che il tester professionale dovrebbe essere a proprio agio nel pensare al sistema come a una scatola nera . Da quel punto di vista, non importa quanto sia successo esattamente quel problema, potrebbe essere il cambio di layout o la magia nera o la riprogettazione totale o il cambio di codice concreto, qualunque cosa.

Dal punto di vista della scatola nera, la tua situazione è piuttosto semplice. Si è verificato un problema, è ancora riproducibile nella versione precedente, ora affermi che la versione più recente non presenta più questo problema. Per un tester, ciò si riduce a un'affermazione che il bug è stato risolto e, rispettivamente, alla necessità di verificare se l'affermazione è vera.

Il tester professionale prenderebbe la tua versione precedente, guarderebbe come è presente il problema lì, quindi prendere la versione più recente e verificare se è andata o è ancora lì.

Dall'alto, il modo più accurato di gestire i bug che descrivi, sarebbe quello di risolverli come risolti, risolti . Ovviamente non sarebbe male se chiarissi nei commenti che la correzione si è verificata come un effetto collaterale indesiderato della modifica del layout.

Uno dei JIRA personalizzati con cui lavoravo in un precedente progetto aveva la risoluzione "Fixed By Design" per comunicare cambiamenti piuttosto profondi con molte conseguenze, alcune intenzionali, altre no. Per casi come quello che descrivi, questo potrebbe essere considerato al posto del semplice "Risolto", poiché suggerisce al lettore di biglietti che si tratta più di un effetto collaterale che di una modifica intenzionale del codice.

— moscerino
fonte

2

Risolto da Design implicherebbe, per me, l'esatto contrario. Nella mia mente, per design significa "intenzionale" (è l'opposto di "per errore").

— TRiG

Sono d'accordo che "riparato" è sufficiente. Non importa se è stato intenzionale o un effetto collaterale di altri cambiamenti. Tuttavia, sono anche d'accordo con @TRiG sul fatto che "Fixed by Design" sia fonte di confusione.

1

@TRiG bene è per questo che ho sottolineato che uno spiega meglio i dettagli esatti nei commenti. Fixed By Design è un po 'ampio; nel progetto l'ho visto che era usato per comunicare cambiamenti piuttosto profondi con molte conseguenze, alcuni intenzionali, altri non - coprendo così casi del genere. Nota anche che né il testo della domanda né la mia risposta implicano "correzione per errore" (quale errore?) - qui, "involontario" è molto più adatto

— moscerino

1

Tutte le risposte sono buone, ma questa sembra inchiodarla. Grazie a tutti.

— Benjamin Gruenbaum,

6

Che ne dici di "Risolto da riprogettazione"?

— penguat

47

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

— Kris
fonte

+1 se non puoi aggiungerlo almeno scegli come non un bug e commenta perché

— tgkprog

9

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

Importa? dipende, per noi direi di sì 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ù pertinenti senza eliminare del tutto il problema .

Anche senza un cliente interessato dai numeri di problema, la potatura di vecchi problemi aperti non più rilevanti è sicuramente utile solo per ridurre il disordine nel browser.

— jk.
fonte

1

"Over Taken By Events" è troppo lungo (imho), andrei con una sola parola (irrilevante / obsoleto) solo perché è più facile da cercare e occupa meno spazio (nei rapporti, ecc.). L'unica volta in cui è stato utile conoscere la quantità dei nostri bug obsoleti è stato quando sono arrivati alla rinfusa, e questo ha indicato un problema di comunicazione. I nostri tester non erano al passo con ciò su cui stavano lavorando i nostri sviluppatori, avevano perso il promemoria che le cose sarebbero andate male per una settimana circa e stavano facendo rumore (inutile). Quindi, guardando indietro al nostro obs. i bug ci hanno aiutato a trovare e risolvere un buco nei nostri processi di comunicazione.

— yannis,

3

in realtà usiamo un acronimo OBE, ma penso che la parola vera usata sia il punto meno interessante qui, il punto è scegliere qualcosa che funzioni per te

— jk.

3

@YannisRizos: correzione dei meta-bug mediante bug. Quant'è fico!

— Jörg W Mittag,

La ricerca di @YannisRizos non è un grosso problema in quanto le risoluzioni valide sono comunque scelte da un menu a discesa (in JIRA)

— jk.

2

@Yannis. Perderei il sonno per quello: il sorpasso dovrebbe essere una parola.

— TRiG

5

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

Usiamo semplicemente "Risolto (Risolto)" e commentiamo nella risoluzione modificare qualcosa come "Risolto dal caso 12345".

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

Questo è IMO migliore di una variante "Too Localized" perché era un vero bug, e meglio di un semplice "Obsoleto" perché era stato corretto, quella funzione non era stata appena rimossa.

— Izkata
fonte

3

Risolto risolvendo e ricontrollando <- storia vera.

— yannis,

1

Jira consente anche questo approccio. Basta menzionare il numero del problema nei commenti di risoluzione e Jira lo trasformerà in un collegamento ipertestuale.

— Marjan Venema,