Within the software development departments of ASELSAN, software products are developed by using different software development models and test activities are carried out progressively within the process. Considering the continuous improvement of test design activities in a specified process, test effort estimation has a significant role during the project planning. In this article, the method for software test effort estimation is described for the software projects. Software and system test effort estimation are made by the method using test metrics. The success of the proposed method is evaluated by comparing calculated test effort estimation with the realization results of the projects.
Yazılım ürünlerinin karmaşıklık seviyesi arttıkça oluşabilecek riskleri yönetebilmek
zorlaşmaktadır. Ölçülebilir bir sürece sahip olmak proje boyunca karşılaşılabilecek
risklere karşı dayanıklı ve çevik olunmasına yardımcı olmaktadır. Test süreci de bu
kapsamda değerlendirildiğinde oluşabilecek riskleri azaltmak ve süreci yönetilebilir
kılmak amacıyla test sürecine yazılım test efor tahminleme yaklaşımı getirilmelidir.
Proje planlamasındaki en önemli nokta projenin ne kadar sürede biteceğinin tahmin
edilebilmesidir. Elde somut bir ölçüm olmadığı takdirde güvenilir bir tahminde
bulunmak oldukça zordur. Tecrübeler üzerinden yapılan tahminler kesin olmadığı gibi,
bazı durumlarda gerçek senaryodan da oldukça uzak olabilmektedir. Bu nedenle
metrik belirleyip ölçümleme yapıp, metrikler üzerinden proje bitiş sürecine dair
tahminleme yapmak başvurulabilecek en pratik yöntemlerden birisidir. Metrik bir tür ölçüm
göstergesidir[
Tom de Marco’nun tabiriyle “Ölçülemeyen bir şeyin kontrol edilebilmesi oldukça
zordur”[
Metrikler genel olarak süreci ölçmek, izlemek ve süreç kalitesini geliştirmek için
kullanılmaktadır[
Teknoloji sektöründe çalışan birçok uzman, metriklerin öneminin farkında olmakta
ancak nereden ve nasıl başlayacağının kararını vermekte zorlanmaktadır[
Şekil. 1. Metrik Yaşam Döngüsü 3.1
Neden metrik toplanmak istendiği bu safhada belirtilmelidir. Amacı olmadan yapılan çalışmalar hem zaman hem de bütçe olarak zarar demektir. Ayrıca verimli bir çalışma da olmayacaktır. Amaç belirlenirse rota daha kolay oluşturulup hedefe daha etkin ve daha doğru bir şekilde ulaşılır. Örnek verilecek olunursa: • Riskli alanlar için daha fazla test süresi ayrılması • Müşteri kabul testleri memnuniyetinin 3 yıl içerisinde %20 arttırılması • Gelecek projeler için test efor tahmininin yapılması • Müşteriden geri dönecek hataların önem derecesinin kritik seviyede olmaması 3.2
Piyasada yüzlerce metrik bulunmaktadır. Bunların hepsini toplamak verimsiz olacağı
gibi kısıtlı olan test süresini boş yere harcama anlamına gelecektir. Belirlenen amaca
yönelik metriklerin tanımlanıp onlar üzerinde çalışma yapılmalıdır. Seçilen metrikler
kolay toplanabilir, rapor edilebilir ve istatistiksel olarak modellenebilir olmalıdır.
Projeler, ihtiyaçlar, kullanılan teknoloji, müşterilerinin ihtiyaçları sürekli olarak
değişebilir. Bunlara göre seçili metrikler güncel olmalı ve metrik toplama işlemi canlı
tutulmalıdır. Seçilen metrikler tanımlanan amaçlarla ilgili sorulara cevap olmalıdır[
Testlerin koşumu ve raporlanması esnasında test yönetim araçlarını kullanmak metrik toplama işlemini oldukça kolaylaştırabilir. Uygun filtreler ile belirlenen metriklerin sonuçları toplanabilir. Toplanan metrikler ile üst düzey metrikler de basit matematiksel işlemler ile hesaplanabilir. 3.4
Projenin belirli zamanlarında, tutulan metrikler üzerinden projenin gidişatı hakkında çalışma yapılması projenin risk seviyesini azaltmaya yarar. Projede acil müdahale edilmesi gerekli alanların yöneticilerle konuşulup derhal müdahale edilmesi, çok ciddi kayıpların önüne geçebilir. Örnek verecek olursak test planı başına test senaryosu hata yoğunluğu artıyorsa müşteriye verilecek sürümde çok ciddi sayıda hata olması beklenebilir. Bu durumda hata çözümünden sonra yapılacak etki analizi için koşturulacak test senaryosu sayısının artırılması ya da test senaryolarının gözden geçirilip daha verimli hale getirilmesi düşünülebilir. 3.5
Toplanılan metriklerin kalıcı olması ve gelecek projelerde kullanılabilir olması için anlaşılabilir bir şekilde saklanması gerekmektedir. Metriklerin toplanma amacının, test efor tahmini ihtiyacı sırasında kullanılmak olduğu düşünüldüğünde, metriklerin kalıcılığı ve doğruluk payı yüksek olmalıdır. Bu metrikleri sadece sizin kullanmayacağınızı düşünürseniz diğer paydaşlar tarafından anlaşılabilir ve kolay uygulanabilir metrik kümesi bırakmak oldukça önemlidir. 3.6
Metrikler üzerinden tahmin işlemi metrik yaşam döngüsünde bulunan ve faydalı görülen yeniden kullanılabilir metrikler üzerinden gerçekleştirilir.Projenin içeriğine ve kullanılacak test metodolojisine göre uygun metriklerin seçilip projede yer alan uygun parametreler üzerinden tahmin işlemi gerçekleştirilebilir. Unutmayalım ki her proje sonunda metriklerimizi güncellemek gereklidir. Test ve süreçler anlamında ya da alan bilgisi olarak kazanılan her tecrübeyle metrikler hassaslaşacak ve daha iyi sonuçların elde edilmesine ortam sağlayacaktır. 4
Yazılım test efor tahmininde en önemli olan parametrelerden biri zamandır. Proje
zaman planlamaları her zaman gerçeklerle uyuşmayabilir. Sistemcisinden,
tasarımcısına, üretimcisinden, testçisine bütün proje çalışanlarına daha fazla zaman gereklidir.
Test faaliyeti projede son adımlarda olduğundan ve projenin teslim tarihi olduğundan
genellikle testçiye da kısıtlı zaman kalır. Bu yüzden daha çok zaman bazlı metriklerin
tutulmasında ve kullanılmasında fayda vardır. Günümüzde metrikler farklı kategoriler
altında listelenmektedir. Biz bunları bölüm bölüm ayırmak yerine ölçümleri yapılan
tüm metrikleri ve tutulan değerleri açıklıyor olacağız. Aselsan içerisinde çalışılan
daha önceki ve hala devam etmekte olan projeler sırasında ölçüm yapılan
metrikleri(metrikler sadece test faaliyeti için tutulan süreyi ifade etmektedir) sıralayacak
olursak eğer[
Tablo 1. Baz Metrikler
Toplam kullanıcı hikayesi sayısı Toplam gereksinim sayısı Kullanıcı hikayesi başına test senaryosu sayısı Gereksinim başına test senaryosu sayısı Test planı başına kullanıcı hikayesi sayısı Test planı başına gereksinim sayısı Tasarlanan test senaryo sayısı Koşulan test senaryo sayısı Başarılı olan test senaryo sayısı Hatalı test senaryo sayısı Test senaryosu koşum süresi Toplam hata sayısı Test senaryosu tasarlanma süresi Kullanıcı hikayesi için gözden geçirme süresi Gereksinim için gözden geçirme süresi Test planı başına test ortamının oluşturulması süresi Hata kaydının hata kayıt aracına girilme süresi Test planı başına test raporunun hazırlanma süresi Hatalı test senaryosu için girilen hata sayısı Test başarı oranı Tablo 1’de gösterilen Metrik-AD Alper Dönmez tarafından tutulan, Metrik-EU Erdem Üçüncü tarafından tutulan metrikleri göstermektedir.
Elimizdeki metrikler üzerinden basit matematiksel işlemler ile başka metrikler de elde
edebiliriz. Bunları sıralayacak olursak eğer[
X100 • Test senaryosu hata yoğunluğu= • Gözden geçirme etkisi= ö" ç Tablo 1 üzerinde ölçümleri verilen metrikler üzerinden bir sonraki yazılım test projesine ait test efor tahmini yapılabilir. Bu sayede metrikler ile proje planlamasında test eforuna ne kadar zaman ayrılması gerektiği açık bir şekilde hesaplanabilir. Tablo 1’de verilen metrikler kullanılarak Tablo 2 üzerinde efor tahmini çalışması yapılmış ve sonuçları verilmiştir. Girdi olarak sadece kullanıcı hikayesi(Alper DÖNMEZ için)gereksinim(Erdem ÜÇÜNCÜ için) miktarları kullanılmıştır. Đlk çalışmadan 140 kullanıcı hikayesinden oluşan bir küme seçilmiş olup, ikinci çalışma için 1800 adet gereksinim kümesi seçilmiştir. Tablo 1 üzerinde verilen metrikler ile Tablo 2 üzerinde 140 kullanıcı hikayesi ve 1800 gereksinim için diğer tüm satırlar doldurulmuştur. Tablo 1’ de 100 kullanıcı hikayesi ve 1000 gereksinim için tahminlerde kullanılacak metrikler hesaplanmıştır. Bu metrikler üzerinden Tablo 2 doldurulmuştur. Birinci regresyon testinden sonra çok ufak bir iş hacmi olacağından test efor tahmini hesaplanmamıştır. Sadece ilk test koşumu ve daha sonrası için ilk regresyon testleri için planlama ve koşum süreleri için tahmin işlemi gerçekleştirilmiştir.
Tablo 2. Vaka Çalışması
Toplam kullanıcı hikayesi Toplam gereksinim sayısı Test planı sayısı Tasarlanan test senaryo sayısı Test senaryosu koşum süresi Test senaryosu tasarlanma süresi Kullanıcı hikayesi için gözden geçirme süresi Gereksinim için gözden geçirme süresi Test ortamının oluşturulması süresi Hata kaydının hata kayıt aracına girilme süresi Test raporu hazırlama süresi
140 9 1001 31 gün 42 gün 13 gün 13 gün 4 gün 4 gün 107 gün
Test-EU 1800 7 1800 19 gün 19 gün 15 gün 7 gün 1 gün 2 gün 63 gün
Regresyon-AD 40 9 gün
Regresyon-EU 100 1 gün 1 gün 10 gün 0 1 gün Tablo 2’de gösterilen Test-AD ve Regresyon-AD Alper Dönmez tarafından tahmini yapılan, Test-EU ve Regresyon-EU Erdem Üçüncü tarafından tahmini yapılan değerleri göstermektedir. Tablo 2’de görüldüğü üzere 140 kullanıcı hikayesi yazılım testi için test yaşam döngüsünün ilk regresyon da dahil olmak üzere tamamlanması için 6 adam-ay(120 gün), 1800 gereksinime sahip sistem testi için test yaşam döngüsünün ilk regresyon da dahil olmak üzere tamamlanması için 3,5 adam-ay(70 gün) olacak şekilde süre tahmini yapılmıştır. Bu testlerin gerçeklenme süreleri sırasıyla 7 ay ve 4 ay sürmüştür. Bu durumda tahminlerin doğruluk oranını hesaplayacak olursak:
Tahmin 1 Doğruluk Oranı = %85 Tahmin 1 Hata Oranı = %15 Tahmin 2 Doğruluk Oranı = %88 Tahmin 2 Hata Oranı = %12 (1) (2) Hesaplanan doğruluk ve hata oranları sonuçları(1,2) firma içerisinde daha önceden karşılaşılan proje süreleri uzamaları ile karşılaştırıldığında kabul edilebilir bir ölçüde olduğundan metriklerin kullanımına devam edilmesi kararı alınabilir. Elimizde metrik olmadan baz alınarak tahmin yapılan kullanıcı hikayesi ve gereksinim sayıları göze alındığında mevcut tecrübelerle de yaklaşık süreler tahmin edilebilirdi. Bu durumda metriklerin kullanımına ihtiyaç olmadığı da düşünülebilir. Metriklerin her proje sonrası güncellenmesiyle ve alan bilgisinde kazanılacak tecrübe ile hesaplanan süre ve gerçek süre arasındaki farkın gittikçe azalacağı tahmin edilmektedir. Metriklerin doğruluk oranları tahmin için yeterli seviyede olsa da yeni projelerde tutulacak metrikler ile sentezlendikten sonra doğruluk payının artması düşünülmektedir. Bu nedenle metriklerin kontrol altında tutulması ve her yeni projede gözden geçirme işleminden sonra gerekli güncellemelerin yapılması gerekmektedir.
Metriklerin önemli bir rol oynadığı görüldüğünde ve metrikler baz alınarak süreç
iyileştirilmek istendiğinde doğru soruların sorulması gerekmektedir. Ama metrik
tutmaya nereden başlamak lazım? Hangi metrikleri tutalım? Ne kadar metrik yeterli?
gibi çok fazla soru mevcuttur. Bu sorular tamamen projeye ve şirketin organizasyonel
yapısına bağlı olarak değişiklik gösterir. O yüzden en basitinden başlamak lazım.
Olabildiğince az, toplaması kolay, gelecekte işimize yarayacak metrikleri seçmek en
efektif başlangıç olacaktır[
Metriklerin tutarlılık seviyesi arttıkça efor tahmini sonucunda oluşacak hata payının düşeceği beklenmektedir. Proje planlamasının düzgün bir şekilde yürütülmesi ve geliştirilmesi için bazı ölçümlemeler olmalıdır. Bu ölçümlerin değişken olabileceğinin unutulmaması gerekmektedir. Bu makalede metriklerden, neden tutulması gerektiğinden ve metrikler üzerinden yapılan bir test efor tahmini çalışmasından bahsedilmiştir. Bahsedilen metrikler efor tahmininde kullanılan anahtar metrikler olup oldukça kolay toplanabilmektedir. Yapılan tahmin ile gerçek süre karşılaştırılmış olup, tahminin doğruluk oranına göre metriklerin geçerli olduğu kararı alınmıştır. Toplanan metrikler üzerinden yazılım test efor tahmininin nasıl daha verimli ve etkili hesaplandığı gösterilmiştir. Metrikleri test sürecinizin bir parçası yapmak istiyorsanız neden metrik tutmalıyız sorusuna verecek cevabınız olmalıdır. Bu makaleye yorumları ve tavsiyelerinden dolayı Ediz ACAR ve Salih ÜNSAL’a teşekkür ederiz.