Test / test verimliliğinin iyi bir ölçüsü nedir?

KG organizasyonu olarak test verimliliğimizi ölçmeyle ilgili yönetimle bir tartışmaya katılmak üzereyim. Bunun arkasındaki temel neden, ekibimizin yarısının sözleşmeli yapılması ve işimizin ne kadar etkili / verimli olduğumuza dair bazı metrikler sunmak istemesi, böylece yüklenicilerin hizmet sözleşmesi ile sözleşme parametrelerini müzakere etmek için temel verilerimiz olması. .

Biraz uğraştım ve bu konuda bulduğum görüşlerin çoğu geliştirici verimliliği etrafında dönüyor: kod satırları, teslim edilen hikaye noktaları, tanıtılan kusurlar, vb.

Peki ya test ediciler? Testlerimiz çoğunlukla gereksinimlere dayalıdır ve manuel, yarı otomatik ve otomatik testlerin bir karışımıdır (her şeyi otomatikleştirmek için uğraşmadığımız için değil, bazı şeyler test sistemimizde otomatikleştirilemediğinden).

Yazılan test sayısı işe yaramaz ve bulunan çok sayıda hata, etkili KG'den ziyade zayıf gelişimin bir ölçüsü olabilir.

Otomasyon önlemleri (kod kapsamı, özellik kapsamı ...) iyi olabilir, ancak geliştiricilere (geliştirici olarak, yanlışlıkla bir şey kırıp kırmadığımı bilecek miyim) müşterilerden daha fazla yardımcı olduğunu düşünüyorum (bunu yapmak istiyorum ve işe yaramaz).

Müşteriler sorunla karşılaşmazsa kalite iyi olduğundan, KG ekibinin ve sürecinin etkinliğinin (etkinliğinin değil) iyi bir ölçüsü, KG tarafından bulunmayan müşteriler tarafından bulunan hataların ölçüsüdür .

Bu metrikle ilgili temel sorun, yapılan iş ile anlamlı sayılara sahip olduğunuzda önemli bir gecikme olabilmesidir.

KG'yi değerlendirmek için son işimde kullandığımız birkaç ölçüm var:

• Bulunan hata sayısı. Bundan nefret ediyorum. Bir geliştirici için "Yazılan kod satırı sayısı" gibi.
• Üretilen otomatik test senaryolarının sayısı.
• Fonksiyonel testlerde kapsanan toplam uygulamanın yüzdesi.
• Evrelemede üretime karşı bulunan böcek sayısı.

Sonunda, KG ekibinizin işi, doğada çıkmadan önce hataları bulmaktır. Metrikleri aslında bu hedefe ulaşmaya dayanmalıdır. Test senaryolarının kapsamı düşük, minimum miktarda otomatik test ve üretimde yüksek oranda hata varsa, iyi bir iş çıkarmazlar. Bununla birlikte, ürünleri vurmadan çok önce hataları bulma konusunda iyi bir sicile sahiplerse, metrikleri oldukça yüksek olmalıdır.

KG, iki ana metrik ile ölçülmelidir: Sahada bulunan KG'yi kaç hata geçebilir? Onların şiddeti nedir?

Dev-complete'tan daha serbest bırakılacak ciddi hataları bulmak için KG'yi belirtebilirsiniz. Tahmini tamamlanma tarihlerine (özellik başına) göre testi tamamlamadığı için KG'yi belirtebilirsiniz.

Sonunda, müteahhit personelinizin etkinliğini ölçmek için bir sözleşme personeli kullanarak elde edilen tasarruflardan daha fazla para harcayacağınızdan korkuyorum ...

Çalıştığım şirket çeşitli KG ölçümleri kullanıyor.

En alakalı olduğunu düşündüğüm kod kapsamı. EMMA gibi bir araç , manuel testlerine ek olarak kapsamlı otomatik testler yazdıkları için harika çalışıyor.

Ne yaparsanız yapın, test sayısına odaklanmayın. Bu, günde LOC kadar faydalıdır .

Proje yürütme sırasında geliştirme ve test aşamalarındaki performansı ölçmenin birçok yolu. Projelerimizde aşağıdaki önlemleri kullandık. 4 popüler Kod metriği ile ölçülen geliştirme performansı (Sürdürülebilirlik endeksi, Siklometrik karmaşıklık, Kalıtım derinliği, Sınıf kaplinleri). C # için Microsoft Visual Studio'da alacak. Test kapsamı için Ncover / Ndepend çok kullanışlıdır. Test performansı, son 4 sprint tarafından devredilen geliştirme hatalarıyla ölçülür. Sistem test hataları, son 4 sprint üzerinde yuvarlanır. Belirli sürümde / sunulan Otomasyon testinin hiçbiri geçmedi.