=Paper=
{{Paper
|id=None
|storemode=property
|title=Yazılım Test Sürecinde Problemler ve Çözüm Önerileri
|pdfUrl=https://ceur-ws.org/Vol-1072/submission39.pdf
|volume=Vol-1072
|dblpUrl=https://dblp.org/rec/conf/uyms/SahinogluSKKO13
}}
==Yazılım Test Sürecinde Problemler ve Çözüm Önerileri==
https://ceur-ws.org/Vol-1072/submission39.pdf
Yazılım Test Sürecinde Problemler ve Çözüm Önerileri
Mehmet ġAHĠNOĞLU, Mustafa SARI, AyĢegül KURT, Salih KURNAZ, Mehmet
ÖZBEK,
1
Yazılım Test ve Kalite Değerlendirme Merkezi, TÜBĠTAK BĠLGEM, Gebze, Kocaeli
{mehmet.sahinoglu, mustafa.sari, aysegul.kurt, salih.kurnaz,
mehmet.ozbek}@tubitak.gov.tr
Özet. Günümüzde, farklı sektörlerdeki ihtiyaçlar için farklı yazılım ürünleri ge-
liĢtirilmektedir. Yazılım geliĢtirme sürecinin önemli bir aĢaması da yazılım test
sürecidir. Yazılım testleri ürün kalitesinin yükseltilmesi ve müĢteri memnuniye-
tinin artırılması için kritik öneme sahiptir. Test sürecinin baĢarısı doğrudan pro-
jenin baĢarısını etkilemektedir. Yazılımlardaki çok küçük hatalar dahi can, mal
kayıplarına neden olabilecek kritik sonuçlara sebebiyet verebilir. Bu sebepler-
den dolayı yazılım test sürecinin etkili ve verimli geçmesi projenin istenen he-
deflere ulaĢmasında büyük öneme sahiptir.
Bu çalıĢmada test süreçlerinde karĢılaĢılan problemler belirli gruplarda toplana-
rak, bu problemlere neden olan sebepler ve bu problemler için önerilen çözüm
önerileri anlatılmıĢtır. KarĢılaĢılan problemler; planlama ile ilgili problemler,
yönetimsel problemler, gereksinimler ile ilgili problemler, düĢünsel problemler,
paydaĢlar arasındaki problemler ve genel test problemleri olarak gruplandırıla-
bilir. Bu gruplar altında toplanan problemlerin sebepleri belirtilerek, çözüm yol-
ları önerilmiĢtir.
Anahtar Kelimeler. Yazılım Test Süreci, Proje YaĢam Döngüsü, Test Sürecin-
de Problemler
1 Giriş
Yazılımın doğrulanması ve geçerlenmesi süreci, birçok alt faaliyetten oluĢur. Bu faa-
liyetlerden biri proje yaĢam döngüsü süreçlerinin sonunda meydana gelen çıktıların
doğru, tam, tutarlı ve açık olduğunun doğrulanmasıdır.
Bir diğer faaliyet ürünün teknik yeterliliğinin değerlendirilmesi ve uygun sonuçlar
elde edilene kadar bu aktivitelere devam edilmesidir.
Doğrulama süreci, geliĢtirilen yazılımın kendisinden beklenen davranıĢları gerçek-
leĢtirdiğini ve istenmeyen davranıĢları göstermediğini ortaya koyan süreçtir. GeliĢtiri-
len yazılımın, gereksinimleri tam olarak karĢıladığı ve geliĢtirmenin her evresindeki
çıktıların doğru olduğuna karar verilmesi gerekir. Doğrulama sürecinin, ürünün ku-
sursuz olarak çalıĢmasına katkısı büyük olduğundan, yazılım geliĢtirmede en önemli
süreçlerden birisidir [1].
Doğrulama sürecinin temel amacı, kalitesi yüksek ürün üretebilmektedir. Doğru-
lama geçerleme sürecinin mümkün oldukça projelerin erken evrelerinde baĢlatılması
olası problemlerin önünü kesme veya çözümünün daha erkene alınmasına yardımcı
olacaktır [1].
Geçerleme süreci, yazılımın tam olduğunu ve kendi içinde tutarlı olduğunu göste-
ren bir süreçtir. Proje sırasında iĢ adımları ve ara çıktılar gözden geçirilip bunların
kabul edilebilir olduğundan emin olunur.
Yazılımın tutarlılığını, bütünlüğünü ve doğruluğunu göstermek için yazılım geliĢ-
tirme yaĢam döngüsü aĢamasında ve aĢamaların her birinin arasında geçerleme süreci
uygulanır. Ayrıca geçerleme süreci yazılım geliĢtirme esnasında eğitimler, standartlar,
gözden geçirme ve yorumlar, geri bildirimler, kontrol listelerine göre denetimlerin
yapılması gibi aĢamalarla gerçekleĢtirilir [2].
Yazılım test faaliyetleri doğrulama ve geçerleme süreci içerisindeki alt aktiviteler
arasında önemli aktivitelerdir.
Yazılım test sürecinin olmadığı ya da eksik olduğu durumlarda yaĢanabilecek ne-
gatif durumlar; proje yönetimi ile ilgili problemler, test yönetimi ile ilgili problemler,
düĢünsel problemler ile ilgili problemler olarak genel baĢlıklarla toplanabilir. Bu ça-
lıĢma kapsamında belirtilen genel durumlar detaylı bir Ģekilde ele alınacaktır.
2 Proje Yönetimi ile ilgili Problemler ve Çözüm Önerileri
2.1 Proje Planlaması
Yazılım projelerinde proje özelliklerine, ihtiyaçlarına, hedeflerine uygun olarak belir-
lenen yazılım geliĢtirme yaĢam döngüsü seçimi ve bu yaĢam döngüsü aĢamalarının
amaçlarının belirlenmesi, bu aĢamalarda yapılması gereken faaliyetlerin ve bu faali-
yetlerin çıktılarının belirlenmesi gerekmektedir.
Proje süreçleri içerisinde bir aĢama tamamlandıktan, hedeflerine ulaĢarak faaliyet-
ler kapandıktan sonra ilerleyen dönemlerde bu aĢamalara geri dönmenin, projenin
planlarından sapmasına, aynı iĢlerin tekrar yapılmasına, zaman, iĢ gücü kaybedilme-
sine sebebiyet vermektedir. Örneğin, projenin sistem testleri gerçekleĢtirilir iken,
müĢteri kurumdan yeni bir özellik talebi gelmesi, isterlerin tekrar düzenlenmesi, geliĢ-
tirme sürecine geri dönülmesi ve test sürecinin (yineleme ve sistem testleri) yeni du-
ruma göre tekrar değerlendirilmesini gerektirecektir. Bu problemin önüne geçilebil-
mesi için proje analiz ve planlama süreçlerinin paydaĢlar ile birlikte belirlenmesi,
onaylarının alınması ve bu planlara bağlı kalınması gerekmektedir.
2.2 Kaynak Planlanması
Proje planlama aĢamasında gerekli kaynaklar belirlenirken, planlanan test faaliyetleri,
iĢ yüküne, yapılacak çalıĢmaların teknik gerekliliklerine göre belirlenir. Test faali-
yetlerini yürütecek test mühendisi sayısı ve testler sırasında kullanılacak araçların
belirlenmesi gerekmektedir. Test mühendisi sayısının gerekenden az belirlenmesi iĢ
yükünün artmasına, yeterli detayda test yapılamamasına ve test sürecinin hedeflerine
ulaĢamamasına sebebiyet vermektedir. Aynı durum test faaliyetlerinde kullanılacak
araçlarının belirlenmesinde de geçerlidir. Gereken araçların tedarik edilememesi veya
geç tedarik edilmesi test sürecinin verimliliğini ve etkinliğini düĢürecektir.
2.3 Zaman Planlaması
Yazılım geliĢme yaĢam döngüsünün diğer aĢamalarında olduğu Ģekilde test çalıĢma-
larının verimli olması ve istenen çıktılar elde edilmesi için zaman planlamasına
uyulması gerekmektedir. Yazılım testlerindeki faaliyetler, planlama, test tasarımı,
testlerin koĢturulması, bulunan hataların düzeltilmesi, yineleme testleri, değiĢi-
kliklerin olması ve bunların dokümante edilmesidir. Projelerde farklı sebeplerden
dolayı zamansal dar boğazlara girilmesi ihtimali vardır. Proje teslim zamanının yak-
laĢması geliĢtirme sürecinin henüz tamamlanmaması sonucunda zaman kazanmak için
test süreci için ayrılan zaman ötelenmekte ve test faaliyetleri planlanandan daha az bir
zamana sıkıĢtırılmaktadır. Böylece oluĢan zaman baskısı istenen detayda test yapıl-
masının engelleyeceği için test faaliyetlerinin kalitesini düĢürmektedir.
2.4 Görevler ile ilgili Belirsizlikler
Projelerde planlamalar yapılırken önemli noktalardan biri de görev tanımlamaların
yapılmıĢ olmasıdır. Yazılım testlerinde farklı bağımsızlık seviyelerine göre farklı
pozisyondaki kiĢilere farklı görevler verilebilmektedir. Test faaliyetlerinin sağlıklı
ilerleyebilmesi için proje içerisinde görevlerin ve bu görevleri gerçekleĢtirecek insan-
ların belirli olmaması nedeniyle, bazı iĢlemlerin takibi yapılamamakta ve bu iĢlemler
tamamlanamamaktadır.
2.5 Yanlış Kestirimler
Proje baĢlangıç aĢamalarında test faaliyetleri için yapılan kestirimler iki temel daya-
nağa sahiptir, bunlar tecrübeye dayalı kestirimler ve istatistiksel verilere dayalı
kestirimlerdir. Proje planlarının temel aldığı öngörüler takvimsel öngörüler, iĢ gücüne
dayalı öngörüler, bütçe öngörüleri ve proje risk öngörüleri Ģeklinde sıralanabilir. Bu
öngörülerin isabetli olup olmaması, test faaliyetlerinin istenen amaçlara ulaĢmasında
etkili olmaktadır.
2.6 Test Altyapısı ile ilgili Sorunlar
Yazılım test faaliyetlerinin sağlıklı olarak devam edebilmesi için önemli noktalardan
birisi de yazılım geliĢtirme ortamından ayrı bir test ortamının olmasıdır. Bu ortam
yazılım geliĢtirme müdahalelerinden uzak tutulmalıdır. Burada amaç test edilen
yazılım ürününün durağan bir yapıda tutulmak istenmesi, yazılımda alınan çıktıların
aynı iĢlemler karĢısında aynı kalmasını sağlamaktır.
Test edilen yazılım ürününün bahsedilen durağan tepkiler vermesini sağlamak için
diğer bir zorunluluk ta ürün ile ilgili düzenli sürüm tanımlama ve sürüm kontrolünün
yapılmasıdır. Bu düzen sağlanmadığı durumda yazılım sürüme ait hatalar, hata dü-
zeltmeleri (bug fix), geliĢtirmeden kaynaklı eklemeler sürümler arasında net olamaya-
cak ve sağlıklı bir test süreci iĢletilemeyecektir.
2.7 Dokümantasyon Fazlalığı veya Eksikliği
Yazılım test faaliyetleri, yazılım yaĢam döngüsü içerisindeki diğer yazılım faaliyetleri
gibi girdileri ve çıktıları için dokümantasyona ihtiyaç duymaktadır. Test sürecine girdi
sağlayacak dokümanların (Gereksinimler, Plan dokümanları, ġartname vb.) yeterli
detayda olmaması, süreç için gerekli verileri sağlayamadığı için süreci olumsuz
etkilemesi beklenebilir.
Test faaliyetleri sonucunda çıktı olan, diğer test faaliyetlerine ve diğer yazılım ge-
liĢtirme evrelerine girdi olacak dokümanların miktarı iyi belirlenmelidir. Eğer gerek-
tiğinden fazla olur ise test faaliyetlerinin hızını düĢürme riski oluĢmaktadır.
Test dokümantasyonu miktarını belirlemek için IEEE 829 Standardı kullanılmalı-
dır. Burada Önem Derecesi kavramı (Integrity Level) öne çıkmaktadır [3].
2.8 Yönetim Destek Eksikliği
Test çalıĢmalarının oluĢturduğu doğal pozisyonlardan dolayı, yazılım geliĢtirme ekibi
yazılım test ekibine direnç gösterebilir. Bu direnç yapılan çalıĢmaların verimliliğini
düĢürecek boyutta olabilir. Test ekibinin bu duruma gelmemesi için proje yönetiminin
test ekibini desteklemesi, yaptığı çalıĢmaların önemine inandığını geliĢtirici ekip içer-
isinde hissettirmesi gerekmektedir. Bu desteğin sağlanamadığı durumlarda test ekibi
etkinliğini kaybedebilir.
2.9 Gereksinim Yönetimi ile ilgili Problemler
Yazılım projelerinde baĢarısızlıkların nedenleri incelendiğinde, gereksinimler ile ilgili
sorunların en baĢta olduğu görülmektedir [4]. Yazılım projelerinde gereksinimler, test
faaliyetlerinin ana girdisidir.
Test stratejisi, test teknikleri, önceliklendirme gibi noktaların belirlenmesinde
fonksiyonel ve fonksiyonel olmayan gereksinimler incelenmektedir. Bu açıdan sis-
temde yer alan bir özelliğin, bir fonksiyonun gereksiniminin olmaması test sürecine
negatif yansıyacağı öngörülebilir. Gereksinimler tanımlanırken sadece fonksiyonel
isterlerin tanımlanması yeterli olmayacaktır. Fonksiyonel olmayan güvenlik (secu-
rity), güvenilirlik (reliability), kullanılabilirlik, gibi özelliklerin de sistem içerisinde
tanımlanması gerekmektedir. Ġsterler tanımlanırken uyulması gereken kurallar bulun-
duğu gibi isterleri değerlendirirken isterlerin taĢıması gereken özellikler de bulunmak-
tadır. Ġsterler doğru, doğrulanabilir, tam, net, sade, tutarlı, gerçekleĢtirilebilir, izlene-
bilir olmalıdır. Gereksinimlerin proje baĢlangıç aĢamasından itibaren tasarım, gerçek-
leĢtirme, test faaliyetleri aĢamaları için izlenebilirliğinin kurulmuĢ olması gerekmek-
tedir. Proje yaĢam döngüsü süreçlerinde gözden geçirme (review) faaliyetleri önemli
yer tuttuğu gibi isterler için de gözden geçirme çalıĢmaları yapılmalıdır. Yukarıda
belirtilen özelliklere uygunluk durumu, izlenebilirliği de gözden geçirilmelidir. Ġster-
lerin yazımı tamamlandıktan sonraki evrelerde müĢteri talepleri, tasarımsal değiĢiklik-
ler gibi sebepler ile isterlerin değiĢtirilmesi söz konusu olabilir. Bu değiĢikliklerin
etkilerinin değerlendirilmesi ve proje ilerleyiĢinde hesaba katılması gerekmektedir.
Bahsedildiği gibi, gereksinimler üzerine inĢa edilmiĢ bir projede gereksinim değiĢik-
lik oranlarının yüksek olmaması dikkat edilmesi, incelenmesi, gerekli tedbirlerin
alınması gereken bir durumdur. Bu durumların sonuçlarında test planlama, test özel-
liklerinin belirlenmesi faaliyetlerinin tekrar yapılacak olması test sürecini uzatacağı
öngörülebilir. Birçok kiĢiden oluĢan ve farklı fiziki ortamlarda çalıĢanların olduğu
projelerde gereksinimlerde yapılan değiĢikliklerin tüm ekip tarafında takip edilebile-
ceği ve gerekli uyarılaarın yapılabileceği bir alt yapı kurulması diğer bir gerekliliktir.
2.10 Bağımsızlık Kavramı
Yazılım projelerinde test faaliyetlerini gerçekleĢtiren kiĢi veya kiĢilerin farklı
bağımsızlık seviyelerinde oldukları durumlar görülmektedir. Her bağımsızlık seviyes-
inin pozitif ve negatif yanları bulunmaktadır. Bağımsızlık seviyesi arttıkça test
mühendisinin önyargı ve ĢartlanmıĢlık seviyesi azalmaktadır. Dolayısı ile baĢkalarının
göremediği hataları görebilirler. Bağımsız Test ekibi sistemin gereksinim ve tasarım
aĢamalarında etkili olarak, testlerin baĢarılı bir Ģekilde gerçekleĢtirilmesini sağla-
maktadır. Bağımsızlık seviyesi düĢükten yükseğe doğru Ģu Ģekilde sıralanabilir:
─ GeliĢtirmeyi yapan yazılımcı kendi kodunu test edebilir,
─ GeliĢtirme ekibinin içerisinde, ürünü kodlayan kiĢiden baĢka bir kiĢi test edebilir,
─ Aynı firma içerisinde, test için uzmanlaĢmıĢ ayrı bir ekip tarafından testler gerçek-
leĢtirilebilir,
─ BaĢka bir firmadan test iĢlerini yapacak ayrı bir ekip proje test faaliyetlerini ger-
çekleĢtirebilir.
Bağımsız test ekibi ile çalıĢmanın avantajları olduğu gibi, dezavantajları da sözkonusu
olabilir. Tamamen bağımsız olma durumunda geliĢtirme ekibinden izole olunma ihti-
mali bulunmaktadır. Bağımsız test ekibi yazılım ekibi ile farklı fiziksel ortamlarda
çalıĢtıklarından dolayı çalıĢanlar birbirlerini görmemektedir. Bu durum beraberinde,
yazılım geliĢtirme ekibi için kalite duygusunun yitirilmesini getirebilir.
3 Test yönetimi ile ilgili problemler
3.1 Yanlış Test Stratejisi ve Yaklaşımı
Test stratejisi ve yaklaĢımı projeye özgü bir Ģekilde belirlenmektedir. Test planlaması
sırasında test yaklaĢımına karar verilir, detaylandırılır ve bu yaklaĢımdan yola
çıkılarak test durumları, test aktiviteleri belirlenir. Test planlamasının ilk adımı test
stratejisinin belirlenmesidir. YanlıĢ test yaklaĢımının belirlenmesi test sürecinde
istenen hedeflere ulaĢılamamasına, tekrarlı iĢlerin yapılmasına, sürenin uzamasına
neden olabilir. Kurumsal firmalarda daha çok görülen hatalardan biri de her projeye
benzer test stratejisinin uygulanmak istenmesidir. Bir uygulamada baĢarılı olmuĢ bir
test stratejisi, diğer bir projenin kendisine özgü durumundan dolayı istenen baĢarı
seviyesinde olmayabilir.
Her projeye aynı test yöntemlerini uygulamama yaklaĢımını sistematik hale getir-
mek için önem derecesi kavramı kullanılabilir. Burada proje bir proje özelliğine göre
(risk, sonuç vb.) seviyelendirilir. Daha sonra bu özelliğe göre projenin tamamı veya
modüllerine bir önem derecesi tanımlanır. Bu önem derecesi kavramı temel alınarak,
test sürecindeki dokümantasyon ve faaliyetlerin derinliği miktarı belirlenir. Böylece
her projenin hatta her modülün özelliklerine göre test yaklaĢımı belirlenebilir.
Test yaklaĢımında yapılan diğer bir hata da test edilecek noktaların doğru belirle-
nememesidir. Genelde kolay test edilen kısımlar tekrar tekrar test edilirken, test edil-
mesi zor ama önemli alanlara yeterli önem gösterilmemektedir. Diğer bir durum ise
test sürecinde tüm test durumları birden koĢturularak, diğerlerine göre daha önemli
kısımlara aynı özen gösterilmektedir. Bu durum zamanın ve test eforunun etkin ve
etkili kullanılmaması sonucuna çıkmaktadır. Bu durumda önceliklendirme yapılması
gerekir. Sistemdeki karĢılıklarının önemlerine dayanarak test durumlarının öncelik-
lendirilmesi gerekmektedir.
3.2 Planlamanın Eksik olması
Proje planlaması yapılırken test süreçlerinin de planlaması gerekmektedir. Test plan-
ları tüm test süreçlerini, test aktivitelerini, test giriĢ ve çıkıĢ kriterlerini, test yak-
laĢımlarını, takvimi, kabulleri ve varsayımları, test sürecinde kullanılacak araçları
tanımlamalıdır. Test dokümantasyonu IEEE Std. 829 standardında belirtilmiĢtir
[3].Test planları tüm test seviyelerini kapsayacak Ģekilde yazılan bir Test Ana Planın-
dan, ve her test seviyesini (birim test seviyesi, entegrasyon test seviyesi, sistem test
seviyesi) tanımlayan Test Planlarından oluĢmaktadır. Planları hazırlarken yeterli detay
seviyesi açıklanmadığı durumlarda belirsizlikler sorunlara sebebiyet verebilmektedir.
Testlere giriĢ kriterleri ne zaman testlere baĢlanacağını, hangi durumların testlere
baĢlanması için gerekli olduğunun belirtilmesidir. Bu konular yazılım geliĢtiren ekip
ile daha önceden belirlenmesi gereken konulardan biridir. Test ekibi etkili test yapa-
bilmek için bazı Ģartların olgunlaĢmasını talep edebilir, sistemin duman (smoke) tes-
tlerini tamamlamıĢ olması buna örnek olarak verilebilir. Bu durum test ekibi ile
yazılım ekibi arasında anlaĢmazlıklara sebebiyet verebilir.
Test Ana Planında (Master Test Plan) ve seviye test planlarında testlerin hangi kri-
terler sağlandığında tamamlanacağı bilgisi de yukarında belirtilen sebeplerden dolayı
yer almalıdır.
Test süreçlerinde, nelerin test edileceğinin belirlenmesi yanında, nelerin test edil-
meyeceğinin de belirlenmesi ve bu konuda paydaĢlar arasında anlaĢmaya varılmalıdır.
Bu durum da taraflar arasında problemlere sebebiyet verebilir.
3.3 Yetersiz Derinlikteki Testler
Test faaliyetlerinin gerçekleĢtirilmesi sırasında yaĢanabilecek tehlikelerden birisi de
yeterli seviyede test edilememesidir. Yazılımın test edilmesi sadece bir yol takip edi-
lerek doğru çalıĢtığının gösterilmesi değildir. Eğer sadece ana akıĢ (Happy Path) test
edilirse sistemin çalıĢmayan yanlarının gösterilmesi için gösterilmesi gereken çaba
gerçekleĢtirilmemiĢ ve amaca ulaĢılamaz. Bu durumu kontrol etmek ve test faaliyetle-
rinin hangi seviyede yapıldığının izlenmesi için etkili yöntemlerden birisi Test Kap-
sam Aracı (Test Coverage Tool) kullanmaktır. Bu araçlar yazılıma ait kodları izle-
mektedirler. Yazılım testleri yapılırken çalıĢtırılan kod parçalarını belirlemekte, iĢlem
sonucunda da test faaliyetleri sonucunda çalıĢtırılan kodların, tüm kodlara oranını
vererek bir kapsam yüzdesi vermektedir.
3.4 Yetersiz Test Metrikleri
Yazılım geliĢtirme yaĢam döngüsü sırasında tüm evrelerde olduğu gibi test süreçle-
rinin de izlenmesi ve bu evreler hakkında bilgi sahibi olunması, çıkarımlar yapılması
ve bu çıkarımlara göre gerektiği durumlarda sürece müdahale edilmesi gerekmektedir.
Ölçüm iĢlemi doğru metriklerin alınması ile yani doğru soruların sorulması ile baĢla-
maktadır. Yetersiz metrikleri olan bir test süreci yeterli ölçümleri yapamayacak,
dolayısı ile doğru verilere ve çıkarımlara ulaĢamayacaktır. Bir projede en yaygın
kullanılan test metrikleri aĢağıdaki gibidir:
─ Test durumları hazırlama aĢamasında, test durumlarının tamamlanma yüzdesi,
─ Test ortamı hazırlanmasında yapılması gereken iĢlerin yüzde kaçının tamamlandı-
ğı,
─ Testlerin koĢturulması safhasında test durumlarının ne kadarının koĢturulduğu,
─ Hata verileri, (hata sayısı, hata yoğunluğu, hata oranı, düzeltilen hata sayısı, düzel-
tilme iĢleminden sonra tekrarlanan testlerde baĢarı oranı),
─ Test kapsam yüzdesi (kod üzerinde),
─ Test mühendislerinin sisteme güveni,
─ Takvimsel kilometre taĢları,
─ Test maliyeti
Örnekleri yukarıda verilen metriklerden veriler geldiğinde verileri değerlendirmek,
riskler belirlemek ve bu riskler doğrultusunda kararlar almak gerekmektedir. Eğer
riskleri belirleyecek, değerlendirecek ve gerekli tedbirleri alacak bir mekanizma kuru-
lamaz ise proje takibi takip edilemez, plandan sapmalar tespit edilemez, projenin ba-
Ģarısını etkileyecek risklere karĢı gerekli müdahaleler yapılamaz.
3.5 Alan Bilgisi Eksikliği
Test faaliyetleri farklı alanlarda farklı stratejiler gerektirmektedir, örneğin güvenlik-
kritik bir sistemin testleri ile bir banka uygulamasının testleri farklı bilgiler, farklı alt
yapı gerektirmektedir. Test mühendisinin projenin ilgili konusunda bilgiye sahip ol-
ması gerekmektedir. Test mühendisi yeterli bilgiye sahip değilse yapacağı testlerin
istenen hedeflere ulaĢmasından Ģüphe edilebilir.
3.6 Hataların Net Bir Şekilde Bildirilmemesi
Test süreci sırasında bulunan hataların test ekibi tarafından raporlanarak yazılım
geliĢtirme ekibine iletilmesi, yazılım geliĢtirme ekibi tarafından bu hataların analiz
edilerek düzeltilmesi gerekmektedir. Bu iĢlemlerin yapılabilmesi için bulunan hata-
ların geliĢtirme ekibine doğru ve tam olarak iletilmesi kritik öneme sahiptir.
3.7 Test Araçları ile ilgili Problemler
Test araçları doğru kullanıldığında test faaliyetlerine yüksek katkıları olmaktadırlar.
Bununla beraber, araçların yanlıĢ kullanılması test araçlarından alınan verimi
düĢürmektedir.
Test araçları ile ilgili yapılan genel hatalar:
─ Gerçekçi olmayan beklentiler,
─ Gerekli sürelerin azımsanması,
─ Gerekli eforun azımsanması,
─ Araca gerekenden fazla güvenilmesi,
─ Araç için destek alınan firmanın desteği kesmesi, Ģeklinde sıralanabilinir.
3.8 Yineleme (Regresyon) Testleri ile ilgili Problemler
Yazılım test sürecinde hatalardan dolayı yapılan düzeltmeler ve yeni geliĢtirme faali-
yetler sonucunda kodda değiĢiklikler yapılmaktadır. Bu değiĢikliklerin sistemin ilgili
alanlarında beklenmedik bir hataya sebebiyet verip vermediğinin kontrolü yineleme
testleri (regresyon) ile yapılmaktadır. Bu testlerin yetersiz olması durumunda sistem
içerisinde beklenmedik hataların çıkması ihtimali artmaktadır.
4 Sonuç
Yazılım ürününün baĢarısı, gereksinimleri karĢılaması ve müĢterilerin memnuniyeti
ile ölçülebilir. Bu tanımlanan baĢarıya ulaĢmak için ürünün doğru süreçler iĢletilerek,
gereksinimlerde tanımlanan Ģekilde sonuçlandırılması gerekmektedir. Bu amaç ile
doğrulama ve geçerleme süreci yazılım projelerinin hedeflenen baĢarıya ulaĢmasında
kritik bir yere sahiptir. Yazılımın doğrulama ve geçerleme faaliyetleri içinde değer-
lendirilebilecek test faaliyetleri geliĢtirilen ürünün istenen özelliklere uygunluğunun
kontrol edilmesi açısından oldukça önemlidir. Bu faaliyetlerin etkinliği ve etkililiği
çok farklı sebeplerden dolayı düĢebilir. Bu sebepler öngörülebilir ve önlem alınabilir
sebeplerdir.
Teşekkür - Yazarlar, bu çalıĢmanın gerçekleĢtirilmesi için destek sağlayan
TÜBĠTAK BĠLGEM Yazılım Test ve Kalite Değerlendirme Merkezi'ne teĢekkür
eder.
Kaynaklar
1. Özbek M., Kurt A., Gürbüz A., “Emniyet-Kritik Sistemlerin Yazılım Doğrulama Süreci
Software Verification Process in Safety-Critical Systems”
2. Yıldırım E., PiĢken M., “Orta Ölçekli Yazılım Firmaları Ġçin Ġdeal Bağımsız Doğrulama ve
Geçerleme Organizasyon YaklaĢımı”
3. IEEE 829-2008, Standard for Software and System Test Documentation
4. The Standish Group Report, (1995)
5. IEEE 1012-2012, Standard for Software Verification and Validation