Come misurare (e migliorare) la qualità delle correzioni dei bug? [chiuso]

Idealmente, avrai il maggior numero possibile di test di unità utili, testando ogni combinazione di input per ogni classe.

Quindi, quando correggi un bug, controlla il test dell'unità che avrebbe dovuto catturarlo. Forse c'è una condizione limite o una combinazione di input non incontrati in precedenza (aggiungere un nuovo test di unità). Forse un test esistente è stato trasmesso erroneamente (correggi il test).

Se una correzione di bug causa il fallimento di un altro test di unità, ora hai un risultato misurabile che ti dice della qualità della correzione del bug. Ovviamente si potrebbe avere un'applicazione con un accoppiamento troppo stretto in cui le modifiche al codice in un'area interessano il codice in un'altra area quando forse non dovrebbero.

Se si combina questo con un sistema di integrazione continua che ricompilerà il codice ed eseguirà test su base regolare, si otterrà un feedback molto rapido sulla qualità delle correzioni dei bug e sulla frequenza con cui interromperà l'altro codice.

I tuoi sviluppatori lavorano sotto pressione? Hanno condizioni di lavoro silenziose? Hanno i migliori strumenti di debug che i soldi possono comprare? Hai dei tester? ...

Ci sono troppi fattori che possono rendere la soluzione dei bug un'attività che crea più bug di quanti ne risolva. Troppi per essere elencati qui. Se noti che per ogni ticket chiuso, il QA ne apre altri due, parla con il tuo team, verifica quali sono i problemi nei processi utilizzati dal team, scopri perché il bug originale esisteva nel primo caso.

Ad esempio, se uno sviluppatore lavora sotto pressione e pressione del management e gli viene assegnato un ticket che dice che quando il prezzo originale è $ 0,89, quello finale dovrebbe essere $ 1,20, la tentazione sarebbe di aggiungere:

if (price == 89) {
    return 120;
}

Questo non risolve il problema quando il prezzo è $ 0,88 o $ 0,90, ma il biglietto è chiuso e la gestione è felice, per ora.

Is it a good idea to instruct bug-fixers to always look for the cause of their defect

Bene, è davvero una pessima idea risolvere i difetti senza conoscere la causa principale. Il problema è: non puoi costringere la tua squadra a fare sempre un'analisi delle cause alla radice istruendoli , devono addestrarli.

and then evaluate the ratio of previous bug-fixes being such cause?

La valutazione di un tale rapporto non migliorerà la situazione. Invece, ti suggerisco di prendere ogni bug come occasione per lavorare con i tuoi compagni di squadra su come rendere il tuo codice più a prova di proiettile. Quindi discutete con i vostri colleghi: perché questo errore è stato introdotto in primo luogo e cosa potrebbe essere fatto per prevenire un simile errore la prossima volta:

• il codice è troppo complicato / non sufficientemente documentabile?
• il codice può essere riorganizzato per renderlo più pulito?
• è stata dimenticata la solita revisione del codice?
• c'è un caso di test mancante (nei test di unità o nell'elenco di controllo per i test manuali?)
• ...

Come fai a sapere se il "nuovo" bug è causato da una correzione o se è sempre stata presente? La tentazione è di dire "Non ho mai visto questo bug prima dell'ultima patch, quindi la patch deve aver introdotto il bug", ma se questo era unilateralmente vero, come ha fatto il bug originale a entrare nel codice di produzione? Aumentare la qualità delle correzioni comporterebbe essenzialmente l'aumento del costo delle correzioni e ritardare la loro implementazione, perché ciò significa dedicare più tempo alla verifica di una correzione prima di rilasciare la patch (qualcosa, nella mia esperienza, la gestione non vuole dedicare molto tempo / soldi a). Ciò implica anche che i programmatori (o almeno i tester) siano effettivamente anche utenti del sistema. Nella mia situazione, il team che lavora sulle patch non ha idea di quale sia l'effettivo utilizzo del sistema che supporta e mostra.