Perché non è consigliabile inviare più difetti nello stesso numero / biglietto?

Non sono sicuro che questo sia il posto giusto per porre la seguente domanda concettuale (Stackoverflow non lo è sicuramente).

Ho visto questa domanda in un esame a scelta multipla (risposta singola), simile agli esami ISTQB :

Perché non è consigliabile segnalare diversi difetti nello stesso problema / biglietto?

un. Al fine di mantenere il rapporto conciso e chiaro.

b. Perché gli sviluppatori potrebbero risolvere solo un bug.

c. Perché i tester del gruppo di test sono classificati in base alla quantità di bug rilevati.

d. I sistemi di gestione dei bug non supportano questa funzione di più bug.

La mia unica opinione è che asia la risposta corretta.

b- non può essere perché la correzione-feedback-risolto-chiuso dovrebbe evitare quel caso. c- Ovviamente sbagliato.

d - I plugin Redmine / Trac supportano più campi.

La risposta secondo il foglio di risposta è b.

Qualcuno può spiegare perché? I commenti con opinioni sulle risposte sono ben accetti.

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

Il sistema di tracciamento dei bug viene eseguito per ... tenere traccia dei bug. Tracciare un bug significa:

1. Creazione di un record in cui si afferma che potrebbe esistere un bug, con informazioni su come riprodurlo,

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

3. Asserendo che il bug è ora risolto,

4. Confermando 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:

• Giorno 1 [Cliente] Quando si preme il pulsante "Rimuovi" nella finestra "Dettagli prodotto", l'applicazione si blocca. Il riavvio dell'applicazione mostra che il prodotto non è stato rimosso. Il comportamento previsto è rimuovere il prodotto.

• Giorno 4 [Sviluppatore] <Problema riprodotto>

• Giorno 5 [Sviluppatore] <Problema risolto nella revisione 5031>

• Giorno 12 [Cliente] <Biglietto chiuso: problema risolto>

Il registro è semplice e chiaro . Puoi facilmente rintracciare cosa è stato fatto e quando , quale revisione ha risolto quale bug, ecc. Ad esempio, se il sistema di tracciamento dei bug è integrato con il controllo versione, quando visualizzi una revisione specifica, puoi verificare quali bug sono stati risolti in esso.

È facile trovare informazioni . È facile vederne lo stato (è riprodotto? Se il biglietto è stato chiuso, perché?). È facile filtrare i biglietti (voglio visualizzare i biglietti che riguardano solo l'interfaccia utente dei plugin, dato che voglio solo i biglietti che sono aperti, più vecchi di una settimana e assegnati a me dal nostro designer dell'interazione e hanno priorità media o alta).

È facile riassegnare un biglietto o determinare in origine qual è la persona che dovrebbe essere responsabile del bug.

Ora immagina il seguente registro:

• Giorno 1 [Cliente] L'app si blocca quando premo il pulsante "Rimuovi" nella finestra "Dettagli prodotto". Inoltre, il colore di sfondo del pannello di sinistra è blu scuro, mentre dovrebbe essere viola. Ho anche notato che il testo della finestra "Dettagli prodotto" non è tradotto bene in tedesco; è previsto? Quando sarà disponibile la traduzione finale? A proposito, hai ricevuto la nuova icona che ho inviato per l'azione "Pubblica prodotto"? Non lo vedo nella finestra "Sincronizza dati".

• Giorno 6 [Sviluppatore] Ho cambiato il colore in viola.

• 7 ° giorno [Sviluppatore] Sì, è normale che la traduzione in tedesco sia incompleta.

• 8 ° giorno [Cliente] Ok per il tedesco. E l'italiano? Lucia ti ha inviato il file XML due giorni fa.

• Giorno 9 [Developer] Ora va bene.

• Giorno 10 [Cliente] Ok per il pulsante "Rimuovi"? Strano, al mio computer, si blocca ancora.

• 11 ° giorno [Sviluppatore] No, volevo dire che va bene per la traduzione italiana.

• 12 ° giorno [Cliente] Vedo. Grazie. Ma c'è un problema con il colore. L'hai cambiato in viola scuro, ma dovrebbe essere viola chiaro, come il pannello superiore della finestra principale.

• 13 ° giorno [Sviluppatore] Ho aggiornato l'icona.

• Giorno 14 [Cliente] L'icona? Quale icona?

• Giorno 15 [Sviluppatore] L'icona che mi hai chiesto di aggiornare.

• Giorno 16 [Cliente] Non ti ho mai chiesto di aggiornare alcuna icona.

• Giorno 17 [Sviluppatore] Ovviamente hai chiesto. Vedi questo biglietto. Hai scritto che l'icona di pubblicazione del prodotto deve essere aggiornata. L'ho fatto.

  ⁞

• Giorno 100 [Cliente] Quindi, per quanto riguarda le voci nel registro?

• Giorno 101 [Sviluppatore] Non ho idea di cosa tu stia parlando. Non è nemmeno in questo biglietto, ma nel 6199. Sto chiudendo questo come risolto. <Ticket chiuso: problema risolto>

• Giorno 102 [Cliente] Ci dispiace riaprirlo, ma il problema non è stato risolto. Sto parlando delle voci nel registro: ti ho detto la scorsa settimana che il testo a volte non è valido quando contiene caratteri unicode. Ti ricordi? <Biglietto riaperto>

• Giorno 103 [Sviluppatore] Ricordo vagamente qualcosa del genere, ma dopo aver cercato le ultime tre pagine di questo biglietto, non riesco a trovare alcuna traccia. Puoi scrivere di nuovo qual è stato il problema?

  ⁞

• Giorno 460 [Sviluppatore] Ho trascorso due ore a cercare una traccia di ciò che hai detto sui file inviati crittografati attraverso la rete. Non sono sicuro di poter trovare la richiesta precisa.

• Giorno 460 [Cliente] Voi ragazzi dovreste davvero essere più organizzati. Ti ho notificato quattro volte su questo problema nelle ultime due settimane. Perché stai dimenticando tutto?

  ⁞

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

Nota: è possibile ritenere che tali registri non esistano. Credetemi, ne ho visti più di una volta.

Solo per commentare la tua dichiarazione:

non può essere perché la correzione-feedback-risolto-chiuso dovrebbe evitare quel caso

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

1. Un pulsante di reimpostazione del modulo in realtà invia il modulo, anziché cancellare i valori
2. La dimensione del carattere sul pulsante è del 110% quando dovrebbe essere del 115%.

Entrambi sono corretti per il rilancio di un tester, in quanto entrambi sono errori nell'implementazione. Ma supponiamo che il proprietario del prodotto decida che la prima attività secondaria è un blocco da rilasciare (cioè deve essere risolto prima che il prodotto possa essere pubblicato), ma la seconda attività è un problema minore (cioè può essere risolto in una v1. 1 versione).

In tal caso, non abbiamo altra scelta che dividere il n. 2 nel proprio biglietto (o rischiare di dimenticarsene). Se possiamo 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.

Scopo:

Questa risposta (e la domanda) sembra applicabile solo al rilevamento dei difetti del codice, in cui il codice sorgente non funziona secondo le specifiche o le 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).

Uno scopo importante del rilevamento dei difetti è comunicare e coordinarsi tra più ruoli (programmatori, tester, clienti e manager).

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

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

• Per consentire il rilevamento indipendente e inequivocabile di difetti riproducibili in modo indipendente , e
• Fornire la migliore approssimazione (corrispondenza individuale) alla causa principale di ciascun difetto.

Nel fare ciò, dovrebbe massimizzare le seguenti qualità desiderabili:

• Scala in modo efficiente con l'aumentare del numero di difetti nel tempo.
• Prevenire la sindrome del bersaglio mobile.

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

Tracciamento indipendente e inequivocabile significa che:

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

   • Motivo 1: semplificare la gestione,
     • Esempio: abilita l'uso di "numero di ticket non risolti" come metrica.
   • Motivo 2: tradurre in oggetto utilizzabile
     • Esempio: se non viene risolto, la responsabilità ricade sul programmatore assegnato. Se viene risolto ma non chiuso, la responsabilità ricade sul tester assegnato (verificatore).
   • Conseguenza: in questa metodologia, parzialmente risolto difetto merita di essere suddiviso in diversi difetti dipendenti.

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

   • "Riproducibile in modo indipendente" significa che possono avere stati diversi. Uno può sembrare risolto mentre l'altro rimane rotto.
   • Motivo: 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 del codice richieda almeno una modifica del codice.
     • Se due difetti sono riproducibili in modo indipendente, saranno necessarie più modifiche al codice.
     • Se due difetti sono riproducibili in modo indipendente, entrambi devono essere testati (verificati), poiché il superamento di un test non implica il superamento dell'altro test.
   • Esempio 2: se inizialmente si riteneva che due sintomi avessero la stessa causa principale e quindi classificati nello stesso biglietto, e in seguito fossero stati mostrati come riproducibili in modo indipendente, dovrebbero essere suddivisi in due biglietti.

Guardalo dal punto di vista di qualcun altro che utilizza il sistema, presentandosi pochi mesi dopo. Trovano un bug nel programma. Sono in giro con Google e vedono che esiste un ticket di supporto che corrisponde ai loro problemi. E hey, è chiuso! Eccezionale! È stato risolto nell'ultima versione! Quindi si aggiornano ... e il bug è ancora lì? Cosa c'è che non va in questi stupidi sviluppatori?!?

Niente, in realtà. Si scopre che c'è qualcosa che non va nella persona che invia la segnalazione di bug. Hanno inviato due bug nello stesso biglietto. Uno è stato facile da risolvere e si è risolto rapidamente, l'altro no. Anche se usi qualcosa come fix-feedback-resolved-closed, può comunque essere meno che chiaro cosa sta succedendo, specialmente per un osservatore esterno.

È molto meglio assegnare a ciascun bug il proprio ticket e se si dispone di più bug correlati ma apparentemente distinti, la maggior parte dei sistemi di tracciamento dei bug ha una funzione che consente di collegare un bug a un altro. (E in caso contrario, puoi semplicemente inserirlo nel rapporto. "Vedi anche bug # 12345.")