Se una nuova funzionalità è implementata e c'è un bug, il QA dovrebbe rifiutare quella funzione o accettarla e presentare un nuovo bug?

Non c'è una risposta dura e veloce; dipende dalla tua organizzazione.

Una cosa da considerare è che se il QA trova molti bug nella nuova funzione, sarebbe meglio rintracciarli separatamente, quindi tenderei a presentare segnalazioni di bug individuali.

Se il bug è così importante che non è possibile utilizzare la funzione come previsto (ad es. manca la voce di menu per avviare la funzione) potrebbe essere più logico rifiutare la funzionalità in modo definitivo - non ha nemmeno raggiunto il livello di test di sanità mentale.

Non dimenticare che se ti riferisci a un bug report, quel QA ha bisogno di un numero di versione significativo per archiviare il bug - non è né un bug nella versione 1.0 né un bug nella versione 2.0 - deve essere contro un particolare build / caricamento intermedio o simile.

Ovviamente, il QA dovrebbe anche avere il potere di rifiutare l'intero build dall'essere consegnato ai clienti - semplicemente misurando che "c'è un solo bug in quella nuova funzionalità" non è sufficiente.

Un piccolo manuale come risposta:

1.Tutta la funzione, non file bug

Non farlo! Anche se la funzione è consentita in produzione con bug, i problemi dovrebbero essere registrati (potrebbe non essere mai corretto ma questa è un'altra storia).

2.Cosa in evidenza, bug del file

Da usare quando il problema è minore o ha una soluzione ragionevole e non avrà un grande impatto. Il bug è segnalato e, si spera, sarà risolto in futuro. Esempio di bug qui: la finestra si sposta di 1 px a destra dopo 10 minimizza, i commenti vengono ignorati nel file di output, i bug minori dell'interfaccia utente.

3. Non consentire funzionalità, bug di file

Non consentire alla funzione di uscire dall'ambiente dev quando il bug rilevato è critico / ha un impatto su molte persone (come qualcuno menzionato prima, manca una voce di menu e non è possibile utilizzare la nuova funzione o dati) perdita). Tuttavia, l'apertura di un bug per un simile problema potrebbe essere complicato perché il bug è solitamente visibile per tutte le persone nell'organizzazione, ma ha senso solo per un piccolo gruppo. Potrebbe creare rumore.

4. Non consentire funzionalità, non file bug

Gli stessi tipi di bug di 3 si applicano qui. L'unica differenza è che non viene creato alcun bug, ma piuttosto il gruppo dev è informato a riguardo. Alla fine potrebbe essere registrato da qualche altra parte (su una lavagna bianca)

Una terza opzione è di rifiutare la nuova funzionalità e presentare un bug. Se si dispone di un dipartimento QA separato che è il gatekeeper per la qualità, non dovrebbero mai accettare codice danneggiato. IMO, "rifiutare" dovrebbe sempre essere la prima scelta.

è possibile presentare un bug in seguito

Questo potrebbe essere impopolare con lo sviluppo - e persino con i product manager) - ma questa è una buona cosa. Se qualcosa è doloroso, fallo spesso. Ciò farà sì che le persone trovino una soluzione al problema. Cioè, se ogni volta che inviano il codice buggy ritorna con un "rifiuto", si stancheranno di quello e lavoreranno di più per trovare i difetti nel loro codice.

Non ho familiarità con Pivotal Tracker, quindi non sono sicuro di cosa possa fare esattamente.

Dove lavoro usiamo FogBugz per il tracciamento dei bug, e in un caso come questo dovremmo contrassegnare la funzione "In attesa di correzioni" e aprire casi separati per ognuno dei bug trovati. Questo risolve entrambi i tuoi problemi: consente a ciascun bug di essere monitorato individualmente (e in realtà dovrebbe essere, in una funzione complessa) e consente anche di sapere chiaramente se la funzione è pronta per la spedizione o meno.

Dipende dalla severità del bug.

Di norma, una funzionalità dovrebbe essere accettata se supera il test di accettazione. Se quel bug è stato trovato lì, la funzione è normalmente respinta.

Indipendentemente dal fatto che quella funzione sia stata rifiutata o meno, il bug dovrebbe essere archiviato separatamente. Gli ingegneri noteranno sicuramente una funzionalità fallita, ma se il bug è menzionato solo nei commenti, sarà più difficile tenere traccia di questo bug.