Esistono studi scientifici condotti su TDD che utilizzano il costo totale di proprietà di un prodotto come misura?

11

Quando stavo leggendo il riassunto dei precedenti lavori in Dogsa T, Batic D. L'efficacia dello sviluppo guidato dai test: un caso di studio industriale. Diario della qualità del software. 2011; 19 (4): 643-661. mi ha colpito il fatto che le misurazioni utilizzate in molti studi sul TDD si basano su elementi come linee di codice, difetti e tempo impiegato per lo sviluppo.

Ci sono studi là fuori che si concentrano sul costo totale di proprietà per i prodotti che sono stati sviluppati utilizzando TDD rispetto allo sviluppo tradizionale o all'ultimo test?

Sono particolarmente interessato al costo totale di acquisizione e ai costi operativi.

— Patrik Björklund
fonte

3

Ci sono alcuni studi sulle implicazioni e sui benefici del TDD, ma i risultati sono contraddittori. Alcuni progetti (questo è nella mia esperienza) hanno un tasso di bug e costi di gestione inferiori a causa dell'utilizzo di TDD, poiché il costo di modifica di una funzione si riduce drasticamente. Alcuni altri sono fermati.

Alcuni studi ( eccone uno - controlla la diapositiva n50) mostrano che il numero di bug è aumentato con la copertura. Suppongo che una maggiore copertura implichi TDD e che un numero maggiore di bug implichi un costo di proprietà più elevato.

Dal mio punto di vista, nessuna metrica o pratica da sola può essere correlata a una migliore qualità o a minori costi di gestione. C'è una combinazione di fattori che possono portare a qualche correlazione. E questi fattori cambiano tra team e progetti.

Penso che tutti abbiamo sentito storie di team, che hanno appena iniziato a fare TDD, scrivendo metodi di test a 100 righe, che (a mio avviso) aumentano il costo di proprietà, poiché l'aggiornamento di quel test sarà costoso.

La mia regola pragmatica è che le persone che hanno a cuore e sono desiderose di apprendere , lavorando in un ambiente che le supporta e le loro idee hanno una migliore qualità e costi di gestione.

— Augusto
fonte

slide n50 è estremamente fuorviante. "Maggiore è la copertura maggiore è il numero di bug", molto probabilmente significa "maggiore è la copertura maggiore è il numero di bug ... troverai." È possibile, ma dubito che una maggiore copertura porterà a difetti più iniettati. Questo sta semplicemente affermando che maggiore è la copertura, maggiore è la resa del difetto dalla fase di sviluppo. E sì, ci sono molte metriche che possono misurare la qualità e il costo di proprietà - # difetti iniettati per fase, resa dei difetti per fase e rilavorazioni sono tutte cose misurabili con un impatto diretto sulla qualità e sui costi. Vedi PSP / TSP per alcuni grandi esempi di queste metriche.

— Michael,

Michael, nel contesto di quella diapositiva, il presentatore mostra ciò che è correlato a una maggiore densità di bug. Una delle metriche erano i casi di test, quindi più test ha una classe, più in alto ci sarà un bug nella classe. Ciò che il presentatore cerca di dire è che nessuna metrica di per sé è correlata a una densità di bug minore.

— Augusto,

0

Non ho studi specifici, ma posso dirti dall'esperienza personale e dalle esperienze di altri sviluppatori, so che quando applicato correttamente per progetti di medie e grandi dimensioni TDD riduce il time to market, riduce bug e difetti e migliora la qualità del codice .

Detto che non sono proiettili d'argento, puoi scrivere un buon codice senza TDD? sì, puoi scrivere un codice errato usando TDD sì. Inoltre, a seconda del progetto, TDD può aumentare notevolmente il costo di proprietà del codice, un buon esempio è la NASA, in cui il costo per riga di codice è enorme, ma il costo di proprietà non è al centro, è la mancanza di difetti.

Se applicato correttamente, TDD aumenterà i costi iniziali e la base di codice, ma otterrete i vantaggi a lungo termine del test di regressione, del rilevamento tempestivo dei bug e di una migliore progettazione del codice che dovrebbe ridurre i difetti, i costi dei test e i tempi di manutenzione, riducendo così il costo complessivo di Proprietà.

— Bob il bidello
fonte