La densità dei difetti misura l'efficacia QA o DEV?

I have read that it measures the effectiveness of QA but I do not get it

È senz'altro una buona idea prendere una tale affermazione sulle metriche con un pizzico di sale.

L'unico modo in cui posso pensare di utilizzare le metriche fornite per misurare l'efficacia del QA, è di prendere lo stesso codice , darlo a diverse persone di controllo qualità e lasciarle testare in modo indipendente . In teoria, più bug trovano, migliore è il QA (tuttavia, in realtà dovrebbe essere inclusa anche la gravità dei bug rilevati).

Ovviamente, così facendo la dimensione del codice è fissa, quindi usare la densità come numero è del tutto inutile, in realtà potresti semplicemente usare "Numero di bug trovati dal QA" come metrica.

Come hai correttamente notato da te stesso, non appena si variano le persone QA e l'oggetto in prova, la metrica non ti dice nulla di affidabile sull'efficacia della QA.

Poiché non hai fornito alcun riferimento dove hai trovato questa affermazione discutibile, ho fatto una rapida ricerca sul Web per vedere cosa hanno scritto gli altri su questa metrica. Mi ha portato a questa pagina , menzionando due usi per le metriche sulla densità dei difetti:

• For comparing the relative number of defects in various software components so that high-risk components can be identified and resources focused towards them.

• For comparing software/products so that quality of each software/product can be quantified and resources focused towards those with low quality.

"L'efficacia del controllo qualità" non viene menzionata da nessuna parte. Quindi, secondo questa fonte, la densità dei difetti è una metrica per quantificare gli aspetti qualitativi del software, non dello sviluppo o del processo di garanzia della qualità.

(E se leggi qualcosa di diverso in un libro di testo, è meglio chiedere agli autori del libro cosa hanno in mente con le loro dichiarazioni.)

La densità dei difetti misura il numero di difetti rilevati per unità di misura del codice (mai e poi mai usare linee di codice per questo), per un dato periodo di tempo. Più alto è il numero, maggiore è la densità dei bug.

La densità dei bug può essere considerata una misura inversa della qualità dell'app. Più bassa è la densità (cioè, meno difetti sono stati segnalati), maggiore è la qualità del codice.

Ma essendo una semplice metrica ha dei difetti:

• Se semplicemente non eseguo il test del codice, la densità dei difetti è zero: qualità perfetta! Naturalmente, in realtà, il codice più testato non è di buona qualità.
• Viceversa, per lo stesso pezzo di codice, otterrei più difetti segnalati dai tester super-zelanti di quanto vorrei per un fasullo dev chiesto di fare qualche test. Quindi ora ho due densità (e quindi due misure di qualità) per l'unico pezzo di codice. E dal momento che sto giudicando quei tester sul numero di difetti rilevati, li sto incentivando a segnare il punteggio più basso possibile.
• E, naturalmente, c'è il problema dei primi test. Associare uno sviluppatore e un tester durante uno sprint, e l'output sarà probabilmente basso di bug. Ma è estremamente improbabile che i difetti rilevati durante lo sprint vengano registrati, quindi non ho alcuna misura di qualità a meno che non ripassi il test per ottenere la mia metrica.

La densità dei difetti è solo una metrica. Per essere in grado di leggere di più in esso (qualità del codice, efficacia dei test, probabilità dell'applicazione che contiene errori significativi ecc.) È necessaria una strong dose di soggettività. A meno che tu non sappia quanto sia efficace il tuo test, la densità dei difetti non sarà una misura di qualità affidabile ad esempio. Ma se non puoi usare le metriche per misurare l'efficacia del test, come lo misuri? Quindi è necessaria una misura soggettiva.

Probabilmente si riferiva ai difetti trovati dopo . cioè dagli utenti non QA.

In questo caso, è una misura dell'efficacia della QA poiché un lavoro scarsamente codificato sarebbe più facile da trovare bug e quindi non da rilasciare. Molto bene, ma il codice non perfetto, potrebbe avere un paio di errori minori, difficili da trovare, ma non molti.

Ovviamente potrebbe anche misurare il project manager-cura-più-su-scadenze-di-bug-ness