TDD üzerinde bir ürün için toplam sahip olma maliyetini ölçüm olarak kullanan herhangi bir bilimsel çalışma var mı?

11

Dogsa T, Batic D' de önceki çalışmaların özetini okurken . Test odaklı geliştirmenin etkinliği: endüstriyel bir vaka çalışması. Yazılım Kalite Dergisi. 2011; 19 (4): 643-661. TDD ile ilgili birçok çalışmada kullanılan ölçümlerin, kod satırları, kusurlar ve kalkınma için harcanan zaman gibi şeylere dayandığını gösterdi.

TDD'ye karşı geleneksel geliştirme veya test-son kullanılarak geliştirilen ürünlerin toplam sahip olma maliyetine odaklanan herhangi bir çalışma var mı?

Özellikle toplam edinim maliyeti ve işletme maliyetleri ile ilgileniyorum.

— Patrik Björklund
kaynak

3

TDD yapmanın etkileri ve yararları hakkında bazı çalışmalar vardır, ancak sonuçlar çelişkilidir. Bazı projeler (bu benim deneyimime göre), TDD kullanmanın bir sonucu olarak daha düşük bir hata oranına ve sahip olma maliyetine sahiptir, çünkü bir özelliği değiştirme maliyeti önemli ölçüde azalır. Bazıları durdu.

Bazı çalışmalar ( burada bir kontrol n50 slaydı), hata sayısının kapsama alanı ile arttığını göstermektedir. Ben daha fazla kapsama TDD ima ve daha fazla hata daha yüksek sahip olma maliyeti ima varsayıyorum.

Benim bakış açımdan, tek başına hiçbir ölçüm veya uygulama daha iyi kalite veya daha düşük sahip olma maliyeti ile ilişkili olamaz. Bazı korelasyonlara yol açabilecek faktörlerin bir kombinasyonu vardır. Ve bu faktörler ekipler ve projeler arasında değişir.

Sanırım hepimiz TDD yapmaya yeni başlayan, 100 satırlık test yöntemleri yazan takımların hikayelerini duyduk, bence bu testin güncellenmesi pahalı olacak.

Benim pragmatik kuralım, onları önemseyen ve öğrenmeye hevesli olan, onları destekleyen bir ortamda çalışan ve fikirlerinin daha iyi kalite ve sahip olma maliyetine sahip olmasıdır.

— Augusto
kaynak

n50 lamı son derece yanıltıcıdır. "Daha fazla kapsama alanı ne kadar çok hata" büyük olasılıkla "daha fazla kapsama alanı daha fazla hata ... bulacağınız anlamına gelir." Mümkün, ancak daha fazla kapsama alanının daha fazla enjekte edilen hataya yol açacağından şüpheliyim. Bu, sadece daha fazla kapsama alanı, geliştirme aşamasından daha fazla kusur veriminin daha yüksek olduğunu belirtmektedir. Ve evet, kalite ve sahip olma maliyetini ölçebilen çok sayıda metrik var - # aşama aşama enjekte edilen hatalar, aşama aşama hata verimi ve yeniden işleme, kalite ve maliyet üzerinde doğrudan etkisi olan ölçülebilir şeylerdir. Bu metriklerin bazı harika örnekleri için PSP / TSP'ye bakın.

— Michael

Michael, bu slayt bağlamında, sunucu daha yüksek bir hata yoğunluğu ile neyin ilişkili olduğunu gösterir. Metriklerden biri test senaryolarıydı, bu yüzden bir sınıfta ne kadar çok test vakası varsa, sınıfta bir hata o kadar yüksek olacaktır. Sunucunun söylemeye çalıştığı şey, kendi başına hiçbir metriğin daha küçük bir hata yoğunluğu ile ilişkili olmadığıdır.

— Augusto

0

Özel bir çalışmam yok ama size kişisel deneyimden ve diğer geliştiricilerin deneyimlerinden anlatabilirim ki, orta ve büyük projeler için doğru uygulandığında TDD'nin pazara sunma süresini azalttığını, hataları ve kusurları azalttığını ve kod kalitesini iyileştirdiğini biliyorum. .

Onların gümüş mermi olmadığını söyledikten sonra, TDD ile iyi bir kod yazabilir misiniz? TDD kullanarak kötü kod yazabilir misiniz? Ayrıca, projenize bağlı olarak TDD, kod için sahip olma maliyetinizi büyük ölçüde artırabilir, iyi bir örnek, kod satırı başına maliyetin büyük olduğu NASA'dır, ancak sahip olma maliyeti odak değildir, kusur eksikliğidir.

Doğru uygulandığında TDD başlangıç maliyetlerinizi ve kod tabanınızı artıracaktır, ancak regresyon testi, erken hata tespiti ve daha iyi kod tasarımı gibi uzun vadeli faydalar elde edersiniz; mülkiyet.

— Kapıcı Bob
kaynak