Yazılım Test Eforunun Kestirimi İçin Öneriler

Günümüzde bilişim sektöründe karşılaşılan başlıca sorunlardan ve kritik işlemlerden bir tanesi de proje büyüklük kestirimidir. Proje büyüklük kestirimi proje başlangıcından önce, proje başlangıcında ve ileri aşamalarında yapılabilen ve projenin ne kadar zamanda ne kadar işgücü ile ve ne kadar masrafla yapılabileceğinin tahmin edilmesi işlemidir. Projenin teklif aşamasında ve/veya planlama aşamasında yapılan kestirimlerin tam olarak proje için doğru yapılamaması projenin başarısızlıkla sonuçlanmasına neden olabilir.

The Standish Group’un araştırmasına göre; projelerin %31’i, projeler tamamlanmadan iptal ediliyor [1]. Ayrıca projelerin %52.7’si orijinal tahminlerinin %189’una mal oluyor. Bu başarısızlıklar ve maliyet aşımları buzdağının sadece görünen tarafı. Kayıp fırsat maliyetleri ölçülebilir değil ama kolaylıkla milyon dolarlara mal olabilmektedir. Projelerin doğru planlanması, gerçekçi beklentiler ve proje kilometretaşlarının doğru planlanması proje başarı oranını %25-%30 etkileyen faktörlerdir. Proje sonunda orijinal tahminden sapmadaki en büyük etkenlerden bir tanesi test eforunun gerçekci bir şekilde tahmin edilmemesidir. Oysa ki test eforu, harcanılan toplam efor içerisinde önemli bir büyüklüğe sahiptir. Capers Jones’un bu konudaki araştırmaları gösteriyor ki, bir projede test eforu, tüm proje eforunun %25-%30’u kadardır [2].

Yazılım projelerinde büyüklük kestirimi sırasında, genellikle yazılım geliştirme süreci için işgücü, zaman ve masraf tahminleri yapılır ve test aktiviteleri göz ardı edilebilir. Birçok zaman test için harcanacak işgücünün hesaplandığı kestirimlerde bile, yapılan kestirim projeye özgü değerler dikkate alınmadan, daha önce geliştirme için yapılan kestirim baz alınarak yapılmaktadır. Daha iyi bir proje büyüklük kestirimi için test aktiviteleri de geliştirme aktiviteleri gibi incelenmelidir. Capers Jones yine bir araştırmasında birçok projeden yararlanarak yazılım test senaryo sayısının kestirimi için bir kural tanımlamıştır [3]. Capers Jones’un kuralına göre test senaryo sayısı aşağıdaki gibi hesaplanır.

Bu formül başlangıç noktası olarak ele alınsa dahi, test aktivitelerinin daha iyi kestirilebilmesi için gerekli kuralları şu şekilde sıralayabiliriz;                                                                                            

1. Kestirim gereksinimlere dayanmalıdır. Kestirim yapılmadan önce neyin test edileceği iyice anlaşılmalıdır. Proje planlama aşamasında gereksinimleri iyice incelenip geliştirme ekibi geliştirme için gerekli işgücünü kestirip proje planını yaptıktan sonra test ekibine dönüp test ne kadar sürer diye sorarlar. Bunun yerine tüm gereksinimler test ekibi tarafından anlaşılmalı ve neyin nasıl test edileceği anlaşıldıktan sonra buna göre test büyüklüğü kestirilmelidir. Proje planı bu kestirimde düşünülerek yapılmalıdır. Test ekibi katılımı olmadan yapılan bir kestim gerçekçi olamaz.
2. Test için gerekli işgücü kestirimi, uzmanlar tarafından yapılmalıdır. Test uzmanı gereksinimleri inceleyip her gereksinimin testi için ne kadar işgücü gerektiğini kestirmelidir. Test uzmanı gereksinimleri inceler ve bazı kategorilere ayırır, bunlar;
   1. Kritik: Geliştirici ekibi gereksinimin gerçekleşmesi hakkında çok az bir bilgiye sahip olduğu gereksinimler.
   2. Yüksek Riskli: Geliştirici ekip gereksinimin gerçekleşmesi hakkında yeterli bilgiye sahip fakat gerçekleşmesi zor olan gereksinimler.
   3. Düşük Riskli: Geliştirici ekip gereksinimin gerçekleşmesi hakkında yeterli bilgiye sahip ve gerçekleşmesi kolay olan gereksinimler.

Test uzmanı gereksinimleri inceler, bu kategorilerden birine yerleştirir ve gereksinimin testi için ne kadar işgücü gerektiğini kestirir. Bu kategoriler test aktivitesinin büyüklüğünün kestirilmesi için yardım etmektedir.

3. Kestirim daha önce bitirilmiş projelere göre yapılmalıdır. Proje büyüklük kestirim yöntemlerinde olduğu gibi test aktivitelerinin büyüklük kestirimi de önceden bitirilmiş projelerin test aktivitelerinin büyüklüklerine dayanarak kestirilmelidir.
4. Bütün kararlar kayıt altına alınmalıdır. Bu test aktivitelerinin başarısı için çok önemlidir. Süreç içerisinde gereksinimlerde yaşanabilecek olası değişikliklerde daha önceden alınan kararların kayıtları test aktivitelerinin kolay bir şekilde tekrar kestirilmesini sağlar. Aynı şekilde test aktivitesi sırasında oluşan durumların ve alınan kararların kayıt altına alınması sonraki projelerde yapılan kestirimlerin başarısını arttıracaktır.
5. Kestirim bir araçla desteklenmelidir. Metriklerin tutulabileceği tablolar, otomatik kestirim yapan araçlar kullanılabilir. Ayrıca Masraf tabloları, risk tabloları alınan kararlarla ilgili notlar vb. saklanması için de bazı araçlar kullanılabilir.
6. Yapılan kestirim doğrulanmalıdır. Yapılan kestirim önceki projeler için yapılan kestirimlerle karşılaştırılmalıdır. Benzer projeler için yapılan kestirimler ile yapılan kestirim arasında önemli bir farklılık hissedilir ise kestirim yeniden yapılabilir.

Burcu Karaömer - [email protected]

[1]       The Chaos Report, The Standish Group International, 1995.

[2]       Software Cost Estimating Methods for Large Projects, Capers Jones, Software Productivity Report, LLC

[3]       SOFTWARE ESTIMATING RULES OF THUMB, Capers Jones, Version 3, 2007