Quali caratteristiche sono essenziali per un buon software di tracciamento dei bug?

La semplicità. Se è troppo complicato o troppo lungo per entrare o ordinare i bug, nessuno vorrà utilizzarlo.

Integrazione con SCM, in modo che eventuali correzioni possano essere ricondotte al codice e le modifiche al codice possono essere ricondotte a un problema. Ciò richiede la vigilanza per il check-in solo il codice relativo al problema promosso / controllato contro. cioè no "Aggiunta funzione xyz, e bug casuali fissi in 4 posizioni diverse e un refactoring rapido di feature zyx".

Un'altra buona caratteristica è la gestione del flusso di lavoro, in modo che il processo aziendale sia seguito dal codice. Ad esempio, potrebbe avere un percorso del flusso di lavoro simile a questo: Bug segnalato - > Triaged per priorità e validità - > assegnato a dev - > ha funzionato - > assegna a QA - > passare test - > segna come chiuso.

Proprietà forzata dei bug. Non dovrebbe essere possibile avere un problema aperto che non è responsabilità di qualcuno. Oltre a questo, semplice è meglio.

• Funzionalità di reporting buone / veloci. Il management vuole monitorare la tendenza del bug.

• API per automazione, notifica e-mail automatizzata, integrazione con controllo sorgente, ecc.

1. rapporti personalizzati : possibilità di creare e salvare rapidamente query di ticket, da parte di tutti gli utenti e non solo degli amministratori. a tutti piace la propria visione degli insetti. se questo è fatto bene, non c'è bisogno di notifiche, basta accedere alla visualizzazione preferita di "ticket on my plate"
2. annulla il controllo della versione : dovrebbe essere facile trovare il codice modifiche associate a un ticket.
3. Intelligence del flusso : il sistema non dovrebbe consentire l'ingresso dei ticket dichiara dove cadrà nelle fessure, quindi se lo stato cambia 'Rifiutato', dovrebbe imporre l'assegnazione a qualcuno in dev
4. personalizzabile : ogni progetto è diverso, ogni squadra è diversa. alcuni team hanno bisogno di 8 stati diversi, altri ne hanno solo 3. ma la GUI dovrebbe rimanere
5. semplice : mantieni grandi gli elementi chiave del ticket e in anticipo e semplice. versione, titolo, descrizione, stato, proprietario
6. cronologia : questo spicca davvero quando è sbagliato (ti guardo, Unfuddle); quindi dovrebbe essere indicato. la cronologia delle modifiche al ticket deve essere visibile in un bel registro cronologico.

Trovo abbastanza importante essere in grado di collegare i problemi (e specificare un tipo di collegamento, ad esempio, dipende da). A parte i soliti sospetti di versione in cui è stato trovato il bug, in quale versione puntiamo a risolverlo (in modo che possiamo guidare le mappe stradali), un campo di stima è valido per la pianificazione di progetto / agile.

Il bello di avere per me è votare dal pubblico, la possibilità di notificare agli utenti le modifiche al problema e di avere un sistema abbastanza flessibile di categorizzazione dei problemi.

In effetti praticamente tutto ciò che JIRA supporta out of the box:)

Qualsiasi funzione che esegue un'attività per il programmatore. Non dovrebbe davvero essere parte dell'IDE? C'è l'elenco dei bug. Scegli uno su cui lavorare e tutti gli status e i timestamp sono a posto. Le modifiche al codice sono collegate. I test richiesti sono associati. Controllalo come fisso, aggiorna lo stato e fallo sapere a tutti.

Possibilità di identificare somiglianze sui biglietti che sono già stati chiusi.

Potrebbero essere usati algoritmi di data mining, forse.

Query potenti Il software di tracciamento dei bug dovrebbe aiutare a gestire i progetti applicando rigorosi processi di sviluppo in ogni fase della risoluzione del problema.