È fattibile tracciare o misurare la causa dei bug o è questo solo chiedendo conseguenze non intenzionali?

Question

Esiste un metodo per il monitoraggio o la misurazione della causa dei bug che non comporterà conseguenze non intenzionali dai membri del team di sviluppo? Recentemente abbiamo aggiunto la possibilità di assegnare la causa di un bug nel nostro sistema di tracciamento. Esempi di cause includono: codice cattivo, codice mancato, requisiti incompleti, requisiti mancanti, test incompleti, ecc. Non ero un sostenitore di questo come potevo vedere che porta a comportamenti involontari dal team di Dev. Ad oggi questo campo è stato nascosto dai membri del team e non utilizzato attivamente.

Ora siamo nel bel mezzo di un progetto in cui abbiamo un numero più ampio del normale di bug e questo tipo di informazioni sarebbe bello avere per capire meglio dove siamo andati male e dove possiamo apportare miglioramenti in futuro (o adeguamenti ora). Per ottenere buoni dati sulla causa dei bug avremmo bisogno di aprire questo campo per input per i membri del team di dev e di QA e sono preoccupato che guiderà cattivi comportamenti. Ad esempio, le persone potrebbero non voler aggiustare un difetto che non creano perché ritengono che si riflette male sulla loro performance, o le persone potrebbero perdere tempo a discutere sulla classificazione di un difetto per motivi simili.

Qualcuno ha trovato un meccanismo per fare questo tipo di monitoraggio senza guidare comportamenti cattivi? È possibile aspettarsi dati utili dai membri del team se spieghiamo alla squadra il ragionamento dietro i dati (non guidare le metriche delle prestazioni individuali, ma le metriche di successo del progetto)? C'è un altro modo migliore per fare questo tipo di cosa (un post-hoc mortem o una discussione aperta sui problemi forse)?

Answer 1

Un sacco di pacchetti di controllo della versione hanno cose come svn blame. Questa non è una metrica diretta per il monitoraggio di un bug, ma può dirti chi ha controllato modifiche a una versione che ha un insetto importante in esso.

Ci sono anche programmi come http://www.bugzilla.org/ che aiuta a tenere traccia delle cose nel tempo .

Ma per quanto veramente scavare nel perché esistono bug, sì, vale sicuramente la pena di esaminare, anche se non posso dare una metrica standard per la raccolta di tali informazioni. Ci sono una serie di motivi per cui un sistema potrebbe essere molto buggato:

.
• Specifiche scarsamente scritte
• Timeline precipitose
• Programmazione a bassa abilità
• Bad morale
• Mancanza di test beta o qa
• Mancanza di preparazione del software in modo che sia anche fattibile per il test beta o qa
• Scadente rapporto tra tempo trascorso a pulire bug vs ottenere nuove funzionalità
• scarso rapporto tra tempo trascorso a fare miglioramenti senza bug vs ottenere funzionalità
• Un sistema complesso superiore che è facile da rompere
• Un ambiente che cambia fuori dalla base del codice, come l'amministrazione della macchina
• la colpa per gli errori che influenzano la compensazione del programmatore o la promozione

Questo è solo per citarne alcuni ... Se troppi bug sono un grosso problema, allora la gestione e i programmatori di guida e qualsiasi altro portataggio nell'intero processo è necessario sedersi e discutere il problema.

Answer 2

I tassi di bug alti possono essere un sintomo di un programma che è troppo affrettato o inflessibile.Passare a un approccio di difetti zero può aiutare.Risolvi tutti i bug prima di lavorare sul nuovo codice.

Assegnazione dei motivi è una buona tecnica per vedere se hai un'area problematica.Le metriche tipiche che ho visto e incontrato sono ancora una divisione tra:

.
• Errori delle specifiche (mancanti, incorrec, ecc.)
• bug dell'applicazione (codice di arrivo, codice mancante, dati cattivi, ecc.)
• Test errati / nessun errore (aspettative generalmente errate o specifiche non ancora implementate)

Reveiwing e verificando le cause dei difetti possono essere utili.