Il file QA dovrebbe contenere 5 bug separati o un bug con più parti?

Naviga le tue risposte
4

La domanda potrebbe non essere semplice come sembra, dato che abbiamo faticato un po 'con questo. Se ci sono 5 bug separati, che possono essere risolti con una singola correzione, allora è uno spreco adottare questo approccio. Un bug potrebbe scivolare attraverso le fessure, e toglierebbe un'immagine completa, o sarebbe solo nascosto per un po 'di tempo (abbiamo parecchi anni di bug in sospeso, e il nostro tracker di bug fa schifo alla ricerca :().

Ora, se si registra un errore di oltre 100 parti (come le descrizioni dei comandi di aiuto che mancano in tutte le 234 finestre di dialogo), allora dovrebbe essere trattato come un progetto ed essere suddiviso. Tuttavia, se si tratta di un bug di 3-4 parti, lo sviluppatore tenterebbe di risolvere tutti i 3 o 4 contemporaneamente. Questo è dove diventa interessante. Cosa succede se il codificatore risolve solo 3 o 3.5 su 4? Dopo aver testato un nuovo bug, dovrebbe essere archiviato e quello vecchio chiuso? Se sì, allora questo richiede pratiche di programmazione scarse, in cui abbastanza vicino è abbastanza buono. Se il bug ha esito negativo, allora tutto deve essere rifatto e ri-testato. Ora ... cosa succede se la parte 1 è la dimensione di un breadbox in termini di dimensioni e rischio, la seconda parte è più simile a una macchina, la parte 3 è come una casa e così via:)

Quando ridimensionamento e priorità di questo bug (devo menzionare che usiamo Scrum), la parte della casa non è stata notata - chi legge comunque un titolo di bug? Quindi, è stato considerato un frutto basso appeso - basso sforzo, basso rischio, utente felice = alta ricompensa. Ma, recentemente siamo stati morsi con uno di loro. Quello che sembrava essere logicamente la stessa area, in realtà era il codice in stato transitorio, dove stiamo cercando di deprecare un metodo di fare le cose, o una libreria per la creazione di widget con un'altra, nuova e migliore. Il problema è che abbiamo dovuto rilasciare la metà conversione, quindi abbiamo creato due animali molto diversi tra loro. I nostri addetti al controllo qualità non lo sapevano, non ci si aspetta che lo sappiano, e quindi nella loro mente sono tutti gli stessi problemi.

Dobbiamo essere al QA-friendly - non spingere indietro troppo o troppo spesso, ma anche provare a fornire una serie di euristiche che aiuterebbero a decidere se depositare un bug o più. Suppongo che il problema potrebbe risiedere in strumenti deboli, in cui è difficile fare lo split e la fusione dei bug. Tuttavia, come gestisci queste cose in generale?

P.S. In Scrum - una volta che hai deciso di aggiustare qualcosa, probabilmente dovrebbe essere corretto. Rompi questa regola troppe volte e la disciplina si degraderà.

    
posta Job 11.12.2010 - 00:14
fonte

4 risposte

23

5 bug = 5 segnalazioni di bug; il fatto che possano essere tutti sistemati in una sola volta non è la preoccupazione di QA.

in altre parole, indovinando che tutti e 5 i bug derivano dallo stesso problema, è mettere il carrello davanti al cavallo.

    
risposta data 11.12.2010 - 00:20
fonte
2

In generale, sono d'accordo con @Steven Lowe, ma d'altra parte non voglio ottenere 10 segnalazioni di bug, una per ogni cosa che è scritta male. Penso che l'approccio giusto sia che il QA usi le loro teste - se pensano che sia probabile che le cose siano tutte un grosso bug, dovrebbero essere permesse di metterle in una segnalazione di bug. Quando lo sviluppatore li ottiene, e scopre che alcuni di essi sono un bug, e alcuni sono un altro, lo sviluppatore può quindi pubblicare un nuovo bug report sui pezzi che non vuole correggere in questo momento e aggiornare il vecchio bug report per coprire solo i bit che sono stati corretti.

Dovrai andare avanti e indietro un po 'con il QA su questo (perché non sanno per certo quando le cose sono correlate e quando non lo sono), ma penso che otterrai il miglior risultato (costi amministrativi minimi) facendo in modo che la certificazione della qualità faccia uso del loro miglior giudizio e, in caso di necessità, esegua il backfilling nello sviluppo.

    
risposta data 11.12.2010 - 19:14
fonte
1

Vorrei andare con un errore, ma se la correzione iniziale copre solo una parte di esso, allora la domanda diventa se dovesse esserci un nuovo bug aperto per quella parte in quanto potrebbe essere che quello che si pensava fosse risolto in una volta non è realistico o qualcosa di nuovo può essere introdotto e quindi dovrebbe essere un nuovo bug. La chiave sta cercando di capire dov'è, "In questo caso facciamo un nuovo bug", linea come non dovrebbe essere che ogni correzione genera un nuovo bug, ma in alcuni casi potrebbe avere senso per me.

Il mio problema con 5 segnalazioni di bug è che questo potrebbe significare un sovraccarico amministrativo che non vale la pena dato che alcuni potrebbero volere che ogni correzione venga eseguita in un ramo separato, il che può essere un po 'una perdita di tempo per la mia mente . Una volta che c'è abbastanza esperienza ci dovrebbe essere una buona dose di precedenza per vedere dove si trova quella linea.

Per dare un esempio più specifico, immagina un modulo che ha una manciata di problemi di stile, ad es. il bordo non si allinea correttamente in IE7, in Firefox un'altra parte del modulo non è allineata correttamente e poche altre cose che sono per lo più cosmetiche, ma fanno sì che il modulo non soddisfi le specifiche. Se ogni problema dovesse essere registrato come un bug separato, il che potrebbe significare un sacco di lavoro duplicato sia per il QA che per lo sviluppo dato che ogni bug deve essere creato, schermate allegate, ecc. Che non mi sembra utile se unirli insieme in un bug può essere migliore tutto intorno. Questo non ha nulla a che fare con la conoscenza di ciò che è o non è nel codice, ma piuttosto su come tagliare le cose con precisione. Ad alcune persone piace affettare le cose in pezzi itty-bitty ma questo può essere passivo-aggressivo se la persona lo fa solo per far incazzare uno sviluppatore. Ad esempio, se qualcuno deve reimpostare la propria password su "password" preferiresti fare un passo per digitare ogni carattere uno per uno o è meglio supporre che la persona sappia come digitare i caratteri consecutivi insieme in modo che invece di essere 8 passi per inserire la nuova password è solo una.

    
risposta data 11.12.2010 - 00:25
fonte
0

Sono d'accordo che il QA non dovrebbe cercare di indovinare la natura della relazione tra i bug. Se trovano 5 bug, apri 5 bug. Se dimostrano di avere una causa e una correzione di base comuni, possono essere uniti, oppure si può fare il riferimento canonico e gli altri chiusi, qualunque cosa.

    
risposta data 11.12.2010 - 19:14
fonte

Leggi altre domande sui tag

Come implementare una migliore sicurezza in Linux? Come testare un metodo che non è tanto un'unità, perché è più una classe di 'orchestrator' / 'process' / 'controller' / 'coordination' [duplicato]