Özet. Bu çalışmada özel bir bankanın yazılım proje yöneticilerine yönelik olarak, kodlama ve birim testleri tamamlanan yazılım birimlerinin fonksiyonel testleri için gerekecek test süresi/eforunu tahmin ederlerken kullanabilecekleri özgün bir yöntem geliştirilmesi amaçlanmıştır. PTP-Vision adı verilen bu yöntem ile, bir test analistine atanan her bir yazılım birimi için gerekecek test çalıştırma kişisel eforunun (dolayısıyla süresini) test sürecinin ön safhalarında iken doğru bir şekilde tahmin edilebilmesi sağlanmıştır. Geliştirilen yöntemin temelinde, test analistinin kendi kişisel test sürecini Humphrey'in Kişisel Yazılım Süreci'nde (Personal Software Process - PSP) tanımlandığı gibi modelleyerek ölçümlemesi ve bu ölçümlerin analizi suretiyle kişisel tahmin veritabanını oluşturması bulunmaktadır. Bu yöntemin geliştirme ve sınama çalışmaları için bankanın yazılım uygulamalarından elde edilen gerçek veriler kullanılmıştır. Geliştirilen yöntemin çalışabilirliği ve hassasiyeti test sürecinin ön safhalarında yapılan tahminler ile gerçekleşen efor/süre değerleri karşılaştırılmak suretiyle değerlendirilmiştir. Ortam ve uygulama ile ilgili belli parametrelerin aynı kalması durumunda tahmin hatalarının %12 bandını aşmadığı, çoğunlukla çok daha küçük olduğu görülmüştür. Anahtar Kelimeler: Test süresi tahmini, Test eforu tahmini, Proxy-tabanlı tahmin, Kişisel test süreci, Bankacılık yazılım uygulamaları.
method allows the project manager to predict the required test run effort (hence duration) of a test analyst for an assigned software unit at the initial test stages. On the basis, the test analyst models and measures her personal test process (PTP) as described in Humphrey's Personal Software Process (or PSP) and generate a personal estimation database by analyzing these measurements. For the development and testing of this method, real data from the bank's software development projects were used. The feasibility and sensitivity of the developed method were evaluated by comparing the estimations made at the earlier stages of the test process with the actual values of test effort. It has been found that if certain parameters related to environment and application remain stable, prediction errors do not exceed 12% band, and in most cases much smaller. 1
Proje yöneticileri açısından yazılım test faaliyetleri için harcanacak zaman ve eforun doğru ve tutarlı bir şekilde tahmini oldukça önemlidir. Gerçekleşen değerlerin tahmin edilen değerler ile örtüşmemesi projenin ciddi manada başarısız olmasına sebep olabilir. Örneğin geçmişte Denver Havaalanı Otomatik Bagaj Sistemi Projesi’ndeki öngörülemeyen gecikmenin maliyetinin 340 milyon doları bulduğu hesaplanmıştır [1]. Bu bağlamda, eldeki belli kaynaklar ile test için ayrılacak süre hakkında tutarlı bir tahmin yapabilme önemli yönetim işlevlerinden birisi olmasına rağmen bunu başarabilmek özellikle erken safhalarda kolay değildir. Yazılım test süresinin projenin diğer planlama parametreleriyle karmaşık alakası dolayısıyla, proje yöneticisinin karar verme mekanizmalarını destekleyecek yöntem ve araçlara ihtiyaç duyulmaktadır.
Forrester Research şirketinin dünya çapında yaptığı araştırmaya göre [2] finans sektöründeki kuruluşların yazılım giderleri diğer sektörlere göre daha fazladır, dolayısıyla test süresine yönelik etkin bir tahmin metodu bu maliyetlerin kontrolünde katkı sağlayacaktır. İş birliği yaptığımız özel bankanın yazılım merkezinde yaşanan problem proje yöneticileri tarafından test analistlerine atanan test işleri – test projesi olarak adlandırılmaktadır– için başlangıçta uzman görüşüne bağlı olarak belirlenen sürelerin gerçekçi olmaması ve sürekli uzatılmak zorunda kalınmasıdır. Bu problemin çözümüne yönelik olarak üniversite-sanayi iş birliği ile test süreci iyileştirme çalışması yapılmıştır.
Literatüre bakıldığında test süresinin tahmini için yapılmış çalışmaların bankanın probleminin çözümü için yetersiz kaldığı görülmüştür. Burada test analistinin kişisel bazda ihtiyaç duyacağı süreyi daha test analiz ve tasarım safhasında iken tutarlı bir şekilde tahmin edebilmesi ve gecikmeden ek süre gereksinimini proje yöneticisine bildirebilmesi hedeflenmiştir.
İkinci bölümde test süresi tahmini için mevcut yöntemler incelenmiştir. Üçüncü bölümde bankada uygulanan test süreci anlatılmıştır. Dördüncü bölümde Kişisel Yazılım Süreci ve Proxy Tabanlı Tahmin Yöntemi ile ilgili bilgi verilmiştir. Beşinci bölümde geliştirilen Proxy tabanlı tahmin yöntemi tanımlanmıştır. Altıncı ve son bölümde ise yapılan pilot çalışma ve çalışmanın sonuçlarına yer verilmiştir.
İlgili Çalışmalar Literatürde yazılım testi eforu tahmini alanında yapılmış çalışmaların genellikle yazılım geliştirme eforu tahmin yöntemleri uyarlanarak türetilmiş olduğu görülmüştür. Jayakumar ve Abran [3] yazılım testi eforu tahmin etmeye yönelik metotları beş ana grupta toplamaktadır: Uzman görüşüne dayalı yöntemler, Analoji ve iş kırılım yöntemleri, Faktör ve Ağırlık tabanlı yöntemler, Yazılım Büyüklüğüne dayalı yöntemler, Bulanık mantık ve diğer modellere dayalı yöntemler.
M. Chemuturi [4] yazılım testi eforunu tahmin etmek için uzman görüşüne dayalı olan Delfi Metodunu test efor tahmini için uyarlamıştır. Geniş Bant Delfi ve Başparmak Kuralı da benzeri diğer yöntemlerdir.
Yapılan diğer bir çalışmada, yazılım eforu tahmini için yaygın kullanıma sahip olan
İşlev Noktası Analiz Yöntemine dayalı olarak Test Noktası Analiz Yöntemi [
Nageswaran Kullanım Noktaları yöntemini geliştirmiştir [
Analoji Tabanlı Kestirim yöntemi ile organizasyonlarda gerçekleşmiş birbirine benzer olan projelerden elde edilen veriler vasıtasıyla yazılım testi efor tahmini yapılmaktadır [4]. Chemuturi yaptığı diğer çalışmalarda bu yönteme benzer olan Görev Tabanlı Tahmin ve Test Senaryosu Sayma Tabanlı Tahmin Yöntemlerini geliştirmiştir. Matematiksel olarak bu yöntemler ile edilen sonuçlar doğrulanabilirdir. Ancak testin ilk safhalarında büyüklük hesaplanamamaktadır ve tahmin yapma süresi uzundur [4].
Yazılım büyüklüğüne dayalı tahmin yöntemleri olan Test Büyüklüğüne Dayalı Tahmin, COCOMO ve Slim, Seer and Knowledge Plan gibi yöntemler gerçeğe yakın sonuç üretebilmekte olup ve farklı organizasyonlarda yapılan tahminlerin birbiri ile kıyaslanmasına olanak tanımaktadır [3]. Literatürde bu yöntemler dışında bulanık mantık ve yapay sinir ağları yaklaşımlarına dayalı olarak geliştirilen yöntemlere rastlanmıştır. 3
Test faaliyetleri bu çalışmanın yapıldığı bankada V Modeline uygun olarak
gerçekleşmektedir. Modelin sağ tarafında yer alan aktiviteler sol tarafında yer alan aktivitelerin
çıktılarını doğrulamakta veya geçerlemektedir [
Bankanın test süreci dışarıdan alınan bir danışmanlık sonucunda tanımlanan sürece
ve kullanılan yazılım yaşam döngüsü otomasyon araçlarına bağlı olarak [12]’ye göre
tanımlanmıştır:
1. Test Planlama ve Kontrol – Proje planlaması ile aynı anda gerçekleşir ve test kapanış
işlemleri tamamlanana kadar devam eder. Test Yöneticisi tarafından yürütülmekte
olup, bu safhada Test Analistinin aktif rolü bulunmamaktadır.
2. Test Analizi ve Tasarımı – Yazılımcı birim testleri ile paralel yürütülür ve genel test
hedefleri somut test koşullarına ve test senaryolarına dönüştürülür [
Test Analistlerinin bu safhada, İhtiyaç Analiz Dokümanında yer alan girdiler,
olaylar veya aksiyonlar ile bunların sonucunda oluşması beklenenlerin
gerçekleştirilmesi için gerekli adımların açıklandığı dokümantasyonu [15] hazırlamaları
gerekmektedir. Bir test senaryosu aşağıdaki bilgileri içermelidir:
• Seviye: Test senaryosunu önceliklendirmek için kullanılan değer. Örneğin 7.4.
• Test Adımı: Test senaryosunun gerçekleştirilmesi için gerekli adımlar. Test
nesnesinin analizine, özelliklerine, davranışına ve yazılımın yapısına dayanmalıdır.
Örneğin, Kullanıcıya DYBDXXX yetkisi verilmez + Birimi ilgili işlem
referansını almaya yetkili olur + Yeni referans alma yetkisi verilir + İşlem Tipi
Tanımlama Ekranında tanımlı olan bir referansı alır.
• Doğruluk Kriteri: Bir test nesnesinin (fonksiyon) veya özelliğin başarılı veya
başarısız olup olmadığını belirlemek için kullanılan karar verme kurallarıdır.
Örneğin, B. D. Ekranı / D. R. İşlemleri referansı alamadığı görülür.
• Case Özelliği: Pozitif veya negatif olarak iki değerden birini alabilir. Pozitif
olması durumunda test senaryosu sonunda başarılı bir işlem gerçekleşmiş, negatif
olması durumunda ise başarısız bir işlem gerçekleşmiş olması beklenir. Örneğin,
Pozitif.
3. Test Uyarlama ve Yürütme/Çalıştırma – Yazılımcının birim testlerini tamamlanması
ile başlar ve test çıkış kriterleri karşılanana kadar devam eder. Test Uyarlaması
testlerin çalıştırılmaya hazırlanmasını, test verilerinin ve test senaryosunun yürütülmeye
başlayabilmesi için test ortamının nihai hale getirilmesini, test senaryolarını
desteklemek için test verisi belirlenmesini ve kaynak tahsisini içeren test çalıştırma
çizelgesinin hazırlanmasını kapsar [
Yazılım geliştirme projelerinde çalışan kişilerin yetenek ve çalışma disiplinleri kaliteli
ürün ortaya koyabilmek için büyük önem arz etmektedir. Watts S. Humphrey, PSP
(Personel Software Process - Bireysel Yazılım Geliştirme Süreci) konusundaki
çalışmaları ile kişisel çalışma sonuçlarını iyileştirmek için tanımlanmış bir süreci izleyerek
disiplin içinde yazılım geliştirmeyi sağlayan bir çerçeve sunar [
PSP kullanan yazılım geliştiricileri bireysel yazılım geliştirme süreçlerinin
performansını topladıkları ölçümlere (büyüklük, geliştirme süresi, hata sayısı gibi) dayalı
olarak analiz edebilirler. Buna bağlı olarak kendi geliştirme süreçlerini iyileştirebilir ve
geliştirme işleriyle ilgili Proxy tabanlı kestirim yöntemi (PROBE - Proxy Based
Estimating Method) ile hassas tahminler yapabilirler [
Bu çalışmada bankada çalışan bir test analistinin kişisel test çalıştırma süresinin testin analiz ve tasarım safhasında iken öngörülebilmesi (tahmin edilebilmesi) hedeflenmektedir. Kişisel Yazılım Süreci (PSP) ve PROBE Yöntemi test sürecine uyarlanarak yeni bir kişisel test çalıştırma süresi tahmin metodu oluşturulmuştur.
Ölçümlerin sağlıklı yapılabilmesi için PSP’nin yazılım geliştirme süreci için önermekte olduğu Süre Kayıt Etme Formu (Time Recording Log) test sürecine uyarlanmıştır. Test Analisti bu formu kullanarak her bir bileşenle ilgili harcadığı süreleri kendisine atanan test projeleri için kayıt altına almaktadır.
Test analistlerinin test çalıştırma safhasındaki faaliyetleri izlenmiş ve her bir test projesinde toplam sürenin/eforun aşağıdaki faaliyetlerden/sürelerden oluştuğu tespit edilmiştir: • İdeal şartlarda test çalıştırma süresi – Test analistinin test nesnesine ait test için bulgu çıkmadığı ve bilgi gereksinimi olmadığı bir durumda harcadığı süredir. • Test çalıştırma süresi – Bir test senaryosunun çalıştırıldığı toplam süredir. Yazılımcı tarafından bulgunun düzeltilme süresini ve geri gönderilmesi akabinde yeniden test edilme süresini de içerisinde barındırmaktadır Bu süre, Test Süresi Kayıt Formunda <Test> olarak işlenmektedir. Bir bulgu tespit edildiği zaman testin doğruluğundan emin olmak için test dokümanlarının yeniden incelenmesi, bulguların raporlanması, bilgi alışverişi ve mailleşmeler de – test nesnesine ilişkin bilgi edinme gereksinimi çıkması durumu olarak adlandırılmaktadır. • Bulgu düzeltme süresi – Bulgu çıkması durumunda yazılımcının ilgili test senaryosunda çıkan bulguya ne kadar zamanda döndüğünü gösteren süredir. Bu süre bulgu raporlandıktan yani yazılımcının eline ulaştıktan sonra başlatılmaktadır. Bu süre, Test Süresi Kayıt Formuna <Bulgu> olarak işlenmektedir. • Yeniden test etme süresi – Düzeltilen bulgu ile ilgili senaryonun yeniden test edildiği süredir. Bu süre, Test Süresi Kayıt Formuna <Re-test> olarak işlenmektedir. • Kayıplar – Test çalıştırılırken yazılım ve analist ekipleri ile yapılan bilgi alışverişleri, mailleşmeler, bulgu raporlanması kayıp süre olarak değerlendirilmektedir.
Bu çalışmada her bir projenin tek bir yazılımcısı olduğu varsayılmaktadır. Test Süresi Kayıt Formu her bir yazılımcı ve proje için ayrı tutulmakta ve her bir test senaryosu için süreler ilgili forma kayıt edilmektedir. 5.2
İdeal Şartlarda Test Çalıştırma Süresinin Tahmini
Bu sürenin tahmini için Humphrey’in PROBE yöntemi [
Kategori Eşleşme (MK) Birlikte Çalışabilirlik (BC) Ekran Tasarımı (ET) Ekran Fonksiyonları (EF) Çıktıların Kontrolü (ÇK) Uyarı ve Hata Mesajları (UHM)
Test Süresi Kayıt Formu kullanılarak 18 projeye ilişkin 1598 adet test senaryosunun (126 adet Eşleşme, 560 adet Birlikte Çalışabilirlik, 86 adet Ekran Tasarımı, 244 adet Ekran Fonksiyonu, 91 adet Çıktıların Kontrolü, 222 adet Uyarı ve Hata Mesajları) çalıştırma süreleri toplanmıştır. Akabinde her bir kategoride yer alan ölçüm sonuçları tespit edilmiştir. Kategori bazında toplanan ölçüm sonuçlarının dağılımı analiz edilerek test senaryo büyüklüklerinin Küçük (S), Orta (M) ve Büyük (L) olmak üzere 3 kategoriye ayrılmasına karar verilmiştir.
Toplanan ölçüm sonuçlarının istatistiksel ortalama değer ve standart sapmasının hesaplanması vasıtası ile her bir kategoride yer alan Tablo 1’de verilen Tahmin Veritabanı elde edilmiştir.
Geçmişe yönelik olarak toplanmış verilerin analiz edilmesi ile elde edilen Tahmin Veritabanı kullanılarak, yeni gelen bir projenin İdeal Şartlarda Test Çalıştırma Süresinin (P) tahmin edilebilmesi hedeflenmektedir. Bu doğrultuda her bir (S) senaryosunun tipi (x) ve büyüklük kategorisi (y) belirlenir, hangi kategoriye girdiği belirlenen senaryonun tahmini çalıştırılma süresi Tahmin Veritabanından bulunur. Bu işlem projedeki tüm senaryolar (n adet senaryo) için tekrarlanır. İdeal Şartlarda Test Çalıştırma Süresi (P) aşağıdaki gibi ifade edilmektedir:
P = ()*+ S(x, y)
Test çalıştırma süresi test senaryoları hazırlandıktan sonra tahmin edilebileceği gibi bazı durumlarda ise test senaryoları hazırlanmasının bir adım öncesinde yani ihtiyaç analiz dokümanı incelenirken öngörülmesi ihtiyacı doğmaktadır. Bu durumlarda test analisti ihtiyaç analiz dokümanını incelerken kontrolü yapılacak durumları imgeleyerek de tahmin yapabilmektedir. İmgeleyerek yapılan tahminlerde de test senaryoları üzerinden tahmin yaparken izlenen aynı adımlar takip edilmektedir.
Tablo 2. Proje Bazında Bulgu Adetleri ve Ortalama Bulgu Düzeltme Süreleri Proje Proje 1 Proje 2 Proje 3 Proje 4 Proje 5 Proje 6 Proje 7 Proje 8 Proje 9
Yazılımcı
Bulgu
Adedi Test çalıştırma süresi, yazılımcı tarafından bulgunun düzeltilme süresini ve geri gönderilmesi akabinde yeniden test edilme süresini de içerisinde barındırmaktadır.
Tespit edilen bulguların düzeltme sürelerinin test çalıştırma süresine etkisinin tespit edilebilmesi için, bu çalışmada 18 tane test projesine ait tespit edilen bulguların düzeltme süreleri kullanılmıştır (Tablo 2.) Bahsi geçen her bir projenin tek bir yazılımcısı vardır. Geliştirilmekte olan model için de her bir projenin tek bir yazılımcısı olduğu varsayımında bulunulmuştur. Çalışmada 18 proje için 7 farklı yazılımcı ile çalışılmıştır.
Gözlemlenen değerlerden, yazılımcıların Tablo 3’deki bulgu yoğunlukları ve ortalama bulguya dönüş süreleri çıkarılmıştır. Bulgular düzeltilip test analistine döndükten sonra yapılan düzeltmelerin başarısını doğrulamak için ilgili test senaryolarının tekrardan çalıştırılması (re-test) gerekmektedir. Yazılımcının bulgu yoğunluğu oranında, yeniden test etme süresine ihtiyaç duyduğu varsayılmıştır. Düzenleme yapıldıktan sonra koşulan test senaryolarından da m% oranında bulgu çıkabileceği ve bulgu çıkma oranının 0.001’e yakınsayana kadar t iterasyon boyunca gerçekleyebileceği farz edilmiştir. 1
Yeniden Test Etme Süresi (R) = )*+ λ ∗ P ∗ (0/++)) Çalışmada kayıt altına alınan senaryo başına yeniden test etme adetleri proje bazında değerlendirilerek, yapılmakta olan çalışmada düzeltme yapılan senaryolardan %10 oranında (m=10) yeniden test etme ihtiyacı tespit edilmiştir.
Yukarıda bahsedilen sürelere ek olarak, Kayıplar olarak tabir edilen sürelerin Test Çalıştırma Süresine katkısı için sabit bir değer (K) vermek yerine, ideal şartlarda test çalıştırma süreleri dikkate alınmıştır. Bu çerçevede, ideal şartlardaki test çalıştırma sürelerinin [P] dağılımına göre kategoriye ayrılmış ve her bir kategori için K değerinin katkısı olmadan hesaplanan test yürütme süresi [P+B+R] ve Gerçek Test Yürütme sürelerinden de K değerleri hesaplanmıştır.
Yapılan çalışmada, Tablo 2’de verilmekte olan 18 proje için ideal şartlardaki test çalıştırma sürelerinin dağılımı incelendiğinde üç gruba ayrılabileceği öngörülmüştür. Tablo 3. Yazılımcı Bulgu yoğunluğu ve ortalama bulgu düzeltme süresi
Yazılımcı
Bulgu Yoğunluğu (%)
Bulguya Dönüş Süresi (saat) Yazılımcı-1 Yazılımcı-2 Yazılımcı-3 Yazılımcı-4 Yazılımcı-5 Yazılımcı-6 Yazılımcı-7 Bu doğrultuda elde edilen K değerleri aşağıdaki gibidir; • K=01,29 saat eğer P < 3,50 saat • K=14,57 saat eğer 3,50 < P < 13,28 saat • K=27,84 saat eğer P > 13,28 saat
K değerleri 18 proje için elde edilmiş değerlerdir, toplanan verinin artması ile bu değer değişecek olup iyileşeceği düşünülmektedir.
Tablo 4’de Gerçek Test Yürütme Süresi, test analistinin Bankacılık Veritabanına her bir yazılım testi projesi için girmiş olduğu aktivite bilgilerinden alınmaktadır. Söz konusu süre sadece test faaliyetlerinin yapıldığı zamanı yansıtmaktadır. Proje sürecinde yer alan test analistinin eğitimlerini, izinlerini, molalarını vb. içermemektedir.
Yukarıda bahsedildiği gibi birbirini takip eden adımlardan oluşan ve paralelde başka bir iş için efor sarf edilmediği varsayıldığında, Tahmini Test Çalıştırma Süresi (T) aşağıdaki gibi elde edilmektedir: 1
T= 32*+ S(x, y) + λ * q * n + )*+ λ ∗ P ∗ (0/++)) + K
Tablo 4’de, geçmişe yönelik ölçümlerin elde ettiğimiz modele yerleştirilmesi sonucunda her bir proje için elde edilen Tahmini Test Çalıştırma Süreleri verilmektedir. Tabloda verilmekte olan sonuçlar analiz edildiğinde tahmin edilen ve gerçek süreler arasında genelde doğrusal bir ilişkinin olduğu görülmektedir (Şekil 1.) 11 No’lu proje değerlendirme dışı tutulduğunda tahmini ve gerçek süreler arasındaki ortalama bağıl hata %6,27 olarak bulunmuştur. Bu çerçevede bakıldığında, incelenen çalışma için model üzerinde oluşturulan tahminlerin gerçek süreler ile örtüştüğü gözlenmektedir.
Proje 11’in sıradışı durumu ayrıca incelenmiştir. Yazılımcı bulguları geç düzelttiği için test analistinin projeye ara verdiği ve başka bir iş aldığı anlaşılmıştır. Geliştirilen modelde test analistinin sadece tek bir proje ile ilgilendiği varsayımında bulunulmasından dolayı K değeri eklenmeden hesaplanan test çalıştırma süresinin, gerçek test çalıştırma süresinden büyük olduğu gözlenmektedir. Yazılımcının bulguya dönüş süresinin ortalamanın çok dışında olmasının hatalara yol açtığı sonucuna varılmıştır. Proje Adı Proje-01 Proje-02 Proje-03 Proje-04 Proje-05 Proje-06 Proje-07 Proje-08 Proje-09 Proje-10 Proje-11 Proje-12 Proje-13 Proje-14 Proje-15 Proje-16 Proje-17 Proje-18 posta gönderimlerinin banka çalışanları tarafından raporlanabilmesi amacı ile, mevcut e-posta verilerinin raporlanabilir ortama aktarılması sağlanacaktır. Test projesi kapsamında ise bu proje kapsamında tüm mevcut ve güncel e-posta verilerinin raporlanabilir ortama aktarımının doğru bir şekilde tamamlandığı test edilecektir.
Testi yapılacak olan projenin gereksinimleri İhtiyaç Analizi Dokümanında aşağıdaki gibi tanımlanmıştır: • E-posta gönderimlerinin raporlanabilir ortama taşınması için gerekli tablo yapısının ve veri taşıma yöntemlerinin geliştirilmesi gerekmektedir. • E-posta gönderimlerine ait verilerin Mars (Bankacılık Veritabanında e-posta kayıtları ile müşteri ilişkisini sağlayan özgün bir değer) ile ilişkili olarak tutulması için Mars bilgisinin mevcut tablo yapılarına eklenmesi gerekmektedir.
Bu çerçevede bakıldığı zaman iki farklı sunucuda bulunan güncel verilerin tutulduğu 8 tabloya ve mevcut verilerin tutulduğu 5 tabloya ait toplamda 116 veri sahasının doğru şekilde aktarılması beklenmektedir. Aktarımı sağlayacak olan 5 farklı program bileşeni çalıştırılacaktır. Bu sahalardan 2 tanesi (biri güncel veri için diğeri de mevcut veri için) Mars bilgisini tutmak için kullanılacak olup kontrolleri için farklı program bileşenlerinin çalıştırılması ve farklı tabloların kontrol edilmesi gereksinimi doğmaktadır. Şekil 1. Tahmini ve Gerçek Test Çalıştırma Süreleri Aktarımın testi ile ilgili olarak; • Çalıştırılacak olan 5 program bileşeninin doğru çalıştığının kontrol edilmesi için birlikte çalışabilirlik kontrolü yapılacaktır. Bu kontrollerin büyüklüğünün L(büyük) olacağı öngörülmektedir:
5 * S(BC, L) • 116 sahanın doğru beslendiğinin görülmesi için eşleşme kontrolü yapılacaktır, bu sahalardan iki tanesinin kontrolü için farklı tabloların da kontrolüne ihtiyaç duyulduğu için büyüklüğünün L (büyük) olacağı öngörülmektedir. Kalan sahalardan 44 tanesi için büyüklüğü M (orta) olacağı düşünülmektedir, geriye kalan 70 sahanın kontrolünün ise S (küçük) büyüklüğünde olması beklenmektedir: 2 * S(MK, L), 44 * S(MK, M), 70 * S(MK, S)
Toplamda 119 kontrol yapılmakta olup buradan testin senaryo sayısının da 119 olabileceği tespit edilmiştir. Tahmin Veritabanı kullanılarak ideal şartlarda test çalıştırma süresi 26,54 saat olarak hesaplanmaktadır.
Projenin geliştiricisi Yazılımcı-7’dir. Yazılımcı-7’nin bulgu yoğunluğu ve bulgu düzeltme süresi kullanılarak, bulgu düzeltme süresi 14,06 saat olarak ve yeniden test etme süresi 54,53 saat olarak hesaplanmıştır.
Elde edilen değerlerin toplanması ile Test Analistinin bahsedilen projeyi 71,27 saatte yani günde 8 saat çalışarak yaklaşık 9 iş gününde bitirmesi öngörülmektedir. Test Analistinin Bankacılık Veritabanına girmiş olduğu gerçekleşen aktivite süreleri incelendiğinde projeyi toplam 84 saatte ve 10,5 iş gününde bitirmiş olduğu görülmüştür.
Pilot çalışmada test çalıştırma süresinin %84,85 doğrulukta tahmin edilebildiği gözlemlenmiştir. Her yeni projenin sağladığı veriler sayesinde gelişme yaşayan Tahmin Veritabanının sağlam bir temele oturması beklenmektedir. Dolayısı ile test çalıştırma süresi tahminindeki hatanın azalacağı düşünülmektedir.
Bu çalışma kapsamında Watts Humphrey’in PSP ve PROXY tahmin yönteminden esinlenilmiştir. Özel bir bankada çalışan test analistlerinin kişisel test süreci modellenmiş ve geçmiş test projelerinden toplanan test süreci verilerinden bir tahmin veritabanı oluşturulmuştur. Geliştirilen proxy tabanlı PTP-Vision yöntemi pilot projeye uygulanarak test çalıştırma süresi tahmin edilmiştir. Veritabanının oluşturulması sırasında ve pilot çalışmadan elde edilen sonuçlar tahmin ve gerçekleşme süresinin büyük oranda tutarlı olması (%84,85), geliştirilen yöntemin belirli bir alanda belirli bir yazılımcı kümesi ile çalışan ve test proje büyüklükleri birbirine yakın olan durumlarda bir test analisti için uygulanabilir ve gerçekçi olduğunu göstermektedir.
Test analistinin kişisel süreci için model üzerinden yapacağı tahminlerin gerçek sonuçlar ile örtüşmesi beklenmektedir. Ancak sonuçların her duruma genelleştirilebilmesi şu an için mümkün değildir. Yukarıda belirtildiği gibi tahmin veritabanında yer alan değerler o ana kadar toplanan değerlerden oluşmakta olup, nihai değerler değildir. Yeni projelere ait ölçüm sonuçlarının toplanması durumunda bu değerler değişecektir. Şu an için her yeni proje için elde edilen ölçüm sonuçlarının daha iyi tahmin sonuçları verip veremeyeceğine yönelik bir hata analizi yapılmamıştır. Bunun için çok daha uzun bir süre ve banka yazılım merkezi genelinde bir çalışmanın yapılmasına ihtiyaç vardır. Ancak eldeki bulgulara dayalı olarak ölçüm sonuçları çoğaldıkça Kişisel Tahmin Veritabanının sağlamlaşacağı ve tutarlı tahminler vereceği beklenmektedir.
Bankacılık yazılımları sektöründe zaman önemli bir kısıt olduğu için yöntemin farklı
alanda çalışan (mobil, özel projeler, nakit yönetimi, krediler vb.) birçok test analistine
yaygınlaştırılması aşamasında test analistlerinin kendi süreçlerini izlemeleri ve
verilerini bizim gibi kağıt ortamında kayıt altına almaları zor olacaktır. PSP’de veri toplamayı
kolaylaştıran bir kısım araçlar [
Çalışmanın devamında genel istatistik yöntemleri yerine Geri Yayılma Algoritması (Backpropagation) kullanılarak ölçümlerin Tahmin Veritabanını beslemesinin sağlanması amaçlanmaktadır. Geri yayılım algoritması hataları geriye doğru çıkıştan girişe azaltmaya çalışmaktadır. Böylelikle yeni projeye ait ölçüm sonuçları ile Tahmin Veritabanının iyileşip iyileşmediği tespit edilebilecektir. İyileştiren değerlerin Tahmin Veritabanına beslenmesi yolu ile veritabanının sağlamlaştırılması hedeflenmektedir.