Stato "Aperto" e "Riaperto"


9

Perché i sistemi di localizzazione dei problemi di solito hanno stati "Aperti" e "Riaperti" distinti?

Risposte:


6

I problemi aperti sono in genere la prima occorrenza di qualunque problema si tratti.

I problemi che vengono riaperti sono 1) che si ripetono e / o 2) non risolti correttamente. Ci possono essere diversi motivi per questo: uno chiave può essere spesso collegato alla descrizione originale del problema all'utente finale.

Non credo che nessun negozio ragionevole lo userebbe come metrica per giudicare il personale tecnico [da solo], ma è utile come misura per identificare quanto sono efficaci le risposte e potrebbe anche significare problemi di fondo che devono essere affrontati.


4

La mia vecchia azienda ha usato quegli stati per tenere traccia di quante volte il tuo problema è andato a "Riaperto" per vedere quanto "cattivo" sei stato uno sviluppatore. Hanno pensato che esistesse una correlazione tra il numero di volte in cui un oggetto di lavoro viene "Riaperto" e il tuo valore come programmatore.

Non ci lavoro più.


bene, buona mossa Robert. Ovunque utilizzi questo tipo di metriche degli sviluppatori per giudicare gli sviluppatori non è un buon posto dove stare.
ozz,

1
sì, se finisci per tracciare qualsiasi tipo di metrica, qualcuno inevitabilmente li userà per il male.
Robert Greiner,

Una volta ho letto di un'azienda che ha premiato i tester per i bug trovati e gli sviluppatori per il tempo medio per correggere i bug. Hai indovinato. Gli sviluppatori hanno detto ai tester quali "bug" cercare ... una volta segnalati, li hanno "riparati" molto rapidamente ...
mattnz

@mattnz sì, di solito quando hai queste metriche di tipo bullcrap, gli sviluppatori / tester trovano sempre un modo per inclinare le cose a loro favore.
Robert Greiner,

3

La durata di un bug è spesso:

  1. Ha aperto
  2. risoluto
  3. (Opzionale) Riaperto
  4. risoluto
  5. (Opzionale) Vai a: 3
  6. Chiuso

vale a dire.

Qualcuno trova un bug e lo apre nel tracker. Lo sviluppatore lo risolve nel miglior modo possibile con la sua comprensione del problema. Tester esegue nuovamente i test per verificare che la correzione abbia funzionato e si riapre se possono verificare che non ha funzionato. Se la correzione viene verificata, il bug viene chiuso.

L'altro scenario è che una correzione da qualche altra parte ha causato una regressione e il bug deve essere corretto nuovamente. Pertanto, viene riaperto.


2

Potrebbe anche essere per rendere più ovvio che il problema richiede più attenzione o attenzione più rapida perché continua a essere un problema dopo che si ritiene che il problema sia stato risolto.


2

Aperto significa che si tratta di un nuovo problema. Riapre meanse ti è stato un problema che è stato aperto-> Clossed e quindi nuovamente aperto.

Perché è stato riaperto? Forse lo sviluppatore e il tester hanno pensato che il problema fosse stato risolto, ma non era stato risolto. O forse il problema è stato risolto, ma alcune successive modifiche al codice hanno causato il ripetersi del problema. Non importa come, ma un problema riaperto è un brutto segno e quindi è classificato in modo diverso.


1

Il modo in cui lo usiamo qui:

Nuova attività: creata all'inizio del progetto per mostrare tutto il lavoro che deve essere fatto. È aperto fino a quando qualcuno non lo codifica, quindi viene risolto. Viene riaperto solo se qualcosa non è stato implementato o se la funzionalità è cambiata e lo sviluppatore deve tornare indietro e dedicare un bel po 'di tempo a lavorarci su.

Bug / difetto: aperto da qualcuno nel QA o da un altro sviluppatore che controlla il prodotto funzionante complessivo. Se ti viene assegnato un bug, lo risolvi e poi lo risolvi e torna in test. Se il QA ritiene che non sia stato risolto, lo riapriranno e allegaranno qualsiasi altra informazione. Il ciclo Risolto / Riaperto può andare fino a quando il QA non è soddisfatto che il bug sia stato corretto, quindi chiudono il ticket.

Quindi, fondamentalmente, usi Reopen per dire che un biglietto è già stato visto e qualcuno ha lavorato su di esso per sentirlo risolto, ma non era così.


1

Fondamentalmente è un tipo di coerenza: un bug (o un problema in generale) è "aperto" se è stato creato da zero. È "riaprire" se è stato creato dopo l'esecuzione di una precedente elaborazione.

Per uno sviluppatore (o chiunque gestisca il problema) non dovrebbe fare alcuna differenza. È stata sollevata un'emissione che ora dovrebbe essere elaborata.

Tuttavia, uno stato di "riapertura" distinto può ancora essere utile per una serie di scenari:

In primo luogo, può essere utilizzato come modo per monitorare se il processo di garanzia della qualità funziona o meno. Se il QA ha fatto tutto nel modo giusto, non dovrebbe mai verificarsi un bug dopo che è stato corretto. Quindi, si potrebbe dire che il numero di volte in cui un bug è stato impostato nello stato di "riapertura" è il numero di volte in cui il QA non ha eseguito correttamente il suo lavoro. Ciò implica naturalmente che esiste un buon processo di controllo qualità e che gli utenti partecipano attivamente al processo e sanno quando "aprire" e quando "riaprire" un problema.

Un altro uso è che, quando si verifica nuovamente un bug, non è necessario sollevare un altro problema, ma è possibile aggiungere informazioni a un problema già esistente (e quindi conservare informazioni importanti come la cronologia dei problemi, file aggiuntivi che sono stati caricati, commenti precedenti e ecc.) ma indica ancora "hey, questo è successo di nuovo ).


1

Uno dei motivi principali per tenere traccia di "riaprire" è che può darti un'indicazione di problemi di instradamento profondo, piuttosto che semplici insinuazioni e supervisione dei dettagli. Se un particolare modulo o pezzo di funzionalità ha numerosi "ripopen", indica una debolezza che deve essere risolta. Un gran numero di singoli punti di apertura per il lavoro affrettato e / o la pratica sciatta.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.