Yapılan işin, üretilen çıktının kalitesini, performansını değerlendirmek için belirli ölçülere ihtiyaç duyarız. Ölçmek, aynı zamanda yapılan işi daha iyi yönetmenin bir ön şartıdır. Tom DeMarco’nun meşhur “You can’t manage what you can’t measure” sözüne de bu vesileyle yer vermiş olalım.

İşte tam noktada, nasıl ölçeceğimize belirli metriklerle karar veririz. “Ölçülebilen” değerlere metrik diyoruz. Test otomasyonunda kullanılan metrikler objektif sonuç vermeli, ölçülebilir ve anlamlı olmalı, otomasyonun gelişim alanlarını belirlemeye yardımcı olmalı. Test otomasyonu için kullanılabilecek başlıca metrikler aşağıda örneklendirilmiştir.

Otomatik Test Yüzdesi

Bir proje manuel, otomatik veya her iki yöntemle de test edildiğinde otomatik test yüzdesi bir metrik olarak kullanılır. Otomatik test yüzdesi, otomatikleştirilen test senaryolarının toplam test senaryolarına oranı ile hesaplanır.

Hangi testlerin otomatikleştirileceği ve hangilerinin otomatik test kapsamı dışında bırakılacağı projeye, kullanılan teknolojiye, uygulanan test stratejisine göre farklılık gösterir. Geliştirilmesi tamamlanmamış veya stabil olmayan bir yazılım için otomatik test kodları yazılmamalıdır. Return on investment dediğimiz yatırım getirisi en yüksek test setleri otomasyona dahil edilmelidir. Kısacası bir testin otomatikleştirilebilir olması, otomatik test edilmesi gerektiğini göstermez.

Otomatik test yüzdesini farklı proje/component düzeyinde karşılaştırmalı olarak kullanarak test otomasyonunda büyük resmi görmek de mümkün.

İlerleme Yüzdesi

İlerleme yüzdesi, belirli bir sürede otomatikleştirilebilir test senaryolarından otomatik test edilenlerin yüzdesidir. Hedef, otomatik test edilmesi gereken senaryoların %100 otomasyonla test edilmesidir.

İlerleme yüzdesinde yapılan işin büyüklüğüne göre hafta, ay gibi farklı zaman aralıkları referans alınabilir.

İlerleme yüzdesine benzer şekilde testin ilerleme grafiği de tamamlanan test senaryolarının belirli bir zamana bölünmesiyle elde edilir. Bu şekilde testin tüm proje planı içindeki durumu izlenebilir. Testin ilerleyişi genellikle “S” grafiği olarak karşımıza çıkar. Projenin başında temel senaryoların test edilmesiyle başlayan test süreci, geliştirmenin farklı aşamalarda tamamlanmasıyla kapsamlı test senaryolarının çalıştırılmasıyla devam eder. Daha sonra belirli bir olgunluk seviyesine gelerek stabilite sağlanır.

Otomatik Test Kapsama Yüzdesi

Test kapsamı söz konusu olduğunda çalıştırılan test senaryo sayısı tek başına bir şey ifade etmiyor. Test senaryolarının yazılımın/ürünün fonksiyonalitesinin ne kadarını kapsadığını doğru tespit etmek önemli. Örneğin 1000 test senaryosu benzer veya aynı test datası ile yazılımın sınırlı bir kısmını test ederek, düşük bir test kapsama oranı sağlıyor olabilir. Bu metrik, testin verimliliğinden çok boyutu hakkında fikir verir.

Test kapsamını belirlerken yazılım sistemini ölçümlemede kullanılan Function Point(FP) analizinden de faydalanılarak bir sayısal değere ulaşmak mümkün.

Test kapsamının derinliğine karar verilirken kabul kriterleri(acceptance criteria) önemlidir. Finans, sağlık gibi kritik sistemlerde test kapsamının maksimum seviyede tutulması beklenirken, diğer sistemlerde test kapsamı sadece önceliklendirilen ve kritik kabul edilen test senaryolarından oluşur. Testin kapsamının kritikliğini yine yazılımın son kullanıcısı, hedef kitlesi de önemli ölçüde etkiler.

Hata Yoğunluğu

Literatürde “Defect Density” olarak geçen bu metrik aslında sadece otomasyona özgü olmayıp, testin her aşamasında kullanılmaktadır. Hataların, yazılımın belli bir alanında, bir fonksiyon vs. üzerinde yoğunlaşmış olması analiz edilerek hataların kök sebebine inilir. Fonksiyonun karmaşık olması, yazılımın hatalı tasarlanmış olması, geliştirici kaynaklı sebepler gibi farklı birçok sebep bu sonucu vermiş olabilir.

Bilinen hataların sistemin toplam büyüklüğüne oranı ile hata yoğunluğu hesaplanır. Genellikle hata yoğunluğu yazılımın component büyüklüğüne göre analiz edilir. Burada bir diğer önemli nokta hataların kritiklik seviyesidir. Hata yoğunluğunda, hataların düşük mü yoksa yüksek seviyede mi kritik olduğu da göz önünde bulundurulmalıdır. Bir yazılım componenti 10 düşük seviye hata ile testten kabul alırken, kritik tek bir hatanın bulunduğu başka bir component testten başarısız sayılabilir.

Diğer Metrikler

Yukarıda saydıklarımızın dışında sadece test otomasyonunda değil manuel test sürecinde de kullanılan birçok test metriği bulunuyor. Şimdilik bunlardan bazılarının isimlerine yer verelim.

• Hata Trend Analizi
• Hata Maliyeti
• Testte Bulunan Hata Yüzdesi
• Canlıda Bulunan Hata Yüzdesi
• Hata Çözüm Verimlilik Yüzdesi (Defect Removal Efficiency)
• Hata Çözüm Süresi
• Tekrar Açılan (Reopen) Hata Yüzdesi
• Hata Öncelik Yüzdesi
• …

Kaynak:  “Implementing Automated Software Testing ” by Elfriede Dustin, Thom Garrett, Bernie Gauf ; Test Automation Strategy and Planning Training by Keytorc