L'approccio generale per misurare queste cifre è:
- Stabilire un piano di test con copertura sufficiente.
- Esegui il piano di test formale (potrebbe essere automatizzato o test manuale) e registra il test non riuscito e, se necessario, i rapporti sui bug emessi dopo l'analisi delle cause principali.
- Confronta le cifre con i KLOC che possono essere calcolate automaticamente dal codice sorgente.
Inutile dire che se si ha un approccio di test manuale "ad-hoc", non si ottengono numeri di bug coerenti: come già accennato, molti bug non vengono scoperti immediatamente. Tuttavia, i piani di test formali con unità, integrazione e test di accettazione sono molto comuni per i software più complessi e mission critical. TDD enfatizza ulteriormente i test, fornendo test unitari molto dettagliati che possono controllare e diagnosticare la funzionalità promessa e tutti gli invarianti che il tuo codice dovrebbe rispettare.
C'è anche la domanda se i risultati dei test preventivi eseguiti da uno sviluppatore prima di inviare il suo codice per l'integrazione devono essere contati o meno. Stessa domanda per problemi rilevati nelle revisioni tra pari.
Anche la definizione di bug è un problema. Le persone abusano di questa parola in un linguaggio comune, e la frontiera non è chiara: è una non conformità del codice con le specifiche? o sono anche problemi causati da requisiti poco chiari? Qui alcuni standard con definizioni precise, come ISO 9126 , possono davvero aiutare.
Infine, il KLOC è un concetto che è stato introdotto in un tempo in cui le lingue dominanti erano orientate alla linea (ad esempio fortran, cobol). Quindi è davvero una domanda al giorno d'oggi, che cosa dovrebbe contare per un LOC: linee vuote? righe di commento? linee condizionatamente compilate? linee attive o istruzioni attive? ecc ...
Detto questo, avrai ovviamente delle variazioni nelle tue cifre assolute che dipenderanno dalle tue definizioni e metodologia precise. Ma se rimani coerente, potrebbero emergere fatti interessanti quando guardi all'evoluzione di queste metriche piuttosto che alle cifre assolute.
Esistono società che mantengono statistiche su un numero enorme di software e hanno sviluppato un modello predittivo che viene utilizzato per prevedere la frequenza dei bug in base all'evoluzione della metrica sul progetto. Quindi usano questa previsione nel processo decisionale sul rilascio o meno sul mercato (penso di aver letto un documento di HP qualche anno fa, ma non sono riuscito a ritrovarlo). Tali previsioni hanno ovviamente solo valore statistico: il fatto che sia significativo in generale, non evita che un particolare progetto possa contraddire completamente il modello.
Personalmente, non sono sicuro che questi metodi predittivi abbiano ancora senso in un'era di agilità e TDD, in cui i bug vengono prevenuti nelle fasi iniziali e al volo. Tuttavia, devo ammettere che l'introduzione di metriche così strutturate su progetti di subappalto (ad esempio il sotfware costruito secondo i requisiti ben specificati) ha permesso di controllare e affrontare rapidamente i problemi di affidabilità di alcuni appaltatori.