Perché non è raccomandato pubblicare più difetti nella stessa emissione / biglietto?

Immagina se Stack Overflow avesse una linea guida: invece di fare una domanda, vieni e chiedi, nella stessa domanda, qualunque cosa ti venga in mente, tutti i tuoi problemi che hai avuto nelle ultime due settimane. Cosa significherebbe upvote e downvote? Quali sarebbero i titoli delle domande? Come accettare la migliore risposta? Come taggare la domanda?

Il sistema di tracciamento dei bug è fatto per ... tracciare i bug. Tracciare un bug significa:

1. Creazione di un record che dice che potrebbe esistere un bug, con informazioni su come riprodurlo,

2. Confermando che, in effetti, il bug esiste ed è un bug, non qualcosa di design,

3. Affermando che il bug è stato risolto,

4. Conferma che il bug è stato risolto.

In un modello molto semplicistico, 1 e 4 saranno eseguiti dal cliente e 2 e 3 dallo sviluppatore.

Immagina il seguente registro:

• Day 1 [Customer] When pressing on “Remove” button in “Product details” window, the application hangs. Restarting the application shows that the product wasn't removed. The expected behavior is to remove the product.

• Day 4 [Developer] <Issue reproduced>

• Day 5 [Developer] <Issue solved in revision 5031>

• Day 12 [Customer] <Ticket closed: issue solved>

Il log è semplice e chiaro . Puoi facilmente tenere traccia di ciò che è stato fatto e quando , quale revisione ha risolto quale bug, ecc. Ad esempio, se il sistema di tracciamento dei bug è integrato con il controllo della versione, quando visualizzi una revisione specifica, puoi controllare quali errori sono stati risolti in esso.

È facile trovare informazioni . È facile vedere il suo stato (è riprodotto? Se il biglietto era chiuso, perché?). È facile filtrare i ticket (Voglio visualizzare i ticket che riguardano solo l'interfaccia utente dei plugin, visto che desidero solo i ticket aperti, più vecchi di una settimana e assegnati dal nostro interaction designer e sono di media o alta priorità).

È facile riassegnare un ticket o determinare in origine chi è il responsabile del bug.

Ora immagina il seguente registro:

• Day 1 [Customer] The app hangs when I press “Remove” button in “Product details” window. Also, the background color of the left panel is dark blue, while it should be purple. I also noted that the text of the “Product details” window is not translated well to German; is it expected? When the final translation would be available? BTW, have you received the new icon I sent for the “Publish product” action? I don't see it in the “Sync data” window.

• Day 6 [Developer] I changed the color to purple.

• Day 7 [Developer] Yes, it's normal that the translation to German is incomplete.

• Day 8 [Customer] Ok for German. What about Italian? Lucia sent you the XML file two days ago.

• Day 9 [Developer] It's ok now.

• Day 10 [Customer] Ok for the “Remove” button? Strange, at my computer, it still hangs.

• Day 11 [Developer] No, I wanted to say it's ok for Italian translation.

• Day 12 [Customer] I see. Thank you. But there is a problem with the color. You changed it to dark purple, but it should be light purple, like the top panel on the main window.

• Day 13 [Developer] I updated the icon.

• Day 14 [Customer] The icon? What icon?

• Day 15 [Developer] The icon you asked me to update.

• Day 16 [Customer] I never asked you to update any icon.

• Day 17 [Developer] Of course you asked. See this ticket. You wrote that the publish product icon should be updated. I've done it.

  ⁞

• Day 100 [Customer] So, what about the entries in the log?

• Day 101 [Developer] I have no idea what you're talking about. It's not even in this ticket, but in 6199. I'm closing this one as solved. <Ticket closed: issue solved>

• Day 102 [Customer] Sorry to reopen it, but the problem is not solved. I'm talking about the entries in the log: I told you last week that the text is sometimes invalid when it contains unicode characters. Do you remember? <Ticket reopened>

• Day 103 [Developer] I vaguely remember something like that, but after searching the last three pages of this ticket, I can't find any trace. Can you write again what was the problem?

  ⁞

• Day 460 [Developer] I spent two hours searching for a trace of what you've said about the files sent encrypted through the network. I'm not sure I can find the precise request.

• Day 460 [Customer] You guys should really be more organized. I notified you four times about this issue for the last two weeks. Why are you forgetting everything?

  ⁞

Di cosa tratta questo registro? È stato risolto 43 volte e riaperto 43 volte. Significa che lo sviluppatore è così stupido da non riuscire a risolvere lo stesso problema per 460 giorni? Ah, no, aspetta, questo ticket è stato assegnato a 11 sviluppatori nel frattempo. Qual è l'accordo? Come cercare un problema specifico? In realtà è assegnato a Vanessa, ma i suoi cinque colleghi sono preoccupati anche di sette degli undici numeri di questo biglietto. Quando il biglietto dovrebbe essere chiuso? È quando metà dei problemi è risolta? O forse dieci su undici?

Nota: potresti credere che tali registri non esistano. Credimi, ne ho visti più di una volta.

Solo per commentare la tua affermazione:

can't be it as the fix-feedback-resolved-closed should avoid that case

Ciò presuppone che tutti i bug sollevati verranno risolti contemporaneamente. Immagina uno scenario in cui viene generato un ticket contro la v1 del prodotto con due problemi:

1. Un pulsante di reimpostazione del modulo invia effettivamente il modulo anziché cancellarlo i valori
2. La dimensione del carattere sul pulsante è del 110% quando dovrebbe essere del 115%.

Entrambe sono corrette per un tester, dato che sono entrambi errori con l'implementazione. Ma diciamo che il proprietario del prodotto decide che la prima sotto attività è un blocco da rilasciare (cioè deve essere aggiustata prima che il prodotto possa andare in diretta), ma la seconda attività è un problema minore (cioè può essere risolto in una v1. 1 versione).

In questo caso, non abbiamo altra scelta che dividere il n. 2 nel proprio biglietto (o rischiare di dimenticarlo). Se siamo in grado di farlo, significa che possono essere implementati, testati e distribuiti indipendentemente l'uno dall'altro, nel qual caso ha senso avere problemi individuali fin dall'inizio.

Ambito:

Questa risposta (e la domanda) sembra applicabile solo al monitoraggio dei difetti del codice, in cui il codice sorgente non funziona in base alle specifiche o alle intenzioni dei programmatori.

Al contrario, è comune che i ticket dei difetti della GUI contengano più specifiche, poiché ogni ticket della GUI è effettivamente una "riprogettazione" (difetto di progettazione), una "specifica rivista" o una "richiesta di funzionalità" (funzionalità mancante).

Un importante scopo del monitoraggio dei difetti è quello di comunicare e coordinare tra più ruoli (programmatori, tester, clienti e manager).

Nei progetti in cui la qualità del codice ha un significato elevato (ad esempio, rispetto alla facilità d'uso), il tracciamento dei difetti può consistere in più aspetti, uno dei quali si concentrerebbe sul rilevamento dei difetti del codice , separatamente dal rilevamento di miglioramenti e richieste di assistenza clienti.

Lo scopo del sistema di tracciamento dei difetti del codice è:

• Abilitare il indipendente e il tracciamento univoco dei difetti indipendentemente e
• Fornire la migliore approssimazione (corrispondenza uno-a-uno) alla causa principale di ciascun difetto.

Mentre lo fa, dovrebbe massimizzare le seguenti qualità desiderabili:

• Scala in modo efficiente quando il numero di difetti aumenta nel tempo.
• Prevenire la sindrome del bersaglio in movimento.

Disclaimer: questa riformulazione deriva dalla mia esperienza personale. Potrebbe essere insufficiente o errato per lo scopo dell'esame di certificazione.

Tracciamento indipendente e non ambiguo significa che:

1. Ogni difetto valido può essere risolto o non risolto , senza ambiguità.

   • Motivo 1: per semplificare la gestione,
     • Esempio: consente l'utilizzo del "numero di ticket non risolti" come metrica.
   • Motivo 2: per tradurre in elemento utilizzabile
     • Esempio: se non è risolto, la responsabilità ricade sul programmatore assegnato. Se è risolto ma non chiuso, la responsabilità ricade sul tester assegnato (verificatore).
   • Conseguenza: in questa metodologia, un difetto parzialmente risolto merita di essere scomposto in diversi difetti dipendenti.

2. I difetti riproducibili in modo indipendente dovrebbero essere monitorati in modo indipendente.

   • "Indipendentemente riproducibile" significa che possono avere stati diversi. Uno può sembrare fisso mentre l'altro rimane rotto.
   • Motivazione: per ridurre al minimo la discrepanza tra il rilevamento dei difetti e l'analisi della causa principale.
     • Si ritiene che ogni causa principale che può essere ricondotta a un difetto di codice richieda almeno un cambio di codice.
     • Se due difetti sono riproducibili in modo indipendente, saranno necessarie più modifiche al codice.
     • Se due difetti sono riproducibili in modo indipendente, devono essere entrambi testati (verificati), perché il superamento di un test non implica che l'altro test passi.
   • Esempio 2: se inizialmente si riteneva che due sintomi avessero la stessa causa di origine e quindi classificati nello stesso biglietto, e in seguito si dimostrassero essere riproducibili in modo indipendente, allora dovrebbero essere suddivisi in due biglietti.

Guardalo dal punto di vista di qualcun altro che usa il sistema, mostrandolo pochi mesi dopo. Trovano un bug nel programma. Guardano Google e vedono che c'è un ticket di assistenza che corrisponde al loro problema. Ehi, è chiuso! Eccezionale! È stato risolto nell'ultima versione! Quindi, aggiornano ... e il bug è ancora lì? Cosa c'è di sbagliato in questi stupidi sviluppatori?!?

Niente, in realtà. Si scopre che c'è qualcosa di sbagliato nella persona che ha inviato il bug report. Hanno presentato due bug nello stesso biglietto. Uno era facile da sistemare e veniva riparato rapidamente, mentre l'altro no. Anche se usi qualcosa come fix-feedback-resolved-closed, può ancora essere meno chiaro di quello che sta succedendo, specialmente a un osservatore esterno.

È molto meglio dare a ogni bug un proprio ticket, e se si hanno più bug correlati ma apparentemente distinti, la maggior parte dei sistemi di tracciamento dei bug ha una caratteristica che consente di collegare un bug a un altro. (E se no, puoi semplicemente metterlo nel rapporto. "Vedi anche bug # 12345.")