Perché la maggior parte dei sistemi di rilevamento dei problemi ha un unico campo di stato? [chiuso]

I tracker hanno un solo campo di stato perché un bug può essere risolto o meno. Non c'è in mezzo. Se ci sono più campi, sarebbe lo stesso di quando uno sviluppatore dice "funziona per me", dove ovviamente non lo fa.

Questo fa rispettare il fatto che solo una persona / reparto decide se un bug è corretto o meno, che si tratti del team di sviluppo, del controllo qualità o del giornalista. In alcuni tracker, come FogBugz, solo il reporter può contrassegnare un bug come fisso.

L'indicatore "progresso" è un altro campo, il cui scopo è sapere dove si trova il bug nel "percorso verso la sacra correzione". Tuttavia (e in particolare nello sviluppo del software) , spesso è un indicatore scarso, poiché il debugging raw può essere molto lungo nel caso di un Hindenbug. Inoltre ci possono essere dei viaggi avanti e indietro tra il QA e le squadre di sviluppo, il che significa che, come una partita di tennis, il punteggio va avanti e avanti, fino a quando uno della squadra guida di 2 punti.

Non confondere di avere più di due valori in un campo (attivo / fisso) con più campi. Ovviamente il QA può dire se il bug è stato risolto o meno. E forse l'utente finale può accettare una funzione. Ma queste informazioni possono ancora essere tutte in un singolo campo con valori come:

proposed / approved / active / coded / tested / deployed / acccepted

Con più campi (uno per la decisione aziendale di farlo, uno per l'opinione dello sviluppatore, uno per l'opinione del QA, ecc.) si potrebbe finire con una situazione in cui lo stato degli sviluppatori continua a "lavorarci" e il controllo qualità lo stato è "testato e pronto per la distribuzione". Quindi avresti bisogno di un processo o di un codice per assicurarti che uno stato non fosse mai fuori sincrono con gli altri. Avere un singolo campo rende i conflitti del genere impossibili.

Secondo me: la prima delle tue distinzioni è ragionevole, la seconda no.

Ovviamente i programmatori devono essere in grado di superare lo stato di un problema, perché sono gli unici che possono effettivamente fare qualcosa per la causa principale. Ma hai perfettamente ragione nel cambiare codice e risolvere il problema dell'utente in modo molto diverso, quindi è utile distinguere tra "proposta / implementata / ipotizzata" e "correzione accettata / verificata / confermata", e avere il secondo disponibile per il QA. Questo di solito è fatto (e in effetti lo considererei un strong disincentivo a lavorare dove non si fa questa distinzione).

Il secondo è problematico. Ovviamente l'utente reale è l'unico che può confermare con finalità che un problema è effettivamente risolto; ma aspettando che l'utente effettivo confermi tutto può diventare orribilmente lento e noioso. I clienti possono rifiutarsi di rispondere, essere riluttanti a parlare con persone tecnologiche, ecc. Ecc. Inoltre, come si fa notare, i clienti possono solo vedere le correzioni che sono arrivate a una versione pubblica. Tutto ciò può rendere impossibile mantenere un flusso di lavoro scalabile. Pertanto verificare che le correzioni siano nelle mani dei clienti è un problema di gestione delle versioni tanto quanto del lavoro di sviluppo, e un tracker dei problemi da solo non è lo strumento giusto per risolvere questo problema.

In breve: i diversi valori di stato che un problema può avere sono piuttosto più complicati del semplice "aperto" o "chiuso", ma penso che quelli che dovresti usare formano un bel successione tridimensionale di stati. Pertanto aggiungere campi multipli solo per esprimere "segnalato ma non riprodotto" o "corretto ma non spedito" è una complessità non necessaria.

Kilian ha un buon punto che 3. non è necessario in quanto è un aspetto di gestione / implementazione del rilascio, piuttosto che lo sviluppo del software. Di solito c'è un campo come Versione Fix che può essere modificato dal team di rilascio più tardi quando si decide quale versione includere. In questo caso, è giusto che il team DEV non abbia l'ultima parola se un problema è stato risolto o meno.

Per le comunicazioni avanti e indietro tra DEV e il team di QA il campo giusto da utilizzare è Assegnato a . Quando il team addetto al QA conferma definitivamente che il problema è stato risolto, può impostare lo stato su fisso.

Questo flusso di lavoro dovrebbe essere supportato dalla maggior parte degli strumenti di monitoraggio dei problemi (io uso JIRA al giorno d'oggi).