1.

YAZILIM TEST VE KALİTE KAVRAMINA GİRİŞ

Giriş
Yazılım testi “bir yazılımın, kendisinden beklenen özellikleri karşılayıp karşılayamadığını incelemek amacıyla yapılan işlemlerdir. Bu şekilde yazılımdaki hatalar bulunup
düzeltilebilir ve gereksinimlere uygun hale getirilebilir.”. Bu bölümde yazılım kalitesi ve testi kavramına giriş yapılacaktır.

1.1. Yazılım Kalite ve Testi ile İlgili Genel Bilgiler

Yazılım testi, bir yazılımın gereksinimleri karşılayıp karşılamadığını, uygun şekilde hazırlanmış test senaryoları ile hata bulma amaçlı yapılan çalışmalara verilen isimdir.
Hiçbir yazılımın yaşam süreci boyunca her an hatasız olması mümkün değildir, bu sebeple bir yazılımdaki hataları bulmak ve yazılımın kalitesini ölçmek için test işlemi
çok önemlidir.  Yazılım testinin yapılma amaçları temel olarak

 ileriye dönük kodun geliştirilme masraflarını azaltmak,

 ürün çalıştırılmadan önce kalitesini ölçmek,

 yapılan hataların tekrarlanmasını önlemek,

 zaman ve maliyet tasarrufu yapmak,

 saygınlık kazanmak,

şeklinde özetlenebilir (Singh ve Singh, 2019):

Yazılım projeleri değerlendirilirken test sürecine giren ürünler, ideal uygulama elde edilene kadar devam etmelidir. Diğer bir deyişle yazılım testinin belli bir süresi
yoktur, test süreci kodlama başlamadan önce başlamalı ve kodlama boyunca devam etmelidir. Test, ürünün beklenilen seviyede olduğunu belirlemek, değilse de
istenilen ölçüye gelmesini sağlamak için kullanılan, belirli birtakım kurallar dahilinde işletilen bir süreçtir. Bu sürecin kalitesi aslında işletilen testin de kalitesini verir.
Test, kaliteli bir süreç dahilinde işletiliyorsa kalite içerisinde en önemli başlıklardan biri olur. Diğer bir tanımlamaya göre yazılım testi, bir yazılım bileşeni veya sistemin
denetlenebilir koşullar altında işletilmesi (veya çalıştırılması) ve elde edilen sonuçların değerlendirilmesidir. Burada bahsi geçen denetlenebilir koşulların hem normal
hem de anormal koşulları kapsaması gerekir. Bu yüzden, testin bilinçli şekilde hatalı şeyler yaparak olabilecek şeyleri önceden belirlemeye yönelik olması gerekir.
Sonuç olarak, olması gereken şeylerin olmadığını veya olmaması gereken şeylerin olduğunu denemek ve ortaya çıkartmak yazılım testinin amacı olmalıdır. Yazılım
testi, bir yazılımın sonsuz sayıdaki çalışma alanından, sınırlı sayıda ve uygun şekilde seçilmiş testler ile belirlenmiş gereksinimleri karşıladığının doğrulanması veya
beklenen ile gözlenen sonuçlar arasındaki farkların belirlenmesini amaçlar. Yazılım testi gerçekleştirilirken dikkat edilmesi gereken durumlar aşağıdaki şekilde
özetlenebilir (Whittaker, 2000):

 Yazılım ürünü mutlaka çalıştırılarak test edilmelidir. Ancak burada çalıştırılma kelimesi geniş bir yelpazeye karşılık gelmektedir. Bu sebeple “yazılım ürünü gerektiği
şekilde çalıştırılarak test edilmelidir” şeklinde ifade edilmesi daha doğrudur.

 Yazılımın çalışma alanlarının tümünün testi imkansız olacağından; kritiklik düzeylerine göre sıralanıp, yeterli görülen sayıda, en kritikleri test edilmelidir.

 Yazılımın, kullanıcı beklentilerine, gereksinimlerine ve akla uygun, mantıklı beklentilere cevap verip veremediği test edilmelidir.

 Test faaliyetlerinin, yazılım geliştirme sürecinin daha başlangıç safhalarından itibaren vazgeçilmez bir parçası olduğu açıktır.

Kim olursa olsun her insanın belli bir hata yapma olasılığı bulunmaktadır, yazılım ürünleri de insanlar tarafından yazılan kodlardan oluşur. Bunun dışında yazılımı
geliştiren kişilerin belli konularda bazı şeyleri bilmesi mümkündür ancak her şeyi bilmesi mümkün değildir.
Ayrıca insanlar belli yeteneklere sahip olmalarına karşın kusursuz değildirler ve hataya meyillidirler. Bunun yanı sıra zaman ve bütçe konusundaki kaygılar ve gerekli
kontrol ve testler için yeterli zaman olmaması sonucunda yazılım ürününün herhangi bir kısmında, yazılımda, sistemde ya da dokümanda hata oluşturur. Hata olan kod
çalıştırıldığında sistem beklenen fonksiyonları gerçekleştiremez ve başarısız olur. Bu sebeplerden dolayı;

 müşteriye sunmadan önce ürün kalitesinden emin olmak,

 yeniden çalışma (düzeltme) ve geliştirme masraflarını azaltmak,

 geliştirme işleminin erken aşamalarında yanlışları saptayarak ileri aşamalara yayılmasını önlemek, böylece zaman ve maliyetten tasarruf sağlamak

amaçlarıyla ürün müşteriye sunulmadan önce test edilmesi gerekmektedir (Freeman, 2002). Şekil 1.1’de bir yazılım modüllerinin farklı roller tarafından farklı
şekillerde anlaşılması gösterilmektedir (Javaturk, 2014). Şeklin açıklaması neticesinde yazılım testinin neden gerekli olduğu net bir biçimde anlaşılmaktadır.Buradaki
kareler incelenecek olursa aşağıdaki durumlar ortaya çıkmaktadır.

Müşterinin tarif ettiği yapıya bakıldığında, bir ağaca asılı olan 3 basamaklı bir salıncak olduğu görülmektedir. Esasında müşterinin tarifinde bir sorun olduğu bellidir,
çünkü 3 basamaklı bir salıncak, pratik hayatta kullanılabilecek bir araç değildir. Ancak bu durum ne müşteri ne analist ne de diğer roller tarafından fark edilmiştir.

Proje liderinin anladığı yapıya bakıldığında proje liderinin ilk karedeki 3 basamak yanlışlığını kendi düşüncesinde düzelttiği ve basamak sayısının 1’e indirdiği
görülmektedir. Ancak proje lideri bu kez salıncağın ağaçtaki konumu üzerinde bir hata yapmıştır. Çünkü salıncağı ağacın ortasında olarak tasarlamıştır ki bu da bu
salıncağın kullanılamaması anlamına gelmektedir. Ayrıca burada esas dikkat çekici nokta müşterinin tarif ettiği ile proje liderinin anladığının birbirinden çok farklı
olmasıdır.

Analistin tasarladığı yapıya bakıldığında, analistin genel olarak proje liderinin anladığını oluşturduğu, ancak ortaya kullanılamayan bir tasarım çıktığından bu durumda
geri dönüşü olmayacak şekilde ağacı kestiği, geri dönüşü olmayan bu hatası neticesinde ağacın ortasında oluşturmaya çalıştığı boşluğun oluşmadığı ve hiçbir işe
yaramadığı, bu sefer düşen ağaç gövdesinde boşluk oluşturabilmek için 2 tane dayanak yaptığı yani proje bütçesini arttırdığı ve neticede yine de kullanılabilir bir
tasarım çıkmadığı görülmektedir. Ayrıca burada esas dikkat çekici nokta müşterinin tarif ettiği ile proje liderinin anladığının birbirinden çok farklı olmasının yanında
analistin tasarladığının da bunların hiçbirine tam olarak uygun olmamasıdır.

1
Şekil 1.1. Yazılım Modüllerinin Farklı Roller Tarafından Farklı Şekillerde Anlaşılması

Programcının yazdığı modüle bakıldığında analistin tasarladığı versiyondaki mantıksızlığın bulunmadığı, bu yapı için daha doğru ve daha az maliyetli (yanlardaki
dayanaklar yok) bir tasarım oluşturduğu, agacın ve 1 basamaklı bir salıncağın bulunduğu ancak burada da salıncağın yerlerde olduğu ve hiçbir işe yaramadığı
görülmüştür. Yine burada, müşterinin tarif ettiği, proje liderinin anladığı, analistin tasarladığı ve programcının yazdığı yapıların hiçbirinin birbirine benzemediği
görülmektedir.

Danışmanın tarif ettiği yapıya bakıldığında akla yatkın bir şekilde ve proje liderinin tasarladığına benzer bir şekilde ağacın yanında yer alan bir salıncak tasarlandığı
görülmektedir. Ancak bu salıncağın klasik bir salıncak şeklinde değil bir koltuk şeklinde tasarlandığı görülmektedir. Bu da danışmanın tarif ettiği yapının hem daha
önceki müşterinin tarif ettiği, proje liderinin anladığı, analistin tasarladığı, programcının yazdığı modüllerin hiçbirine benzemediği hem de daha masraflı bir tasarım
yapıldığı anlamına gelmektedir.

Projenin nasıl dokümante edildiği kısmına bakıldığında, projelerde genellikle eksik bırakılan dokümantasyon kısmına esprili bir yaklaşım gösterildiği görülmektedir.
Burada dokümantasyonun sadece gölgesi görünmektedir ve gerçek anlamda bir dokümantasyon bulunmamaktadır.

Hangi operasyonların yüklendiği kısmına bakıldığında ağacın ve salıncağın ipinin bulunduğu ancak salıncağın kendisinin bulunmadığı görülmektedir. Bu da “bazı
operasyonların yüklenmeye başlandığı ancak tamamlanmadığı” şeklinde yorumlanabilir ve yine yüklenen operasyonlar, müşterinin tarif ettiği, proje liderinin anladığı,
analistin tasarladığı, programcının yazdığı ve danışmanın tarif ettiği yapıların hepsinin birbirinden farklı olduğu görülmektedir.

Müşteriye nasıl fatura kesildiği kısmında da yine esprili bir yaklaşım söz konusudur.
Burada henüz modüller tamamlanmadığı halde müşteriye yapılanlardan çok daha fazla bir fatura kesildiği ifade edilmiştir. Her ne kadar bu durum bir kötü niyet
içermese de bazı projelerde maliyetin düşünülenden çok daha yüksek boyutlara çıktığı görülmektedir. Bu da yine yazılım projelerindeki maalesef süregelen
plansızlıklardan ve tahminsizliklerden kaynaklanmaktadır.

Yazılımın nasıl desteklendiği kısmına bakıldığında dokümantasyonu ifade eden kareye benzer şekilde yazılımlarda genellikle eksik bırakılan destek kısmının ele
alındığı görülmektedir. Burada maalesef geri dönüşümü olmayacak bir hata işlenerek ağaç kesilmiştir, bu durumda yazılıma yapılacak desteğin çok güçlü olması
gerektiği anlaşılmaktadır.

Gerçekte müşterinin ihtiyacı olan kısmına gelindiğinde ise esasında tüm bu karelerin özeti ve yazılım testinin neden önemli olduğu görülmektedir. Gerçekte müşterini
ihtiyacı olan ağacın yanına asılı bir araba lastiği şeklindedir ve müşterinin kendi tarif ettiğine, proje liderinin anladığına, analistin tasarladığına, programcının yazdığına,
danışmanın tarif ettiğine ve diğerlerine benzememektedir. Buna göre buradan çıkarılacak sonuç, müşterilerin kendi istek ve ihtiyaçlarını dahi kimi zaman yeterince
doğru bir şekilde açıklayamadıkları bu sebeple de yazılımda sürekli olarak teste ihtiyaç duyulduğu ve yazılımın her noktasının farklı şekillerde test edilmesi
gerektiğidir.

1.2. Yazılım Testi ile İlgili Doğru Bilinen Yanlışlar

Yazılım testi bilişimdeki birçok alana göre yeni sayılabilecek bir alandır. Ayrıca yazılım ürünlerini çeşidinin sürekli olarak değişmesi ve güncellenmesi ile yazılım
testlerinin de sürekli olarak değişmesi ve güncellenmesi gerekmektedir. Bu sebeple yazılım testleri ve kalitesi ile ilgili olarak tüm durumlar netleşmemiştir ve pek çok
doğru bilinen yanlış bulunmaktadır.
Aşağıda bu doğru bilinen yanlışların en önemlileri verilmiştir (Myers ve diğ., 2012).

 Doğru Bilinen Yanlış 1: Yazılım testi çok pahalı bir işlemdir.

 Doğru Bilinen Yanlış 2: Yazılım testi çok zaman tüketen bir işlemdir.

 Doğru Bilinen Yanlış 3: Yalnızca tamamen geliştirilmiş yazılım ürünler test edilir.

 Doğru Bilinen Yanlış 4: Bir yazılım ürününü baştan sona, komple test yapmak mümkündür.

 Doğru Bilinen Yanlış 5: Test edilmiş bir yazılımda kesinlikle hata yoktur.

 Doğru Bilinen Yanlış 6: Kaçırılan tüm hatalar, test uzmanları yüzünden olur.

2
 Doğru Bilinen Yanlış 7: Test uzmanları ürünün kalitesinden de sorumludur.

 Doğru Bilinen Yanlış 8: Test otomasyonları mutlaka zamanı kısaltmak için kullanılır.

 Doğru Bilinen Yanlış 9: Herkes bir yazılımı test edebilir.

 Doğru Bilinen Yanlış 10: Bir test uzmanının tek görevi hataları bulmaktır.

Doğru Bilinen Yanlış 1: Yazılım testi çok pahalı bir işlemdir.

Gerçek: Yazılım firmaları için yazılım testi genellikle gereksiz bir maliyet olarak görülür. Bunun sebepleri arasında yazılım testi gerçekleştirmek için fazladan araç, kişi,
süre kullanılması gereği ve bunların her birinin ekstra bir maliyet olması, ayrıca yazılımcıların işlerini doğru yaptıkları takdirde herhangi bir yazılım testine gerek
olmaayacağına inanmaları gelmektedir. Halbuki yazılım testi ile ilgili bu tip maliyetler çok yüksek değildir. Ancak yazılım testi için gerekli maliyetler
gerçekleştirilmediğinde ve gerekli önlemler alınmadığında ve bunun sonucunda yazılımlarda pek çok hata oluştuğunda, bu hataların düzeltilmesi için harcanacak
maliyetler çok daha yüksek olacaktır. Genellikle yazılım firmalarının kaçtığı maliyet esasında yazılım testi gerçekleştirmek için harcanan bedel değil, oluşan hataları
düzeltmek için harcanan bedeldir. Ancak bu durum birçok yazılım firması tarafından net bir şekilde anlaşılamamaktadır. Sonuç olarak esasında bilinmelidir ki hata
düzeltme maliyeti, test yapma maliyetinden daha yüksektir.

Doğru Bilinen Yanlış 2: Yazılım testi çok zaman tüketen bir işlemdir.

Gerçek: İlk doğru bilinen yanlışa benzer nitelikler göstermektedir. Yazılım firmaları için yazılım testi genellikle gereksiz zaman harcama olarak görülür. Bunun
sebepleri arasında yazılım testi gerçekleştirmek için fazladan süreye ihtiyaç duyulması ve yazılımcıların işlerini doğru yaptıkları takdirde herhangi bir yazılım testine
gerek olmayacağına inanmaları gelmektedir. Yazılım testi ile ilgili belli bir zaman harcanması gerektiği doğrudur ancak, bu zaman harcamadığı takdirde yazılımlardaki
hatalar ile ilgili yeterince önlem alınamaz ve bunun sonucunda yazılımlarda pek çok hata oluştuğunda, bu hataların düzeltilmesi için harcanacak zaman çok daha
yüksek olacaktır. Genellikle yazılım firmalarının kaçtığı zaman esasında yazılım testi gerçekleştirmek için harcanan zaman değil, oluşan hataları düzeltmek için
harcanan zamandır. Ancak bu durum birçok yazılım firması tarafından net bir şekilde anlaşılamamaktadır. Sonuç olarak esasında bilinmelidir ki hata düzeltme için
harcanan zaman, test yapmak için harcanan zamandan çok daha yüksektir.

Doğru Bilinen Yanlış 3: Yalnızca tamamen geliştirilmiş yazılım ürünler test edilir.

Gerçek: Özellikle adım adım ilerleyen yaklaşımlarda (Agile vb) ürün tamamen bitmeden de test edilebilir. Burada şunu belirtmekte fayda vardır. İşlemin adı yazılım
testi olduğundan sadece kodların test edilmesi gibi bir yaklaşım düşünülmemelidir. Bir yazılıma ait bir fikir oluştuğu andan itibaren bu fikrin, algoritmaların, zaman ve
maliyet şemalarının,  tüm yazılım ürünlerinin, kodların, arayüzlerin, veri tabanlarının, verilerin, sorguların vb tüm elemanların test edilmesi mümkündür. Dolayısıyla
ortada hiçbir yazılım ürünü yokken dahi uygun yazılım testlerinin gerçekleştirilmesi sağlanabilir.

Doğru Bilinen Yanlış 4: Bir yazılım ürününü baştan sona, komple test yapmak mümkündür.

Gerçek: Bir yazılım ürününün tüm seçeneklerini tüm kriterlere göre, komple test etmek mümkün değildir. Aynı anda bunların yalnızca bir kısmı gerçekleştirilebilir.
Diğer bir deyişle bir yazılım ürünü belirlenen bütün kriterlere göre test edilebilir ya da bir kritere göre tüm yolları yani tüm seçenekleri test edilebilir ancak bir yazılım
ürününün tüm veri olasılıklarının test edilmesi mümkün değildir. Bu durum şu şekilde örneklendirilebilir. Bir yazılım ürününde kullanıcıların TC Kimlik Numarası’nın
girilmesinin istendiği bir alan olduğunu düşünelim.
Bu alanın genel olarak test edilmesi mümkündür yani “bu alana gerçekten veri giriş yapılabiliyor mu”, “veri girişi ne kadar sürede gerçekleştiriliyor”, “kullanıcılar için
alanın tasarımı uygun mudur” gibi sorualra cevap vermek mümkün olabilir. Ancak o alana girilebilecek tüm veri olasılıklarını test etmek mümkün değildir.
Kullanıcıların her birinin gerçekten doğru bir TC Kimlik Numarası girdiğini bile varsaysak ortaya çıkabilecek olasılıklar sonsuz sayıdadır. Buna bir de kullanıcıların
girebileceği tüm farklı olasılıklar da eklendiğinde ortaya içinden çıkılmaz bir durum çıkmaktadır. Zira bir yazılım kullanıcısının her alana her türlü veriyi girebilme
ihitmali mevcuttur ve yazılım testi işlemini gerçekleştiren kişilerin bu durumu düşünmesi gerekmektedir.

Doğru Bilinen Yanlış 5: Test edilmiş bir yazılımda kesinlikle hata yoktur.

Gerçek: Bu, müşterilerin, proje yöneticilerinin ve diğer kişilerin sıklıkla inandığı ve inanmak istediği bir doğru bilinen yanlıştır. Ancak 4. maddede verilen sebepten
ötürü bir yazılımın tamamen test edilmesi mümkün değildir ve bu sebeple hiç kimse bir yazılım ürününün, çok iyi bir şekilde test edilse bile %100 hatasız olduğunu
iddia edemez.

Doğru Bilinen Yanlış 6: Kaçırılan tüm hatalar, test uzmanları yüzünden olur.

Gerçek: Hatalar yalnızca test uzmanları yüzünden olmaz. Şekil 1.1’de de resmedildiği üzere test planlayıcıları, yazılımcılar, analistler, müşteriler, yöneticiler de
hataların sebebi olabilir. Bir analist analiz etmesi gereken durumları eksik bırakırsa, müşteri ihtiyaçlarını tam olarak ifade edemezse, yazılımcılar yazmaları gereken
kodları yanlış bir şekilde yazarsa, raporlayıcılar eksik ya da yanluş rapor hazırlarsa bu durumda yine pek çok hata meydana gelebilir. Bu durum, hataların; programın
kendisi, zaman, maliyet, dokümantasyon vb farklı noktaların hepsinden kaynaklanabilmesi ile açıklanabilir.

Doğru Bilinen Yanlış 7: Test uzmanları ürünün kalitesinden de sorumludur.

Gerçek: Test uzmanlarının ürünün kalitesinden de sorumlu olduğu kanısı yaygın ama yanlış bir kanıdır. Test uzmanları hatası azaltılmış bir yazılımdan sorumludurlar
ancak kaliteyi direkt olarak sağlamakla yükümlü değildirler. Kalite, test uzmanları yanı sıra analistler, yazılımcılar gibi ekibin tamamının beraber sağlayabileceği bir
kavramdır. Burada şunu da belirtmekte fayda vardır ki test anlık bir işlemdir ancak kalite uzun zamana yayılan bir kavramdır ve hemen belli olmaz, dolayısıyla test
yaparak kalite hakkında bir fikir edinmek mümkün olsa da kalitenin tam anlamıyla tespit edilmesi söz konusu olamaz.

Doğru Bilinen Yanlış 8: Test otomasyonları mutlaka zamanı kısaltmak için kullanılır.

Gerçek:  Otomasyonların test zamanını kısaltabildiği doğrudur. Ancak her otomasyon her zaman zamanı kısaltmaz. Test otomasyonu, manuel olarak yapılan testleri
kısaltmayı sağlar. Ancak test otomasyonu genellikle süreyi kısaltmak için değil, gereksinimlerin sürekli değişmesi durumunda her gereksinime uygun bir test
uygulamak için kullanılır. Buna göre bir yazılım test otomasyonunun farklı işlevleri ve amaçları da olabilir. Bu konu ders kitabının 8. bölümü olan “Yazılım Test
Otomasyonları” adlı bölümde daha ayrıntılı bir şekilde açıklanmıştır.

Doğru Bilinen Yanlış 9: Herkes bir yazılımı test edebilir.

Gerçek: Aslında bu cümle bir açıdan doğrudur. Herkes bir yazılımı test edebilir ancak herkesin gerçekleştirebileceği yazılım testleri ve bu testleri üzerinde
çalıştırabileceği yazılım çeşitleri belili bir seviyededir. Diğer bir deyişle

 herkes her yazılımı test edemez.

 herkes bir yazılıma aynı testleri uygulayamaz.

3
 herkes bir yazılıma eşit seviyede test uygulayamaz.

 herkes bir yazılımda aynı senaryoları uygulayamaz.

Doğru Bilinen Yanlış 10: Bir test uzmanının tek görevi hataları bulmaktır.

Gerçek: Testçinin en önemli görevinin hataları bulmak olduğu doğrudur, ancak test uzmanlarının hataları bulmak dışında,

 hatalarla ilgili çözüm önerilerinde bulunmak

 hataların durumu ile (artış, azalma) ilgili analiz çıkarmak

 yazılımın performansını belirlemek

 yazılımcılara tavsiyelerde bulunmak

gibi görevleri de vardır.

1.3. Yazılım Kalite ve Testi ile İlgili İlkeler

Yazılım testinin gerçekleştirilmesi ile ilgili pek çok farklı ilke bulunmakla beraber literatürde genellikle bunlardan en önemli 7 tanesi ele alınır. Bu ilkeler ve açıklamaları
aşağıda verilmiştir (Limaye, 2009).

 İlke 1: Yazılım testi hataların varlığını gösterir.

 İlke 2: Her test uzmanının başına hata yokluğu yanılgısı gelebilir.

 İlke 3: Yazılım testi dediğin erken yapılmalıdır.

 İlke 4: Kusursuz ve her şeyi kapsayan bir yazılım test yapmak mümkün değildir.

 İlke 5: Yazılımlardaki hatalar kümelenmiş şekilde bulunur.

 İlke 6: Yazılım testinde tarım ilacı paradoksu oluşabilir.

 İlke 7: Yazılım testi yazılımın içeriğine bağımlıdır.

İlke 1: Yazılım testi hataların varlığını gösterir.

Bu ilkenin devamı “… yokluğunu göstermez.”  şeklinde olmalıdır. Yazılım testi, yazılımda kalan keşfedilmemiş hataların tespit edilmesini sağlayabilir. Ancak tersi
doğru değildir eğer bir yazılım testi neticesinde hiçbir hata bulunmuyorsa, bu durumun gerçekten hiçbir hata bulunmamasından dolayı ortaya çıkması oldukça düşük
bir olasılıktır. Eğer bir yazılım testi sonucunda hiçbir hata ortaya çıkmıyorsa bunun birçok sebebi olabilir. Bunlar arasında

 yanlış bir testin uygulanması,

 testin yanlış veriler ile uygulanması,

 yanlış modüllere veya yazılım ürünlerine test uygulanması,

 sözkonusu testin daha önce de gerçekleştirilmiş ve hataların anlık olarak düzeltilmiş olması,

gibi sebepler sayılabilir. Tabi burada şunu da belirtmek gerekir, bir yazılımın hatasız olması ya da hatasız olmaya yakın olması dahi, o yazılımın başarılı bir yazılım
olduğu anlamına gelmeyebilir. Bu durum bir sonraki ilkede açıklanmıştır.

İlke 2: Her test uzmanının başına hata yokluğu yanılgısı gelebilir.

Bir yazılım testinin amacı yalnızca hataları bulmak değildir. Bundan daha da önce söz konusu yazılımın, müşterinin ve/veya kullanıcıların ihtiyaçlarına yönelik olarak
geliştirilmiş olması gereklidir. Bir yazılım %99 oranda hatasız olabilir ancak bu yazılım eğer müşterinin ve/veya kullanıcılarının ihtiyaçlarını karşılamıyorsa bu durumda
o yazılımın hatasız olmasının çok büyük bir önemi olmaz. Esasında bir yazılım tetsinde hata bulunmaması bir yanılgıdır çünkü normal şartlar altında bir yazılımda bir
hata bulunmaması beklenmez. Ancak şunu da belirtmek gerekir ki bir yazılımda tüm hataların tespit edilmesi ve düzeltilmesi, sistemin kullanılamaması, ihtiyaçlara
karşılık gelmemesi durumuna yardımcı olmaz. Bu sebeple hem hataların erkenden bulunması hem de yazılımın amacına uygun olup olmadığının anlaşılması açısından
yazılım testlerinin erkenden gerçekleştirilmesi faydalı olacaktır. Bir sonraki ilke erken test ile ilgilidir.

İlke 3: Yazılım testi dediğin erken yapılmalıdır.

Yazılım testi, Yazılım Geliştirme Yaşam Döngüsü’nde olabildiğince erken başlamalıdır.

Her test her aşamada gerçekleştirilemez ancak Yazılım Geliştirme Yaşam Döngüsü içerisinde her aşamada mümkün olan testler gerçekleştirilmelidir. Yazılım testi
işlemine ne kadar erken başlanırsa, yazılım bileşenlerindeki hatalar o kadar hızlı bir şekilde tespit edilir ve tespit edilen hatalar o kadar hızlı bir şekilde düzeltilir.
Ayrıca yazılım projesinin maliyeti açısından da teste erken başlanmalıdır. Bir yazılımda ne kadar ileri seviyede bir hata ortaya çıakrsa, o hatayı düzeltmek için
harcanacak maliyet de artacaktır. Üstelik yapılan araştırmalardan bu maliyetin doğrusal oalrak değil üstel olarak arttığı görülmüştür. Şekil 1.2.’de örnek bir hata
düzeltme maliyeti verilmiştir (Tayar, 2010). Bu sebeple yazılım testlerine mümkün olduğunca erken başlanmalıdır.

4
Şekil 1.2. Yazılım Hata Düzeltme Maliyeti

İlke 4: Kusursuz ve her şeyi kapsayan bir yazılım test yapmak mümkün değildir.

Bir yazılım ürünündeki olası tüm seçenekleri değerlendiren, tüm olasılıkları ele alan bir yazılım testinin gerçekleştirilmesi mümkün değildir. Yazılım geliştirici ekipler de
bunu kabul etmekte ve planlamalarını buna göre yapmaktadır. Buna göre yazılım geliştirici ekipler kusursuz ve her şeyi kapsayan bir test hedeflemek yerine risk
oranına göre, optimum zaman ve maliyetle en yüksek miktarda test yapmayı hedeflemektedir. Bilmek gerekir ki bir yazılımda hataların dağılımı yazılım ürünlerinde
eşit şekilde değildir. Bu sebeple hangi hataların incelenmesi gerektiği gibi kısımlara da önceden karar verilmelidir.

İlke 5: Yazılımlardaki hatalar kümelenmiş şekilde bulunur.

Bir elektronik eşyada, bir projede, bir sınav kağıdında ve dünyadaki pek çok yapılanmada olduğu gibi yazılımlarda da %80 - %20 prensibi geçerlidir. Bu prensip
yazılımlardaki hataların %80’inin yazılım modüllerinin %20’sinde; yazılımlardaki hataların %20’sinin ise yazılım modüllerinin %80’ininde bulunması anlamına
gelmektedir. Bus ebeple bir yazılım modülü test edilirken çok fazla hata çıkması o yazılımın diğer modüllerinde de bu kadar hata yoğunluğu olduğu; ya da bir yazılım
modülünde hiç hata çıkmaması, diğer yazılım modüllerinde de hata olmadığı anlamına gelmez.

İlke 6: Yazılım testinde tarım ilacı paradoksu oluşabilir.

Tarımda bir tarladaki ya da bahçedeki böceklerin yok edilmesi ya da etkisizleştirilmesi için çeşitli tarım ilaçları kullanılmaktadır. Ancak arka arkaya aynı tarım ilaçları
kullanıldığı takdirde bu tarım ilaçları bir süre sonra böcekleri bulamamaya ve/veya etkisiz hale getirmemeye başlar. Aynı durum insan vücudundaki kimi ilaçlar için de
geçerlidir. İnsanlar aynı antibiyotik ilacını uzun süre ve yanlış bir şekilde kullandıklarında o antibiyotik artık vücuda bir fayda vermemeye başlar. Bu prensip yazılım
testinde de geçerlidir. Yazılım modülleri de sürekli aynı şekilde, aynı verilerle test edildiğinde bir süre sonra artık hataları bulamamaya başlar. Bu durumun üstesinden
gelmek için, test senaryolarının düzenli bir şekilde incelenmesi, sıklıkla gözden geçirilmesi, gerekli oldukça güncellenmesi gerekmektedir. Ayrıca yazılımlar üzerinde
sürekli olarak aynı test teknikleri uygulanmamalı; test teknikleri de güncel gelişmelere göre revize edilmelidir.

İlke 7: Yazılım testi yazılımın içeriğine bağımlıdır.

Ne kadar “yazılımlar şu şekilde test edilmelidir”, “yazılımlar test edilirken şu gibi kurallar uygulanmalıdır” gibi genellemeler yapılsa da aslında her yazılımda yapılacak
test yazılımın içeriğine bağlıdır. Bir e-ticaret sitesini, bir oyunu, bir mobil uygulamayı, bir masaüstü yazılımını, bir web tarayıcısını, bir ofis yazılımını, bir POS sistemini,
bir ATM sistemini ve diğer tüm yazılımları test etmek birbirinden farklı olacaktır ve her yazılım test edilirken kendisine özgü verilerin kullanılması gerekmektedir.

1.4. Yazılım Test Uzmanlarının Yapması ve Yapmaması Gerekenler

Bir yazılım ürününün test edilmesi esasında oldukça fazla sayıda adımdan oluşan bir süreçtir. Aşağıda bu adımlar belirtilmiş ve açıklanmıştır (Kuhn ve diğ., 2004;
Jorgensen, 2008; Craig ve Jaskiel, 2002).

 Geliştirilecek olan yazılım ürününü tanımak

 Müşteri istek ve ihtiyaçlarını anlamak

 Risk analizi yapmak

 Test zamanlarını belirlemek

 Test planını oluşturmak

 Kullanıcı durum ve senaryolarını belirlemek

 Senaryoları risk durumlarına göre sınıflandırmak

 Birim testleri yapmak

 Duman testleri yapmak

 Hataları raporlamak

 Risk seviyesi yüksek olan test senaryolarını tekrar test etmek

 Çözülen hataları test edip, müşteriden onay almak

 Test raporu yayınlamak

Geliştirilecek olan yazılım ürününü tanımak: Bir yazılım test uzmanı, test edeceği yazılım ürününün özelliklerini bilmelidir. İlke 7’de de açıklandığı gibi yazılım
testi içerik bağımlıdır ve her yazılım ürününün kendine özgü özellikleri mevcuttur. Dolayısıyla yazılım test uzmanı bir e-ticaret sitesini mi, bir oyunu mu, bir mobil
uygulamayı mı, bir masaüstü yazılımını mı, bir web tarayıcısını mı, bir ofis yazılımını mı, bir POS sistemini mi, bir ATM sistemini mi yoksa başka özellikleri olan bir

5
yazılımı mı test ettiğini bilmelidir. Ayrıca her yazılım ürününün kendi içerisinde de özellikleri bulunabilmelidir ve yazılım test uzmanı bunları da bilmeli ve bunlara göre
yazılım test senaryoları oluşturmalıdır.

Müşteri istek ve ihtiyaçlarını anlamak: Bir yazılım bileşenini veya sistemi test ederken karar verilmesi gereken en önemli hususlardan biri bu yazılım bileşeni
veya sisteminin müşteri istek ve ihtiyaçlarına uyumlu olup olmadığıdır. Buna karar verebilmek için de elbette ki müşterilerin istek ve ihtiyaçlarının net bir şekilde
anlaşılması gerekmektedir. Müşterilerin istek ve ihtiyaçları tam olarak anlaşılamadığı takdirde, oluşturulacak olan yazılım bileşeni veya sistemin düzgün bir şekilde
oluşturulması, amaca uygun olması mümkün olmayacaktır. Bu da yazılım testinin de boşa yapılması anlamına gelecektir. Dolayısıyla müşterinin istek ve ihtiyaçlarını
anlamak yazılım testi açısından çok önemli bir husustur.

Risk analizi yapmak: Herhangi başka bir üründe olduğu gibi yazılım ürünlerinde de test işlemi gerçekleştirilirken ne gibi durumlarla karşı karşıya kalınabileceği
bilinmelidir, diğer bir deyişle iyi bir risk analizi yapılmış olmalıdır. Bu sayede önceden hazırlıklı olarak test yapılır ve çok daha faydalı bir test süreci geçirilmiş olur.

Test zamanlarını belirlemek: Yazılım testi işlemi Yazılım Geliştirme Yaşam Döngüsü içerisinde herhangi bir zamanda yapılabilir. Bir teztin ne kadar zaman boyunca,
kaç kez yapılacağına karar vermek de yazılım test işleminin en önemli hususlarından biridir. Gereğinden az yapılan test işlemi hataların tamamının bulunamaması ile
sonuçlanırken, gereğinden fazla kez yapılan test işlemi ise zaman, para ve emek israfına neden olabilecektir. Dolayısıyla yazılım testinin zamanının belirlerlen de bir
optimum seviye bulunmalıdır.

Test planını oluşturmak: Bir yazılım ürünü test edileceği zaman öncelikle bu ürünün test edilmesiyle ilgili bir plan geliştirilmelidir. Bu plan içerisinde bu ürünün ne
şekilde, hangi teknikler kullanılarak test edileceği, hangi verilerin kullanılacağı, test işleminin kaç kez ve ne kadar süreyle gerçekleştirileceği gibi maddeler
bulunmalıdır.

Kullanıcı durum ve senaryolarını belirlemek: Test planı oluşturmanın bir aşaması olarak ifade edilebilecek olan kullanıcı durum ve senaryolarını belirlemek
işlemi, bir yazılım ürünü test edilirken kullanıalcak olan tekil durumların ya da çoklu durumlardan oluşan senaryoların oluşturulması olarak ifade edilebilir. Bir ATM
yazılımı test edilirken kartın takılması ve şifre girilmesi birer kullanıcı durumu iken, belli bir miktarda paranın çekilmeye çalışılması bir kullanıcı senaryosudur. Çünkü
belli bir miktar para çekilmeye çalışılırken yapılan birçok doğru ya da yanlış işlem mevcuttur. Kartın takılması, şifrenin girilmesi, şifrenin doğru olup olmadığının
kontrol edilmesi, hesapta talep edilen miktarda paranın bulunup bulunmadığının kontrol edilmesi, ATM cihazı içerisinde talep edilen miktarda paranın bulunup
bulunmadığının kontrol edilmesi, kullanıcının günlük para çekme limitinin uygun olup olmaması gibi birçok kontrol işleminin gerçekleştirilmesi gerekmektedir. Benzer
şekilde bir öğrenci işleri otomasyonunda ders tablosunun açılması bir kullanıcı durumu iken, öğrencinin kaldığı derslerin tespit edilmesi bir kullanıcı senaryosudur.
Çünkü öğrencinin kaldığı dersler tespit edilmeye çalışılırken yapılan birçok doğru ya da yanlış işlem mevcuttur. Öğrencinin bilgilerinin tespit edilmesi, ders bilgilerinin
tespit edilmesi, öğrenci listesinde yer alan derslerden aldığı notların tespit edilmesi, bu notlar içerisinde hangilerinin geçme hangilerinin kalma anlamına geldiğinin tespit
edilmesi gibi birçok işlem gerçekleştirilmelidir.

Senaryoları risk durumlarına göre sınıflandırmak: Bir önceki maddede yazılım test işlemleri gerçekleştirilirken kullanıcı durum ve senaryolarının belirlenmesi
gerektiği ifade edilmiştir. Ancak kimi zaman yazılımlarda test edilmesi gereken durum ve senaryoların sayısı çok fazla olabilmektedir. Bu durumda yazılım test
uzmanlarının yapması gereken en önemli işlemlerden biri kullanıcı durum ve senaryolarını risk durumlarına göre sınıflandırmaktır.
En riskli durum ve senaryoların ilk olarak test edilmesi, telafisi mümkün olmayan hataların oluşmasını engelleyecek bir husustur.

Birim testleri yapmak: Birim bir yazılım ürünündeki en en alt seviyedeki elemanlara verilen isimdir. Yazılım ürünlerinde ilk test birimler üzerinde yapılan birim
testleridir. Daha sonra test edilen birimler birleştirilerek test edilir, sonrasında farklı modüller birleştirilerek test edilir ve en son tüm sistem test edilir. Buna göre birim
testi hataların en erken aşamada bulunması açısından oldukça büyük önem arz etmektedir.

Duman testleri yapmak: Duman testi, bir yazılım ürününün ayrıntılı bir şekilde test edilmesinden önce o üründe yer alan en önemli fonksiyonların hızlı bir şekilde
test edilmesi anlamına gelmektedir. Yazılım test uzmanının duman testi yapması oldukça önemlidir çünkü bu sayede yazılım ürününün durumu hakkında genel bir bilgi
elde edilmiş olur ve sonraki süreçteki ayrıntılı testlere bu şekilde daha kolay karar verilir.

Hataları raporlamak: Hataları bulmak, yazılım test uzmanının görevidir ancak hataların düzeltilmesi yazılım test uzmanının doğrudan görevi değildir. Hataların
düzeltilmesi işlemi, yazılım geliştiricilerin, analistlerin, müşterilerin, kullanıcıların hep birlikte ele alması gereken bir konudur çünkü hataların kaynaklandığı noktaya
bağlı olarak düzeltilmesi için yapılması gerekenler de değişecektir. Bütün bu sebeplerden ötürü yazılım test uzmanları yaptıkları testler sonucunda tespit ettikleri
hataları başarılı bir şekilde raporlamalı ve yazılım geliştirme ekibinin diğer üyelerine konu ile ilgili gerekli bilgileri sunmalıdır.

Risk seviyesi yüksek olan test senaryolarını tekrar test etmek: Her test senaryosunun risk seviyesinin aynı olmadığı daha önce de ifade edilmişti. Risk
seviyesi yüksek olan bazı test senaryolarını tekrar tekrar test etmek gerekebilir. Çünkü bazen böyle durumlarda test senaryolarının bir kez test edilmesi tüm hataların
tespit edilmesini sağlayamayacaktır.
Buna göre yazılım test uzmanlarının yapması gereken işlemlerden biri de risk seviyesi yüksek olan test senaryolarını tekrar test etmektir. Bu tekrarın kaç kez
yapılması gerektiği, yazılım modülünün durumuna göre değişebilir.

Çözülen hataları test edip, müşteriden onay almak: Daha önce de ifade edildiği gibi bir yazılım test uzmanının tek görevi hataları bulmak değildir. Bulunan
hataların çözümleri ile ilgili de görevleri olabilmektedir. Bir yazılım test uzmanı kimi zaman bulunan hataların çözümü ile ilgili de tavsiyelerde bulunabilmektedir. Ancak
bundan daha önemlisi bir hata çözüldüğü zaman bu hatanın yeniden test edilmesi ve sonrasında için müşteriden onay alınmasıdır. Bu sayede yapılan testin gerçek
anlamda bir anlamı olabilmektedir. Yoksa hatalar bulunup düzeltilmezse veya yapılan düzeltmeler için müşterilerden onay alınmazsa bu durumda sadece yazılım testi
yapılmış olur, herhangi bir işe yaramaz.

Test raporu yayınlamak: Yazılım mühendisliğinin en önemli aşamalarından biri dokümantasyondur. Yazılım testi işlemi gerçekleştirilirken de dokümantasyon
oluşturmak çok önemlidir. Test raporu adı verilen bu dokümantasyonda

 hangi tür testlerin uygulandığı, 

 uygulanan testlerin kaç kez uygulandığı,

 uygulanan testlerin hangi modüllere uygulandığı,

 testlerin uygulanması esnasında hangi verilerin kullanıldığı,

 testlerin uygulanması esnasında kullanılan verilerin nereden elde edildiği,

 test sonucunda ne gibi sonuçlar elde edildiği,

 test sonucunda elde edilen sonuçların önceki sonuçlarla karşılaştırılması ve testin değerlendirilmesi,

gibi hususlar yer almalıdır. Test raporu, tesi gerçekleştiren kişiler dışındaki kişilerin de bu testten haberdar olması ve uygulanan testlerin düzenli şekilde takip edilmesi
açısından önem arz etmektedir. Bir test uzmanının bütün bu işlemleri gerçekleştirirken sahip olması gereken bazı özellikler bulunmaktadır. Bu özellikler ve
açıklamaları aşağıda verilmiştir.
6
 Süreci iyi bilmelidir

 Metolodjisi iyi olmalıdır

 Planlı olmalıdır

 Şüpheci olmalıdır

 Net olmalıdır

 Test ortamlarını kullanmayı bilmelidir

Süreci iyi bilmelidir: Bir yazılım test uzmanı her ne kadar yazılım içerisindeki analiz, tasarım, programlama gibi diğer işlemleri yapmasa da bu işlemlerin nasıl
gerçekleştirildiğini ve süreci bilmelidir. Esasında sadece yazılımda değil gerçek hayattaki tüm testlerde de test edilen ürünün ya da hizmetin sürecinin iyi bir şekilde
bilinmesi gerekmektedir. Süreç iyi bilinmediği takdirde hataların nereden kaynaklandığı, ileride buna benzer bir hatanın ortaya çıkıp çıkmayacağı, oluşan hataların
nasıl düzeltilebileceği gibi unsurların tespit edilmesi mümkün değildir.

Metolodjisi iyi olmalıdır: Yazılım testinde ve tüm diğer testlerde belli metodolojiler izlenmelidir. Bu sayede test işlemi gerçekleştirilirken eksik bir unsur
bırakılmamış olur.
Eğer bir metodoloji izlenmezse ve test işlemi rastgele olarak yapılırsa arada test edilmesi gerektiği halde test edilmeyen modüller, test işlemi içerisinde kullanılması
gerektiği halde kullanılmayan veriler vb kalabilecek ve testin performansı düşebilecektir.

Planlı olmalıdır: Bir önceki maddeye paralel şekilde yazılım test uzmanının planlı şekilde test işlemi gerçekleştirmesi gerekir. Bu sayede arada eksik modül ve eksik
veri kalması durumu söz konusu olmayacaktır.

Şüpheci olmalıdır: Bir yazılım test uzmanı şüpheci olmalı ve verilenle yetinmemelidir.
Diğer bir deyişle sadece belli sınırlar içerisinde test yapmamalı, bir yazılımda her türlü durumun söz konusu olabileceğini bilmeli ve sadece olumlu testleri değil
olumsuz testleri de yapmalıdır. Bu test türleri ve kavramlar ileriki bölümlerde daha net bir biçimde açıklanacaktır.

Net olmalıdır: Bir yazılım test uzmanı yazdığı senaryolarda net olmalı ve bu senaryoları herkesin anlamasını sağlamalıdır. Öyle ki yazılım test uzmanı görev
değiştirdiğinde ya da projeden ayrıldığında bu senaryolar yine takip edilebilmelidir.

Test ortamlarını kullanmayı bilmelidir: Yazılım testlerinin önemli bir kısmında test yazılımları kullanılmaktadır, ayrıca otomasyonlar dışında da test edilecek
modüllerin ve verilerin belirlenmesi, verilerin elde edilmesi, test sonuçlarının oluşturulması gibi işlemler esnasında farklı test yazılımları ve ortamları kullanılmaktadır.
Yazılım test uzmanları bu ortamları iyi bir şekilde bildikleri takdirde daha başarılı test sonuçları elde edebilecektir.

Sonuç olarak bir test uzmanının yapması ve yapmaması gerekenler aşağıdaki şekilde özetlenmiştir: Bir yazılım test uzmanı,

 hataları bulmalıdır,

 hataları mümkün olduğunca erken bulmalıdır,

 hataların çözüldüğünden emin olmalıdır ancak hataları kendisi çözmemelidir,

 iyi niyetle test yapmamalıdır,

 gereksinimler olmadan test etmemelidir.

Bölüm Özeti
Günümüzde her alanda yazılımların kullanıldığını düşünüldüğünde, “Bir yazılımın gereksinimleri karşılayıp karşılamadığını, uygun şekilde hazırlanmış test senaryoları ile
hata bulma amaçlı yapılan çalışmalar” olarak tanımlanabilecek olan yazılım test işleminin ne kadar önemli olduğunu kolayca anlaşılabilir. Yazılım geliştiricileri, yazılım
testçileri, yazılımı kullananlar, bilişimciler ve hemen herkes tarafından yazılımların hatasız olamayacağı kabul edilmektedir. Ancak yazılımlarda hatanın minimuma
indirilmesi, sistemleri tamamen çökertecek hataların önlenmesi, yapılabilecek hataların önceden görülmesi ve önlemlerin önceden alınması mümkün olabilmektedir.
Bu sebeple yazılım test çalışmaları her geçen gün daha büyük önem kazanmaktadır. Yazılım testi aynı zamanda, ileriye dönük olarak yazılımların geliştirilme
masraflarını azaltmayı, herhangi bir yazılım bilşeninin kalitesini ölçmeyi, hata yapılsa bile hatanın yenilenmesini önlemeyi, zaman ve maliyet tasarrufu yapmayı ve
yazılım geliştiriciler ve kullanıcılar açısından saygınlık kazanmayı sağlayabilmektedir. Bu sebeple yazılım test işlemlerinin doğru zamanda, doğru kişiler tarafından ve
doğru yöntemlerle yapılması gerekmektedir.

Yazılım testi hgenel kanının aksine yazılım geliştirildikten sonra değil, yazılım geliştirilmeden önce başlamalı ve tüm yazılım süreci boyunca devam etmelidir. Yazılım
testine ne kadar erken başlanırsa potansiyel ve mevcut hatalar o kadar erken bulunabilir, bu hataları düzeltmek o kadar erken mümkün olabilir ve böylece işlem hem
daha az maliyetle hem de daha kısa sürede halledilebilir. Ancak yazılım testine genellikle erkenden başlanmadığı için yazılımlardaki hataların bulunması ve düzeltilmesi
geç dönemlere kalmakta ve yüksek maliyetlere sebep olmaktadır. Bu da yazılım geliştirici ve kullanıcıların yazılım tesi çok zaman alıcı ve çok maliyetli bir işlemmiş
gibi bir yanılgıya düşmesine sebebiyet vermektedir.
Yapılan bazı yanlış uygulamalardan ötürü yazılım kalite ve testi konusunda buna benzer birçok “doğru bilinen yanlış” bulunmaktadır. Örneğin yazılımın ancak
tamamlandıktan sonra test edilebileceği, bir yazılım ürünündeki tüm kombinasyonların test edilmesinin mümkün olduğu, test edilmiş yazılım ürününde asla hata
bulunmadığı, yazılım hatalarının sadece testçiler yüzünden oluştuğu gibi inanışlar tamamen yanlıştır.

Her konuda olduğu yazılımları test ederken de belli kurallara ve ilkelere uymak gereklidir. Yazılım testi rastgele olarak değil sistematik olarak gerçekleştirilmesi
gereken bir proses olduğundan bu kural ve ilkeler özellikle önem arz etmektedir. Örneğin yazılım testine mutlaka erkenden başlanması, yazılımdaki hataların kimi
zaman kümeler halinde olmasından dolayı yazılım test uzmanını yanlış yönlendirebilmesi, yazılım testinin içerik bağımlı olması gibi durumlara mutlaka dikkate dilmesi
gerekmektedir.

Yazılım testi yazılım geliştirmenin içerisinde yer alan bir süreçtir ancak çoğu noktada yazılım geliştirmeden farklılıklar gösterir. Buna paralel olarak yazılım test
uzmanlarının da yazılım geliştiricilerden farklı özelliklere sahip olması gerekir. Örneğin şüpheci ve sistematik olmalıdırlar ki doğru test senaryolarını deneyebilsinler;
hızlı olmalıdırlar ki mümkün olduğunda çok test senaryosu deneyebilsinler, süreci iyi bilmelidirler ki potasniyel hataları tahmin edebilsinler. Bunun yanında yazılım test
uzmanları bir hata bulduğunda o hatayı çözmemeli ancak çözüm önerilerinde bulunmalıdır.

Kaynakça

D. R. Kuhn, D.R. Wallace,  A.M. Gallo, Software fault interactions and implications for software testing, IEEE Transactions on Software Engineering, Sayı. 30(6), 
Sayfa: 418-421, 2004.
7
Erhan Tayar, Hata Düzeltme Maliyeti, http://yazilimtestgaraji.blogspot.com/2010/04/hata-duzeltme-maliyeti.html, 2010.

G. J. Myers, C. Sandler, T. Badgett, The Art of Software Testing, John Wiley & Sons Publications, 2012.

H. Freeman, Software testing, IEEE Instrumentation & Measurement Magazine, Sayı. 5 (3), Sayfa: 48-50, 2002.

J. A. Whittaker, What is software testing? And why is it so hard?, IEEE Software, Sayı. 17(1), Sayfa: 70-79,  2000.

Javaturk, http://www.javaturk.org/yazilim-hayat-dongusu-biraz-da-gulelim, 2014.

M. G. Limaye, Software Testing Principles, Techniques and Tools, Mc Graw Hill, 2009.

P. C. Jorgensen, Software Testing A Craftsman's Approach, Auerbach Publications, 2008.

R. D. Craig, S. P. Jaskiel, Systematic Software Testing, Artech House Publishers, 2002.

S. K. Singh, Amarjeet Singh, Software Testing, Vandana Publications, 2019.

Yazılım Hataları, https://www.pngindir.com/png-ybdka6.

Ünite Soruları

Soru-1 :

Aşağıdakilerden hangisi yazılım testinin sebeplerinden biri değildir?

(•) - daha önce yapılan hataların tekrarlanmasını önlemek

(•) - hatasız bir yazılım oluşturmak

(•) - zaman ve maliyet tasarrufu yapmak

(•) - kaliteyi ölçmek

(•) - ileriye dönük kodun geliştirilme masraflarını azaltmak

Cevap-1 :

hatasız bir yazılım oluşturmak

Soru-2 :

Yukarıdaki şekilde bir projenin nasıl dokümante edildiği ile ilgili esprili bir yaklaşım verilmiştir. Bu şekilde dokümantasyon ile ilgili hangi durum
anlatılmak istenmiştir?

(•) - çok uzun olması

(•) - çok maliyetli olması

(•) - çok uzun sürmesi

(•) - doğru bir şekilde yapılmaması

(•) - çok fazla ayrıntı gerektirmesi

8
Cevap-2 :

doğru bir şekilde yapılmaması

Soru-3 :

 Bir yazılımda sadece kodların değil algoritmaların da test edilebiliyor olması hangi “Doğru Bilinen Yanlış” ile ilgili bir durumdur?

(•) - Yalnızca tamamen geliştirilmiş yazılım ürünler test edilir.

(•) - Bir yazılım ürününü baştan sona, komple test yapmak mümkündür.

(•) - Yazılım testi çok zaman tüketen bir işlemdir.

(•) - Yazılım testi çok pahalı bir işlemdir.

(•) - Yazılım testi çok yavaş bir işlemdir.

Cevap-3 :

Yalnızca tamamen geliştirilmiş yazılım ürünler test edilir.

Soru-4 :

Aşağıdakilerden hangisi bir yazılım test uzmanının doğrudan görevi değildir?

(•) - yazılımcılara tavsiyelerde bulunmak

(•) - hataları çözmek

(•) - hataların durumu ile (artış, azalma) ilgili analiz çıkarmak

(•) - test planı oluşturmak

(•) - hataları bulmak

Cevap-4 :

hataları çözmek

Soru-5 :

Yukarıdaki şekil, hangi yazılım test ilkesi ile ilgilidir?

(•) - Yazılım testi dediğin erken yapılmalıdır.

(•) - Kusursuz ve her şeyi kapsayan bir yazılım test yapmak mümkün değildir.

(•) - Yazılımlardaki hatalar kümelenmiş şekilde bulunur.

(•) - Yazılım testinde tarım ilacı paradoksu oluşabilir.

(•) - Yazılım testi içerik bağımlıdır.

9
Cevap-5 :

Yazılım testi dediğin erken yapılmalıdır.

Soru-6 :

Uygulanan testlerin hangi modüllere uygulandığı gibi bir bilginin aşağıdakilerin hangisinde yer alması beklenir?

(•) - Hata raporu

(•) - Yazılım raporu

(•) - Test raporu

(•) - Analiz raporu

(•) - Risk raporu

Cevap-6 :

Test raporu

Soru-7 :

Aşağıdakilerden hangisinin bir yazılım otomasyon aracındaki tek bir modülü temsil etmesi beklenmez?

(•) - Yazılım ürünü

(•) - Yazılım bileşeni

(•) - Birim

(•) - Sistem

(•) - Yazılım elemanı

Cevap-7 :

Sistem

Soru-8 :

TC Kimlik Numarası’nın girilmesi beklenen bir alanı tam anlamıyla test ederken kaç adet veri kullanılması gerekli olur?

(•) - 1

(•) - 3

(•) - 5

(•) - 100

(•) - sonsuz

Cevap-8 :

sonsuz

Soru-9 :

Yazılım testi yapan kişiler ile ilgili aşağıdakilerden hangisi yanlıştır?

(•) - herkes her yazılımı test edemez

(•) - herkes bir yazılıma aynı seviyedeki testleri uygulayamaz

(•) - herkes bir yazılıma aynı testleri aynı şekilde uygulayamaz

(•) - herkes bir yazılıma aynı testleri uygulayamaz

(•) - bazı yazılımları hiç kimse test edemez

Cevap-9 :

bazı yazılımları hiç kimse test edemez

10
2. YAZILIM HATALARI
Giriş
Yazılımla ilgili hemen herkes yazılımların hatasız ürünler olamayacağı konusunda hemfikirdir. Ancak bu durum, yazılımlardaki hataların önemsiz olduğu, bulunmalarına
ve düzeltilmelerine gerek olmadığı anlamına gelmez. Yazılımlardaki hataların tespit edilmesi ve düzeltilmesi, yazılımın doğru ve verimli çalışması açısından çok
önemlidir. Hataların doğru tespit edilmesi için hatalar hakkında bilgi sahibi olmak gereklidir. Bu bölümde yazılımlarda meydana gelebilen hata çeşitlerinden ve tarihte
çok farklı sebepler ile ortaya çıkmış büyük yazılım hataları ve sonuçlarından bahsedilmiştir.

2.1. Yazılım Hataları ile İlgili Kavramlar

Yazılım hataları ile ilgili çeşitli farklı kavramlar bulunmaktadır. İngilizce’de bu ayrım daha net iken Türkçe’de genellikle her yanlış duruma hata denmektedir, halbuki
her hata aynı olmadığı gibi her yanlış durum da hata değildir. Aşağıda yazılım hataları ile ilgili terimler, sıklıkla kullanılan İngilizce karşılıkları ve açıklamaları verilmiştir.

Hata (Bug): Bir bileşen ya da sistemin gerekli işlevini gerçekleştirmesini engelleyen her türlü durumdur. Doğru olmayan verilerin kullanılması, doğru olmayan
komutların kullanılması, doğru olmayan fonksiyonların tanımlanması, bir fonksiyona yanlış sayıda parametre beslenmesi, yazım yanlışı yapılması vb yazılım hatalarına
örnek olarak verilebilir. Hata, bileşen ya da sistem çalışırken ortaya çıkarsa daha büyük sorunlara ve arızalara neden olabilir.

Kusur  (Defect): Bir bileşen ya da sistemin gerekli işlevini gerçekleştirmesini engelleyen kusurlara verilen isimdir.  Sistemin farklı bir yapı ile uyumsuz olması,
sağlaması gereken kriterleri sağlamaması, güncellik problemi yaşaması örnek olarak verilebilir.

İnsan hatası (Error): Bir insan tarafından gerçekleştirilen ve doğru olmayan sonuç üreten her türlü eylemdir. Burada insandan kastedilen genellikle programcıdır
ancak analist, müşteri,
test uzmanı gibi kişiler de bu kategori altında incelenebilir. Bu kavrama örnek olarak formülasyonların sisteme yanlış girilmesi, yanlış türde veri tanımlanması vb
verilebilir.

Arıza (Failure): Bileşen veya sistemin, beklenen teslim, servis veya sonuçtan sapmasıdır.
Bu kavram, hata, kusur ve insan hatasından daha büyük bir kavramdır ve genellikle bir ya da birkaç hata, kusur ve insan hatasının sonucu olarak ortaya çıkar.
Sistemin çalışmaması ya da çalışsa bile yanlış sonuç vermesi arıza olarak kabul edilebilir. Bir arızanın genellikle fiziksel veya fonksiyonel göstergeleri bulunmaktadr.
Örneğin, arıza durumundaki bir sistemin yavaş çalışması, yanlış çıktılar üretmesi veya tamamen çalışmasını sonlandırması beklenebilen durumlar arasında
gösterilebilir.

Anomali (Anomaly): Gereksinimden, tasarımdan, kullanıcı dokümanından, standartlardan, beklenti, tecrübe veya algıdan sapma durumu olarak ifade edilebilir.
Anormallikler gözden geçirme, test, analiz, derleme veya ürünün kullanımı sırasında ortaya çıkabilir. Anomali her ne kadar sistemsel olarak olumsuz bir durum olsa
da müşteri/kullanıcı açısından her zaman olumsuz olmamaktadır. Örneğin bir e-ticaret sitesinde beklenenden daha çok müşterinin alışveriş yapması bir anomalidir, bu
anomali sistem açısından bir sorundur çünkü sistemin kaldıramayacağından fazla yük üzerine yüklenmektedir; ancak müşteri/kullanıcı açısından teorikte bir sorun
değildir çünkü daha fazla kazanç kazanmaları mümkün olabilecektir.
Tabi yazılım sisteminin bu yükü kaldıramaması ve tamamen çökmesi söz konusu olursa bu durumda müşteri/kullanıcı için de büyük bir problem olabilecektir.

Bunlar dışında, çok sık kullanılmamakla beraber Türkçesi yine kusur olarak belirlenmiş olan fault, yanlış olarak belirlenmiş olan mistake ve İngilizce – Türkçe
karşılıkları aynı şekilde kullanılan problem kavramları da mevcuttur. Ayrıca hatalar bunun dışında aşağıdaki şekilde de sınıflandırılabilir (Şen, 2020).

 Uygulama Geliştirme Aşamasında Yapılan Hatalar

o Sözdizimi Hataları (Syntax Errors)

o Çalışma Zamanı Hataları (Run Time Errors)

o Mantıksal Hatalar (Logical Errors)

 Mimari ve Tasarım Hataları

 Belgelendirme Hataları

Uygulama Geliştirme Aşamasında Yapılan Hatalar: Hatalar yazılım geliştirme sürecinde kaçınılmazdır. Geliştiricinin kendi kendine test ettiği zamanları bile kolay
kolay ortaya çıkmayabilirler. Hiç hata içermeyen bir yazılım geliştirmek imkânsızdır, yalnız, doğru bir hata yönetimi ile hataları azaltmak mümkündür. Uygulama
geliştirme aşamasında yapılan hatalar şu şekilde gruplanabilir:

 Sözdizimi Hataları (Syntax Errors) : Kullanılan programlama dilinin kurallarına aykırı olan ifadelerinin kullanılmasından kaynaklanır. Bazı durumlarda hemen
fark edilebilir, yalnız, gözden kaçtığı durumlar da olabilir. Bu durumlarda derleyici tarafından yapılan uyarılar vasıtasıyla, hatanın yapıldığı satır numarası öğrenilebilir.
Ayrıca, günümüzde kullanılan çeşitli IDE’ler (Integrated Development Environment – Bütünleşik Geliştirme Ortamı) sayesinde bu hatalar hemen fark edilmektedir
ve/veya otomatik olarak düzeltilmektedir. Şekil 2.1.’de çeşitli söz dizimi hataları görülmektedir (Magee, 2018).

11
Şekil 2.1. Sözdizimi Hataları Örnekleri

 Çalışma Zamanı Hataları (Run Time Errors): Çalışma zamanı (“run time” ya da “compile time”) hataları, programın çalıştırıldığı anda ve/veya yazılımın
müşterinin makinesine kurulduğu anda ortaya çıkan hatalardır. Genelde, bir fonksiyon belirli varsayımlar üzerine kodlanır, ancak kullanıcının programı çalıştırdığı
zaman istenilen o şartlar sağlanmadığı için bu hatalar oluşur. Dolayısıyla, bu tür hataların ne zaman oluşabileceğini tahmin etmek zordur. Günümüzde, bu tür hataları
önleyebilmek için “istisnaî durumlar” oluşturulmaktadır.  Olmayan bir dosyaya veri yazmaya çalışmak;  olmayan bir dosyayı okutmak; yazılım içerisinde istenilen
dosyanın belirtilen yerde bulunamaması gibi durumlar bu tür hataların birer örneğidir.

 Mantıksal Hatalar (Logical Errors): Programın kendisinden beklendiği sonuçlardan farklı sonuçlar üretmemesi ve beklenenden farklı bir sırada çalışması
olarak ifade edilebilir. Algoritmanın doğru bir yol izleyecek şekilde tasarlanması önemlidir.
Çünkü mantıksal hataların tespit edilmesi zordur. Örneğin; matematiksel bir hesabın yapılması gereken bir uygulamada, kodlama esnasında * (çarpı) yerine yanlışlıkla
+ (artı) ifadesinin kullanılması, yanlış sonuçlar vererek, buna bağlı olan tüm diğer hesapları da yanlış sonuçlar vermesine neden olur. Bu tür hatalar, büyük sorunlar
yaratabilir.

Mimari ve Tasarım Hataları: Yazılım tasarımcıları, müşterinin istek ve gereksinimlerini yazılıma çevirdiği zaman çeşitli hatalar yapmaktadır. Yaygın ve tipi olarak
yapılan hataların bazıları şu şekildedir:

 Geliştirilecek olan yazılımın eksik ve yetersiz incelenmesi

 Her bir yazılım bileşeninin (sorumluluk, iletişim) net olmayan rolü

 Belirtilmemiş birincil veri ve veri işleme sınıfları

 Gereksinimleri yerine getirmek için kullanılan yanlış algoritmalar

 Yanlış iş veya işleme sırası

 İş süreç tasarımının zayıf kalması

 Geliştirilen uygulamanın % 80’inin istisnai durumlar ve hatalar üretmesi

Belgelendirme Hataları: Yazılan kodlar, ortalama olarak 3 – 6 ay içerisinde unutulmaktadır. Dolayısıyla, bir hata ile karşılaşınca, bakılması gereken koda en son 6
ay önce bakıldı ise, hatanın nerden geldiğini bulmak ve hatta hangi fonksiyonun ne işe yaradığını anlamak zaman alır. Ancak, geliştiricinin elinde ilgili kod parçası
hakkında ne iş yaptığı, neyi ve nasıl hesapladığı konusunda bilgiler içeren bir belge olursa, hem hatırlaması kısa zaman alır hem hatayı daha hızlı bulma imkânı olur.
Özellikle de, bu geliştirici ekibe yeni gelen birisi ise, kod hakkında bir belgenin olmaması onun durumunu daha da zorlaştıracaktır.  Bu yüzden, yazılım geliştirme
sürecinin önemli ve olmazsa olmaz aşamalarının birisi de belgelendirmedir.

Hataların ve kusurların doğru bir şekilde tespit edilebilmesi için hata/kusur sınıflandırmasının (bug/defect taxonomy) başarılı bir şekilde yapılmış olması gereklidir.
Hata/kusur sınıflandırması, hataların hiyerarşik kategorilere ayrılarak özellikle hata bazlı testlerde tekrar kullanılmasını sağlayan yöntemdir ve hataların önem/risk
derecesine göre, oluşma şekline göre veya farklı kriterlere göre gruplandırılmasını sağlar. Bu sayede hangi modülde hangi tip hatanın aranacağı, hangi tip hata
bulunduğunda nasıl bir çözüm oluşturulması gerektiği gibi konular daha kolay bir biçimde oluşturulabilmektedir. Hatalar/kusurlar örneğin performans ile ilgili, güvenlik
ile ilgili, uyumluluk ile ilgili olabileceği gibi yanlış yazılan bir kod neticesinde tüm sistemde hata/kusur olması durumu da söz konusudur.

Yazılımlardaki hataların ve sebeplerinin belirlenip, analiz edilip ortadan kaldırılması ile birlikte yazılımın hatasız hale getirmesi için gerçekleştirilen çalışmalar genellikle
hata ayıklama olarak adlandırılır. Bu çalışmaları gerçekleştirebilmek için kimi zaman hata ayıklama aracı olarak adlandırılan araçlar kullanılır. Bu araçlar bulunan
hataların özel olarak tekrar oluşturularak yazılımın durumunun incelenmesi ve ilgili hatanın bulunması için yazılımcılar tarafından kullanılan bir araçtır ve programcıların
yazılımı adım adım yürütmesine, herhangi bir komutta durdurmasına, değişkenlere değer atamasına ve ne değer aldığını gözlemesine olanak sağlar.

Yazılımlardaki hataların ayıklanabilmesi için hata yönetimi kavramı oldukça önemlidir.

Hata yönetimi, hataların farkına varılmasını, araştırılmasını, aksiyon alınmasını,  kaydedilmesini, sınıflandırılmasını, etkilerinin tanımlanmasını ve çözülmesini ele alan
sürece verilen isimdir. Bu süreçteki işlemlerin gerçekleştirilmesi için kimi zaman hata yönetim aracı adı verilen araçlar kullanılmaktadır. Bu araçlar, hataların ve
değişikliklerin kaydedilmesini ve durumlarının izlenmesini, hataların atanmasını, düzeltilmesini ve tekrar test edilmesini izlemek ve kontrol etmek ve sonunda
raporlama gerçekleştirmek için kullanılır.

Bir yazılımın performansı ve kalitesi, içerisinde yer alan hata vb kavramların durumuna oldukça bağlıdır. Bu konu ile ilgili literatürde çeşitli sayısal değerler
tanımlanmıştır. Bu değerler, sıklıkla kullanılan İngilizce karşılıkları ve açıklamaları aşağıda verilmiştir.

 Hata/Kusur Yoğunluğu (Bug/Defect Density): Bir yazılım sistemi ya da bileşeninde bulunan hata/kusur sayısının sistemin büyüklüğüne oranı olarak tanımlanır.
Buradaki sistemin büyüklüğü, kullanılan sistem ve ele alınan duruma göre değişmekle beraber genellikle kod satır sayısı, sınıf sayısı, fonksiyon puanları gibi
büyüklükler kullanılarak tespit edilir.

 Hata/Kusur Tespit Yüzdesi (Bug/Defect Detection Percentage (DDP)): Bir test fazında bulunan hataların/kusurların sayısının, aynı fazda ve daha sonraki
fazlarda bulunan hataların/kusurların sayısına oranıdır.

 İnsan Hatası Toleransı (Error Tolerance): Yanlış girdiler olmasına rağmen bir sistem veya bileşenin normal operasyonuna devam edebilme yeteneği olarak
tanımlanır. Özellikle sistemlerin sağlamlık, kurtarılabilirlik gibi kriterlerinin tespit edilmesinde önemli rol oynar.

 Arıza Oranı (Failure Rate): Arıza sayısının belirli bir ölçü birimine göre oranlanması olarak ifade edilebilir. Bu kavrama örnek olarak belirli bir zamanda alınan
arıza sayısı ya da bilgisayar başına alınan arıza sayısı verilebilir.

 Arızalar Arasında Geçen Ortalama Süre (Mean Time Between Failures):

Bir sistemin arızaları arasında geçen ortalama zamandır. Ne kadar büyük bir değerse sistem o kadar az hata ile karşılaşıyordur ve o derece güvenilirdir anlamına
gelir.
Buna göre güvenilirlik büyüme modelinin bir parçasıdır.

Bazı durumlarda bir hatanın başka bir hatanın bulunmasını engellemesi söz konusu olabilir, hata maskeleme olarak adlandırılan bu durum, yazılım test uzmanlarının
işini oldukça zorlaştırmaktadır. Bu durumun oluşmasını engellemek için çeşitli işlemler yapılmaktadır. Örneğin “testi gerçekleştiren kişinin tecrübesinin test edilen
12
bileşen veya sistemde hangi yanlışların olabileceğinin tahmin edilmesinde kullanılması ve testlerin bu yanlışları ortaya çıkarmak üzere tasarlanması” olarak
tanımlanabilecek olan hata tahminleme işlemi bu konudaki önemli bir işlemdir. Bunun dışında elde edilen hatalarınd üzenli oalrak raporlanması ve belki bir hata veri
tabanı oluşturulması da hataların başarılı bir şekilde bulunmasını sağlayabilecek bir durumdur. Ayrıca yine hataların başarılı bir şekilde tespit edilebilmesi için literatüre
geçmiş olan çeşitli sistmeatik yaklaşımlar da bulunmaktadır. Aşağıda bu yaklaşımların isimleri, sıklıkla kullanılan İngilizce karşılıkları ve açıklamaları verilmiştir.

 Arıza Durumu ve Etki Analizi (ADEA)  (Failure Mode and Effect Analysis (FMEA)): Riskleri belirlemek, olası arıza durumlarını analiz etmek ve bunların
oluşmasını engellemeye çalışmak için kullanılan sistematik bir yaklaşımdır.

 Arıza Durumu, Etki ve Kritiklik Analizi (ADEKA) (Failure Mode, Effects, and Criticality Analysis (FMECA)): ADEA'nın daha gelişmiş halidir.
ADEA'ya ek olarak, arıza durumlarının olasılığı ile bunların sonuçlarının önemini göstermek için kullanılan kritiklik analizini de içermektedir. Bu analiz oldukça yüksek
olasılığa sahip arıza türleri ve onların önemini belirten sonuçlarına dikkat çeker. Böylece iyileştirici önlemlerin en değerli alana yönlendirilmesini sağlar.

 Kusur Ağacı Analizi (Fault Tree Analysis (FTA)): Kusurların nedenlerini analiz etmekte kullanılan bir yöntemdir. Bu yöntem, arızalar ile insan hataları ve dış
etkenler arasındaki mantıksal bağlantıları görsel olarak modeller.

Hatalar, kusurlar ve arızalar, yapılacak testlerin belirlenmesinde de önemli rol oynamaktadır. Kimi zaman test senaryolarını belirleme/seçme prosedürü bir veya daha
fazla hata kategorisinden hata bulmayı hedefleyen test senaryolarını belirlemeyi hedefler. Bunun dışında bir yazılım sistemine ya da bileşenine kasıtlı bir şekilde hata
eklenmesi ya da bir yazılım sisteminde ya da bileşeninde kontrollü bir şekilde arıza oluşturulması ile, söz konusu sistem ya da bileşenin içerisindeki hataların tespit
edilmesi, hatadan kendini kurtarabilme yeteneğinin ölçülmesi, arıza sonrasında, verilerin kaybolmaması veya bozulmaması ve bütün servis seviyelerinin korunması için
yapılan işlemlerin tespit edilmesi gerçekleştirilmektedir. Yine özel olarak güvenlik testlerinde, yazılım sistem ya da bileşenlerine özel olarak saldırılar gerçekleştirilerek
sistemin ne kadar güvenli olduğunun tespit edilmesi için çalışmalar yapılmaktadır.

Tarihteki ilk yazılım/bilgisayar hatası Şekil 2.2.’de verilmiştir. 1945’te Grace Murray Hopper isimli bir bilişimci, Mark II’nin prototipi üzerinde çalışırken kodunun
ısrarla çalışmadığını görmüş, yapılabilecek bütün yazılım testleri yapmış ve kodun hala çalışmadığını görünce donanımsal bir hata olabileceğini düşünerek sistemi
açmış ve şekildeki güve cinsi böcekle (bug) karşılaşmıştır. Bu böcek, bu sebeple tarihteki ilk yazılım/bilgisayar hatası olarak kabul edilmektedir. Yazılım/bilgisayar
hatalarına bug denilmesi bu eski tip bilgisayarlardan kalma bir terimdir. Yine bu terimden faydalanarak yazılımları hatadan yani böcekten arındırma işlemi ise
debugging (böcek ayıklama) olarak anılmaya başlanmıştır (Tarman, 2014).

Şekil 2.2. Tarihteki İlk Yazılım/Bilgisayar Hatası

2.2. Tarihte Yaşanmış En Önemli Yazılım Hataları

Yazılımlar farklı özelliklerdeki ekipler tarafından yazıldığı, farklı programlama dilleri, ortamlar, teknolojiler kullanılarak hazırlandığı ve çok karmaşık sistemler olabildiği
için hata yapılmasına çok meyilli sistemlerdir. Bunun dışında insanların da hata yapmaya eğilimli canlılar olması, yazılımların elle tutulur, gözle görülür yapılar
olmamasından dolayı kimi zaman doğru bir şekilde ölçülememesi ve kontrol edilememesi de yazılımlarda hata oluşmasını artıran unsurlardır. Bu gibi sebeplerden
ötürü maalesef literatürde çok fazla önemli ve kritik sonuçlar ortaya çıkaran yazılım hatası oluşmuştur. Bu kısımda bunlar arasında en trajik olan bazıları ele alınmıştır.

Bu hatalar;

 Mariner-1 Uzay Roketi Hatası

 Hartford Colesium Binası Hatası

 Sovyet Gaz Hattı Hatası

 Therac-25 Tedavi Cihazı Hatası

 Berkeley Unix Sisteminde Tampon Bellek Taşması Hatası

 Patriot Füzesi Hatası

 Pentium İşlemci Hatası

 Kerberos Rastgele Sayı Üretme İşlemi Hatası

 Denver Havalimanı Otomatik Bagaj Sistemi Hatası

 Arienne-5 Füzesi Hatası

 Mars Climate Orbiter Hatası

 Ulusal Kanser Enstitüsü Hatası

 Y2K Hatası

 Mercy Hastanesi Ölüm İlanları Hatası

13
 Michigan Hapishanesi Erken Tahliye Hatası

 World of Warcraft Hatası

 Los Angeles Havalimanı Hatası

 Google Malware Hatası

 Honda Yazılım Hatası

 Apple Maps Yön Hatası

 Knight Capital Group Finans Hatası

 Mahkeme Jüri Daveti Hatası

 Toyota Prius Aracı Hatası

şeklindedir.

Mariner-1 Uzay Roketi Hatası: 1962 yılında yaşanmış bir kazadır. Kağıda yazılan bir matematiksel formülün bilgisayarda kodlanırken yanlış bir şekilde yazılması
sonucunda oluşmuştur. Fortran'la yazılan yazılımda DO 3 I = 1,3 yerine DO 3 I = 1.3 yazılmış ve Fortran'da boşluklar anlam taşımadığı ve değişkenler ayrıca
belirtilmediğinden yazılım bir döngüye gireceğine, D03I değişkenine 1.3 değerini yüklemiş ve işlemlere devam etmiştir. Sonuç olarak roket fırlatıldıktan 4 dakika
sonra yörüngeden çıkmış ve herhangi bir zarar vermemesi için yok edilmiştir ve bu durum NASA’ya 80 milyon dolara mal olmuştur (Of, 2017). Şekil 2.3.’de
Mariner-1 Uzay Roketi gösterilmiştir (Wikpedia Mariner-1, 2021).

Şekil 2.3. Mariner-1 Uzay Roketi

Hartford Colesium Binası Hatası: 1978 yılında gerçekleşmiştir. Çoklu değişkene sahip matematiksel bir formülün hesaplanmasında işlem hatası yapılmıştır. Sonuç
olarak CAD yazılımı ile tasarlanan Hartford Colesium binası çökmüş, 90 milyon dolarlık zarara neden olmuştur (Times, 1978; History, 2017; Journal, 2018). Şekil
2.4’te Hartford Colesium Binası görülmektedir (Martin ve Delatte, 2001).

Şekil 2.4. Hartford Colesium Binası

Sovyet Gaz Hattı Hatası: 1982 yılında gerçekleşmiştir. Yazılan bir bilgisayar yazılımındaki bir güvenlik açığı sonucunda CIA ajanlarının geliştirdiği bir böcek
yazılım ile tarihin en büyük nükleer olmayan patlaması gerçekleşmiştir. Söylentiye göre, CIA’e bağlı çalışan operatörler Sibirya gaz hattını kontrol etmek üzere satın
alınan Kanada bilgisayar sistemine bir böcek yerleştirmiştir. Sovyetler Birliği’nin bu sistemi hassas Amerika Birleşik Devletleri teknolojisini gizlice satın alma ya da
çalma çabalarının bir parçası olarak aldığı iddia edilmektedir. Yine söylentiye göre, CIA, programı keşfetmiş ve onun geri tepmesini sağlamaya karar vermiştir.
Bunun için Sovyet incelemesinden geçecek, ama sonunda işletme anında başarısız kalacak bir ekipmanı araç olarak kullanmıştır. Böylece gezegenin tarihinde en
büyük nükleer olmayan patlama meydana gelmiştir (Wired, 2004; Risi, 2015).

Therac-25 Tedavi Cihazı Hatası: 1985-1987 yıllarında gerçekleşmiş ve maalesef ölümle sonuçlanmış bir yazılım hatasıdır. Kanser hastalarını iyileştirme amacıyla
kullanılan bir cihazda, hastalarda kullanılan radyasyon ışınlarının miktarını ayarlayan plakalar yazılımdan kaynaklı bir sorun yüzünden devreye girmemiştir ve bu
durumda bu cihazın o anda kullanılmakta olduğu 6 hastadan 3’ü aşırı radyasyona (normalin 100 katı) maruz kalması nedeniyle hayatını kaybetmiştir. Şekil 2.5’te
cihaz görülmektedir (Caballero, 2019).

Şekil 2.5. Therac-25 Tedavi Cihazı

Berkeley Unix Sisteminde Tampon Bellek Taşması Hatası: 1988 yılında oluşan tampon bellek yetersizliği sonucunda bir grup siyah şapkalı hacker birçok
bilgisayara sızmıştır. Sızılan bu bilgisayarların sayısının 2000-6000 arası olduğu düşünülmektedir. Bu durum ilk internet solucanı olarak ifade edilmektedir ve bu
solucana Morris Worm adı verilmiştir. Bu konuyla ilgili olan kod fonksiyonu gets() olarak ifade edilen bir standart girdi-çıktı kütüphanesi fonksiyonudur. Bu
fonksiyon ağ üzerinde bir metin satırının tamamını okuma işlemini gerçekleştirmektedir. Ancak maalesef gets() fonksiyonunun girdiyi sınırlamayla ilgili bir kontrolü
14
yoktur ve çok büyük bir girdi solucanın bağlanabildiği makinayı kontrolüne almasını sağlayabilir. Bu da görüldüğü üzere kimi zaman büyük hatalara yol
açabilmektedir. Bu hata sonucunda programcılar çalışan koddaki gets() fonksiyonunu kullanım dışı bırakmış; ama onu C programlama dilinin standart girdi-çıktı
kütüphanesinden çıkarmayı kabul etmemiştir (Museum, 1988; Intertech, 2013).

Patriot Füzesi Hatası: 1991 yılında gerçekleşmiştir. Zaman hesaplamasında kullanılan

24 bitlik sabit noktalı değişkende oluşan bir hata yüzünden 29 Amerikan askeri hayatını kaybetmiştir. Literatürde yer alan en ölümcül yazılım hatalarından biri olarak
tarihe geçmiştir (Intertech, 2013; Threat, 2018).

Pentium İşlemci Hatası: 1993 yılında gerçekleşmiştir. Yazılan yazılımdaki integer (tamsayı) türünde ve bu aralıkta olması gereken bir yapının, matematiksel
formülde yanlış yazılması sonucunda firma, zarara uğramıştır. Bir silikon hatası Intel Pentium bilgisayar yongasının belli bir büyüklük aralığındaki ondalıklı sayıları
bölerken hata yapmasına yol açmaktaydı, önce Intel daha hassas hesaplamalara ihtiyacı olduğunu kanıtlayanlar için yonga değişişkliği yapmayı önermiş; ama
sonunda teslim olmuş ve şikâyet eden herkesin yongasını değiştirmeyi kabul etmiştir, bu da 475 milyon dolarlık bir zarar anlamına gelmekteydi (American, 2014).

Kerberos Rastgele Sayı Üretme İşlemi Hatası: 1988-1996 yıllarında gerçeklemiştir.

Rastgele Sayı Üretme İşlemi için kullanılan yazılımda kullanılan rastgele sayı üreticisinin uygun bir parametre ile beslenmemesi sonucunda Kerberos firmasına ait
yetkili bilgisayarlardan bir kaçına izinsiz giriş yapılmasına sebep olmuştur (Mind, 2015).

Denver Havalimanı Otomatik Bagaj Sistemi Hatası: 1994 yılında meydana gelmiştir. Amerika Birleşik Devletlerinin Denver kentindeki uluslararası
havaalanındaki uçuşlardaki beklemeleri azaltmak, daha az maliyetle daha hızlı bagaj hizmeti sunmak için otomatik bagaj sistemi yazılımı geliştirilmiştir. Mayıs ayında
açılış yapılması planlanan bu sistem için aynı senenin Nisan ayında otomatik bagaj sisteminin ilk testini izlemeleri için basın mensupları havalimanına davet edilmiştir.
Gazeteciler ve muhabirler test sırasında, sistem raylarının altına dağılan kıyafetleri ve kişisel eşyaları fark etmiş, bu durumun bagajın kayıştan kayışa geçmesini
sağlayan aktüatörlerin hata sonucu bagajı sistemden attığını gözlemlemiştir. Bu hataların basında yer alması sonrası Denver Belediye Başkanı Wellington Webb
planlanan Mayıs açılışını iptal etmiştir ve uzunca bir süre sistemin açılışı gerçekleştirilememiştir. Şekil 2.6’da Denver Havalimanı Otomatik Bagaj Sistemi
görülmektedir (Ceylan, 2020).

Şekil 2.6. Denver Havalimanı Otomatik Bagaj Sistemi

Arienne-5 Füzesi Hatası: 1996 yılında gerçekleşmiştir. Kullanılan yazılımda aritmetiksel işlemlerde 64 bit kullanılması gerekirken, yazılımın önceki sürümünde 16
bitlik değerlerin kullanılması ve bu durumun yazılımın yeni versiyonunda güncellenmemesi sonucunda yine 16 bitin kullanılmaya devam edilmeye çalışılması ile çeşitli
uyumsuzluklar yaşanmıştır.
Bu durumun sonucunda füze, fırlatıldıktan 40 saniye sonra havada infilak etmiştir ve 500 milyon dolarlık bir zarara neden olmuştur. Literatürde yer alan en pahalı
yazılım hataları arasında yer almıştır (Now, 2018).

Mars Climate Orbiter Hatası: 1999 yılında gerçekleşmiştir. Yazılımda kullanılan uzunluk ölçümlerinde İngiliz ölçü birimlerinin kullanılması sonucunda yazılımda
çeşitli uyumsuzluklar yaşanmıştır ve sonuçta NASA’ya 125 milyon dolara mal olmuştur  (Wired, 2010).

Ulusal Kanser Enstitüsü Hatası: 2000 yılında yaşanmış bir hatadır. Yazılım kaynaklı hata nedeniyle hastalara yanlış dozda radyasyon verilmesi sonucunda 8 hasta
hayatını kaybetmiştir ve bilinen 20’den fazla kişi ciddi sağlık sorunları yaşsamıştır (Of, 2017).

Y2K Hatası: 2000 yılında yaşanmıştır, zaten hata da milenyum problemi olarak bilinmektedir. 1 Ocak 2000 yılından sonra eski bilgisayar ve yazılımlarında görülen
ve tarih ve zamanla ilgili işlemlerde hatalı sonuçlara yol açan bir yazılım hatasıdır. Bazı eski programlama dilleri geliştirilirken öngörüsüz davranılmış ve tarih
değerlerinde yıl ibaresi 2 basamak ile ifade edilmiş, yani 1950 yılı 50, 1985 yılı 85 olarak tanımlanmış, bu basit tasarım hatası 2000 yılına girildiğinde, o yılın 1900
gibi algılanmasına neden olmuştur. Şekil 2.7’de Y2K hatasının temsili bir gösterimi verilmiştir (Strategyturk Bilgisayar Kulübü, 2020).

Şekil 2.7. Y2K Hatası

Mercy Hastanesi Ölüm İlanları Hatası: 2002 yılında yaşanmıştır. Mercy Hastanesi sistemlerindeki veri tabanı kayıtlarının düzensizliği nedeniyle veri tabanında
bulunan hasta kayıtlarındaki 8500 kişi yaşarken ölü ilan edilmiştir (Baseline, 2003).

Michigan Hapishanesi Erken Tahliye Hatası: 2005 yılında gerçekleşmiştir. Veri tabanında bulunan verilerin hatalı sorgulanması sonucunda 239 mahkum, 39 ile
161 gün öncesinden tahliye edilmiştir (Intertech, 2013)

World of Warcraft Hatası: 2005 yılında gerçekleşmiştir. Oyun geliştiricileri, “Corrupted Blood” isimli bir hastalık yayınlamıştır. Ancak hastalık bir anda oyuncular
arasında beklenmedik bir hızla yayılmış ve oyundaki sanal kasabalar binlerce cansız bedenle dolmuştur (Univera, 2009). Şekil 2.8’de World of Warcraft
görülmektedir.

15
Şekil 2.8. World of Warcraft

Los Angeles Havalimanı Hatası: 2007 yılında gerçekleşmiştir. Ağ kartındaki bir hatadan dolayı 8 saat boyunca kimse Los Angeles Havalimanı’na girememiş ve
havalimanından çıkamamıştır (Intertech, 2013).

Google Malware Hatası: 2009 yılında gerçekleşmiştir. Bir Google çalışanının olmaması gereken bir anda yanlışlıkla “backslash” tuşuna basmasıyla birlikte
Google’dan erişilen tüm adresler Malware (kötü yazılım) olarak görünmeye başlamış, dolayısıyla Google kullanan hemen hiç kimse, yaklaşık 1 saat boyunca Google
üzerinden hiç bir siteye erişememiş ve bu da Google için yaklaşık 2 – 3 Milyon dolarlık reklam kaybına yol açmıştır (Şamlıoğlu, 2006).

Honda Yazılım Hatası: 2011 yılında yaşanmış bir hatadır. Hatalı kurulan bir algoritma sonucunda araç özelliklerinin yanlış zamanlarda aktif edilmesi sonucunda
firma 2,5 milyon aracını geri çağırmak zorunda kalmıştır (Cars, 2017).

Apple Maps Yön Hatası: 2012 yılında gerçeklemiştir. Farklı veri tabanlarındaki bilgilerin entegrasyonunda oluşan karmaşıklık ve uyumsuzluk sonucunda Apple ile
Google Maps arasındaki harita (maps uygulaması) rekabet sonucu Apple firması itibar kaybetme durumu ile yüz yüze kalmıştır (Verge, 2012; Guardian, 2012).
Şekil 2.9’da Apple Maps görülmektedir.

Şekil 2.9. Apple Maps

Knight Capital Group Finans Hatası: 2012 yılında gerçekleşmiştir. Yanlış bir algoritma kullanılması sonucunda firma, 30 dakika gibi kısa bir sürede 440 milyon
dolar maddi kayıp yaşamıştır (DealBook, 2012; Bloomberg, 2012; Insider 2013).

Mahkeme Jüri Daveti Hatası: 2012 yılında gerçekleşmiştir. Veri tabanında gerçekleşen hatalı bir sorgulama sonucunda Kaliforniya’daki bir mahkemeye jüri
olarak 1200 kişiye davetiye gönderilmiş, bu davet sonucunda mahkemeye katılmak isteyen kişiler sonucunda tüm eyaletler arası yollarda trafik nedeniyle saatlerce
aksaklıklar yaşanmıştır (Intertech, 2013).

Toyota Prius Aracı Hatası: 2014-2015 yıllarında yaşanmıştır. Motor kontrol ünitesindeki bir yazılımın aşırı ısınma ve güç kaybına neden olması sonucunda aşırı
ısınan araçlar trafik sorunlarına neden olmuştur. Firma, 2014 yılında 2 milyon, 2015 yılında ise 625 bin aracını geri çağırmak zorunda kalmıştır (News, 2018; Times,
2018). Şekil 2.10’da Toyota Pirius aracı görülmektedir (Kutun, 2018).

Şekil 2.10. Toyota Pirius Aracı

Bölüm Özeti
Hatasız bir yazılım geliştirilmesi mümkün değildir. İlk anda hatasız olsa bile yazılımlar dinamik unsurlar olduklarından sonrasında kullanım sırasında da çeşitli hatalar
söz konusu olabilir.
Bu açıdan yazılımlardaki hataların sınıflandırılması, tespit ve düzeltme anlamında büyük önem arz etmektedir. Yazılım hataları ile ilgili çeşitli farklı kavramlar
bulunmaktadır. Bunların en önemlileri hata, kusur, insan hatası, arıza ve anomalidir. Hata bir bileşen ya da sistemin gerekli işlevini gerçekleştirmesini engelleyen her
türlü durumdur. Kusur bir bileşen ya da sistemin gerekli işlevini gerçekleştirmesini engelleyen kusurlara verilen isimdir.  İnsan hatası bir insan tarafından
gerçekleştirilen ve doğru olmayan sonuç üreten her türlü eylemdir. Arıza bileşen veya sistemin, beklenen teslim, servis veya sonuçtan sapmasıdır. Anomali
gereksinimden, tasarımdan, kullanıcı dökümanından, standartlardan, beklenti, tecrübe veya algıdan sapma durumu olarak ifade edilebilir. Bu ayrım hataların özelliğine
göre yapılmışken hataların yapıldığı yerlere göre de sınfılandırılması mümkündür. Örneğin Uygulama Geliştirme Aşamasında Yapılan Hatalar, Mimari ve Tasarım
Hataları ve Belgelendirme Hataları şeklinde bir gruplandırma yapmak mümkündür. Uygulama Geliştirme Aşamasında Yapılan Hatalar da Sözdizimi Hataları, Çalışma
Zamanı Hataları ve Mantıksal Hatalar şeklinde alt sınıflara ayrılır.

Uygulama Geliştirme Aşamasında Yapılan Hatalar, yazılım geliştirme sürecinde kaçınılmaz olarak ortaya çıkan hatalardır.

16
 Sözdizimi Hataları kullanılan programlama dilinin kurallarına aykırı olan ifadelerinin kullanılmasından kaynaklanan hatalardır.

 Çalışma Zamanı Hataları programın çalıştırıldığı anda ve/veya yazılımın müşterinin makinesine kurulduğu anda ortaya çıkan hatalardır.

 Mantıksal Hatalar programın kendisinden beklendiği sonuçlardan farklı sonuçlar üretmemesi ve beklenenden farklı bir sırada çalışması olarak ifade edilebilen
hatalardır.

Mimari ve Tasarım Hataları, geliştirilecek olan yazılımın eksik ve yetersiz incelenmesi, yanlış iş veya işleme sırası, iş süreç tasarımının zayıf kalması şeklindeki
hatalardır.  Belgelendirme Hataları ise yazılımların dokümantasyonlarında yapılan hatalardır. 

Yazılımlarda hataların yapılması sonucunda geçmişten günümüze birçok zararlı durum ortaya çıkmıştır. Uzay roketleri ve füzeler yörüngenin dışına çıkmış, binalar
çökmüş, gaz hatlarında patlamalar meydana gelmiş, hastalara yanlışlıkla yüksek dozda ilaç verilmiş ve kimi hastaların ölümüne sebebiyet verilmiş, bilgisayar
sistemlerinde çeşitli hatalar oluşmuş ve bilgisayar sistemlerine giriş konusunda sıkıntılar yaşanmış, arabaların geri toplanması gerekmiş, havaalanı sistemlerinde
sorunlar oluşmuş, borsalarda beklenmedik hareketler sonucu maddî zararlar söz konusu olmuş,  ölüm ilanları, mahkumların erken tahliyesi gibi uygun olmayan
durumlar oluşmuştur. Bu sebeple yazılımlardaki hataların en kısa sürede tespit edilmesi ve düzeltilmesi önemli bir husustur.

Kaynakça

J. Magee, A guide for beginner programmers, http://people.bu.edu/azs/teaching/cs108/2009fall/debug.html, 2018.

Yazılım Hataları, https://tr.myservername.com/7-types-software-errors-that-every-tester-should-know

İ. Şen, Yazılım Kalite Güvencesi ve Standartlar, http://ismailsen.com.tr/yazilim-kalite-guvencesi-ve-standartlar/, 2020

Mariner-1, https://en.wikipedia.org/wiki/Mariner_1, 2021

R. Martin,  N. J. Delatte, Another Look at Hartford Civic Center Coliseum Collapse, Journal of Performance of Constructed Facilities, Sayı. 15(1), 2001

C. Caballero, Software Architecture: Therac-25 the killer radiation machine, https://medium.com/swlh/software-architecture-therac-25-the-killer-radiation-

machine-8a05e0705d5b, 2019

E. Ceylan, Tarihi Yazılım Felaketleri ve Alınabilecek Dersler, https://erkanceylan.medium.com/tarihi-yaz%C4%B1l%C4%B1m-felaketleri-ve-

al%C4%B1nabilecek-dersler-d5e87a078f50, 2020

M. U. Of, “The 10 worst programming mistakes in history,” 2017.

C. History, “Almost a Tragedy: The collapse of the hartford civic center,” 2017.

N. Y. Times, “Coliseum roof collapses at Hartford civic center,” 1978.

E. Journal, “Hartford stadium collapse: why software is just a tool and should be used wisely,” 2018.

Risi, “CIA trojan causes Siberian gas pipeline explosion,” 2015.

Wired, “Soviets burned by CIA hackers?,” 2004.

C. H. Museum, “1988: U.C. Berkeley paper catalyses interest in RAID,” 2018.

Intertech, “Top 15 worst computer software blunders,” 2013.

M. Threat, “Patriot,” 2018.

S. American, “5 Most embarrassing software bugs in history,” 2014.

S. Now, “Investigators say erroneous navigation input led Ariane 5 rocket off course,” 2018.

O. Mind, “The 5 most infamous software bugs in history,” 2015.

Baseline, “Hospital revives its "Dead" patients,” 2003.

H. Şamlıoğlu, Tarihin En Büyük 10 Yazılım Hatası ve Ölümler..!, https://www.teakolik.com/tarihin-en-buyuk-10-yazilim-hatasi-ve-olumler/, 2006

T. T. A. Cars, “The lost decade: Honda exercises hopeful humility and acknowledges mistakes made,” 2017.

T. Verge, “Wrong turn: Apple’s buggy iOS 6 maps lead to widespread complaints,” 2012.

T. Guardian, “Apple’s $30bn maps mistake,” 2012.

DealBook, “Knight Capital says trading glitch cost it $440 million,” 2012.

B. Insider, “Goldman Sachs’ massive trading error bears a scary resemblance to the one that brought down Knight Capital,” 2013.

Bloomberg, “Knight shows how to lose $440 million in 30 minutes,” 2012.

B. News, “Toyota car fault prompts massive recall,” 2018.

L. A. Times, “Toyota failed to fix defect that can cause Prius to overheat and lose power, dealer claims in lawsuit,” 2018.

M. Kutun, Toyota, C-HR Ve Prius Araçlarında Üretim Hatası!, https://www.webtekno.com/toyota-c-hr-ve-prius-araclari-geri-toplayacak-h36664.html, 2018

Ünite Soruları

17
Soru-1 :

Geometrik cisimlerle ilgili bir yazılımda, yazılım geliştirici, üçgenin alanını ((taban x yükseklik)/2) yerine (taban x yükseklik) şeklinde formülize
ettiyse ve dolayısıyla yazılım hata veriyorsa, bu durumda bu hata hangi hata kategorisine girer?

(•) - Sözdizimi hatası

(•) - Çalışma zamanı hatası

(•) - Mantıksal hata

(•) - Mimarî ve tasarım hatası

(•) - Belgelendirme hatası

Cevap-1 :

Mantıksal hata

Soru-2 :

C programlama dili ile yazılmış bir programda, başlık dosyasının eklenmesi için #include <stdio.h> yazmak gerekirken noktalama işaretleri
unutularak include stdio.h yazılırsa bu durumda bu hata hangi hata kategorisine girer?

(•) - Sözdizimi hatası

(•) - Çalışma zamanı hatası

(•) - Mantıksal hata

(•) - Mimarî ve tasarım hatası

(•) - Belgelendirme hatası

Cevap-2 :

Sözdizimi hatası

Soru-3 :

Yukarıdaki şekilde gösterilen ve aranan web sitesinin bulunmaması anlamına gelen hata hangi hata kategorisine girer?

(•) - Mantıksal Hatalar

(•) - Çalışma Zamanı Hataları

(•) - Sözdizimi Hataları

(•) - Yazım Hataları

(•) - Dosya Hataları

18
Cevap-3 :

Çalışma Zamanı Hataları

Soru-4 :

Aşağıdakilerden hangisi bir yazılımın performansını belirten kriterlerden biri değildir?

(•) - Hata yoğunluğu

(•) - Arıza oranı

(•) - Arızalar arasında geçen ortalama süre

(•) - Hataların büyüklüğü

(•) - İnsan hatası toleransı

Cevap-4 :

Hataların büyüklüğü

Soru-5 :

Kusur ağacı nedir?

(•) - Kusurların nedenlerini analiz etmekte kullanılan bir yöntemdir.

(•) - Oluşan kusurları sıralayan bir yöntemdir.

(•) - Kusurların sebep oldukları maliyetleri sıralayan bir analiz yöntemidir.

(•) - Farklı yazılımlarda ortaya çıkabilecek farklı türdeki hataları belirleyen bir yöntemdir.

(•) - Farklı hata türleri arasındaki ilişkileri gösteren bir yöntemdir. 

Cevap-5 :

Kusurların nedenlerini analiz etmekte kullanılan bir yöntemdir.

Soru-6 :

Mariner-1 Uzay Roketi’nde meydana gelen ve Fortran'la yazılan yazılımda DO 3 I = 1,3 yerine DO 3 I = 1.3 yazılması neticesinde roketin
yörüngeden çıkması aşağıdakilerden hangisi ile açıklanabilir?

(•) - Sözdizimi hatası

(•) - Çalışma zamanı hatası

(•) - Mantıksal hata

(•) - Mimarî ve tasarım hatası

(•) - Belgelendirme hatası

Cevap-6 :

Sözdizimi hatası

Soru-7 :

Yazılım hataları neticesinde aşağıdakilerden hangisinin gerçekleşmesi mümkündür?

(•) - İnsan ölümleri

(•) - Para kayıpları

(•) - Yanlış maddî işlemler

(•) - Yanlış planlamalar

(•) - Hepsi

Cevap-7 :

Hepsi
19
Soru-8 :

31.12.1999’dan 01.01.2000’e geçerken yaşanacağı düşünülen ve programlama dillerinin sahip olduğu değişken sisteminden kaynaklanması
beklenen hatanın literatürdeki ismi nedir?

(•) - Melissa Hatası

(•) - I Love You Hatası

(•) - Y2K Hatası

(•) - Milenyum Hatası

(•) - Wannacry Hatası

Cevap-8 :

Y2K Hatası

Soru-9 :

Aşağıdaki şıklarda verilenlerden hangisi diğerlerinin bir sonucu durumundadır?

(•) - Hata

(•) - Arıza

(•) - Anomali

(•) - Kusur

(•) - İnsan hatası

Cevap-9 :

Anomali

20
3. YAZILIM RİSK ANALİZİ VE YAZILIMDA ÖLÇME
Giriş
Tüm projelerde olduğu gibi yazılım projelerinde baştan yapılan süre, maliyet, kaynak gibi tahminlemelerin çoğu, yaşanan riskler yüzünden beklenildiğinden çok farklı
şekilde oluşur.
Bu yüzden bir yazılım projesinde meydana gelebilecek risklerin kategorize edilmesi gerekmektedir. Yazılımlarda riskleri belirlemenin en önemli yollarından biri
yazılımların doğru bir şekilde ölçülmesidir. Yazılımlarda hem teknik elemanların hem de yönetimsel elemanların ölçülmesi yazılımın başarılı olmasını belirleyen unsurlar
arasında yer alır. Bu bölümde yazılımda risk analizi ve ölçme kavramları açıklanmıştır.

3.1. Yazılım Risk Analizi

Tüm projelerde olduğu gibi yazılım projelerinde de gerek zaman gerek maliyet açısından çeşitli tahminlemeler yapılmaktadır, bu tahminlemelerin birçok farklı kritere
bağlı olması peşinde birçok belirsizliği getirmektedir. Bu belirsizlikler de her projede olduğu gibi yazılım projelerinde de çeşitli riskler oluşturmaktadır (Erdem ve
Younis, 2012). Riskler her projede projenin süreini uzatabilir, projenin maliyetini arttırabilir, projenin tamamlanmasını tamamen engelleyebilir, doğru amaca doğru
giden projelerin yönünü terse çevirerek yanlışa doğru gitmesine sebep olabilir. Riskleri engelleyebilmek için öncelikle risk kavramının tanımlanmasında fayda
bulunmaktadır. Risk kavramı hakkında pek çok farklı tanımlama olmakla beraber en genel tanımlardan birisi “projelerin başarılı bir şekilde tamamlanmasını
etkileyecek potansiyel problemler” şeklinde yapılabilir. Projeler hakkında birçok konuya açıklık getiren PM-BOK (Project Management Body of Knowledge–
Proje Yönetim Bilgi Grubu) risk kavramını, bir projenin hedefleri üzerinde olumlu veya olumsuz etki meydana getirebilecek belirsiz bir durum veya koşul olarak
tanımlamaktadır. Risklerin net bir şekilde tanımlanabilmesi ve belirlenebilmesi için öncelikle risklerin gruplandırılması gerekmektedir. En temel risk kategorileri proje
riskleri, teknik riskler ve işletme riskleri şeklinde ifade edilebilir (Ene, 2013; Calp ve Akcayol, 2012). Bu risk kategorilerinin açıklamaları aşağıda verilmiştir.

Proje Riskleri: Proje planını tehdit eden risklerdir. Herhangi bir proje riski gerçekleşirse projenin zamanlaması planlanandan ileri bir tarihe sarkar ve/veya projenin
maliyeti beklenenden daha yüksek olur. Bu risk kategorisine örnek olarak bütçelerin yanlış planlanması, zamanlamanın yanlış planlanması, personeller ile ilgili
personellerin birbirleri ile uyumsuzluğu, teknik bilgi eksikliği, hastalık gibi insanî sorunlar gibi riskler olarak ifade edilebilir.
Proje riskleri de kendi içerisinde aşağıdaki şekilde sınıflandırılır.

 Fonksiyonalite Riskleri: Sistemin işlevselliğini tam olarak yerine getirememesine neden olabilecek risklerdir.

 Yük–Kapasite Riskleri: Sistemin maksimum sayıda kullanıcıyı destekleyebilmesini engelleyebilecek risklerdir.

 Güvenilirlik Riskleri: Sistemin çökmesine sebep olabilecek risklerdir.

 Sürdürülebilirlik Riskleri: Sistemin devamlılığını kesintiye uğratabilecek risklerdir.

 Veri Kalitesi Riskleri: Verilerin düzgün bir şekilde işlenmesi, saklanması ve çekilmesini engelleyebilecek risklerdir.

 Performans Riskleri: Normal şartlar altında işlemlerin belirlenen sürede yapılmasını engelleyebilecek risklerdir.

 Dokümantasyon Riskleri: Kullanıcı için hazırlanan kullanım kılavuzunda yer alan risklerdir.

 Arayüz Riskleri: Sistemin arayüzlerinde ortaya çıkabilecek risklerdir.

 Entegrasyon Riskleri: Sistemin diğer sistemlerde olan etkileşimi sırasında ortaya çıkabilecek risklerdir.

Teknik Riskler: Bu risk kategorisinde yer alan riskler, üretilen yazılımın genellikle kalitesini etkiler. Bu risk grubundaki bir riskin gerçekleşmesi durumunda yazılımın
oluşturulması zorlaşır veya imkansız hale gelir. Genellikle yazılımın analiz, tasarım, implementasyon ve/veya bakım aşamaları ile ilgili risklerdir. Örneğin her ne kadar
yazılımcılara güzel bir şey gibi görünse de son teknoloji ürünlerin kullanılması genellikle yüksek teknik riskler içermektedir. Bunun sebebi bu son teknoloji ürünlerin
genellikle yeterince test edilmemiş olması ve olası birçok hata içerebiliyor olmasıdır. Teknik riskleri ifade eden en önemli sorunlar ve sorular, “bu sistemin veya
bileşenin içerisinde hata var mı”, “bu sistemin veya bileşenin dokümantasyonu yeterli mi”, “bu sistem veya teknoloji yarın da kullanılabilecek mi” şeklindedir.

İşletme Riskleri: Bu riskler daha çok ürünün piyasasında yaşanabilecek risklerdir. Bu riskler kendi içerisinde 2’ye ayrılır. Bunlar tahmin edilebilen riskler ve tahmin
edilemeyen risklerdir. Tahmin edilebilen riskler genellikle pazarda yaşanabilecek değişiklikler, enflasyon, döviz kuru değişiklikleri vb iken tahmin edilemeyen riskler
ise doğal afetler, planlanmayan yasa ya da sözleşme değişiklikleri ve çevresel faktörlerdir. Buradaki riskler ayrıca pazar riskleri ve satış riskleri olarak da kategorize
edilebilir; pazar riskleri ürünün istenilen oranda talep görüp görmeyeceği ile ilgili risklerdir, satış riskleri ise ürünü satan kişilerin satışı nasıl yapacaklarını yeterince bilip
bilmedikleri ile ilgilidir.

Risklerin projelere mümkün olduğunca az zarar vermesini sağlayabilmek için risk yönetimi yapmak gereklidir. Risk yönetimi, risklerin tanımlanmasını,
değerlendirilmesini, risklerin önlenmesi ya da etkisinin azaltılması için gerekli denetimlerin azaltılmasını, alternatiflerin planlanmasını içeren sürece verilen isimdir. Her
türlü projede, proje yöneticisi, riskleri tamamen engelleyemeyebilir ancak proje yöneticisi risk unsuru taşıyan bir durumla karşı karşıya kaldığı zaman ne yapacağını
bilmelidir. Bunun için risk unsuru taşıyan durumun proje üzerinde nasıl bir etki yaratacağını öngörebilmeli ve bu olası durumlara karşı tedbir alabilmelidir. Proje
yöneticisi risk yönetmi yaparken öncelikle risk değerlendirmesi sonrasında risk planlaması yapmalıdır.

3.1.1. Risk Değerlendirmesi

Risk değerlendirmesi, uzmanların görüşlerinden, benzer sistemlerde çalışmış kişilerin deneyimlerinden, önceki projelerden alınan derslerden ve kararlardan ve
teknoloji değerlendirme raporlarından yararlanılarak gerçekleştirilmektedir. Risk değerlendirilmesi temelde 3 adımdan oluşmaktadır. Bu adımlar aşağıdaki şekildedir.

 risklerin tanımlanması,

 risklerin analiz edilmesi,

 risklerin öncelik derecelerinin belirlenmesi

Risklerin tanımlanması için öncelikle projenin kritik noktalarının iyi bir şekilde tanımlanmış olması gereklidir. Bunları en önemlisi de projenin amaçlarıdır. Projenin
amaçları tanımlandıktan sonra projenin, bu amaçlara ulaşmasını engelleyecek olan riskler tanımlanır, değerlendirilir ve bu risklere karşı alınabilecek olan tedbirler
belirlenir. Bir yazılım projesinde çok farklı risk grupları olabilmekle beraber her yazılım projesi için ortak olan potansiyel tehditler genellikle şu şekilde belirlenir:

 projenin büyüklüğü ve bu büyüklük içerisinde önceden tahmin edilemeyen unsurlar

21
 müşterinin/kullanıcının tutumu ve proje ekibinden beklentileri

 projedeki yazılımların, kodların, algoritmaların, ara yüzlerin, veri tabanlarının ve diğer elemanların geliştirilme ortamı

 kullanılan tüm teknolojiler

Yazılım projeleri ve diğer tüm projelerde risklerin tanımlanması için sorulan bazı sorular bulunmaktadır (Olcaysoy ve Kalıpsız, 2013).

 Projenin amaçlarına ulaşmasına doğru gidilen yolda neler yanlış gidebilir?

 Proje içerisinde ne gibi sorunlar oluşabilir?

 Geliştirme aşamasında hangi tür işlemler projenin başarısız olmasına sebep olabilir?

 Proje içerisindeki zayıf yönler nelerdir?

 Proje ekibinin elindeki hangi varlıklar öncelikli olarak korunmalıdır?

 Proje faaliyetleri hangi olaylar sonucunda aksayabilir?

 Projenin en kritik veri ve bilgi kaynakları nelerdir?

 Projede en fazla harcama yapılan noktalar hangileridir?

 Projede en basit ve en karmaşık süreçler hangileridir?

 Projede herhangi bir cezaî yaptırım gerektirecek bir kısım bulunmakta mıdır?

Tablo 3.1.’de bir yazılım projesinde yer alabilecek proje riskleri ve bu riskleri azaltmak için geliştirilen stratejiler verilmiştir.

Tablo 3.1. Yazılım Proje Riskleri ve Risk Azaltma Stratejileri

Risk Risk Azaltma Teknikleri

Personel eksiklikleri Üst düzeyde kadrolaşma, iş eşleştirme, ekip oluşturma, kariyer gelişimi ve eğitimi, kilit personelin erken planlaması
Gerçekçi olmayan zaman ve maliyet tahminleri Çoklu tahmin teknikleri, tasarım maliyeti, geçmiş proje verilerinin analizi
Yanlış yazım fonksiyonlarını geliştirme Geliştirilmiş yazılımı değerlendirme;  formal belirtim yöntemleri kullanıcı araştırmaları, prototipleme
Yanlış kullanıcı ara yüzü geliştirme Prototipleme, görev analizi, kullanıcı katılımı
Gereksinimlerin ilerleyen zamanlarda değişmesi Katı değişim kontrol prosedürleri ile tekrarlanmalı ve artırımlı gelişim modelinin kullanımı
Gerçek zamanlı performans problemleri Simülasyon, kıyaslama, prototipleme, teknik analiz

Risk analizi, tanımlanan ve belirlenen risklerin sayısal değerlere dönüştürülmesi işlemi olarak ifade edilebilir. Bu amaçla öncelikle riskler; niceliksel büyüklükler
itibariyle ölçeklendirilmelidir, bu ölçeklendirmenin derecesi projeden projeye farklılık gösterebilir, örneğin bir projede sadece düşük, orta, yüksek dereceleri
kullanılırken, başka bir projede çok düşük, düşük, orta, yüksek, çok yüksek gibi daha fazla sayıda ölçeklendirme kullanılabilir. Sonrasında bu dereceler sayısal
değerlere çevrilmelidir. Örneğin düşük 1, orta 2, yüksek 3 değerini almalıdır. Bu işlem tamamlandıktan sonra olasılık teorisi kullanılarak matematiksel teknikler ve
benzetim tekniklerinden faydalanılarak çeşitli sayısal değerler ortaya çıkarılmalıdır. Tüm bu sayısallaştırma işlemi tamamlandıktan sonra her bir riskin olasılığı ve etkisi
değerlendirilmelidir. Risklerin analizlerinde ve risklerin öncelik derecelerinin belirlenmesinde olasılık ve etki analizi büyük önem taşımaktadır. Olasılık, bir riskin
meydana gelme ihtimalini belirtirken etki ise bir riskin meydana gelmesi halinde ortaya çıkacak olan kaybın büyüklüğü şeklinde tanımlanır. Şekil 3.1.’de risklerin
olasılık ve etki analizini gösteren bir matrisi Şekil 3.2’de ise olasılık ve etki analizine göre yapılması gerekenler gösterilmiştir.

Şekil 3.1.Risklerin Olasılık Ve Etki Analizi

Şekil 3.2. Olasılık ve Etki Analizine Göre Yapılması Gerekenler

22
3.1.2. Risk Planlaması

Risk planlaması ya da riske karşı yapılan planlama, temelde, riskin oluşacağının varsayılması ve bu riskin oluşması halinde yönetilmesi için strateji geliştirilmesi
anlamına gelmektedir. Buradaki stratejiler temelde 3 kategori halinde incelenir. Bunlar

 Riskin Oluşmasını Önleme Stratejileri: Riskin oluşma ihtimalini azaltmayı sağlayan stratejilerdir.

 Riski Minimalleştirme Stratejileri: Riskin oluşması halinde verdiği etki ve zararın azaltılmasını sağlayan stratejilerdir.

 Acil Eylem Planları: Riskin oluşması halinde riskin verdiği etki ve zararları düzeltmeyi sağlayan stratejilerdir.

Riske karşı yapılan planlamanın düzgün bir şekilde uygulanabilmesi için genellikle
Risk Tablosu adı verilen bir tablo oluşturulur. Bu tabloda yer alabilecek maddeler ve açıklamaları aşağıda verilmiştir.

 Riskin Açıklaması: Riskin nereden kaynaklandığı, hangi etki ve zararları verebileceği gibi konuların açıklamasıdır.

 Riskin Projeye Etkisi: Riskin gerçekleşmesi neticesinde mevcut projeye ne gibi zararlar vereceğinin açıklamasıdır. Bir risk bir proje üzerinde pek çok etki
bırakabilir, bunlar proje süresinin uzaması, proje bütçesinin büyümesi, projede uyumsuzluk yaşanması, projenin hazırlanan planın dışına çıkması, projede beklenenin
dışında sayı ve nitelikte hata oluşması şeklinde özetlenebilir.

 Riskin Gerçekleşme Olasılığı: Her projede her riskin gerçekleşme olasılığı aynı değildir. Bazı projelerde sıklıkla karşımıza çıkması olasılığı olan bir risk başka
bir projede hiç görülmeyebilir. Bu sebeple projelerde olası riskler belirlenmekle bırakılmaz bunun yanı sıra o riskin gerçekleşme olasılığı da hesaplanır. Böylece riske
karşı önlem almak daha kolay bir hale gelecektir.

 Riske Karşı Alınabilecek Önlemler: Risklere karşı projenin çeşidine ve durumuna göre pek çok farklı önlem almak mümkündür. Örneğin riskin projenin
bütçesini hedef aldığı görülüyorsa ve riskin ortaya çıkacağı modüldeki harcamaları azaltmak mümkün değilse farklı modüllerdeki harcamalar azaltılmaya çalışılabilir,
aynı şey proje süresi için de geçerlidir. Bunun dışında proje planında değişiklikler ve düzenlemeler yapmak gerekebilir.

 Riskin Durumu: Riskin açık, kapalı, aktif, pasif olma durumunu ifade eder. Projeler için olası riskler ya da diğer deyişle risk havuzları mevcuttur ancak her risk
her an aktif durumda değildir, diğer bir deyişle her riskin her an oluşma olasılığı mevcut değildir.

 Riskin Ortaya Çıkma Tarihi: Risklerin ortaya çıkması ile gerçekleşmesi farklı kavramlardır. Ortaya çıkması, havuza girmesi yani potansiyel olarak gerçekleşme
olasılığına sahip olması anlamına gelmektedir. Gerçekleşme ise gerçek anlamda riskin oluşması anlamına gelmektedir.

 Riskin Olası Gerçekleşme Tarihi: Riskin projede olası gerçekleşme tarihinin bilinmesi alınacak önlemler açısından önem arz etmektedir.

 Riskin Kategorisi: Riskler; ticarî, teknik, hukukî vb kategorilere ait olabilir. Bunların tabloda belirtilmesi alınacak önlemin şekli açısından önem arz etmektedir.

Risk yönetiminde kullanılan Risk Tablosu dışında farklı araç ve teknikler de bulunmaktadır.

 Fikir yaratma araçları

o Uzmanlarla görüşme

o Anket düzenleme

o Grup içi görüşmeler

 Eşgüdüm araçları

o Planların gözden geçirilmesi

o Ekip toplantıları yapılması

 İnsan yönetimi araçları

o Liderlik

o Ekip oluşturma becerileri

o Zaman yönetimi

 Karar verme araçları

o Olasılık ve istatistik kavramları

o Yaşam döngüsü maliyet analizleri

 Planlama araçları

o Gantt ve Pert çizelgeleri

o Kritik Yol Yönetimi

şeklindedir.

Bir yazılım testi planlanmaya başlamadan önce olası risklerin belirlenmesi gerekir. Bu alanda Arıza Modu Etki Analizi – AMEA (Failure Mode Effect Analysis –
FMEA) yöntemi kullanılır. Bu risk analizi 3 adımdan oluşur.

 Risklerin kategorize edilmesi,

 Risklerin ölçeklendirilmesi,

 Risklerin RPN (risk priority number – risk öncelik numarası) değerinin belirlenmesi

23
Risklerin ölçeklendirilmesi aşağıdaki şekilde gerçekleştirilir.

 Sistem Açısından Önemine Göre (Severity)

 Müşteri Açısından Önemine Göre (Priority)

 Gerçekleşme Olasılığına Göre (Likelihood)

Sistem Açısından Önemine Göre (Severity): 5 kategoride incelenir.

1. Veri Kaybı: Riskin gerçekleşeceği bileşende verilerin kaybolması durumu söz konusu ise bu risk sistem açısından en öncelikli risk kategorisinde ele alınır ve 1
puanı verilir.

2. İşlevsellik Kaybı: Riskin gerçekleşeceği bileşende herhangi bir veri kaybı söz konusu değilse ancak yapılabilecek olan işlevlerin bazılarında kaybolma söz
konusu ise bu risk sistem açısından yine yüksek öncelikli bir risk kategorisine girer ve 2 puanı verilir.

3. Giderilebilir İşlevsellik Kaybı: Riskin gerçekleşeceği bileşende işlevsellik kaybı gerçekleşmesi söz konusu ise ancak bu işlevsellik kaybı sürekli değil geçici bir
işlevsellik kaybı ise ve çeşitli işlemler neticesinde giderilebilecek durumdaysa bu risk sistem açısından orta öncelikli risk kategorisine girer ve 3 puanı verilir.

4. Kısmî İşlevsellik Kaybı: Riskin gerçekleşeceği bileşende işlevsellik kaybı gerçekleşmesi söz konusu ise ancak bu işlevsellik kaybı modülün tamamında değil
sadece kısmî olarak gerçekleşmekteyse bu risk sistem açısından düşük öncelikli risk kategorisine girer ve 4 puanı verilir.

5. Kozmetik Risk: Riskin gerçekleşeceği bileşende veri ya da işlevsellik olarak değil ancak kullanım kolaylığı, görsellik vb açılardan sıkıntılar mevcutsa bu durumda
bu risk sistem açısından düşük öncelikli risk kategorisine girer ve 5 puanı verilir.

Müşteri Açısından Önemine Göre (Priority): 5 kategoride incelenir.

1. Acil: Riskin gerçekleşeceği bileşende çeşitli sorunlar oluşacaksa ve bu sorunların çözülmesi yazılım için acilse, örneğin bu sorun çözülmeden kullanıcıların yazılıma
erişmesi, veritabanına erişmesi vb mümkün olmayacaksa bu risk müşteri açısından yüksek öncelikli risk kategorisine girer ve 1 puanı verilir.

2. Zorunlu: Riskin gerçekleşeceği bileşende çeşitli sorunlar oluşacaksa ve bu sorunların çözülmesi yazılım için acil değil ancak zorunluysa, diğer bir deyişle sorunların
hemen değil ama kısa zaman içerisinde çözülmesi gerekiyorsa, bu risk müşteri açısından yüksek öncelikli risk kategorisine girer ve 2 puanı verilir.

3. Önemli: Riskin gerçekleşeceği bileşende çeşitli sorunlar oluşacaksa ve bu sorunların çözülmesi yazılım için acil ve zorunlu değilse ancak sorunların çözülmesi
yazılımda önemli faydalar sağlayacaksa, bu risk müşteri açısından orta öncelikli risk kategorisine girer ve 3 puanı verilir.

4. Düzeltilmesi İyi Olacak: Riskin gerçekleşeceği bileşende çeşitli sorunlar oluşacaksa ve bu sorunların çözülmesi projenin daha verimli, daha hızlı, daha güvenli
olmasını sağlayacaksa, diğer bir deyişle projenin çalışmasını değil ancak performansını etkileyecekse bu durumda bu risklerin düzeltilmesi iyi olacaktır ve müşteri
açısından düşük öncelikli risk kategorisine girer ve 4 puanı verilir.

5. İsteğe Bağlı: Riskin gerçekleşeceği bileşende veri ya da işlevsellik olarak değil, yazılımın çalışması ile ilgili değil ancak kullanım kolaylığı, görsellik vb açılardan
sıkıntılar mevcutsa bu durumda bu risk sistem açısından düşük öncelikli risk kategorisine girer ve 5 puanı verilir.

Gerçekleşme Olasılığına Göre (Likelihood): 3 kategoride incelenir.

1. Muhtemel: Bir projede bir riskin oluşması büyük olasılığa sahipse, diğer bir deyişle öncelikli olarak kaçınmak gereken bir risk söz konusu ise bu durumda bu
risk muhtemel kategorisi içerisinde ele alınır ve 1 puanı verilir.

2. Mümkün: Bir projede bir riskin oluşma ihtimali varsa, bu risk mümkün kategorisi altında incelenir ve 2 puanı verilir.

3. İhtimal Dahilinde Olmayan: Benzeri projelerde oluşabilecek olan ancak mevcut projede gerçekleşmesi o anda mümkün olmayan riskler bu kategori altında yer
alır. Düşük öncelikli risk kategorisine giren bu riskler için 3 puanı verilir.

Bu 3 puan değeri de hesaplandıktan sonra RPN değeri bu 3 puanın çarpımı şeklinde elde edilir. RPN değeri ne kadar küçükse risk o kadar acil ve önemlidir. Bir
riskin alabileceği tüm RPN puanları Tablo 3.2’de gösterilmiştir.

Tablo 3.2. Risklerin Olası RPN Değerleri

Sistem Açısından Önemine Göre Müşteri Açısından Önemine Göre Gerçekleşme Olasılığına Göre RPN
Veri Kaybı = 1 Acil = 1 Muhtemel = 1 1 x1 x1 = 1
Veri Kaybı = 1 Acil = 1 Mümkün = 2 1 x1 x2 = 2
Veri Kaybı = 1 Acil = 1 İhtimal Dahilinde Olmayan = 3 1 x1 x3 = 3
Veri Kaybı = 1 Zorunlu = 2 Muhtemel = 1 1 x2 x1 = 2
Veri Kaybı = 1 Zorunlu = 2 Mümkün = 2 1 x2 x2 = 4
Veri Kaybı = 1 Zorunlu = 2 İhtimal Dahilinde Olmayan = 3 1 x2 x3 = 6
Veri Kaybı = 1 Önemli = 3 Muhtemel = 1 1 x3 x1 = 3
Veri Kaybı = 1 Önemli = 3 Mümkün = 2 1 x3 x2 = 6
Veri Kaybı = 1 Önemli = 3 İhtimal Dahilinde Olmayan = 3 1 x3 x3 = 9
Veri Kaybı = 1 Düzeltilmesi İyi Olacak = 4 Muhtemel = 1 1 x4 x1 = 4
Veri Kaybı = 1 Düzeltilmesi İyi Olacak = 4 Mümkün = 2 1 x4 x2 = 8
Veri Kaybı = 1 Düzeltilmesi İyi Olacak = 4 İhtimal Dahilinde Olmayan = 3 1 x 4 x 3 = 12
Veri Kaybı = 1 İsteğe Bağlı = 5 Muhtemel = 1 1 x5 x1 = 5
Veri Kaybı = 1 İsteğe Bağlı = 5 Mümkün = 2 1 x 5 x 2 = 10
Veri Kaybı = 1 İsteğe Bağlı = 5 İhtimal Dahilinde Olmayan = 3 1 x 5 x 3 = 15
İşlevsellik Kaybı = 2 Acil = 1 Muhtemel = 1 2 x1 x1 = 2
İşlevsellik Kaybı = 2 Acil = 1 Mümkün = 2 2 x1 x2 = 4
İşlevsellik Kaybı = 2 Acil = 1 İhtimal Dahilinde Olmayan = 3 2 x1 x3 = 6
İşlevsellik Kaybı = 2 Zorunlu = 2 Muhtemel = 1  2 x 2 x 1 = 4

24
İşlevsellik Kaybı = 2 Zorunlu = 2 Mümkün = 2 2 x2 x2 = 8
İşlevsellik Kaybı = 2 Zorunlu = 2 İhtimal Dahilinde Olmayan = 3 2 x 2 x 3 = 12
İşlevsellik Kaybı = 2 Önemli = 3 Muhtemel = 1 2 x3 x1 = 6
İşlevsellik Kaybı = 2 Önemli = 3 Mümkün = 2 2 x 3 x 2 = 12
İşlevsellik Kaybı = 2 Önemli = 3 İhtimal Dahilinde Olmayan = 3 2 x 3 x 3 = 18
İşlevsellik Kaybı = 2 Düzeltilmesi İyi Olacak = 4 Muhtemel = 1 2 x4 x1 = 8
İşlevsellik Kaybı = 2 Düzeltilmesi İyi Olacak = 4 Mümkün = 2 2 x 4 x 2 = 16
İşlevsellik Kaybı = 2 Düzeltilmesi İyi Olacak = 4 İhtimal Dahilinde Olmayan = 3 2 x 4 x 3 = 24
İşlevsellik Kaybı = 2 İsteğe Bağlı = 5 Muhtemel = 1 2 x 5 x 1 = 10
İşlevsellik Kaybı = 2 İsteğe Bağlı = 5 Mümkün = 2 2 x 5 x 2 = 20
İşlevsellik Kaybı = 2 İsteğe Bağlı = 5 İhtimal Dahilinde Olmayan = 3 2 x 5 x 3 = 30
Giderilebilir İşlevsellik Kaybı = 3 Acil = 1 Muhtemel = 1 3 x1 x1 = 3
Giderilebilir İşlevsellik Kaybı = 3 Acil = 1 Mümkün = 2 3 x1 x2 = 6
Giderilebilir İşlevsellik Kaybı = 3 Acil = 1 İhtimal Dahilinde Olmayan = 3 3 x1 x3 = 9
Giderilebilir İşlevsellik Kaybı = 3 Zorunlu = 2 Muhtemel = 1 3 x2 x1 = 6
Giderilebilir İşlevsellik Kaybı = 3 Zorunlu = 2 Mümkün = 2 3 x 2 x 2 = 12
Giderilebilir İşlevsellik Kaybı = 3 Zorunlu = 2 İhtimal Dahilinde Olmayan = 3 3 x 2 x 3 = 18
Giderilebilir İşlevsellik Kaybı = 3 Önemli = 3 Muhtemel = 1 3 x3 x1 = 9
Giderilebilir İşlevsellik Kaybı = 3 Önemli = 3 Mümkün = 2 3 x 3 x 2 = 18
Giderilebilir İşlevsellik Kaybı = 3 Önemli = 3 İhtimal Dahilinde Olmayan = 3 3 x 3 x 3 = 27
Giderilebilir İşlevsellik Kaybı = 3 Düzeltilmesi İyi Olacak = 4 Muhtemel = 1 3 x 4 x 1 = 12
Giderilebilir İşlevsellik Kaybı = 3 Düzeltilmesi İyi Olacak = 4 Mümkün = 2 3 x 4 x 2 = 24
Giderilebilir İşlevsellik Kaybı = 3 Düzeltilmesi İyi Olacak = 4 İhtimal Dahilinde Olmayan = 3 3 x 4 x 3 = 36
Giderilebilir İşlevsellik Kaybı = 3 İsteğe Bağlı = 5 Muhtemel = 1 3 x 5 x 1 = 15
Giderilebilir İşlevsellik Kaybı = 3 İsteğe Bağlı = 5 Mümkün = 2 3 x 5 x 2 = 30
Giderilebilir İşlevsellik Kaybı = 3 İsteğe Bağlı = 5 İhtimal Dahilinde Olmayan = 3 3 x 5 x 3 = 45
Kısmî İşlevsellik Kaybı = 4 Acil = 1 Muhtemel = 1 4 x1 x1 = 4
Kısmî İşlevsellik Kaybı = 4 Acil = 1 Mümkün = 2 4 x1 x2 = 8
Kısmî İşlevsellik Kaybı = 4 Acil = 1 İhtimal Dahilinde Olmayan = 3 4 x 1 x 3 = 12
Kısmî İşlevsellik Kaybı = 4 Zorunlu = 2 Muhtemel = 1 4 x2 x1 = 8
Kısmî İşlevsellik Kaybı = 4 Zorunlu = 2 Mümkün = 2 4 x 2 x 2 = 16
Kısmî İşlevsellik Kaybı = 4 Zorunlu = 2 İhtimal Dahilinde Olmayan = 3 4 x 2 x 3 = 24
Kısmî İşlevsellik Kaybı = 4 Önemli = 3 Muhtemel = 1 4 x 3 x 1 = 12
Kısmî İşlevsellik Kaybı = 4 Önemli = 3 Mümkün = 2 4 x 3 x 2 = 24
Kısmî İşlevsellik Kaybı = 4 Önemli = 3 İhtimal Dahilinde Olmayan = 3 4 x 3 x 3 = 36
Kısmî İşlevsellik Kaybı = 4 Düzeltilmesi İyi Olacak = 4 Muhtemel = 1 4 x 4 x 1 = 16
Kısmî İşlevsellik Kaybı = 4 Düzeltilmesi İyi Olacak = 4 Mümkün = 2 4 x 4 x 2 = 32
Kısmî İşlevsellik Kaybı = 4 Düzeltilmesi İyi Olacak = 4 İhtimal Dahilinde Olmayan = 3 4 x 4 x 3 = 48
Kısmî İşlevsellik Kaybı = 4 İsteğe Bağlı = 5 Muhtemel = 1 4 x 5 x 1 = 20
Kısmî İşlevsellik Kaybı = 4 İsteğe Bağlı = 5 Mümkün = 2 4 x 5 x 2 = 40
Kısmî İşlevsellik Kaybı = 4 İsteğe Bağlı = 5 İhtimal Dahilinde Olmayan = 3 4 x 5 x 3 = 60
Kozmetik Riskler = 5 Acil = 1 Muhtemel = 1 5 x1 x1 = 5
Kozmetik Riskler = 5 Acil = 1 Mümkün = 2 5 x 1 x 2 = 10
Kozmetik Riskler = 5 Acil = 1 İhtimal Dahilinde Olmayan = 3 5 x 1 x 3 = 15
Kozmetik Riskler = 5 Zorunlu = 2 Muhtemel = 1 5 x 2 x 1 = 10
Kozmetik Riskler = 5 Zorunlu = 2 Mümkün = 2 5 x 2 x 2 = 20
Kozmetik Riskler = 5 Zorunlu = 2 İhtimal Dahilinde Olmayan = 3 5 x 2 x 3 = 30
Kozmetik Riskler = 5 Önemli = 3 Muhtemel = 1 5 x 3 x 1 = 15
Kozmetik Riskler = 5 Önemli = 3 Mümkün = 2 5 x 3 x 2 = 30
Kozmetik Riskler = 5 Önemli = 3 İhtimal Dahilinde Olmayan = 3 5 x 3 x 3 = 45
Kozmetik Riskler = 5 Düzeltilmesi İyi Olacak = 4 Muhtemel = 1 5 x 4 x 1 = 20
Kozmetik Riskler = 5 Düzeltilmesi İyi Olacak = 4 Mümkün = 2 5 x 4 x 2 = 40
Kozmetik Riskler = 5 Düzeltilmesi İyi Olacak = 4 İhtimal Dahilinde Olmayan = 3 5 x 4 x 3 = 60
Kozmetik Riskler = 5 İsteğe Bağlı = 5 Muhtemel = 1 5 x 5 x 1 = 25
Kozmetik Riskler = 5 İsteğe Bağlı = 5 Mümkün = 2 5 x 5 x 2 = 50
Kozmetik Riskler = 5 İsteğe Bağlı = 5 İhtimal Dahilinde Olmayan = 3 5 x 5 x 3 = 75

3.2. Yazılımda Ölçme

3.2.1. Ölçme İşlemi

Yazılım mühendisliğinde ölçme işlemi birçok anlamda yazılım hakkında bilgi sahibi olunmasını sağlayan bir işlemdir. Bu işlemi anlayabilmek için öncelikle ölçme
işlemini tanımlamakta fayda vardır. Ölçme işleminin birçok tanımlaması mevcuttur, en genel tanım olarak “Rakamları ve sembolleri tanımlı kurallara göre gerçek
dünyadaki varlıkların özelliklerine atama işi” olarak ifade edilebilir. Ölçme işlemi ile birlikte sıklıkla kullanılan diğer bir kavram ise kestirimdir. Ölçme mevcut olan bir
varlığın bir özelliğine değer biçmek şeklinde ifade edilirken, kestirim henüz mevcut olmayan (örneğin plan aşamasında olan) bir varlığın bir özelliğini öngörmektir.
Örneğin mevcutta oluşturulmuş bir yazılım bileşeninin kod satır sayısını hesaplamak ölçme olarak ifade edilirken henüz plan aşamasındaki bir yazılımın süresini,

25
maliyetini vb tahmin etmek kestirimdir. Özellikleri nicel olarak tanımlamak için gerçekleştirilir. Ölçme işlemi varlıkların hakkında bilgi sahibi olmak, varlıkların eski ve
yeni durumlarını karşılaştırmak ve buna göre gelecekteki durumları ile ilgili tahminlerde bulunmak, varlıklar hakkında istatistiksel bilgiler elde etmek ve varlıkları
kontrol edebilmek gibi amçalarla gerçekleştirilmesi gereken bir işlemdir. Bilimin geçmişten günümüze yaşadığı gelişmelere paralel olarak ölçme işlemi de gelişme
yaşamıştır. Örneğin geçmişte ölçülemediği düşünülen zaman, sıcaklık, hız, zeka, enflasyon gibi değerler günümüzde kolay bir şekilde ölçülebilmektedir.

Ölçme işlemini gerçekleştirmek için ölçülen varlığın özelliklerine göre farklı birimler, rakamlar ve semboller kullanılmaktadır. Örneğin para birimlerini ölçerken TL,
Dolar, Euro, Sterlin, Yen vb, herhangi bir varlığın uzunluğunu ölçerken metre, giysi bedeni olarak Small (S), Medium (M), Large (L), Extra Large (XL) gibi yapılar
kullanılır. Ölçme için kullanılan bu yapıların bazıları birbirinden tamamen ayrıyken (TL, Dolar, Euro, Sterlin, Yen) bazıları birbirinin türevi şeklindedir (metre,
santimetre, kilometre vb). Tabi burada TL, Dolar, Euro, Sterlin, Yen gibi değerlerin de arasında bir ilişki olduğunu ancak bu ilişkinin sabit değil değişken olduğunu 
belirtmek gerekir. Ölçme birimi, bir varlığın niceliğini ölçmek için kendi cinsinden kullanılan değişmez parçadır ve başında herhangi bir önek bulunmaz. Örneğin
metre, gram gibi birimler esas ölçme birimleridir. Ölçme işlemi her ne kadar varlıkların nicelikleri hakkında bilgi sahibi olmamızı hedeflese de her zaman objektif
ölçümler yapmak mümkün olmaz. Bu sebeple ölçüler dahi kendi arasında objektif ölçüler ve subjektif ölçüler olarak 2’ye ayrılır.  Objektif ölçülerde ölçme işlemini
kim gerçekleştirirse gerçekleştirsin aynı değer elde edilir. Buna örnek olarak cetvel kullanılarak bir uzunluğun ölçülmesi, tartı kullanılarak bir ağırlığın ölçülmesi
verilebilir. Elbette ki burada kullanılan cetvel ve tartının farklı olması ya da kişinin cetveli tutuşu ile ilgili ufak tefek farklılıklar olabilir ancak temelde aynı değer
bulunacaktır. Subjektif ölçülerde ise ölçme işlemi bir araç ya da cihaz kullanılarak yapılmaz, ölçme işlemini yapan kişinin tecrübe ve kişilik özelliklerine göre değişir.
Bu tip ölçme daha çok değerlendirme olarak ifade edilebilir. Buna örnek olarak bir dersin verimliliğini, bir eğitimin etkinliğini derecelendirmek verilebilir. Ölçmenin
türü, ölçülen özelliğe ve ölçülen özelliğin gözlenme şekline bağlıdır. Gözlemin ne şekilde yapıldığı ölçmenin türünü belirlemede yardımcı olur. Temelde doğrudan
ölçme, dolaylı (göstergeyle) ölçme ve türetilmiş ölçme olarak 3 çeşit ölçme türü bulunmaktadır (Şekil 3.3).

Şekil 3.3. Ölçme Türleri

Doğrudan ölçme: Ölçülmeye çalışılan özelliğin değerleri doğrudan gözlenebiliyorsa ya da bu özelliğin kendisiyle doğrudan ilişkili bir ölçme aracı ile ölçülebiliyorsa,
bu işlem doğrudan ölçme işlemi olarak ifade edilmiştir. Örneğin bir kişinin boy uzunluğunu metre ile ölçmek uzunluğu ölçen bir ölçme aracıyla, araya başka bir özellik
karışmaksızın ölçülebildiği için bir doğrudan ölçme işlemidir. Bu tarz ölçmelerde gerçek kat ve gerçek (mutlak) sıfır vardır.
Boy, kilo, sayı, sıra, para miktarı vb. ölçülmesi bu kategoriye girer.

 Bir çocuğun boyunun metre ile ölçülmesi

 Bir manavın elmaları terazi ile tartması 

 Bir öğretmenin sınıftaki öğrencileri sayması 

 İstanbul-Bursa arası uzaklığın ölçülmesi

 Masanın yerden yüksekliğinin belirlenmesi

gibi ölçümler doğrudan ölçme araçları ile yapılabildiği için doğrudan ölçme olarak ifade edilir. Doğrudan ölçme objektif ölçüler kullanılarak gerçekleştirildiğinden
güvenilirliği yüksek bir ölçme çeşididir.

Dolaylı (Göstergeyle) Ölçme: Fiziksel bilimlerde ölçülmeye çalışılan şeyler çoğunlukla gözlenebilirken eğitim ve psikoloji gibi sosyal bilimlerde ölçülmeye çalışılan
kavramlar genelde doğrudan gözlenemez (örn: başarı, tutum ve değer). Bu gibi durumlarda doğrudan ölçme yapmak mümkün değildir. Bir özellik doğrudan
gözlenemez ve ölçülemez ancak bir başka özellik yardımıyla ölçülebilirse bu tür ölçmeye dolaylı (göstergeyle) ölçme denir. Örneğin ders başarısı, ilgi, tutum, zeka,
yetenek, kişilik, beceri vb gibi varlıkları doğrudan ölçmek mümkün değilken çeşitli puanlandırmalar yöntemiyle ölçmek mümkün olabilir.
Dolaylı ölçme bir özelliğin kendisiyle ilgili olduğu düşünülen başka bir özellik aracılığıyla ölçülmesi olarak tanımlanır. Örneğin hava sıcaklığının civalı termometredeki
genleşme ile ölçülmesi bir dolaylı ölçme olarak ifade edilebilir. Bu tarz ölçmelerde gerçek kat ve gerçek (mutlak) sıfır yoktur.

 Oda sıcaklığının ölçülmesi

 Bir öğrencinin yeteneklerinin ve kişilik özelliklerinin ölçülmesi

 Öğrencilerin bir konu ile ilgili becerilerinin tespit edilmesi

 Psikolojik durumların belirli testlerle belirlenmesi

 Zekanın IQ testleri ile ölçülmesi

gibi ölçümler kendilerine ait ölçüm araçları kullanılmadığından ve çeşitli farkı araçlardan faydalanılarak ölçüldüğünden dolaylı ölçme olarak ifade edilebilir.

Türetilmiş Ölçme: Gerek sosyal bilimlerde gerekse fen bilimlerinde bazı değişkenler iki veya daha fazla değişken ve bu değişkenler arasındaki ilişkiye dayanan
bağıntılar yardımıyla tanımlanır. Bağıntıya giren değişkenler ayrı ayrı ölçülerek ortaya çıkan sonuçlar kullanarak hedeflenen ölçme yapılır. Bu tarz ölçme türüne
türetilmiş ölçme denir.  Örneğin

 hız (yol/zaman)

 madde yoğunluğu (kütle / hacim)

 nüfus yoğunluğu (kişi sayısı / alan)

 kuvvet (kütle x ivme)

26
 üçgenin alanı ((taban x yükseklik)/2)

 vücut kitle indeksi (vücut ağırlığı (kg)/(boy (m) x boy (m)))

 sınıfın ortalama puanının hesaplanması (tüm öğrencilerin aldığı puanın toplamı/öğrenci sayısı)

gibi durumlar türetilmiş ölçmeye örnektir.

3.2.2. Yazılımda Ölçme İşlemi

Bir yazılım içerisinde, ölçme işleminin doğru ve düzgün bir şekilde yapılması yazılım projesinin bütçe ve zaman tahmininin yapılması, yazılım içerisindeki durumun
analiz edilmesi, geçmişten günümüze hataların tespit edilmesi, önlenmesi, farklı yazılımlara fikir vermesi ve daha birçok açıdan önem arz etmektedir (Kurtel ve Eren,
2008). Yazılımda ölçme işleminde genellikle kullanılan bir araç vb bulunmadığından doğrudan ya da dolaylı ölçme değil daha çok temel ve türetilmiş ölçme olarak
sınıflandırma yapılır. Bir yazılımdaki temel ve türetilmiş ölçülere örnek olarak aşağıdaki ölçüler verilebilir.

 Temel Ölçüler

o Kod uzunluğu (satır sayısı ile ölçülür)

o Test süresi (“saat” zaman birimi ile ölçülür)

o Test hata sayısı (test boyunca tespit edilen hatalar sayılarak ölçülür)

 Türetilmiş Ölçüler

o Test hata sayısı (test boyunca tespit edilen hatalar sayılarak ölçülür)

o Modül hata yogunlugu (modül hata sayısı/modül kod uzunluğu şeklinde hesaplanır)

o Gereksinim değişiklikleri (değişen gereksinimlerin sayısı/ilk gereksinimlerin

sayısı şeklinde hesaplanır)

Bir yazılım projesinde, ortaya çıkan son ürün ölçülebildiği gibi bu ürünü ortaya çıkarmak için geçirilen süreç ve kullanılan kaynaklar hakkında da ölçümler yapmak
mümkündür.
Yazılım projelerinde son ürün olarak ifade edilen ortaya çıkan kodlar, algoritmalar, arayüzler, veri tabanı tabloları vb olduğundan ölçülebilecek pek çok nitelik
bulunmaktadır. Yine kaynak olarak ifade edilen de insan kaynağı, bütçe, süre, malzeme vb farklı şekillerde olduğundan farklı ölçümler gerekebilecektir.

Bir yazılımda en sıklıkla yazılımın büyüklüğü ölçülmektedir. Bu büyüklük 4 şekilde ölçülebilir. Bunlar uzunluk, işlevsellik, karmaşıklık ve tekrar kullanımdır. Uzunluk
ölçümü genellikle ürünün fiziksel özelliğini anlatan bir kavramdır. Burada örneğin yazılımın kullanım kılavuzunu oluşturan dokümanın sayfa sayısı, yazılımda herhangi
bir amaç için oluşturulan raporların tablo ve şekil sayısı, yazılımı oluşturan kodun satır sayısı şeklinde ölçümler verilebilir. Kod satır sayısı her ne kadar yazılımın
büyüklüğünü ölçmede sıklıkla kullanılan bir değer olsa da tek şekilde hesaplanan bir değer değildir ve çeşitli subjektif yanlara sahiptir. Kod satır sayısı Kaynak Kod
Satır Sayısı, Yorumsuz Kod Satır Sayısı, Yorum Kod Satır Sayısı, Yürütülür Deyim Sayısı gibi farklı sayılara karşılık gelebilir. Ayrıca fiziksel sayma, mantıksal sayma
ve anahtar sözcükleri sayma şeklinde farklı şekillerde sayılabilir. Şekil 3.4’te iki farklı kod parçacığı verilmiş ve aşağıda her iki deyim için fiziksel sayma, mantıksal
sayma ve anahtar sözcükleri sayma işlemlerinin sonucu verilmiştir.

Şekil 3.4. Farklı Kod Parçacıkları

Fiziksel Sayma: Bu sayma, kod satır sayısını fiziksel olarak saymaktadır, yani sadece satırları saymaktadır. Buna göre ilk kod parçacığında 3, ikinci kod
parçacığında 9 satır bulunmaktadır.

Mantıksal Sayma: Bu sayma, kod parçacığının yapmakta olduğu mantıksal işlemleri saymaktadır. Buna göre her iki kod parçacığında da 1 adet mantıksal işlem
bulunmaktadır,
her ikisi de bir if – else işlemi gerçekleştirmektedir, hatta her iki kod parçacığının yapmakta olduğu mantıksal işlem aynıdır sadece farklı şekillerde yazılmıştır.

Anahtar Sözcükleri Sayma: Anahtar sözcük her programlama dilinde bulunan, programlama dilinin kendisine ait olan ve çeşitli işlemlerin gerçekleştirilmesi için
kullanıcı tarafından hazır olarak kullanılan, yazım şekli değiştirilemeyen, herhangi bir değişken ya da sabite verilmeyen sözcüklere verilen addır. Buna göre ilk kod
parçacığında 3 (if, then, else), ikinci kod parçacığında ise 7 (if, then, begin, end, else, begin, end) anahtar sözcük bulunmaktadır.

Kod satır sayısının avantajları otomatik olarak kolayca sayılabilmesi, tanıma uyarak sayıldığında herkes tarafından aynı değerin bulunması, doğrudan son ürünle ilgili
olması şeklinde ifade edilirken, dezavantajları ise konu ile ilgili çok fazla farklı tanımın bulunması, dile bağımlı olarak değişmesi, programcıdan programcıya büyük
değişiklik göstermesi,
son ürün ortaya çıkmadan kullanılamaması dolayısıyla herhangi bir planlama ya da tahminleme için kullanılamaması, işlevsellik, karmaşıklık gibi diğer yazılım
27
büyüklüklerine dair bir fikir verememesi olarak ifade edilebilir. Kod satır sayısının tam olarak bir değerlendirici kriter şeklinde kullanılabilmesi için 2 kodun da aynı
programcı tarafından aynı programlama dili kullanılarak yazılmış olması gereklidir. Bu durumda diğer tüm kriterler eşit olduğu için kodların kod satır sayıları arasında
doğrudan bir karşılaştırma yapılabilir.

İşlevsellik, yazılımın kullanıcıya sunduğu işlevselliğin miktarıdır. Örneğin işlev puanları, özellik puanları vb kriterlerin sayısı olarak ifade edilebilir.

Karmaşıklık, yazılımın çözüm getirdiği konunun karakteristiği şeklinde ifade edilir.

Burada problemin karmaşıklığı dışında algoritmik ve kavramsal karmaşıklık kavramlarından da bahsedilmektedir.

Tekrar kullanım ise bir yazılımın % kaçının tekrar kullanıma uygun olduğunun ölçülmesidir. Bu kavram aynı zamanda verimliliğin de bir ölçüsü olarak kabul
edilmektedir.

Bölüm Özeti
Bu bölümde yazılım projeleri için önemli iki kavram olan yazılım risk analizi ve yazılımda ölçme konuları ele alınmıştır.

Tüm projelerde olduğu gibi yazılım projelerinde de sıklıkla risklerle karşılaşılmaktadır.

Bu riskler, projenin süresini uzatabilir, projenin maliyetini arttırabilir, projenin tamamlanmasını tamamen engelleyebilir, doğru amaca doğru giden projelerin yönünü
terse çevirerek yanlışa doğru gitmesine sebep olabilir. Riskleri engelleyebilmek için öncelikle risk kavramının tanımlanmasında fayda bulunmaktadır. Yazılımlarda
gerçekleşebilecek en temel risk kategorileri proje riskleri, teknik riskler ve işletme riskleridir. Proje riskleri, proje planını tehdit eden risklerdir. Teknik Riskler,
üretilen yazılımın genellikle kalitesini etkileyen riskelrdir. İşletme Riskleri, daha çok ürünün piyasasında yaşanabilecek risklerdir.

Risklerin projelere mümkün olduğunca az zarar vermesini sağlayabilmek için risk yönetimi yapmak gereklidir. Risk yönetimi, temelde risk değerlendirmesi ve risk
planından oluşmaktadır.

Risk değerlendirmesi, uzmanların görüşlerinden, benzer sistemlerde çalışmış kişilerin deneyimlerinden, önceki projelerden alınan derslerden ve kararlardan ve
teknoloji değerlendirme raporlarından yararlanılarak gerçekleştirilmektedir. Risk planlaması ya da riske karşı yapılan planlama, temelde, riskin oluşacağının
varasayılması ve bu riskin oluşması halinde yönetilmesi için strateji geliştirilmesi anlamına gelmektedir. Riskler için genellikle
Risk Tablosu adı verilen bir tablo oluşturulur ve bu tabloda riskin açıklaması, riskin projeye etkisi, riskin gerçekleşme olasılığı, riske karşı alınabilecek önlemler, riskin
durumu, riski ortaya çıkaran kişi, riskin ortaya çıkma tarihi, riskin olası gerçekleşme tarihi ve riskin kategorisi gibi bilgiler yer alır.

Bir yazılım içerisinde, ölçme işleminin doğru ve düzgün bir şekilde yapılması yazılım projesinin bütçe ve zaman tahmininin yapılması, yazılım içerisindeki durumun
analiz edilmesi, geçmişten günümüze hataların tespit edilmesi, önlenmesi, farklı yazılımlara fikir vermesi ve daha birçok açıdan önem arz etmektedir. Yazılımda ölçme
işleminde genellikle kullanılan bir araç vb bulunmadığından doğrudan ya da dolaylı ölçme değil daha çok temel ve türetilmiş ölçme olarak sınıflandırma yapılır.

Bir yazılım projesinde, ortaya çıkan son ürün ölçülebildiği gibi bu ürünü ortaya çıkarmak için geçirilen süreç ve kullanılan kaynaklar hakkında da ölçümler yapmak
mümkündür.
Yazılım projelerinde son ürün olarak ifade edilen ortaya çıkan kodlar, algoritmalar, arayüzler, veri tabanı tabloları vb olduğundan ölçülebilecek pek çok nitelik
bulunmaktadır. Yine kaynak olarak ifade edilen de insan kaynağı, bütçe, süre, malzeme vb farklı şekillerde olduğundan farklı ölçümler gerekebilecektir.

Kaynakça

Bakış OSGB,  Risk Değerlendirmesi Nedir, http://www.bakisosgb.com/risk-yonetimi-nedir/, 2020.

PM-BOK Guide, A Guide to the Project Management Body of Knowledge (PM-BOK® Guide), 2021.

S. Ene, Proje Yönetiminde Yer Alabilecek Risk Kaynaklarının Tespiti Ve Risk Yönetim Planının Geliştirilmesi, Istanbul Journal of Social Sciences, Sayı.5, 2013.

O. A. Erdem, A. E. Younis, Yazılım Projelerinde Risk Yönetimi, Bilişim Teknolojileri Dergisi, Sayı. 5(1), 2012.

M. Hanefi Calp, M. Ali Akcayol, Yazılım Projelerinde Karşılaşılan Risk Faktörleri ve Risk Yönetim Süreci, Marmara Fen Bilimleri Dergisi, Sayı,1, Sayfa: 1-15,
2015.

A. B. Olcaysoy, O. Kalıpsız, Bilişim Projelerinde Yazılım Risk Yönetimi: Telekomünikasyon Örneği.

K. Kurtel, Ş. Eren, Yazılım Ölçümü: Genel Bir Bakış, YKGS2008: Yazılım Kalitesi ve Yazılım Geliştirme Araçları, 9-10 Ekim 2008, İstanbul.

Ünite Soruları

Soru-1 :

Sistem açısından “İşlevsellik Kaybı”, müşteri açısından “İsteğe Bağlı” ve gerçekleşme olasılığına göre “Mümkün” olan bir riskin RPN değeri
kaçtır?

(•) - 1

(•) - 2

(•) - 5

(•) - 10

(•) - 20

Cevap-1 :

20

28
Soru-2 :

Kod satır sayısı aşağıdakilerden hangisine bağlı olarak değişiklik göstermez?

(•) - Programlama dili

(•) - Programcı

(•) - Kullanılan derleyici

(•) - Kullanılan değişkenler

(•) - Kullanılan programlama ortamı

Cevap-2 :

Kullanılan değişkenler

Soru-3 :

Aşağıdakilerden hangisi yazılımın bazı yasal düzenlemelere uymaması ile ilgili bir risk grubudur?

(•) - Teknik risk

(•) - Hukukî risk

(•) - Analitik risk

(•) - Psikolojik risk

Cevap-3 :

Hukukî risk

Soru-4 :

Yukarıdaki şekilde turuncu ile belirtilen yere aşağıdakilerden hangisi getirilmelidir?

(•) - Çok düşük risk

(•) - Düşük risk

(•) - Orta risk

(•) - Yüksek risk

(•) - Çok yüksek risk

Cevap-4 :

Orta risk
29
Soru-5 :

Sistem açısından “Kozmetik Risk”, müşteri açısından “Düzeltilmesi İyi Olacak” ve gerçekleşme olasılığına göre “İhtimal Dahilinde Olmayan” olan
bir riskin RPN değeri kaçtır?

(•) - 3

(•) - 5

(•) - 15

(•) - 60

(•) - 75

Cevap-5 :

60

Soru-6 :

If A>B
                                    then A – B;
                      else if A=B
                                   then A*B;
                       else A + B;

şeklindeki kod parçasına “Anahtar Sözcükleri Sayma” işlemi uygulandığında sonuç kaç olur?

(•) - 5

(•) - 6

(•) - 7

(•) - 8

(•) - 9

Cevap-6 :

Soru-7 :

Bir duvarın, metre kullanılarak ölçülmesi, aşağıdaki ikililerden hangisi ile ifade edilebilir?

(•) - Dolaylı – objektif ölçme

(•) - Doğrudan – objektif ölçme

(•) - Doğrudan – subjektif ölçme

(•) - Dolaylı – subjektif ölçme

(•) - Türetilmiş – objektif ölçme

Cevap-7 :

Doğrudan – objektif ölçme

Soru-8 :

Programcı üretkenliği değeri türetilmiş bir ölçüdür ve bir programcının belli bir zamanda yazdığı kod satır sayısı olarak ifade edilir. Buna göre bu
değerin hesaplanabilmesi için aşağıdakilerden hangisinin kesin olarak bilinmesi gerekir?

(•) - Programlama işleminin ne kadar sürdüğü

(•) - Programın hangi programlama dili kullanılarak gerçekleştirildiği

(•) - Programda kaç adet modül bulunduğu

(•) - Programın kaç kişi tarafından yazıldığı

(•) - Programdaki dokümantasyonun kaç sayfadan oluştuğu

30
Cevap-8 :

Programlama işleminin ne kadar sürdüğü

Soru-9 :

Aşağıdakilerden hangisi bir yazılım projesinde bir risk ortaya çıkarabilir?

(•) - Analist

(•) - Testçi

(•) - Kodlayıcı

(•) - Müşteri

(•) - Hepsi

Cevap-9 :

Hepsi

31
4. YAZILIM TESTİNE AİT KAVRAMLAR
Giriş
Bu bölümde yazılım testine ait kavramlar açıklanmıştır. Bu kavramlar kendi içerisinde
Test Verileri ve Test Senaryoları İle İlgili Kavramlar, Test Başlatma, Bitiş ve Kabul İle İlgili Kavramlar, Test Yönetimi,  Yürütmesi,  Uygulanması ve Süreci İle İlgili
Kavramlar,  Test Planı İle İlgili Kavramlar, Test Araçları İle İlgili Kavramlar, Test Dokümantasyonu İle İlgili Kavramlar ve Diğer Kavramlar şeklinde
gruplandırılmıştır. Bu gruplandırma sayesinde bu bölümde yazılım testine ait hemen hemen tüm kavramların net bir şekilde anlaşılması sağlanmaktadır.

4.1. Test Verileri ve Test Senaryoları ile İlgili Kavramlar

Bu kısımda testlerin gerçekleştirilmesi için gerekli olan hazırlık kısmı olarak ifade edilebilecek olan test verileri ve test senaryoları ile ilgili kavramlar açıklanmıştır. Bu
bölümde açıklanan kavramlar test senaryosu, bloke test senaryosu, üst seviye test senaryosu, alt seviye test senaryosu, test spesifikasyonu, test senaryo
spesifikasyonu, test senaryo grubu, test senaryo tasarım tekniği, test tasarım spesifikasyonu, test prosedür spesifikasyonu, test verisi, test verisi hazırlama aracı, test
verisi yönetimi, test girdisi ve test çıktısıdır.

Test Senaryosu (Test Scenario): Belirli bir program yolunu çalıştırmak ya da bir gereksinim ile uyumluluğunu doğrulamak gibi belirli bir amaç veya test koşulu için
geliştirilen, bir dizi girdi değeri, test öncesi yürütülmesi gereken önkoşullar, test sonrası oluşması beklenen sonuçlar ve koşullar bütünüdür. Tablo 4.1.’de örnek bir
test senaryosu görülmektedir.

Tablo 4.1. Örnek Bir Test Senaryosu

Test Gerçekleşen
Başlık Girdiler Beklenen Çıktılar Durum (Varsa) Hata
Verisi Çıktılar
Kullanıcı
adı:
Geçerli kullanıcı Önceden tanımlanmış bir kullanıcı adı Bir sonraki ekrana
Bir sonraki ekrana sorunsuz rsamli
adı ile sisteme ile sisteme girilir ve Giriş butonuna sorunsuz olarak Başarılı Hata yok
olarak geçilmesi
giriş basılır. geçildi.
Şifre:
123456
Kullanıcı
adı:
Geçersiz Önceden tanımlanmamış bir kullanıcı “Kullanıcı adı ve/veya şifre Bir sonraki ekrana Yanlış şifre girilmesine rağmen bir
rsamli
kullanıcı adı ile adı ile sisteme girilir ve Giriş butonuna yanlıştır.!” mesajı sorunsuz olarak Başarısız sonraki ekrana geçiş yapıldı, acil
sisteme giriş basılır. görüntülenmesi geçildi. olarak düzeltilmeli.
Şifre:
111111

Bloke Test Senaryosu (Blocked Test Case): Koşturulması için gerekli olan önkoşullar yerine getirilmediği için koşturulamayan test senaryosudur.

Üst Seviye Test Senaryosu (High Level Test Case): Girdiler ve beklenen sonuçlar için somut değerler içermeyen test senaryosudur. Soyut test senaryosu
olarak da adlandırılır. Bu test senaryo çeşidinde mantıksal işleçler kullanılır; gerçek değerler barındıran örnekler verilmez.

Alt Seviye Test Senaryosu (Low Level Test Case): Girdiler ve beklenen sonuç için somut değerleri olan test senaryosudur. Somut test senaryosu olarak da
adlandırılır. Bu test senaryo çeşidinde üst seviye test senaryolarındaki mantıksal operatörler amaçlarına karşılık gelen gerçek değerlerle değiştirilir.

Test Spesifikasyonu (Test Specification): Test tasarım, test senaryosu ve/veya test prosedür spesifikasyonundan oluşan dokümandır.

Test Senaryo Spesifikasyonu (Test Case Specification): Bir test öğesi için bir dizi test senaryosunun (amaç, girdiler, test adımları, beklenen sonuçlar ve test
öncesi gerçekleşmesi gereken önkoşullar) tanımlandığı dokümandır.

Test Senaryo Grubu (Test Case Suite): Bir sistem veya bileşeni test etmek için oluşturulmuş test senaryoları kümesidir. Diğer bir deyişle bir test senaryosu için
ardkoşul olan bir durum bir diğeri için ön koşuldur. Test grubu olarak da adlandırılır.

Test Senaryo Tasarım Tekniği (Test Case Design Technique): Test senaryolarını elde etmek ve/veya seçmek için kullanılan prosedür/yordamdır. Test tasarım
tekniği olarak da adlandırılır.

Test Tasarım Spesifikasyonu (Test Design Specification): Bir test öğesi için, test koşullarını (kapsam öğelerini), detaylı test yaklaşımını ve ilgili üst düzey test
senaryolarını tanımlayan dokümandır. 

Test Prosedür Spesifikasyonu (Test Procedure Specification): Testin yürütülmesi için gerekli aksiyonlar dizisini belirten dokümandır. Test betiği veya manuel
test betiği olarak da adlandırılır.

Test Verisi (Test Data): Test edilen sistemin veya bileşenin etkilediği veya bunlar tarafından etkilenen; test yürütülmeden önce varolan veridir. Bu veri bir veri
tabanında, bir dosyada, başka bir sistemde veya başka bir alanda bulunabilir. Tablo 4.2.’de örnek bir test veri seti görülmektedir.

Tablo 4.2. Örnek Bir Test Veri Seti

Öğrenci No Adı Soyadı Sınıfı Not Ortalaması Cinsiyeti Burs Durumu

128 Murat Arım 2 2,7 Erkek Burssuz
135 Ayşe Tuğba 1 3,1 Kadın % 100
502 Serpil Duru 3 2,8 Kadın % 50
419 Rüya Şamlı 4 2,9 Kadın % 100
163 Selçuk Sevilen 2 3,0 Erkek % 100

Test Verisi Hazırlama Aracı (Test Data Preparation Tool): Test için kullanılan verinin; mevcut veri tabanlarından çekilmesi ya da yaratılmasına, üretilmesine,
işlenmesine, düzenlenmesine olanak sağlayan bir tür test aracıdır. Veri analizi araçlarının en önemlileri Microsoft Power BI, Xplenty, Zoho Analytics, Serpin,
HubSpot, Halka Açık Masa, Hızlı Madenci, KNIME, turuncu, OpenRefine’dır.
32
Test Verisi Yönetimi (Test Data Management): Test verisi gereksinimlerinin analizi, test veri yapılarının tasarlanması, test verisinin yaratılması ve sürdürülmesi
sürecidir.

Test Girdisi (Test Input): Testin yürütülmesi esnasında test nesnesine dışarıdan sağlanan veridir. Verinin kaynağı donanım, yazılım ya da insan olabilir.

Test Çıktısı (Test Outcome): Testi yapan kişi dışında başka birine teslim edilmesi gereken herhangi bir test ürünüdür. Şekil 4.1.’de test girdisi ve test çıktısı
görülmektedir.

Şekil 4.1. Test Girdisi ve Test Çıktısı

4.2. Test Başlatma, Bitiş ve Kabul ile İlgili Kavramlar

Bu kısımda bir yazılım testinin ne zaman başaltılacağı, ne kadar zaman devam edeceği, hangi şartlar altında kabul edileceği gibi sorulara cevap veren kavramlar ele
alınmıştır.
Burada incelenen kavramlar kabul kriteri, koşul, test başlatma belgesi, test kapanışı, beklenen sonuç, test karşılaştırma, test karşılaştırması, test karşılaştırıcı, test
koşulu ve gerçekleşen sonuçtur. 

Kabul Kriteri (Acceptance Criteria): Bir yazılım bileşeninin veya sistemin; kullanıcı, müşteri veya yetkili birimin ihtiyaçlarını karşılaması için sahip olması beklenen
çıkış kriteridir.

Koşul (Condition): “Doğru” ya da “Yanlış” olarak değerlendirilebilecek mantıksal ifadedir. Örneğin iki değerin birbirine eşit, birbirinden küçük ya da büyük olması
gibi.
Bu kavrama dayanan ve koşul testi olarak adlandırılan bir yazılım testi de mevcuttur. Şekil 4.2.’de sembolik bir koşul gösterimi verilmiştir.

Şekil 4.2. Sembolik Koşul Gösterimi

Test Başlatma Belgesi (Test Charter): Test hedeflerini ve testin nasıl yapılacağını belirten muhtemel test fikirlerinin bildirisidir. Test başlatma belgesi araştırmacı
testlerde kullanılmaktadır. Test edenin daha iyi ve daha yeni testleri tasarlamak için test yaparken edindiği bilgiyi kullanarak ve bu testleri yürüterek bilfiil test
tasarımını kontrol altına aldığı gayrı resmî test tasarım tekniği olarak ifade edilebilen keşif testlerinden de faydalanılır.

Test Kapanışı (Test Closure): Bir test süreci fazı olan test kapanışı sırasında test projesinde kazanılan tecrübe, test yazılımı ve metrikler toplulaştırılarak sonraki
projelerde kullanılmak için arşivlenir ve bu doküman oluşturulur. Test kapanışı aşaması; test projesi çıktılarını sonuçlandırma ve arşivleme, test değerlendirme raporu
hazırlığı da dahil olmak üzere test sürecini değerlendirme konularından oluşur.

Beklenen Sonuç (Expected Result): Gereksinimlere göre yazılım bileşeninin veya sistemin tahmin edilen davranışıdır.

Test Karşılaştırma (Test Comparison): Test edilen sistemin veya bileşenin gerçekleşen test sonuçları ile beklenen test sonuçları arasındaki farklılıklarının
belirlenmesi sürecidir.
Test karşılaştırması; testin yürütülmesi sırasında (dinamik/aktif karşılaştırma) veya testler yürütüldükten sonra (pasif karşılaştırma) gerçekleştirilebilir.

Test Karşılaştırıcı (Test Comparator): Beklenen sonuçlar ile gerçekleşen sonuçların otomatik karşılaştırmasını yapabilen test aracıdır.

Test Koşulu (Test Condition): Bir ya da daha çok test senaryosu ile doğrulanabilen bir bileşenin veya sistemin bir öğesi ya da olayıdır. Örneğin bir fonksiyon,
işlem, özellik, kalite niteliği ya da yapısal öğe olabilir.

Gerçekleşen Sonuç (Actual Result): Bir yazılım bileşeni veya sistemi test edilirken ortaya çıkan/gözlemlenen davranışlardır.

4.3. Test Yönetimi,  Yürütmesi, Uygulanması ve Süreci ile İlgili Kavramlar

Bu kısımda yazılım testlerinin gerçekleştirilmesi, uygulanması, yürütülmesi ve yönetilmesi işlemleri ve tüm bu işlemlerin süreci ile ilgili kavramlar ele alınmıştır. Bu
kısımda incelenen kavramlar kritik test süreçleri, test yönetimi, test yöneticisi, test direktörü,
test yönetim aracı, test kontrol, test yürütme, test yürütme otomasyonu, test yürütme fazı,
test yürütme çizelgesi, test yürütme tekniği, test yürütme aracı, test süreci, test süreç grubu,
test süreç iyileştirme bildirgesi ve test süreç iyileştiricisidir.
33
Kritik Test Süreçleri (Critical Testing Processes): Oniki kritik süreç etrafında test süreç iyileştirmesi için yapılmış içerik bazlı modeldir. Bir şirketin itibar ve
karlılığını etkileyen süreçleri içermektedir.

Test Yönetimi (Test Management): Planlama, tahmin, gözetim ve kontrol gibi test aktivitelerini içeren süreçtir, genellikle test yöneticisinin sorumluluğundadır. Test
gözetimi ile birlikte kullanılır. Test gözetimi test projesinin durumunu periyodik olarak kontrol eden aktiviteleri içeren süreçtir. Bu süreçte hedeflenen ile gerçekleşen
aktiviteleri karşılaştıran raporlar hazırlanır.

Test Yöneticisi (Test Manager): Test aktivite ve kaynaklarının yönetiminden ve test nesnesinin değerlendirilmesinden sorumlu kişi veya kişilerdir. Bu kişi test
nesnesinin değerlendirilme sürecinin yönlendirilmesinden, kontrolünden, yönetiminden, planlanmasından ve düzenlenmesinden sorumludur. Test lideri olarak da
adlandırılır.

Test Direktörü (Test Director): Test yöneticilerini yöneten üst düzey yöneticidir.

Test Yönetim Aracı (Test Management Tool): Test yönetimine ve test sürecinin bir bölümünün kontrol edilmesine destek sağlayan araçtır. Test projesi
eserlerinin yönetimi, test zaman planlaması, sonuçların kaydının tutulması, ilerlemenin izlenmesi, olay yönetimi ve test raporlama gibi birçok yeteneği barındırır.

Test Kontrol (Test Control): Gözetim sırasında plandan bir sapma görüldüğünde test projesini yoluna koymak için geliştirilen ve uygulanan düzeltici aksiyonların
yer aldığı bir test yönetim bütünüdür.

Test Yürütme (Test Execution): Test edilen sistemde veya bileşende gerçekleşen sonuç(lar) üreten test koşum sürecidir.

Test Yürütme Otomasyonu (Test Execution Automation): Test yürütme kontrolü, beklenen sonuçlar ile gerçekleşen sonuçların karşılaştırılması, test
önkoşullarının belirlenmesi ve diğer test kontrol ve raporlama fonksiyonları için yazılım kullanılması işlemidir.

Test Yürütme Fazı (Test Execution Phase): Yazılım ürün bileşenlerinin çalıştırıldığı ve gereksinimlerin karşılanıp karşılanmadığının anlaşılması için yazılım ürününün
değerlendirildiği, yazılım geliştirme döngüsü içerisinde yer alan zaman dilimidir.

Test Yürütme Çizelgesi (Test Execution Schedule): Test prosedürlerinin yürütülmesi planıdır. Test prosedürleri yürütülme sırasına ve içeriğine göre test yürütme
planına dahil edilir. Tablo 4.3.’te örnek bir test yürütme çizelgesi verilmiştir. Bu çizelgede 8 adet test ve 3 adet gereksinim vardır ve aralarındaki ilişki gösterilmiştir.

Tablo 4.3. Örnek Bir Test Yürütme Çizelgesi

Gereksinim 1 Gereksinim 2 Gereksinim 2

Test 1 1 - -
Test 2 1 1 1
Test 3 - - 3
Test 4 - 2 2
Test 5 1 - 1
Test 6 - 1 -
Test 7 1 1 1
Test 8 - - 1

Test Yürütme Tekniği (Test Execution Technique): Manuel ya da otomatik olarak asıl test yürütme işleminin yapıldığı yöntemdir.

Test Yürütme Aracı (Test Execution Tool): Otomatik test betiği kullanarak başka bir yazılımı çalıştırılabilen bir test aracı türüdür.

Test Süreci (Test Process): Test planlamasını ve kontrolünü, test analizini ve tasarımını, testin uyarlanmasını ve yürütülmesini, çıkış kriterlerinin değerlendirilmesini
ve raporlanmasını ve test kapanış aktivitelerini içeren temel test sürecidir.

Test Süreç Grubu (Test Process Group): Test sürecinin tanımlanması, bakımı ve iyileştirilmesini yöneten (test) uzmanları topluluğudur.

Test Süreç İyileştirme Bildirgesi (Test Process Improvement Manifesto):

Çevik manifestodan esinlemiş bildiridir ve test sürecinin iyileştiren değerleri tanımlar.
Bu değerler detaylandırılmış süreçlerden ziyade esneklik, şablonlardan ziyade en iyi uygulamalar, kalite güvenceden ziyade eş gözden geçirme, model güdümlü
testten ziyade müşteri odaklı test şeklindedir.

Test Süreç İyileştiricisi (Test Process Improver): Bir iyileştirme planına dayanarak test süreç iyileştirmelerini hayata geçiren kişi veya kişilerdir.

4.4. Test Planı ile İlgili Kavramlar

Bir yazılım testinin başarılı olmasının en önemli noktalarından biri testin iyi bir biçimde planlanmasıdır. Bu kısımda yazılım test planı ile ilgili kavramlar ele alınmıştır.
Burada incelenen kavramlar test planı, master test planı, faz test planı, seviye test planı, test planlama ve test iyileştirme planıdır.

Test Planı (Test Plan): Kapsamı, yaklaşımı, kaynakları ve tasarlanan test aktivitelerine dair zamanlamayı tanımlayan dokümandır. Test öğelerini, test edilecek
özellikleri, test görevlerini, her bir görevi kimin yapacağını, testin bağımsızlık derecesini, test ortamını, test tasarım tekniklerini ve kullanılacak giriş ve çıkış kriterlerini
ve tercih gerekçelerini, beklenmedik durum planlaması gerektiren riskleri diğerlerinden ayırarak tanımlar. Test planlama sürecinin bir kaydıdır. Tablo 4.4.’te bir test
planının adımları verilmiştir.

Master Test Planı (Master Test Plan): Genellikle birden fazla test seviyesini ele alan test planıdır. Proje test planı olarak da adlandırılır.

Faz Test Planı (Phase Test Plan): Genellikle bir tek fazı kapsayan test planıdır.

Seviye Test Planı (Level Test Plan): Bir test seviyesini ele alan test planıdır.

Test Planlama (Test Planning): Bir test planını güncelleme veya oluşturma aktivitesidir.

Test İyileştirme Planı (Test Improvement Plan): Organizasyon test sürecinin ve test süreci değerlerinin mevcut durumdaki güçlü ve zayıf yönlerini ele alarak
iyileştirmeyi hedefleyen plandır.

Tablo 4.4. Bir Test Planı Adımları

34
Hedef : Kapsamın ve risklerin tanımlanması ve hedeflerin belirlenmesi
Tanım : Test seviyelerinin, giriş-çıkış kriterlerinin genel yaklaşımının tanımlanması
Koordinasyon : Test aktivitelerinin, yazılımın yaşam döngüsü ile koordine ve entegre edilmesi
Karar : Test kapsamının, test yönteminin ve sonuçlarının nasıl değerlendirilmesi gerektiği konusunda karar verilmesi
Zaman : Test analizi ve tasarımı aktivitelerinin zaman planlamalarının yapılması
Zaman : Testin uyarlanması, koşulması ve değerlendirme zamanının planlanması
Kaynak : Tanımlanan aktiviteler için kaynak ataması yapılması
Şablon : Test dokümantasyonu için yapı ve şablonun tanımlanması
Metrik : Testin hazırlığı, koşulması, hata yönetimi konularının kontrolü için yöntem belirlenmesi
Prosedür : Test prosedürlerinin ayrıntılarının seviyelerinin belirlenmesi

4.5. Test Araçları ile İlgili Kavramlar

Bu kısımda yazılımda test yapılması ile ilgili kullanılan araçlarla ilgili kavramlardan bahsedilmiştir. Burada ele alınan kavramlar test otomasyonu, test ortamı, test
altyapısı,
test öğesi, test aracı ve test yazılımıdır.

Test Otomasyonu (Test Automation): Test yönetimi, test tasarımı, testin yürütülmesi ve sonuçlarının değerlendirilmesi gibi test aktivitelerine yardımcı olmak için
kullanılan yazılımdır.

Test Ortamı (Test Environment): Testin yapılması için gerek duyulan; donanım, aygıt, simülatörler, yazılım araçları ve diğer destekleyici öğeleri içeren ortamın
tamamına verilen isimdir. Test yatağı olarak da adlandırılır.

Test Altyapısı (Test Infrastructure): Test ortamından, test araçlarından, ofis ortamından ve prosedürlerden oluşan; testin yapılması için gerekli organizasyonel
eserlerdir.

Test Öğesi (Test Item): Teste tabi tutulacak münferit öğedir. Test nesnesi olarak da adlandırılsa da genellikle tek bir test nesnesi ve birçok test öğesi olur.

Test Aracı (Test Tool): Planlama, kontrol, spesifikasyon, test verisinin hazırlanması, test yürütme ve test analizi gibi bir veya birden fazla test aktivitesini
destekleyen yazılım ürünüdür.

Test Yazılımı (Testware): Test sürecinde planlama, tasarım ve yeniden test etme gereksinimleri karşılamak üzere üretilen dokümantasyon, girdiler, beklenen
sonuçlar, betikler, kurulum ve temizleme prosedürleri, dosyalar, veri tabanları, ortamlar ve test için kullanılan her türlü araç veya yazılımlar gibi yapılardır. Test
otomasyonundan farklı olarak test yazılımı test sürecinin her anında kullanılan tüm yazılımlara verilen genel bir isimdir.

4.6. Test Dokümantasyonu ile İlgili Kavramlar

Bu kısımda yapılan testlerin dokümante edilmesi ile ilgili kavramlardan bahsedilmiştir.
Burada ele alınan kavramlar değerlendirme raporu, test değerlendirme raporu, test kaydı,
test kaydı tutma ve test özet raporudur.

Değerlendirme Raporu (Assessment Report): Bir yazılım bileşeninin veya sistemin testi neticesinde oluşan değerlendirme sonuçlarını özetleyen rapordur,
içerisinde sonuçlar, öneriler ve bulgular gibi maddeler bulunmaktadır.

Test Değerlendirme Raporu (Test Evaluation Report): Tüm test aktivitelerini ve sonuçlarını özetleyen, test süreci sonunda üretilen dokümandır. Ayrıca, test
sürecinin değerlendirilmesini ve edinilen tecrübeleri de kapsar.

Test Kaydı (Test Log): Testlerin yürütülmesi ile ilgili detayların kronolojik olarak tutulduğu kayıtlardır.

Test Kaydı Tutma (Test Logging): Test kaydına, yürütülen testlere dair bilgi kaydetme işlemidir.

Test Özet Raporu (Test Summary Report): Test aktivitelerini ve sonuçlarını özetleyen bir dokümandır. Aynı zamanda test çıkış kriterlerine karşılık gelen test
öğelerine bağlı ilerlemeyi de içerir.

4.7. Diğer Kavramlar

Bu kısımda yazılım testleri ile ilgili yukarıdaki başlıklara doğrudan girmeyen diğer bazı kavramlardan bahsedilmiştir. Burada ele alınan kavramlar esas test kümesi,
doğruluk, aktör, testin bağımsızlığı, test yaklaşımı, test mimarı, test esası, test döngüsü, test tasarımı,
test tasarım aracı, test güdümlü geliştirme, test tahminlemesi, test kuluçkası,  test uyarlama,
test seviyesi, Test Olgunluk Model Entegrasyonu, test misyonu, test hedefi, test sonucunu bilen, test performans göstergesi, test fazı, test puanı analizi, test ilerleme
raporu,
test tekrarlanabilirliği, test zaman çizelgesi, test betiği, test oturumu, test stratejisi, test çeşidi, test uzmanı, test etme, test edilebilirlik, test edilebilirliğin gözden
geçirilmesi ve test edilebilir gereksinimdir

Esas Test Kümesi (Basis Test Set): Bir yazılım bileşeninin veya sistemin testi esnasında %100’üne ulaşmak için kullanılan bir grup test senaryosudur.

Doğruluk (Accuracy): Bir yazılım bileşeninin veya sistemin doğru veya kabul edilen sonuçları ya da etkilerini istenen hassasiyet derecesinde sağlayabilme
yeteneğidir.

Aktör (Actor): Test edilmekte olan yazılım bileşeni veya sistem ile etkileşim halinde olan kullanıcılar veya diğer sistemlerdir.

Testin Bağımsızlığı (Independence of Testing): Sorumluluk ve kuvvetler ayrılığıdır; testleri tarafsız gerçekleştirmeyi teşvik eder.

Test Yaklaşımı (Test Approach): Test stratejisinin hayata geçirilmesidir. Test projesinin amacı ve yapılan risk değerlendirmesi doğrultusunda, test süreci ile ilgili
başlangıç noktaları, uygulanacak olan test tasarım teknikleri, test sonlandırma kriterleri ve yapılacak test çeşitleri gibi konularda alınan kararları içermektedir.

Test Mimarı (Test Architect): Bir test organizasyonu ve onun diğer disiplinler ile olan ilişkisi için rehberlik ve stratejik yön sağlayan kişi ya da belirli bir sistem için
test araçları, test verisi yönetimi gibi konularını da içeren yapısal test yöntemlerini belirleyen kişidir.

35
Test Esası (Test Basis): Bir yazılım bileşeni veya sistemin gereksinimlerinin çıkarılabileceği tüm belgeler ve test senaryolarının dayandırıldığı dokümantasyondur.
Eğer doküman sadece resmî bir prosedür ile değiştirilebiliyorsa, test esası değişmez test esası olarak adlandırılır.

Test Döngüsü (Test Cycle): Test sürecinin tek bir test nesnesinin test edilmesine yönelik işletilmesi işlemidir.

Test Tasarımı (Test Design): Genel test amaçlarını, somut test koşullarına ve test senaryolarına dönüştürme sürecidir.

Test Tasarım Aracı (Test Design Tool): Test girdilerini gereksinim yönetim aracı gibi araçlarda tutulan test koşulları veya koddan üreten test tasarım aktivitesini
destekleyen araçtır.

Test Güdümlü Geliştirme (Test Driven Development): Yazılım geliştirilirken, geliştirilecek yazılımla ilgili öncelikle test senaryolarının yazıldığı ve genellikle
otomatize edildiği yazılım geliştirme yöntemidir (Ateş, 2013).

Test Tahminlemesi (Test Estimation): Test sürecinin çeşitli yönleriyle ilgili (örneğin harcanan efor, tamamlanma tarihi, maliyetler, test senaryoları sayısı gibi)
tamamlanmamış, kesin olmayan ya da bozuk olan girdilerin hesaplanmaya çalışılması işlemidir.

Test Kuluçkası (Test Harness): Testin yürütülmesi için gerekli olan taklit uygulamaları ve sürücüleri içeren test ortamıdır.

Test Uyarlama (Test Implementation): Test prosedürlerinin geliştirilmesi ve önceliklendirilmesi, test verisinin yaratılması, test kuluçkasının hazırlanması ve
otomatik test betiklerinin yazılması gibi aktiviteleri içeren süreçtir.

Test Seviyesi (Test Level): Birlikte yönetilen ve organize edilen bir grup test aktivitesidir.
Test seviyesi, bir projede sorumluluklara bağlanır. En önemli test seviyeleri birim testi, entegrasyon testi, sistem testi ve kullanıcı kabul testi test seviyeleridir.

Test Olgunluk Model Entegrasyonu (Test Maturity Model Integration - TMMI):

Beş seviyeli, basamaklı bir yapıdan oluşan, test süreçlerinin iyileştirilmesi için gerekli, etkili test süreçlerinin ana hatlarını tanımlayan, Entegre Yetenek Olgunluk
Modeliyle uyumlu çerçeve modeldir (TMMi Foundation, 2009; Serdaroğlu, 2015; Şit ve Bilgin, 2019).

Test Misyonu (Test Mission): Test politikasının bir parçası olarak dokümante edilen, bir organizasyon için testin amacını tanımlayan cümledir. Test politikası
olarak da adlandırılır.

Test Hedefi (Test Target): Bir testin yürütülme ve tasarlanma amacı veya nedenidir.

Test Sonucunu Bilen (Test Oracle): Testin beklenen sonucunun saptanması için kullanılan kaynaktır. Test sonucunu bilen mevcuttaki sistem, başka bir yazılım,
kullanıcı klavuzu veya kişinin uzmanlık bilgisi olabilir, ancak kod olamaz.

Test Performans Göstergesi (Test Performance Indicator): Test geliştirmesini kontrol eden ve yol gösteren, üst seviye etkinlik ve/veya verimlilik metriğidir.
Örneğin hata yakalama oranı bir test performans göstergesidir.

Test Fazı (Test Phase): Projenin bir parçası olan belirgin test aktiviteleri kümesidir, örnek olarak bir test seviyesinde test yürütme aktiviteleri verilebilir.

Test Puanı Analizi (Test Point Analysis): Fonksiyon puan analizine dayalı test tahminleme formülüdür.

Test İlerleme Raporu (Test Progress Report): Test aktivitelerini ve sonuçlarını özetleyen, düzenli aralıklarda üretilen, testin ilerleyişini bir temele (orijinal test
planı gibi) dayanarak raporlayan ve riskleri ve karar gerektiren altenatifleri yönetime ileten dokümandır.

Test Tekrarlanabilirliği (Test Reproducibility): Test yürütüldüğünde her defasında aynı sonuçların üretilebilme durumunu gösteren özelliktir.

Test Zaman Çizelgesi (Test Schedule): Test sürecinde, başlangıç ve bitiş tarih ve/veya zamanlarının birbirleri ile bağımlılıkları göz önüne alınarak tanımlanan
aktivite, iş, görev veya etkinlik listesidir.

Test Betiği (Test Script): Özellikle otomatize olanı olmak üzere test prosedürü spesifikasyonunu ifade eder.

Test Oturumu (Test Session): Testler yürütülürken kesinti olmaksızın harcanan zaman aralığıdır. Keşif testlerinde, her test oturumu başlatma belgesini baz alır,
fakat test uzmanları oturum süresince yeni tasarımlar yaparak farklı hataları bulmaya çalışırlar. Test senaryoları anlık yaratılıp yürütülür ve hatalar kayıt altına alınır.

Test Stratejisi (Test Strategy): Bir ya da birden fazla projede koşturulacak test seviyelerinin üst seviye tanımı ve bir organizasyon veya program için bu
seviyelerdeki test sürecidir.

Test Çeşidi (Test Type): Bir sistem veya bileşeni test etmeyi amaçlayan, belirli bir test hedefine odaklanmış (fonksiyonel test, kullanılabilirlilik testi, regresyon testi
gibi) bir grup test aktivitesidir. Bir test çeşidi bir veya birden fazla test seviyesinde yer alabilir.

Test Uzmanı (Tester): Bir sistemin veya bir bileşenin testini yapan vasıflı uzman kişi veya kişilerdir.

Test Etme (Testing): Tüm test aktivite yaşam döngüsünü içeren süreçtir.
Belirlenmiş gereksinimlerin karşılandığını doğrulamak, amaç için uygun olduğunu göstermek ve hataları tespit etmek için planlama, hazırlık ve yazılımın
değerlendirilmesi süreçlerinden oluşur.

Test Edilebilirlik (Testability): Yazılımın üzerinde değişiklik yapıldıktan sonra da test edilmesine olanak verme yeteneğidir. Test edilebilirlik yazılım ürünlerinin içsel
bir özelliği olmadığı için doğrudan ölçülmesi mümkün değildir. Ancak farklı yöntemlerle ölçülebilir (Hanoğlu, 2019).

Test Edilebilirliğin Gözden Geçirilmesi (Testability Review): Test esaslarının test süreçlerine girdi olarak kullanılabilecek kaliteye sahip olup olmadığının detaylı
kontrol edilmesidir.

Test Edilebilir Gereksinim (Testable Requirement): Gereksinimlerin test tasarımları ve test yürütümüne olanak verecek nitelikte olmasıdır.

Bölüm Özeti
Yazılım testinin başarılı bir şekilde anlaşılabilmsi için bilinmesi gereken birçok kavram vardır. Bu bölümde bu kavramlardan en önemlilerine yer verilmiştir. Bu
bölümde ele alınan kavramlar aşağıdaki şekilde gruplandırılabilir.

Test Verileri ve Test Senaryoları İle İlgili Kavramlar

36
 Test Senaryosu

 Bloke Test Senaryosu

 Üst Seviye Test Senaryosu

 Alt Seviye Test Senaryosu 

 Test Spesifikasyonu

 Test Senaryo Spesifikasyonu

 Test Senaryo Grubu

 Test Senaryo Tasarım Tekniği

 Test Tasarım Spesifikasyonu 

 Test Prosedür Spesifikasyonu

 Test Verisi

 Test Verisi Hazırlama Aracı 

 Test Verisi Yönetimi

 Test Girdisi

 Test Çıktısı 

Test Başlatma, Bitiş ve Kabul İle İlgili Kavramlar

 Kabul Kriteri

 Koşul

 Test Başlatma Belgesi

 Test Kapanışı

 Beklenen Sonuç

 Test Karşılaştırma

 Test Karşılaştırıcı

 Test Koşulu

 Gerçekleşen Sonuç

Test Yönetimi,  Yürütmesi,  Uygulanması ve Süreci İle İlgili Kavramlar

 Kritik Test Süreçleri

 Test Yönetimi

 Test Yöneticisi

 Test Direktörü

 Test Yönetim Aracı

 Test Kontrol

 Test Yürütme

 Test Yürütme Otomasyonu

 Test Yürütme Fazı

 Test Yürütme Çizelgesi

 Test Yürütme Tekniği

 Test Yürütme Aracı

 Test Süreci

 Test Süreç Grubu

 Test Süreç İyileştirme Bildirgesi

 Test Süreç İyileştiricisi

Test Planı İle İlgili Kavramlar

 Test Planı
37
 Master Test Planı

 Faz Test Planı

 Seviye Test Planı

 Test Planlama

 Test İyileştirme Planı

Test Araçları İle İlgili Kavramlar

 Test Otomasyonu

 Test Ortamı

 Test Altyapısı

 Test Öğesi

 Test Aracı

 Test Yazılımı

Test Dokümantasyonu İle İlgili Kavramlar

 Değerlendirme Raporu

 Test Değerlendirme Raporu

 Test Kaydı

 Test Kaydı Tutma

 Test Özet Raporu 

Diğer
Kavramlar                                                                                                                                                                                                                                        

 Esas Test Kümesi

 Doğruluk

 Aktör

 Testin Bağımsızlığı

 Test Mimarı

 Test Esası

 Test Döngüsü

 Test Tasarımı

 Test Tasarım Aracı

 Test Güdümlü Geliştirme

 Test Tahminlemesi

 Test Kuluçkası

 Test Uyarlama

 Test Seviyesi

 Test Olgunluk Model Entegrasyonu

 Test Misyonu

 Test Hedefi

 Test Sonucunu Bilen

 Test Fazı

 Test Puanı Analizi

 Test İlerleme Raporu

 Test Tekrarlanabilirliği

 Test Zaman Çizelgesi

 Test Oturumu

38
 Test Stratejisi

 Test Çeşidi

 Test Uzmanı

 Test Etme.

 Test Edilebilirlik

 Test Edilebilirliğin Gözden Geçirilmesi

 Test Edilebilir Gereksinim

Kaynakça

Ykc Grup, Yazılım Test Hizmeti, http://www.ykcgrup.com.tr/yazilim-test-hizmeti/, 2021

ISTQB Yazılım Testi Terimler Sözlüğü, 2014

E. Hanoğlu, Açık Kaynak Yazılım Projeleri İçin İçsel Ürün Özelliklerine ve Metriklerine Dayalı Bir Test Edilebilirlik Analizi Yöntemi, Hacettepe Üniversitesi, Fen
Bilimleri Enstitüsü,  Yüksek Lisans Tezi, 2019

G. Şit, M. B. Bilgin, Test Olgunluk Modeli Entegrasyonu (TMMi) ile Yazılım Test Süreçlerinin İyileştirilmesi, ISAS, 3rd International Symposium on Innovative
Approaches in Scientific Studies

TMMi Foundation, TMMI Framework and Levels, 2009, www.tmmifoundation.org

D. Serdaroğlu, Yazılım Test Süreci ve TMMi Modelinde Prisma Yaklaşımı Uygulaması, Yüksek Lisans Tezi, Başkent Üniversitesi Fen Bilimleri Enstitüsü, 2015

Ü. Ateş, Test Güdümlü Programlama, BM Dergi 2013

Ünite Soruları

Soru-1 :

Yazılım test senaryoları ile ilgili, aşağıdaki hangi isimde bir kavram bulunmamaktadır?

(•) - Bloke Test Senaryosu

(•) - Test Senaryosu

(•) - Orta Seviye Test Senaryosu

(•) - Alt Seviye Test Senaryosu

(•) - Üst Seviye Test Senaryosu

Cevap-1 :

Orta Seviye Test Senaryosu

Soru-2 :

Aşağıda verilen şekil yazılım testlerinin hangi kavramı ile ilgilidir?

39
(•) - Test Koşulu

(•) - Beklenen Sonuç

(•) - Başlatma Belgesi

(•) - Gerçekleşen Sonuç

(•) - Test Karşılaştırıcı

Cevap-2 :

Test Koşulu

Soru-3 :

Test edilebilirlik aşağıdaki tanımların hangisi ile ifade edilebilir?

(•) - Yazılımcının yazılımı test etme yeteneği

(•) - Yazılımın üzerinde değişiklik yapıldıktan sonra da test edilmesine olanak verme yeteneği

(•) - Yazılım üzerinde test otomasyonlarının kullanılabilme yeteneği

(•) - Yazılım üzerinde farklı kişilerin test yapabilmesi yeteneği

(•) - Yazılımın aktif bir şekilde test edilme yeteneği

Cevap-3 :

Yazılımın üzerinde değişiklik yapıldıktan sonra da test edilmesine olanak verme yeteneği

Soru-4 :

Yazılım test planı ile aşağıdaki hangi isimde bir kavram bulunmamaktadır?

(•) - Master Test Planı

(•) - Faz Test Planı

(•) - Seviye Test Planı

(•) - Test İyileştirme Planı

(•) - Test Analiz Planı

Cevap-4 :

Test Analiz Planı

Soru-5 :

Bir yazılım testinin yukarıdan aşağıya ya da aşağıdan yukarıya şeklinde yapılması aşağıdaki kavramların hangisi ile ifade edilebilir?

(•) - Test Tasarımı

(•) - Test Kuluçkası

(•) - Test Seviyesi

(•) - Test Yaklaşımı

(•) - Test Esası

Cevap-5 :

Test Yaklaşımı

Soru-6 :

Teste tabi tutulacak tekil elemanlara aşağıdaki isimlerden hangisi verilmektedir?

(•) - Test Yazılımı

40
(•) - Test Öğesi

(•) - Test Altyapısı

(•) - Test Ortamı

(•) - Test Planı

Cevap-6 :

Test Öğesi

Soru-7 :

Temel bir test planında aşağıdaki hangi isimde bir aşama bulunmamaktadır?

(•) - Tanım

(•) - Zaman

(•) - Şablon

(•) - Analiz

(•) - Prosedür

Cevap-7 :

Analiz

Soru-8 :

Bir yazılım testi için gerekli olan kaynakların temin edilmesinden kim sorumludur?

(•) - Test Uzmanı

(•) - Test Yöneticisi

(•) - Test Analisti

(•) - Test Yazımcısı

(•) - Test Kontrolörü

Cevap-8 :

Test Yöneticisi

41
5. YAZILIM TEST ÇEŞİTLERİ
Giriş
Yazılım testi denilince genellikle insanların aklına birkaç tane testin adı gelir.
Halbuki yazılım test dünyası bir hayli geniştir ve yapılabilecek pek çok test bulunmaktadır. Her ne kadar her test her yazılım türüne uygulanamıyor olsa da genel
olarak yazılım test çeşitlerini bilmek, her yazılım türünde farklı bakış açıları kazanmayı sağlayabilecektir. Bu sebeple bu bölümde farklı yazılım test türleri açıklanmaya
çalışılmıştır.

5.1. Koşul, Durumlar ve Süreç ile İlgili Testler

Bu kısımda yazılımların koşulları, durumları ve süreçleri ile ilgili test türleri incelenmiştir. Burada incelenen test türleri karşılaştırma testi, koşul testi, karar testi, karar
tablosu testi, karar koşul testi, değiştirilmiş koşul karar testi, çoklu koşul testi, kontrol akış testi, n-anahtar testi, negatif test, temel karşılaştırma testi, geniş kapsamlı
test, iş sürecine dayalı test, süreç uyumluluk testi, süreç döngü testi, kontrol listesine dayalı test, durum geçişi testi,
sınır değer testi, Çevik test, beyaz kutu testi, kara kutu testi, fonksiyonel test, tepkisel test, tekrar testi, betikleştirilmiş test, komut testi, yol testi, içeriye dahil edilen
kaynaklarla yapılan test, tecrübeye dayalı test, kombinasyonlu test, geçersiz girdilerin testi, aksiyon kelimesi güdümlü test, veri güdümlü test, metodik test, model
bazlı test, duman testi, alım testi, istatistiksel test, dikey dizi testi, ikili test, statik test, sözdizim testi, prosedür testi, fonksiyonel olmayan test, operasyonel profil testi,
operasyonel test, dış kaynaklı test, eşli test, ayrıştırma (izolasyon) testi, keşif testi, veri akış testi, tasarım bazlı test, geliştirme testi, dokümantasyon testi, dinamik test,
danışılarak yapılan testler, dal testi, kurgusuz test ve analitik testidir.

Karşılaştırma Testi (Benchmark Test): Yazılım bileşenleri veya sistemlerinin birbirleri arasında veya bir standarta göre karşılaştıran testtir.

Koşul Testi (Condition Testing): Test senaryolarının koşul sonuçlarını koşturacak biçimde tasarlandığı bir beyaz kutu test tasarım tekniğidir.

Karar Testi (Decision Testing): Karar çıktılarının yürütülmesi için tasarlanan test senaryolarını içeren beyaz kutu test tasarım tekniğidir.

Karar Tablosu Testi (Decision Table Testing): Test senaryolarının bir karar tablosundaki girdi ve/veya tetikleyici (neden) kombinasyonlarını içerecek şekilde
tasarlandığı test tekniğidir.

Karar Koşul Testi (Decision Condition Testing): Test senaryolarının, koşul ve karar çıktılarını yürütecek şekilde tasarlandığı beyaz kutu test tasarım tekniğidir.

Değiştirilmiş Koşul Karar Testi (Modified Condition Decision Testing): Test senaryolarının karar sonucunu bağımsız olarak etkileyen tekil koşul sonuçlarını
üretmek için tasarlandığı beyaz kutu tasarım tekniğidir.

Çoklu Koşul Testi (Multiple Condition Testing): Test senaryolarının tek bir komut içindeki tekil koşul kombinasyonlarını çalıştırmak için tasarlandığı beyaz kutu
test tekniğidir.

Kontrol Akış Testi (Control Flow Testing): Test senaryolarının, olayların belli sırada yürütülmesine göre tasarlandığı yapısal bir test yaklaşımıdır. 

N-Anahtar Testi (N-Switch Testing): Tüm geçerli N+1 geçişleri çalıştırmak için tasarlanmış durum geçiş testleridir.

Negatif Test (Negative Testing): Bir yazılım bileşeninin veya sisteminin çalışmadığı noktaları göstermeyi amaçlayan testtir. Negatif testler belli bir test yaklaşımı
veya test tasarım tekniğinden ziyade test uzmanının tutumu ile ilgilidir. Örnek olarak; geçersiz veri girişi veya istisnaî durumlar ele alınabilir. Şekil 5.1.’de sembolik bir
negatif test görülmektedir (Ravichandran, 2018).

Şekil 5.1. Negatif Test

Temel Karşılaştırma Testi (Elementary Comparison Testing): Test senaryolarının değiştirilmiş koşul karar kapsamı tekniğini baz alarak girdi
kombinasyonlarının tasarlandığı kara kutu test tasarım tekniğidir.

Geniş Kapsamlı Test (Exhaustive Testing): Test grubunun tüm girdi ve ön koşul kombinasyonlarını kapsadığı test yaklaşımıdır.

İş Sürecine Dayalı Test (Business Process-Based Testing): Test senaryolarının iş süreçleri baz alınarak oluşturulduğu test yaklaşımıdır.

Süreç Uyumluluk Testi (Process-Compliant Testing): Bir yazılım bileşeni veya sistemi üzerinde, tanımlı süreçlere göre koşturulan testtir. Örnek standart
belirleme komitesi tarafından tanımlanan süreçler verilebilir.

Süreç Döngü Testi (Process Cycle Test): Test senaryolarının iş prosedürlerini ve süreçlerini koşturması için tasarlanan kara kutu test tasarlama tekniğidir.

Kontrol Listesine Dayalı Test (Checklist-Based Testing): Tecrübeye dayalı bir test tasarım tekniğidir. Bu teknikte tecrübeli test uzmanı, yazılımı doğrulamak
için kural veya kriterlerden oluşan genel bir liste kullanır.

Durum Geçişi Testi (State Transition Testing): Test senaryolarının geçerli ve geçersiz durum geçişlerini test edebilmek amacıyla tasarlandığı, kara kutu test
tekniğidir.

Sınır Değer Testi (Boundary Value Testing): Test senaryolarının, sınır değerlerine göre tasarlandığı kara kutu test tasarım tekniğidir (Arnicane, 2009).

42
Çevik Test (Agile Testing): Çevik yazılım geliştirme metodolojilerinin test ayağıdır.
Aşırı programlama (Extreme Programming - XP), Scrum, Kanban, FDD, DSDM, ASD gibi metodların kullanıldığı; yazılım geliştirme sürecinin test sürecinin
müşterisi gibi davranıldığı ve önce testi hazırla yaklaşımının benimsendiği süreçtir (Baran ve diğ., 2016).

Beyaz Kutu Testi (White Box Testing): Bir yazılım bileşeninin veya sisteminin bileşenin içyapısının analizinin yapıldığı test türüdür. 6. ve 7. bölümde daha ayrıntılı
olarak açıklanacaktır.

Kara Kutu Testi (Black Box Testing): Bir yazılım bileşeninin veya sisteminin iç çalışma mantığı dikkate alınmadan fonksiyonel veya fonksiyonel olmayan
şekillerde test edilmesi aktivitesidir. 6. ve 7. bölümde daha ayrıntılı olarak açıklanacaktır.

Fonksiyonel Test (Functional Testing): Bir yazılım bileşeninin veya sisteminin işlevsel özelliklerinin analizine dayanan testtir. 6. bölümde daha ayrıntılı olarak
açıklanacaktır.

Tepkisel Test (Reactive Testing): Bir yazılım bileşeninin veya sisteminin verdiği tepkilere ve koşturulan testlerin sonucuna göre akışın belirlendiği testlerdir.
Genellikle tepkisel testlerin planlama zamanları kısadır ve test edilecek sistem veya nesne gelmeden test tasarımı ve testin uyarlanmasına başlanılmaz.

Tekrar Testi (Re-testing): Yapılan düzeltmelerin başarısını doğrulamak için, en son koşturulduğunda başarısız olmuş test senaryolarını koşturan test türüdür.

Betikleştirilmiş Test (Scripted Testing): Hazırlanmış test senaryolarının sıralı komutlar halinde koşturulması sonucu yapılan test türüdür.

Komut Testi (Statement Testing): Test senaryolarının yazılım komutlarını çalıştıracak şekilde tasarlandığı beyaz kutu test tekniğidir.

Yol Testi (Path Testing): Test senaryolarının yolların çalıştırılması için tasarlandığı beyaz kutu test tekniğidir.

İçeriye Dahil Edilen Kaynaklarla Yapılan Test (Insourced Testing): Şirketin bordrolu çalışanı olmayan ancak proje takımı ile aynı yerde çalışan kişiler
tarafından yapılan testtir.

Tecrübeye Dayalı Test (Experience-Based Test): Test edenin tecrübe, bilgi ve sezgisine bağlı olarak yapılan test türüdür.

Kombinasyonlu Test (Combinatorial Testing): Parametrelerinin herbirinin farklı değerler alabileceği çoklu parametreye sahip objede istenilen test kapsamına en
makul şekilde ulaşmak için test kombinasyonlarından en uygun alt kümenin seçilerek yapılan testtir.

Geçersiz Girdilerin Testi (Invalid Testing): Bir yazılım bileşeni veya sistemi tarafından reddedilmesi beklenen girdi değerleri kullanılarak yapılan testtir.

Aksiyon Kelimesi Güdümlü Test (Keyword-Driven Testing): Test girdilerini içeren dosyada sadece test verilerinin ve beklenen sonuçların değil, aynı zamanda
test senaryosunu oluşturacak aksiyon kelimelerinin de bulunduğu test etme tekniğidir.

Veri Güdümlü Test (Data-Driven Testing): Test girdi ve beklenen sonuçlarını bir tabloda saklayan, bu sayede tek bir test betiğinin tablodaki tüm testleri
çalıştırabildiği bir test tekniğidir.

Metodik Test (Methodical Testing): Bir yazılım bileşeni veya sistemi için bir dizi standart testi temel alarak yapılan testtir. Örneğin bir kontrol listesi, bir kalite
standardı veya genelleştirilmiş test senaryoları olarak ifade edilebilir.

Model Bazlı Test (Model-Based Testing): Bir yazılım bileşenini veya sistemini modelleyen testtir; örneğin güvenirlik büyüme modelleri, kullanım modellerini
operasyonel profil olarak ya da davranışsal modelleri karar tablosu veya geçiş diyagramı olarak modellemek gibi düşünülebilir.

Duman Testi (Smoke Test): Bir yazılım bileşeninin veya sisteminin en önemli fonksiyonlarının çalışıp çalışmadığını anlamak amacıyla detaylara girmeden yapılan
test tekniğidir (Chauhan, 2014).

Alım Testi (Intake Test): Bir yazılım bileşeninin veya sisteminin detaylı ve ileri seviye testlere hazır olup olmadığına karar verilen bir duman testi örneğidir. Alım
testi genelde test uygulama aşamasının başlangıcında gerçekleştirilir.

İstatistiksel Test (Statistical Testing): Test senaryolarının ve girdilerin istatiksel dağılım modellemesine göre tasarlandığı test tekniğidir.

Dikey Dizi Testi (Orthogonal Array Testing): Değişkenlerin tüm ikili kombinasyonlarının dikey diziler kullanılarak test edildiği sistematik test yöntemidir. Bu
yöntem tüm ikili kombinasyon değişkenlerini test etmek için gerekli test senaryosu sayısını önemli ölçüde azaltır.

İkili Test (Pairwise Testing): Bir yazılım bileşeninin veya sisteminin tüm ikili girdi kombinasyonlarını çalıştırmak için test senaryolarının tasarlandığı kara kutu test
tasarım tekniğidir (Oster ve diğ., 2010; Perrouin ve diğ., 2011).

Statik Test (Static Testing): Gereksinimler, tasarım ya da kod gibi yazılım geliştirme eserlerinin çalıştırılmadan, gözden geçirilerek ya da statik analiz kullanılarak
hatalarını bulmak için ile yapılan testlerdir.

Sözdizim Testi (Syntax Testing): Test senaryolarının bir yazılım bileşeni veya sisteminin girdi ve çıktı alanlarına dayandırılarak tasarlandığı bir kara kutu test
tekniğidir Şekil 5.2.’de sembolik bir sözdizim testi görülmektedir.

Şekil 5.2. Sözdizim Testi

Prosedür Testi (Procedure Testing): Testi yapılan bir yazılım bileşeninin veya sisteminin mevcut veya yeni iş/operasyonel prosedürleri karşılayıp karşılamadığına
bakılması için gerçekleştirilen test türüdür.
43
Fonksiyonel Olmayan Test (Non-Functional Testing): Bir yazılım bileşeninin veya sisteminin fonksiyonalitesiyle ilgili olmayan niteliklerinin testidir. Burada örnek
olarak örneğin güvenilirlik, verimlilik, kullanılabilirlik, sürdürülebilirlik ve taşınabilirlik verilebilir.
6. bölümde daha ayrıntılı olarak açıklanacaktır.

Operasyonel Profil Testi (Operational Profile Testing): Bir yazılım bileşeninin veya sistemi operasyonlarının ve olasılıklarının (kısa süreli işlemler) modellemesini
baz alan istatistiki test türüdür.

Operasyonel Test (Operational Testing): Bir yazılım bileşeni veya sistemini kendi operasyonel ortamında değerlendirmek için çalıştırılan test türüdür.

Dış Kaynaklı Test (Outsourced Testing): Proje takımıyla aynı yerde bulunmayan ve firmanın kendi personeli olmayan kişiler tarafından yapılan test türüdür.

Eşli Test (Pair Testing): İki kişinin; örneğin iki test uzmanı, ya da yazılımcı ve test uzmanı, ya da son kullanıcı ve test uzmanının bir yazılım bileşeninin veya sistemi
üzerinde hata bulmak üzere beraber çalışması ile gerçekleştirilen test türüdür. Genellikle bu iki kişi test esnasında tek bir bilgisayarı paylaşırlar.

Ayrıştırma (İzolasyon) Testi (Isolation Testing): Bir yazılım bileşeninin tek başına etraftaki bileşenlerden ayrıştırılmış olarak ele alındığı test türüdür. Bileşenler
etkileşim halinde olduğu diğer bileşenler gerekirse sürücüler ve taklit uygulamalar ile simüle edilebilir.

Keşif Testi (Exploratory Testing): Test edenin daha iyi ve daha yeni testleri tasarlamak için test yaparken edindiği bilgiyi kullanarak ve bu testleri yürüterek bilfiil
test tasarımını kontrol altına aldığı gayri resmi test tasarım tekniğidir (Itkonen ve Rautiainen, 2005; Pfahl ve diğ.,2014), Şekil 5.3.’te sembolik bir keşif testi
görülmektedir (Karacahisarlı, 2018).

Şekil 5.3. Keşif Testi

Tasarım Bazlı Test (Design-Based Testing): Test senaryolarının mimarî ve/veya sistemin detaylı tasarımı baz alınarak oluşturulduğu test yaklaşımıdır. Örnek
olarak bileşen veya sistemler arasındaki arayüzlerin testleri verilebilir.

Veri Akış Testi (Data Flow Testing): “Tanım-kullanım” çiftlerinin çalıştırılarak test edilmesine yönelik test senaryoları içeren beyaz kutu test tasarım tekniğidir.

Geliştirme Testi (Development Testing): Genellikle yazılımcılar tarafından bir yazılım bileşeni veya sisteminin devreye alınması sırasında geliştirme ortamında
gerçekleştirilen resmî veya gayrı resmî testtir.

Dokümantasyon Testi (Documentation Testing): Kullanım kılavuzu veya kurulum kılavuzu gibi dokümanların kalitesinin analiz edilmesi için gerçekleştirilen test
türüdür.

Dinamik Test (Dynamic Testing): Bir yazılım bileşeni veya sistemi üzerinde çalışma esnasında gerçekleştirilen test türüdür.

Danışılarak Yapılan Testler (Consultative Testing): Test ekibi dışındaki bilirkişilerin/uzmanların (iş alanındaki konu uzmanları, teknoloji uzmanları) tavsiye,
yardım ve yönlendirmesiyle yapılan testlerdir.

Dal Testi (Branch Testing): Test senaryolarının programdaki dalları yürütmek için dizayn edildiği beyaz kutu test tasarım tekniğidir.

Analitik Test (Analytical Testing): Sistematik analize dayalı olan testlerdir.

Kurgusuz Test (Ad-Hoc Testing): Resmî olmadan yürütülen test; resmî test hazırlığı yapılmadan, test tasarım tekniği kullanılmadan, beklenen sonucun tam net
olmadığı ve test koşumunun gelişigüzel yapıldığı testlerdir. Şekil 5.4.’te sembolik bir kurgusuz test gösterilmektedir.

Şekil 5.4. Kurgusuz Test

5.2. Bileşenler, Entegrasyon ve Sistem ile İlgili Testler

Bu kısımda yazılımların bileşenleri, entegrasyonları ve sistem özellikleri ile ilgili testler ele alınmıştır. Burada incelenen test türleri bileşen testi, entegrasyon testi, sistem
entegrasyon testi, sistem testi, komşuluk entegrasyon testi, ikili entegrasyon testi, arayüz testi, artımlı test, veri tabanı bütünlük testleri, yukardan aşağıya test,
aşağıdan yukarıya test, Big Bang testi, bileşen entegrasyon testi, donanım-yazılım entegrasyon testi, uygulama programlama arayüzü testi, arka-arkaya test ve iş
parçacığı testidir.

44
Bileşen Testi (Component Testing): Bileşenler üzerinde tek başına yapılan testtir.

Entegrasyon Testi (Integration Testing): Entegre bileşenler veya sistemlerin arayüz ve etkileşimlerindeki hataları açığa çıkarmak için yapılan test türüdür.

Sistem Entegrasyon Testi (System Integration Testing): Sistemlerin birbirleri veya dış birimler ile entegrasyonunun testidir. Burada örnek olarak elektronik veri
değişimi, internet gibi maddeler verilebilir.

Sistem Testi (System Testing): Sistemin istenilen gereksinimleri karşılayıp karşılamadığını doğrulamak amacıyla yapılan test sürecidir.

Komşuluk Entegrasyon Testi (Neighborhood Integration Testing): Ele alınan düğüme komşu tüm düğümlerin entegrasyon testine dahil edildiği testtir.

İkili Entegrasyon Testi (Pairwise Integration Testing): Çağrı grafiğine göre beraber çalışan ikili bileşenleri hedefleyen entegrasyon testi türüdür.

Arayüz Testi (Interface Testing): Yazılım bileşenleri veya sistemleri arasındaki arayüzlerin testleriyle ilgili bir entegrasyon test türüdür.

Artımlı Test (Incremental Testing): Bu testte, tek tek ya da birden fazla bileşen veya sistem entegre ve test edilir. Bu işlem, tüm bileşenler veya sistemler entegre
ve test edilene kadar sürer.

Veri Tabanı Bütünlük Testleri (Database Integrity Testing): Veri tabanına ulaşmak ve yönetmek için gerekli metod ve süreçlerin ele alındığı test türüdür.
Burada amaç erişim metodlarının, süreçlerinin ve veri kurallarının beklendiği gibi çalıştığının, ayrıca veri tabanının çöküp çökmediği, verilerin beklenmeyen şekilde
silinip, yaratılıp, güncellenmediğinin kontrolüdür.

Yukardan Aşağıya Test (Top-Down Testing):  Bir çeşit entegrasyon testi yaklaşımıdır.
Teste bileşen hiyerarşisinin başındaki bileşenden başlanır, alt seviyedeki bileşenler taklit uygulamalar halinde simule edilir. Test edilen bileşen ya da sistem daha sonra
alt seviyedeki bileşenleri test etmek için kullanılır. Süreç en alt seviyedeki bileşenin testi bitinceye kadar devam eder.

Aşağıdan Yukarıya Test (Bottom-Up Testing): Entegrasyon testinde en düşük seviyedeki bileşenlerin ilk olarak test edildiği ve bu test edilen bileşenlerin daha
üstteki bileşenlerin testleri için kullanıldığı artımsal test yaklaşımıdır. Bu süreç en üst seviyedeki bileşenler test edilene kadar tekrarlanır.

Big Bang Testi (Big Bang Testing): Yazılım bileşenleri veya sisteminin, donanım bileşenleri veya sisteminin veya her ikisinin aynı anda birleştirilerek başka bir
bileşene veya genel sisteme tek seferde dönüştürülerek test edilmesini sağlayan bir entegrasyon test yaklaşımıdır.

Bileşen Entegrasyon Testi (Component Integration Testing): Entegre bileşenlerin arayüzlerinde ve etkileşimlerindeki hataları bulmaya yönelik yapılan test
türüdür.

Donanım-Yazılım Entegrasyon Testi (Hardware-Software Integration Testing): Yazılım bileşenleri veya sistemi ve donanım bileşenleri veya sistemi arasındaki
arayüzlerde ve etkileşimlerinde oluşabilecek hataları ortaya çıkarmaya yönelik yapılan test türüdür.

Uygulama Programlama Arayüzü Testi (Application Programming Interface-API) Testing):  Farklı süreçler, programlar ve/veya sistemler arası iletişime
olanak sağlayan kodların testidir. Bu test genellikle negatif testlerden oluşur örneğin hata ele alma algoritmasının sağlamlığının test edilmesi gibi düşünülebilir.

Arka-Arkaya Test (Back-to-Back Testing): Bir yazılım bileşeni veya sisteminin iki veya daha fazla varyansının aynı girdilerle test edilmesi, çıktılarının
karşılaştırılması ve tutarsızlık durumunda analiz edilmesidir.

İş Parçacığı Testi (Thread Testing): Bir çeşit bileşen/birim entegrasyon testi yaklaşımıdır.
Bu yaklaşımda hiyerarşik seviyede bileşenlerin entegrasyonuna karşın, gereksinimler hayata geçirildikçe ilgili bileşenler entegre edilir.

5.3. Kullanım, Kullanıcı, Kabul ile İlgili Testler

Bu kısımda yazılımların kullanımları, kullanıcıları ve yazılımların kabul edilmeleri ile ilgili gerekli koşullar ile ilgili test türleri incelenmiştir. Burada ele alınan test türleri
kullanıcı testi, kullanıcı hikayesi testi, kullanılabilirlik testi, kullanım senaryosu testi, kabul testi,  operasyonel kabul testi, fabrika kabul testi, saha kabul testleri,
rastgele test, alfa testi,  beta testi ve maymun testidir.

Kullanıcı Testi  (User Test): Bir yazılım bileşeninin veya sisteminin kullanılabilirlik özelliklerinin gerçek kullanıcılar tarafından değerlendirildiği test türüdür.

Kullanıcı Hikayesi Testi (User Story Testing): Kullanıcı hikayeleri baz alınarak tasarlanmış test koşullarının doğrulandığı kara kutu test tasarım tekniğidir.

Kullanılabilirlik Testi (Usability Testing): Belirlenmiş koşullar altında yazılım ürününün kullanıcıya cazip geldiğini, kolay kullanılabildiğini, kolay öğrenilebildiğini
ve anlaşılabildiğini doğrulamak için yapılan testtir.

Kullanım Senaryosu Testi (Use Case Testing): Test koşullarının, kullanım senaryolarının koşulması için tasarlandığı bir karar kutu test tekniğidir.

Kabul Testi (Acceptance Testing): Bir yazılım bileşeninin veya sisteminin kabul edilmesine karar vermek için yapılan; kullanıcı ihtiyaçları, gereksinimleri ve iş
sürecine göre yürütülen, sistemin kabul kriterine uygunluğunu, kullanıcıyı, müşteriyi veya yetkili birimi etkin kılarak denetleyen resmi test aktivitesidir.

Operasyonel Kabul Testi (Operational Acceptance Testing): Kabul testi fazında, tipik olarak operasyon ortamında yapılan (simule edilen), operasyon ve/veya
sistem yönetimi yetkilileri tarafından sistemin operasyonel yönlerine odaklanılarak yapılan testtir. Burada örnek olarak kurtarılabilirlik, kaynak kullanımı, kurulabilirlik
ve teknik uyum verilebilir.

Fabrika Kabul Testi (Factory Acceptance Testing): Bir yazılım bileşeninin veya sisteminin gereksinimleri karşılayıp karşılamadığına karar vermek için ürünün
geliştirildiği yerde tedarikçi firmanın personeli tarafından gerçekleştirilen kabul testidir. Genel kullanım donanım için olsa da yazılım için de kullanılır.

Saha Kabul Testleri (Site Acceptance Testing): Bir yazılım bileşeninin veya sisteminin kullanıcının ihtiyaçlarını karşılayıp karşılamadığını, iş süreçlerine uygun olup
olmadığını belirlemek amacı ile kullanıcılar/müşteriler tarafından kendi sahalarında yapılan kabul testidir, genellikle yazılımın yanısıra donanım testlerini de içerir.

Rastgele Test (Random Testing): Test senaryolarının genellikle sözde rastgele algoritmalardan seçilerek güncel hayattaki senaryolara benzetildiği kara kutu test
tekniğidir.
Bu teknik performans ve güvenilirlik gibi fonksiyonel olmayan özelliklerin testinde kullanılabilir.

Alfa Testi (Alpha Testing): Potansiyel kullanıcı/müşteri veya bağımsız test ekibi tarafından yazılım geliştiricinin kendi ortamında fakat yazılım geliştirme ekibinin
kontrolü dışında yapılan operasyonel testtir. Alfa testi genellikle iç kabul testleri şeklinde paket yazılımlar için yapılmaktadır.

45
Beta Testi (Beta Testing): Potansiyel ve/veya var olan, harici konumda bulup, geliştiricilere dahil olmayan kullanıcı/müşterinin; bir bileşenin veya sistemin,
kullanıcı/müşteri ihtiyaçlarına ve iş süreçlerine uygunluğuna karar vermesi için yürütülen işletimsel testtir. Beta testi genel olarak harici kabul testi olarak paket yazılım
ürününün üzerinde pazardan geri bildirim almak amacı ile gerçekleştirilir.

Maymun Testi (Monkey Testing): Geniş bir giriş veri seti içerisinden rastgele seçilerek yapılan ve ürünün nasıl kullanıldığının hiç önemi olmadan sadece rastgele
tuşlara basılarak yapılan test türüdür.

5.4. Güvenlik ile İlgili Testler

Bu kısımda bir yazılımın en önemli noktalarından biri olan güvenlik konusu ile ilgili test türleri incelenmiştir. Burada ele alınan test türleri güvenlik testi, güvenilirlik testi,
kurtarılabilirlik testi, sağlamlık testi, emniyet testi, sürdürülebilirlik testi, risk bazlı test, saldırı bazlı test, bakım testi, arıza durumu testi ve regresyon hassasiyetli testtir.

Güvenlik Testi (Security Testing): Bir yazılım bileşeninin veya sisteminin ne kadar güvenli olduğunu belirlemeye yönelik yapılan testlerdir.

Güvenilirlik Testi (Reliability Testing): Bir yazılım bileşeninin veya sisteminin güvenilirliğini belirleyen test sürecidir.

Kurtarılabilirlik Testi (Recoverability Testing): Bir yazılım bileşeninin veya sisteminin kurtarılabilirliğinin test edilmesidir.

Sağlamlık Testi (Robustness Testing): Bir yazılım bileşeninin veya sisteminin sağlamlığını belirleme testidir.

Emniyet Testi (Safety Testing): Bir yazılım bileşeninin veya sisteminin emniyetli olup olmadığının belirlenmesi testidir.

Sürdürülebilirlik Testi (Maintainability Testing): Bir yazılım bileşeninin veya sisteminin sürdürülebilirliğini belirlemek için gerçekleştirilen test sürecidir.

Risk Bazlı Test (Risk Based Testing): Bir yazılım bileşeninin veya sisteminin risklerinin seviyelerini düşürmek ve projenin ilk aşamasından başlayarak paydaşları
durumdan haberdar etmek amaçlı bir test yaklaşımıdır. Test sürecine rehberlik etmesi için ürün risklerinin belirlenmesini ve risk seviyelerinin kullanımını içerir.

Saldırı Bazlı Test (Attack Based Testing): Bir yazılım bileşeni veya sistemine saldırarak, özellikle güvenlik ile ilgili hataların oluşmasını hedefleyen tecrübeye
dayalı test tekniğidir. Şekil 5.5.’te sembolik bir saldırı bazlı test görülmektedir (Uslu, 2021).

Şekil 5.5. Saldırı Bazlı Test

Bakım Testi (Maintenance Testing): İşletimde olan bir yazılım bileşeni veya sisteminde yapılan değişiklerin veya değişmiş bir ortamın işletimde olan bir sisteme
etkisinin test edilmesi işlemidir.

Arıza Durumu Testi (Failover Testing): Bir yazılım bileşeni veya sisteminde kontrollü bir şekilde arıza oluşturarak yapılan testtir. Bir arıza sonrasında, verilerin
kaybolmaması veya bozulmaması ve bütün servis seviyelerinin korunması için arıza durumu test edilir. Burada ele alınan metriklere örnek olarak fonksiyon elverişlilik
veya tepki süresi verilebilir.

Regresyon Hassasiyetli Test (Regression-Averse Testing): Geriye dönük risklerin farklı test tekniklerinin hayata geçirilmesiyle yönetilmesi, örneğin bir veya
birden fazla test seviyesinde tekrar kullanılabilen test yazılımı ve aşırı test otomasyonunun yapılması anlamına gelir.

5.5. Metrikler ile İlgili Testler

Bir yazılımın kullanılabilmesi için pek çok metriği belli oranlarda sağlaması gerekmektedir.
Bu metrikleri sağlayıp sağlamadığının tespiti için de birçok farklı test yapılmaktadır.
Bu metriklerden güvenlik ile ilgili olan testler bir önceki kısımda verilmiştir. Burada incelenen test türleri uyumluluk testi, standartlara uyumluluk testi, stres testi,
fonksiyonalite testi, verimlilik testi, performans testi, yük testi, erişilebilirlik testi, gereksinim bazlı test, kurulum testi, taşınabilirlik testi, ölçeklenebilirlik testi,
kullanışlılık testi, hacim testi, kaynak kullanım testi, dönüşüm testi ve ezamanlılık testidir.

Uyumluluk Testi  (Compliance Testing): Bir yazılım bileşeni veya sisteminin herhangi başka bir bileşen veya sisteme, bir metrik kümesine, verilere veya başka
herhangi bir maddeye uyumluluğunu saptamaya yarayan test sürecidir.

Standartlara Uyumluluk Testi (Standard-Compliant Testing): Bir yazılım bileşeni veya sistemi için standartlar tarafından tanımlanmış gereksinimlere uyumluluk
testidir. Örnek olarak emniyet hassasiyetli sistemlerin testi için uygulanan standartlar ya da endüstri standartları verilebilir.

Stres Testi (Stress Testing): Bir yazılım bileşeninin veya sisteminin öngörülen veya belirlenmiş çalışma yükünün sınırlarında ya da ötesinde, ya da bellek veya
sunucuya erişimi gibi kaynakların azalması durumundaki çalışma kapasitesini değerlendirmek için yürütülen bir çeşit performans testidir.

Fonksiyonalite Testi (Functionality Testing): Bir yazılım bileşeninin veya sisteminin istenilen işlevselliği gerçekleştirip gerçekleştirmediğini test etme sürecidir.

Verimlilik Testi (Efficiency Testing): Bir yazılım bileşeni veya sistemi için gerçekleştirilen test sürecidir.

Performans Testi (Performance Testing): Bir yazılım bileşeninin veya sisteminin performansını belirlemek için yürütülen test sürecidir.

Yük Testi (Load Testing): Bir çeşit performans testidir. Bir yazılım bileşeninin veya sisteminin artan yük (örneğin eşzamanlı kullanıcıların sayısı ve/veya işlem sayısı)
karşısındaki davranışlarını değerlendirmek için kullanılır. Bileşen veya sistemin yükü ne kadar tolere edeceği tespit edilir. Şekil 5.6.’da sembolik bir yük testi
görülmektedir (Low, 2021).

46
Şekil 5.6. Yük Testi

Erişilebilirlik Testi (Accessibility Testing): Engelli kullanıcıların bir yazılım bileşeninin veya sisteminin ne kadar kolay kullanabildiğini ölçümleyen testtir.

Gereksinim Bazlı Test (Requirements-Based Testing): Test senaryolarının gereksinimlerden elde edilen test amaçları ve test koşulları baz alınarak tasarlandığı
test etme yaklaşımıdır.
Burada örneğin belirli fonksiyonalite veya güvenilirlik, kullanılabilirlik gibi fonksiyonel olmayan özellikler test edilir.

Kurulum Testi (Installability Testing): Bir yazılım bileşeninin veya sisteminin kurulabilirliğinin test edilme sürecidir.

Taşınabilirlik Testi (Portability Testing): Bir yazılım bileşeninin veya sisteminin birçok cihazda çalışabilirliğinin (taşınabilirliğinin) incelendiği test türüdür.

Ölçeklenebilirlik Testi (Scalability Testing): Bir yazılım bileşeninin veya sisteminin ölçeklebilinirliğini belirleme testidir, Şekil 5.7.’de sembolik bir ölçeklenebilirlik
testi görülmektedir (Low, 2021).

Şekil 5.7. Ölçeklenebilirlik Testi

Kullanışlılık Testi (Suitability Testing): Bir yazılım bileşeninin veya sisteminin kullanışlılığını belirlemek amacıyla yapılan test türüdür.

Hacim Testi (Volume Testing): Büyük miktarda veriye tabi tutulan yazılım bileşeni veya sistemin testidir.

Kaynak Kullanım Testi (Resource Utilization Testing): Bir yazılım bileşeninin veya sisteminin kaynak kullanım yeteneğini ölçme testidir.

Dönüşüm Testi (Conversion Testing): Varolan bir yazılım bileşeninin veya sisteminin verileri yerine geçecek sistemde kullanılacak şekilde dönüştüren yazılımın
testidir.

Eşzamanlılık Testi (Concurrency Testing): Bir yazılım bileşeninin veya sisteminin üzerinde iki veya daha fazla aktivitenin aynı zaman aralığında birlikte veya
dönüşümlü olarak çalıştırıldığı test türüdür.

Bölüm Özeti
Yazılım testinin başarılı bir şekilde anlaşılabilmsi için bazı yazılım test türlerinin kavramsal da olsa anlaşılması gerekmektedir. Bu bölümde bu test türlerinden en
önemlilerine yer verilmiştir. Bu bölümde ele alınan kavramlar aşağıdaki şekilde gruplandırılabilir.

Koşul, Durumlar ve Süreç İle İlgili Testler

 Karşılaştırma Testi

 Koşul Testi

 Karar Testi

 Karar Tablosu Testi

 Karar Koşul Testi

 Değiştirilmiş Koşul Karar Testi

 Çoklu Koşul Testi

 Kontrol Akış Testi

 N-Anahtar Testi

 Negatif Test

 Temel Karşılaştırma Testi

 Geniş Kapsamlı Test

 İş Sürecine Dayalı Test

47
 Süreç Uyumluluk Testi

 Süreç Döngü Testi

 Kontrol Listesine Dayalı Test

 Durum Geçişi Testi

 Sınır Değer Testi

 Çevik Test

 Beyaz Kutu Testi

 Kara Kutu Testi

 Fonksiyonel Test

 Tepkisel Test

 Tekrar Testi

 Betikleştirilmiş Test

 Komut Testi

 Yol Testi

 İçeriye Dahil Edilen Kaynaklarla Yapılan Test

 Tecrübeye Dayalı Test

 Kombinasyonlu Test

 Geçersiz Girdilerin Testi

 Aksiyon Kelimesi Güdümlü Test

 Veri Güdümlü Test

 Metodik Test

 Model Bazlı Test

 Duman Testi

 Alım Testi

 İstatistiksel Test

 Dikey Dizi Testi

 İkili Test

 Statik Test

 Sözdizim Testi

 Prosedür Testi

 Fonksiyonel Olmayan Test

 Operasyonel Profil Testi

 Operasyonel Test

 Dış Kaynaklı Test

 Eşli Test

 Ayrıştırma

 Keşif Testi

 Veri Akış Testi

 Tasarım Bazlı Test

 Geliştirme Testi

 Dokümantasyon Testi

 Dinamik Test

 Danışılarak Yapılan Testler

 Dal Testi
48
 Analitik Test

 Kurgusuz Test

Bileşenler, Entegrasyon ve Sistem İle İlgili Testler

 Bileşen Testi

 Entegrasyon Testi

 Sistem Entegrasyon Testi

 Sistem Testi

 Komşuluk Entegrasyon Testi

 İkili Entegrasyon Testi

 Arayüz Testi

 Artımlı Test

 Veri Tabanı Bütünlük Testleri

 Yukardan Aşağıya Test

 Aşağıdan Yukarıya Test

 Big Bang Testi

 Bileşen Entegrasyon Testi

 Donanım-Yazılım Entegrasyon Testi

 Uygulama Programlama Arayüzü Testi

 Arka-Arkaya Test

 İş Parçacığı Testi

Kullanım, Kullanıcı, Kabul İle İlgili Testler

 Kullanıcı Testi

 Kullanıcı Hikayesi Testi

 Kullanılabilirlik Testi

 Kullanım Senaryosu Testi

 Kabul Testi

 Operasyonel Kabul Testi

 Fabrika Kabul Testi

 Saha Kabul Testleri

 Rastgele Test

 Alfa Testi

 Beta Testi

 Maymun Testi

Güvenlik İle İlgili Testler

 Güvenlik Testi

 Güvenilirlik Testi

 Kurtarılabilirlik Testi

 Sağlamlık Testi

 Emniyet Testi

 Sürdürülebilirlik Testi (Maintainability Testing)

 Risk Bazlı Test

 Saldırı Bazlı Test

 Bakım Testi

 Arıza Durumu Testi

49
 Regresyon Hassasiyetli Test

Metrikler İle İlgili Testler

 Uyumluluk Testi

 Standartlara Uyumluluk Testi

 Stres Testi

 Fonksiyonalite Testi

 Verimlilik Testi

 Performans Testi

 Yük Testi

 Erişilebilirlik Testi

 Gereksinim Bazlı Test

 Kurulum Testi

 Taşınabilirlik Testi

 Ölçeklenebilirlik Testi

 Kullanışlılık Testi

 Hacim Testi

 Kaynak Kullanım Testi

 Dönüşüm Testi

 Eşzamanlılık Testi

Kaynakça

ISTQB Yazılım Testi Terimler Sözlüğü, 2014

A. Baran, F. Akar, F. Aslay, Çevik Yazılım Geliştirme Yöntemlerinde Etkili Test Araçları, International Science and Technology Conference, Vienna-Austria, July
13-15, 2016

V. Arnicane, Complexity of Equivalence Class and Boundary Value Testing Methods, Scientific Papers, University of Latvia, Computer Science and Information
Technologies, Sayı. 751, Sayfa: 80-101, 2009

V. K. Chauhan, Smoke Testing, International Journal of Scientific and Research Publications, Sayı. 4(2), 2014.

S. Oster, F. Markert, P. Ritter, Automated Incremental Pairwise Testing of Software Product Lines, International Conference on Software Product Lines, Software
Product Lines: Going Beyond, Sayfa: 196-210, 2010

G. Perrouin, S. Oster, S. Sen, J. Klein, B. Baudry, Y.Traon, Pairwise testing for software product lines: comparison of two approaches, Software Quality Journal,
Sayı. 20, Sayfa: 605–643, 2012

J. Itkonen, K. Rautiainen, Exploratory testing: a multiple case study, ISESE, International Symposium on Empirical Software Engineering, 17-18 Kasım 2005

D. Pfahl, H. Yin, M. V. Mäntylä, J. Münch, How is exploratory testing used? A state-of-the-practice survey, ESEM, 8th ACM/IEEE International Symposium on
Empirical Software Engineering and Measurement, Sayfa: 1–10, 2014

M. Karacahisarlı, Tecrübeye Dayalı Test Tasarım Teknikleri,  https://keytorc.com/blog/tecrubeye-dayali-test-tasarim-teknikleri/, 2018

A. Uslu, DDoS Nedir? DDoS Saldırı Türleri Nelerdir?, https://www.niobehosting.com/blog/ddos/, 2021

J. Low, Web Sitenizi Stres Testi Yapacak 7 Performans Test Aracı, https://www.webhostingsecretrevealed.net/tr/blog/web-tools/load-testing-tools/, 2021

K. Ravichandran, Why Testing Process Needs Negative Testing?, https://www.mstsolutions.com/technical/why-testing-process-needs-negative-testing/, 2018

Ünite Soruları

Soru-1 :

Bir yazılımda kullanıcılar tarafından girilmesi gereken verileri değil de kullanıcılar tarafından girilmesi beklenmeyen ve sistemin uyarı vereceği
verileri deneme işlemi aşağıdakilerden hangisi ile ifade edilir?

(•) - Negatif Test

(•) - Temel Karşılaştırma Testi

50
(•) - Sınır Değer Testi

(•) - Tepkisel Test

(•) - Tekrar Testi

Cevap-1 :

Negatif Test

Soru-2 :

Yazılım test uygulamalarında bazı testler çok ayrıntılı bir şekilde yapılırken bazıları diğerlerine göre daha üstünkörü şekilde yapılır. Aşağıdaki
şıkların hangisinde verilen test türleri daha üstünkörü yapılan test kategorisine girmektedir?

(•) - Birim Testi – Sistem Testi

(•) - Duman Testi – Kurgusuz Test

(•) - İkili Test – Eşli Test

(•) - Dinamik Test – Dal Testi

(•) - Analitik Test – Artımlı Test 

Cevap-2 :

Duman Testi – Kurgusuz Test

Soru-3 :

Aşağıdan Yukarı Test, Yukarıdan Aşağı Test ve Big Bang Testi aşağıdaki test kategorilerinden hangisine girmektedir?

(•) - Güvenlik Testleri

(•) - Entegrasyon Testleri

(•) - Kabul Testleri

(•) - Kullanıcı Testleri

(•) - Uyumluluk Testleri

Cevap-3 :

Entegrasyon Testleri

Soru-4 :

Aşağıdakilerden hangisi bir yazılımın kolay bir sistem üzerinde kolay bir şekilde kullanılıp kullanılamadığını test eden testlerden biri değildir?

(•) - Kurulum Testi

(•) - Taşınabilirlik Testi

(•) - Birlikte Çalışabilirlik Testi

(•) - Arıza Durumu Testi

(•) - Kullanışlılık Testi

Cevap-4 :

Arıza Durumu Testi

Soru-5 :

Bir firma “Beyaz Şapkalı Hacker”lık hizmeti veren bir firmadan hizmet alıyorsa, bu durumda hangi tür testleri yaptırıyor olabilir?

(•) - Arayüz Testi

(•) - Kullanılabilirlik Testi

(•) - Maymun Testi

(•) - Sürdürülebilirlik Testi

51
(•) - Saldırı Bazlı Test

Cevap-5 :

Saldırı Bazlı Test

Soru-6 :

Hangi şıkta verilen test ikilisinin çalışma şekli ya da ilgilendiği konu benzer değildir?

(•) - Rastgele Test – Maymun Testi

(•) - Güvenlik Testi –Veri Tabanı Bütünlük Testleri

(•) - Saldırı Bazlı Test – Arıza Durumu Testi

(•) - Performans Testi – Verimlilik Testi

(•) - Hacim Testi – Yük Testi

Cevap-6 :

Güvenlik Testi –Veri Tabanı Bütünlük Testleri

Soru-7 :

Kullanım ile ilgili yapılan testlerden hangisinde yazılım gerçek kullanıcılar tarafndan test edilmez?

(•) - Kullanıcı Testi

(•) - Kullanıcı Hikayesi Testi

(•) - Kullanılabilirlik Testi

(•) - Operasyonel Kabul Testi

(•) - Saha Kabul Testleri

Cevap-7 :

Operasyonel Kabul Testi

Soru-8 :

Aşağıdaki test türlerinden hangisi tesin yazılımın hangi kısmında yapıldığını açıklamamaktadır?

(•) - Sistem Testi

(•) - Dokümantasyon Testi

(•) - Veri Tabanı Bütünlük Testleri

(•) - Analitik Test

(•) - Arayüz Testi

Cevap-8 :

Analitik Test

Soru-9 :

Bazı testler doğrudan yazılımın herhangi bir özelliğini test etmek için kullanılırken bazıları ise farklı testlere dayanak sağlayan ön hazırlık testleri
olarak düşünülebilir. Aşağıdakilerden hangisi böyle bir teste örnek gösterilebilir?

(•) - Operasyonel Test

(•) - Alım Testi

(•) - Keşif Testi

(•) - Yol Testi

(•) - Prosedür Testi

Cevap-9 :
52
Keşif Testi

53
6. YAZILIM TEST SINIFLANDIRMALARI
Giriş
Yazılım testleri farklı kriterlere göre sınıflandırılmaktadır. Bu sınıflandırma, testlerin seçimi, uygulanması ve diğer işlemler açısından önem arz etmektedir. Bu bölümde,
yazılım testleri ile ilgili en sık yapılan bazı sınıflandırmalar olan seviyelerine göre sınıflandırma, fonksiyonaliteslerine göre sınıflandırma ve yaklaşıma göre sınıflandırma
çeşitleri ele alınmıştır.

6.1. Seviyelerine Göre Yazılım Testleri

Yazılım testlerinin ilk önemli sınıflandırması seviyelerine göre yapılan sınıflandırmadır. Burada seviyeden kastedilen yazılımın ne kadarlık bir kısmının test edilmesidir.
Bir test örneğin yazılımdaki tek bir modüle uygulanabileceği gibi yazılımın belli bir kısmına ya da tamamına da uygulanabilir. Farklı yaklaşımlar olmak üzere genellikle
seviyelerine göre testler 4 seviyede ele alınır. Bunlar

 Birim Testleri

 Birleştirme (Entegrasyon) Testleri

 Sistem Testleri

 Kabul Testleri

şeklindedir. Genel olarak bu testlerin hiyerarşik yapısı Şekil 6.1.’de verilmiştir (Eser, 2019).

Şekil 6.1. Seviyelerine Göre Yazılım Testleri

6.1.1. Birim Testleri

Birim testleri, yazılım tasarımının en küçük biriminin (yazılım bileşeni ya da modül) doğrulanması için yapılan çalışmalara verilen addır. Önemli kontrol yolları, modülün
sınırları içerisindeki hataları ortaya çıkarmak için test edilir. Birim testi bir bileşenin sınırları içindeki mantık ve veri yapıları gibi iç işlemler üzerinde çalışır. Bu test türü
birden fazla bileşen için paralel olarak gerçekleştirilebilir. Birim testler aşağıdaki yapılardan faydalanır.

 Arayüz Testleri: Birim testlerinde birim ara yüzü test edilerek bilgi giriş/çıkışlarının uygun ve yeterli şekilde yapıldığı kontrol edilir. Örneğin, programa giren ve
çıkan tüm iletilerin doğru tipte oldukları gerçeklenir (Yener, 2021).

 Yerel Veri Yapıları Testleri: Yerel veri yapıları incelenerek algoritmanın çalışması boyunca ya da yordamların çağrılması sırasında verilerin saklandığı yerin
bütünlüğünün bozulup bozulmadığı test edilmelidir.

 Sınır Koşulları Testleri:  Sınır koşullarının en düşük ve en yüksek değerleri,

bu değerlerin biraz altı ve biraz üstü kullanılarak sınanmalıdır.

 Bağımsız Yollar Testleri: Birim içindeki birbirinden bağımsız tüm çalışma yolları, tüm dallanmalar tek tek sınanmalıdır.

 Hata Yakalama Yolları Testleri: Birim içindeki tüm hata yakalayıcılar birer birer denenmelidir.

Daha çok beyaz kutu yönteminin kullanıldığı birim testi ile düzgün ve hatasız çalıştığına kanaat getirilen bir birim artık tümleştirme testi için hazır hale gelmiş olur.
Özetle birim testleri (Aslan, 2017)

 yazılan kod parçasının başka bir kod parçası tarafından test edilmesini sağlar.

 yazılan kod parçasının anlaşılmasını kolaylaştırır.

 yazılan kod parçasındaki hata oranını azaltır aynı zamanda hataların daha hızlı bir şekilde tespit edilmesini ve düzeltilmesini sağlar.

 yazılan kod parçasının kalitesinin artmasını sağlar.

 daha hızlı yazılım geliştirmeyi sağlar.

6.1.2. Birleştirme (Entegrasyon) Testleri

54
Birim testleri tamamlandıktan ve birimlerdeki hatalar, aksaklıklar giderildikten sonra birleştirme (entegrasyon) testlerine geçilir. Birleştirme (entegrasyon) testlerinin
amacı, birden fazla biriminin bir araya getirilerek uyumlu bir şekilde ve hatasız çalışması, her birinin tek tek değil de bir bütün içinde, tasarımda belirtildiği şekilde
kendi üzerlerine düşen görevleri yerine getirip getirmediğini kontrol etmektir (Gökalp, 2015).

Çoğu zaman, bireysel olarak doğru çalıştığı sanılan yazılım birimleri, bir araya getirildiklerinde daha önceden fark edilemeyen veya öngörülemeyen davranışlarda
bulunabilirler. Şekil 6.2.’de bu durum mizahî bir şekilde gösterilmiştir. Görüldüğü üzere ayrı ayrı başarılı bir şekilde döşenmiş olan demiryolu rayları bir araya gelince
yön ve doğrultudaki hata dolayısıyla çalışamaz duruma gelmiştir. Dolayısıyla birimler tekil olarak başarılı bir şekilde çalışsalar bile bir araya geldiklerinde çeşitli
kusurlar ortaya çıkabilir. Bu kusurlu davranışları yakalayabilmek için yapılan birleştirme testleri, birimler arasındaki ara yüzlerden kaynaklanan kusurları ortaya
çıkarabilmek ve program yapısını oluşturmak için uygulanan sistematik bir tekniktir. Amaç, birim testlerini başarı ile geçmiş modülleri alıp tasarımda belirtilen
program yapısını ortaya çıkarmaktır (Şit, 2020).

Şekil 6.2. Birleştirme (Entegrasyon) Testlerinin Önemi

Birleştirme testlerinin yapılma nedenleri aşağıdaki şekilde özetlenebilir:

 Bir birimin çalışması başka bir birimin çalışmasını etkileyebilir. Birimler arasındaki arayüzler arasında verilerin kaybolma olasılığı vardır. Bu sebeple ayrı ayrı çalışan
birimler bir araya getirildiklerinde birbirlerini etkileyerek çalışmama, hatalı çalışma ya da farklı bir sorun ortaya çıkarabilirler.

 Bir birim içinde kabul edilebilir sınırlar içinde olan kesinlik değerleri birden fazla birimin devreye girmesi ile kabul edilemeyecek değerlere ulaşabilir.

 Birimler arasında eşzamanlılığın sağlanması gerekir. Birimler arasında paylaşılan evrensel veri yapıları sorun çıkarabilir.

Birimler bir anda tümleştirmek yerine artırımlı olarak tümleştirmek daha iyi sonuç verir. Artırımlı tümleştirme yönteminde değişik stratejiler kullanılabilir. Bunlar

 Yukarıdan Aşağı Birleştirme Testleri

 Aşağıdan Yukarıya Birleştirme Testleri

 Big-Bang Birleştirme Testleri

şeklindedir (Kabakçı, 2015).

Yukarıdan Aşağı Birleştirme Testleri’nde önce ana denetim biriminin testi yapılır, sonra ona en yakın düzeydeki birimlerden biri ile beraber test yapılır. Diğer bir
deyişle önce kullanıcıya en yakın olan yani en yukarıdaki yapı (örneğin arayüz, sistemin tamamlanmış hali) test edilir, sonrasında test aşağıya doğru (modüller,
algoritmalar vb) inerek en sonunda tüm elemanların test edilmesi sağlanır. Bu yaklaşım genellikle yazılım tamamlandıktan sonra gerçekleştirilen bir yaklaşımdır. Şekil
6.3.’te Yukarıdan Aşağı Birleştirme Testleri’nin yapılış şekli verilmiştir (Kabakçı, 2015).

Şekil 6.3. Yukarıdan Aşağı Birleştirme Testleri

Aşağıdan Yukarıya Birleştirme Testleri’nde alt düzey birimler birleştirilerek kümeler haline getirilir. Bu kümeler test edilir. Daha sonra bu kümelerin birleştirilmesinden
oluşan daha üstü düzeyde kümeler meydana getirilir. Bu şekilde en üstte bulunan ana birime kadar ulaşılır. Bu test yaklaşımı genellikle yazılım henüz oluşturulurken
gerçekleştirilir. Şekil 6.’te Aşağıdan Yukarıya Birleştirme Testleri’nin yapılış şekli verilmiştir (Kabakçı, 2015).

55
Şekil 6.4. Aşağıdan Yukarıya Birleştirme Testleri

Big-Bang Birleştirme Testleri’nde birleştirilecek tüm modüllerin testleri bir arada, bütün olarak yapılmaktadır. Böylelikle hızlıca test yapılacağından dolayı büyük
zaman kazancı sağlanır. Ancak tümden yapılan testlerde herhangi bir hata çıkması durumunda hatanın tespit edilmesindeki zorluk olumsuzluk yaratmaktadır. Hatanın
nereden kaynaklandığının araştırılması uzun sürmektedir. Şekil 6.5.’te Big-Bang Birleştirme Testleri’nin yapılış şekli verilmiştir (Kabakçı, 2015).

Şekil 6.5. Big-Bang Birleştirme (Entegrasyon) Testleri

Bir de doğrudan Birleştirme Testi olarak kabul edilmemekle beraber, bir yazılım üzerinde herhangi bir değişim gerçekleştirildiğinde yapılan Regresyon Testleri
bulunmaktadır. Yazılımlara bir modül eklendiği veya yazılımlarda bir modül değiştirildiği zaman yazılım içerisinde değişen hususlar olmaktadır. Yeni veri akış yolları
oluşur, yeni giriş/çıkışlar meydana gelir ve yeni mantık yapıları çağırılır. Bu değişiklikler daha önce sorunsuz olarak çalışan fonksiyonlarda problemlere sebep olabilir.
Bu sebeple her ne kadar farklı yollarla bu birimler arasında birleştirme testleri uygulanmışsa da bu değişiklik neticesinde yeniden bir test işleminin gerçekleştirilmesi
gerekir. Bu da Regresyon Testleri olarak adlandırılmaktadır (Aktürk, 2019).

6.1.3. Sistem Testleri

Sistem testleri, isminden de anlaşılacağı üzere bir sistemin ortaya çıkması sonucunda gerçekleştirilen testlerdir. Buna göre öncelikle tüm birimler test edilir, sonrasında
bu birimler birleştirme testleri ile birleştirilir ve sonrasında ortaya bir sistem çıkmış olur. Artık bu sistemin çeşitli kriterlere göre test edilmesi gerekmektedir. Genel
olarak sistem testleri aşağıdaki test türlerini içerir.

 Performans Testi

 Yük Testi

 Germe (Stres) Testi

 Kurtarma Testi

 Taşınabilirlik Testi

 Kullanılabilirlik Testi

Performans Testi: Sistemin belirli durumlarda, belirlenen beklentileri verip vermediğini kontrol etmek amacıyla yapılan testtir. Performans testi sistemdeki hataların
bulunmasını amaçlamaz ancak sistemdeki darboğazları ortaya çıkarır. Performans testlerinde amaç sistemin bir açığını bulmak değildir. Asıl amaç sisteme yapılan
girdilerden alınan çıktılarla, olması gereken sonuçların uygunluğunu ve tabi başarıyı tespit etmektir. Her yazılım çeşidinde ve yazılım biriminde bu başarı ve performans
farklı kriterlere bağlıdır. Örneğin; büyük bir veri tabanı yönetim sisteminin başarısı, arama ve sonucu gösterme işlemleri için gereken süredir. Gömülü bir sistemin
performansı, insan katkısı olmadan yapmak zorunda olduğu işlemleri başarıyla yapmasıdır. Özellikle gerçek zamanlı sistemler için tanımlanmış olan zaman kısıtlarına
uymak hem yazılım hem de donanım bileşenleri tarafından karşılanması gereken çok önemli isterlerdir. Bu isterlerin uygun şekilde karşılanıp karşılanmadığını
görebilmek için tümleştirilen yazılım ve donanım üzerinde performans testleri yapılır. Performans testleri tüm test aşamalarında yapılabilir (İnel, 2019).

Yük Testi: Her yazılım sistemi belirli tür ve miktarda veriyi işlemek ve bunlara göre başka veriler üretmek için tasarlanır. Gerçek zamanlı sistemler ve kontrol
sistemleri daha çok belirli kesmelere karşı bir işlem yaparak belirli bir tepkide bulunur. Veritabanı yönetim sistemleri ise çok miktarda veriyi saklama, bunlar üzerinde
sorgu yapma ve rapor üretme gibi işlevler yürütür. İşte bu tür yoğun veri akışına sahip sistemler için yük testleri yapılır. Yük testleri, sistemin sınırlarını zorlayarak en
fazla ne kadar veri işleme kapasitesi olduğunu belirlemek, bu yükte davranışlarını kontrol etmek amacıyla yapılır. Hatta, bazı durumlarda, isterlerde belirtilen
değerlerin de üzerine çıkılarak kaldırabilecek en fazla yükün ne olabileceği araştırılır.

Tipik bir sistemin yük testinde genellikle aşağıda verilen işlemler gerçekleştirilir:

 Veri hacmi testi: Sistemin yüksek miktarda veri ile yüklenmesi

 Veri debisi testi: Tüm girişlerin yüksek hızda veri ile yüklenmesi

56
 Kapasite testi: Sistemin bellek ve disk kullanımının zorlanması

Germe (Stres) Testi: Normal olmayan koşullarda, hem yazılım hem de donanımın ne şekilde davranacağını görmek üzere germe (stres) testleri yapılmalıdır. Bu
amaçla yapılacak testler şunlardır:

 Sistemi normal olmayan miktarda öz kaynak gerektirecek şekilde zorlamak amacıyla yapılan testler

o Yüksek hacim ve hızda veri girişi yapmak

o Beklenenden çok daha yüksek frekansta kesmeler yapmak

o Beklenen ve kullanılandan çok daha fazla bellek ve işlemci gücü gerektiren durumlar yaratmak

 Sistemin kaldırabileceği yük durumunda, ani etkilere verilecek tepki süresini ölçmek üzere yapılan testler

Kurtarma Testi: Yazılım sistemlerinin hiçbir zaman hatasız olmasının beklenmeyeceği daha önceki bölümlerde de ifade edilmişti. Ancak yazılımların bir hata
durumunda kendini toparlayarak tekrar çalışmaya devam etmesi beklenir. Çünkü her hata oluştuğunda yazılım çökecek olsa bu durumda hiçbir yazılım kendisinden
beklenen işlemleri gerçekleştiremez. Aşağıdaki yöntemler kullanılarak zararlar en aza indirilebilir.

 Yedekli yazılım mimarisinde, ana yazılım birimi çalışırken, yardımcı yazılım da aynı veya farklı bir donanım üzerinde paralel şekilde çalışır, fakat çıktı üretmez.
Ana yazılımın çökmesi halinde bu yardımcı yazılım devreye girer.

 Hataya dayanıklı yazılım ise, herhangi bir nedenle bütünüyle çökmemek üzere, kendi kendini düzeltebilen modüller halinde geliştirilen yazılımlardır.

Kurtarma testi önce yazılımı sonra da donanımı çeşitli olası şekillerde bilinçli bir şekilde çökerterek sistemin kendini tekrar toplamasının denenmesi, isterlerin
doğrulanması amacıyla yapılır. Bu kapsamda genelde şu testler yapılır:

 Yedekli yazılım mimarisinde, ana yazılımın devreden çıkartılması ve yardımcı yazılımın otomatik olarak devreye girmesi, bilgi işlemenin kayba uğramadığının
kontrolü

 Yeniden yazılım modülü başlatma yönteminde, çken modülün tekrar başlatılması ve çökmeden önceki durumunu kazanması

 Çökme sırasında kaybolma olasılığı olan verilerin tekrar alınması veya üretilmesi

 İnsan katkısı gereken geri kazanma durumlarında, ortalama zamanın ölçülmesi, isterlere göre değerlendirilmesi

Güvenlik Testi: Bir bilgi sisteminin verileri ve işlevselliğini korumak için tasarlanmış bir süreçtir. Herhangi bir bilgi sızıntısı olup olmadığını kontrol edilir. Sistemin tüm
potansiyel açık kapıları ve zayıflıkları araştırılır. Temel güvenlik testi çeşitleri şunlardır:

 Zafiyet Taraması: Güvenlik literatüründe yer alan güncel açıklıkların, test edilen yazılımda bulunup bulunmadığına dair yazılım ile yapılan tarama çalışmasıdır.

 Penetrasyon (Sızma) Testi: Yazılımın güvenlik becerilerini üst düzeyde tutmak, dışarıdan gelebilecek saldırıları görüp önlem almak, güvenlik açıkları nedeniyle
oluşabilecek bilgi kayıplarına engel olabilmek için yapılan çalışmalardır.

 Risk Belirleme: Yazılımı etkileyebilecek olan risklerin belirlenmesi için yapılan çalışmadır. Yazılımda risk konusu ayrıntılı olarak kitapta 3. Bölüm’de açıklanmıştır.

 Şifre Kırma: Bir yazılımın güvenliğini belirleyen en önemli noktalardan biri yazılımda yer alan şifrelerin kolay bir şekilde kırılmamasıdır.

Taşınabilirlik Testi: Var olan bir yazılım bileşeni veya uygulamayı yeni bir ortamda test etme işlemidir. Uygulamanın diğer ortamlarda yüklenebilirlik, uyumluluk,
adaptasyon, değiştirilebilirlik yetenekleri araştırılır. Uygulamalar şu ortamlar için test edilebilir:

 Donanım platformları (istemciler, sunucular, ağ bağlantı cihazları, giriş ve çıkış aygıtları)

 İşletim sistemleri (versiyonları ve servis paketleri dahil).

 Tarayıcılar (her bir sürümü dahil)

Şekil 6.6.’da taşınabilirlik kavramı sembolik olarak gösterilmiştir.

Şekil 6.6. Taşınabilirlik Kavramı

Kullanılabilirlik Testi: Tasarımların veya ara yüzlerin kullanıcı ile buluşmasından önce tasarımın kullanılabilirliğini ölçmek amacıyla yapılan testlere verilen isimdir.
Sadece bir kullanıcının o an için hareketlerini gözlemlemek ile ilgilidir. Kullanılabilirlik testleri kullanılabilirlik problemleri hakkında bize bilgi verir ve kullanıcıların
uygulama ile nasıl etkileşimde bulunduğuna bakar. Kullanılabilirlik temelde, 5 niteliksel özellik ile ölçülür.

 Öğrenilebilirlik: Bu nitelikle “Kullanıcılar, tasarımı ilk kullandıklarında yerine getirmeleri gereken görevleri kolaylıkla yapabiliyorlar mı?” sorusuna cevap
aranmaktadır.
57
 Verimlilik: Bu nitelikle “Kullanıcılar, tasarımın çalışma şeklini öğrendikten sonra gerçekleştirecekleri işlemleri ne kadar hızlı yapabiliyorlar?” sorusuna cevap
aranmaktadır.

 Memnuniyet: Bu nitelikle “Tasarımı kullanmak kullanıcıları duygusal anlamda mutlu ediyor mu, kullanıcılar tasarımı kullanırken kendini rahat hissediyorlar mı?”
sorusuna cevap aranmaktadır.

 Hatırlanabilirlilik: Bu nitelikle “Kullanıcılar, bir süre tasarımı kullanmadıktan sonra tekrar kullanamaya başladıklarında tasarıma dair var olan bilgilerin ne
kadarını hatırlayabiliyorlar?” sorusuna cevap aranmaktadır.

 Hatalar: Bu nitelikle “Kullanıcılar, ne kadar hata yapıyor ve bu hataları ne sıklıkta tekrarlıyorlar, hataları ne kadar hızlı yok edebiliyorlar?” sorusuna cevap
aranmaktadır.

6.1.4. Kabul Testleri

Çalıştırılmadan önce yazılımın son sınanmasıdır. Bu sınama ile yazılımın kullanıcılar, müşteriler vb tarafından kabul edilip edilmeyeceği tespit edilmeye çalışılır. Artık
yapay veriler yerine gerçek veriler kullanılır. Bu test türü;

 Alfa testi

 Beta testi

olarak çeşitlenir.

Alfa Testi: Yazılım geliştiricinin kendi ortamında müşteri tarafından gerçekleştirilen bir sınamadır. Geliştirici bu testleri gözlemleyerek gerçek kullanım hakkında bilgi
sahibi olmaya çalışır; kusur buldukça not alır ve düzenleme işlemlerini yürütür. Alfa testlerinin en önemli özelliği, denetim altındaki bir ortamda, asıl kullanıcılardan biri
tarafından yapılıyor olmasıdır.

Beta Testi: Birçok kullanıcının kendi ortamında yapılır. Geliştirici genellikle bu testlere katılmaz; yalnızca belirli aralıklarla sonuçları ve yorumları alır. Bu testin
özelliği de geliştirici tarafından kontrol edilemeyen gerçek uygulama ortamı koşullarında yazılımın denenmesidir. Beta testi sonunda geliştirici, bulunan kusurları
düzelterek tüm kullanıcılar için yeni bir sürüm çıkartır.

6.2. Fonksiyonalitesine Göre Yazılım Testleri

6.2.1. Fonksiyonel Olan Testler

Fonksiyonel olan testler (ya da daha genel söylemle fonksiyonel testler), test aktivitelerinde odaklanılan, sistemin işlevsel yönünü ele alan testlere verilen isimdir. Bir
yazılımın temelini oluşturan ve bir girdiye göre beklenen çıktının verilip verilmediğinin kontrol edildiği test durumları fonksiyonel testler ile belirlenir. Bu test türü yaygın
olarak uygulanan ve kullanılan test türüdür. Bir yazılım ürününde ilk olarak yapılması gereken testler arasında yer alır.
Ayrıca müşteri tecrübelerine dayanan bir test tipidir. Sistemin teknik alt yapısının nasıl olduğu ile ilgilenilmez. Fonksiyonel test, birim testten sistem testine kadar tüm
test safhalarında uygulanabilir. Fonksiyonel test, firmalara, kullanıcı test takımlarının en az çaba ile yaratılmasına olanak sağlayarak, daha yüksek kalitede
uygulamaları daha az riskle ve maliyetle yerleştirmelerine imkan tanımaktadır. Fonksiyonel test, yazılım uygulamasının her bir fonksiyonunun gereksinim
spesifikasyonuna uygun olarak çalıştığını doğrulayan bir test türüdür. Bu test, esas olarak kara kutu yaklaşımı ile gerçekleştirilir ve uygulamanın kaynak kodu ile
ilgilenmez. Sistemin her işlevselliği, uygun girdi sağlanarak, çıktı doğrulanarak ve gerçek sonuçlar beklenen sonuçlarla karşılaştırılarak test edilir. Bu test, Kullanıcı
Arayüzünün, API'lerin, Veritabanının, güvenliğin, istemci/sunucu uygulamalarının ve Test Edilen Uygulamanın işlevselliğinin kontrol edilmesini içerir. Bu testler manuel
olarak veya otomasyon kullanılarak yapılabilir. Fonksiyonel testlerin amaçları aşağıdaki şekilde özetlenebilir:

 uygulamanın ihtiyaçları tam olarak karşılayıp karşılamadığının belirlenmesini sağlar.

 var olan uygulamanın anlaşılır ve kullanıcının isteklerine hızlı bir şekilde cevap verme olanağını sağlar.

 uygulamanın hatasız, güvenilir ve etkin bir şekilde çalışmasını sağlar.

 sistem gereksinimlerine uygun olarak sistemin çalışıp çalışmadığının kontrolünü sağlar.

6.2.2. Fonksiyonel Olmayan Testler

Fonksiyonel olmayan test, bir yazılım uygulamasının işlevsel olmayan yönlerini (performans, kullanılabilirlik, güvenilirlik vb.) kontrol etmeye yönelik bir test türüdür.
Fonksiyonel testlerle asla ele alınmayan fonksiyonel olmayan parametrelere göre bir sistemin hazır olup olmadığını test etmek için açıkça tasarlanmıştır. Şekil 6.7.’de
fonksiyonel olmayan testlerde ele alınan metrikler gösterilmiştir (Gulec, 2020).

Şekil 6.7. Fonksiyonel Olmayan Testlerde Ele Alınan Metrikler

Fonksiyonel olmayan testler, fonksiyonel testler kadar önemlidir ve müşteri memnuniyetini etkiler. Fonksiyonel testler ile fonksiyonel olmayan testler Tablo 6.1’de
karşılaştırılmıştır.

Tablo 6.1. Fonksiyonel Olan ve Fonksiyonel Olmayan Testlerin Karşılaştırılması

58
Parametreler Fonksiyonel Olan Test Fonksiyonel Olmayan Test
Yürütme Önce yapılır. Sonra yapılır.
Odak alanı Müşteri gereksinimleri Müşteri beklentisi
Kullanım Uygulamanın davranışını doğrular. Uygulamanın performansını doğrular.
Amaç Yazılım eylemlerini doğrulamak Yazılım performansını doğrulamak
Gereksinimler Fonksiyonel spefikasyonlar  kullanılarak  gerçekleştirilir. Performans    spefikasyonları kullanılarak gerçekleştirilir.
Manuel test Manuel testker ile  gerçekleştirmek kolaydır. Manuel testler ile gerçekleştirmek çok zordur.
İşlevsellik Ürünün  ne yaptığını açıklar. Ürünün nasıl  çalıştığını açıklar.

6.3. Yaklaşımına Göre Yazılım Testleri

6.3.1. Kara Kutu Testleri

Kara kutu testi, test edilen yazılım bileşeni, sistem, uygulama vb’nin iç yapısıyla, kod ya da tasarımla ilgilenmez. Kara kutu testi bir yazılım bileşeni, sistem,
uygulamanın performans, hız, güvenlik, kullanışlılık vb gibi kriterlerinin test edildiği bir yaklaşımdır. Yazılım geliştiriciler tarafından yapılabildiği gibi, pek fazla bir kod
bilgisi gerektirmediğinden yazılım ekibinin geliştiriciler dışında kalan üyeleri, müşteriler ya da kullanıcılar tarafından da gerçekleştirilebilir. Esasında her kullanıcı bir
uygulamayı kullanırken bilmeden kara kutu testi yapmış olur, çünkü uygulamanın dışı ile ilgilenir ve kullanımındaki hataları bulabilir, ancak yazılımın içerisindeki hataları
bulamaz.

6.3.2. Beyaz Kutu Testleri

Beyaz kutu testi, kara kutu testinin aksine test edilen yazılım bileşeni, sistem, uygulama vb’nin iç yapısıyla, kod ve tasarımla ilgilenir. Buna göre kodun nasıl yazıldığı,
doğru yapıların kullanılıp kullanılmadığı, spagetti ya da ölü kod olup olmadığı, kodun daha verimli hale getirilip getirilemeyeceği gibi sorulara cevap bulmaya çalışır.
Bu test yaklaşımı, doğrudan yazılımın performansı ile ilgilenmez ancak kod optimizasyonuna katkıda bulunur. Esasında kod geliştirilirken sürekli olarak beyaz kutu
testi yapılmaktadır çünkü kod yazımı esnasında ortaya birçok hata çıkabilmektedir ve bu hatalar anlık olarak düzeltilmektedir, ayrıca bu hatalar yalnızca kodlar
içerisinde düzeltilir, ara yüzde bir düzeltme olmamaktadır.

6.3.3. Gri Kutu Testleri

Bazı kaynaklarda varlığı kabul edilmese de bazı kaynaklarda kabul edilen gri kutu testi kara kutu ve beyaz kutu testlerinin birleşimidir. Bu testi gerçekleştiren kişinin
yazılımın veri tabanına ve dokümanlara erişimi vardır. Böylece tasarıma ve verilere uygun test dokümanı üretebilir. Yani uygulamanın iç işlemlerine kısmen erişime izin
verir. Ancak kodlara erişimi yoktur, kodları inceleyemez. Kutu yaklaşımı bir sonraki bölüm olan 7. Bölüm’de ayrıntılı bir şekilde açıklanmıştır.

Bölüm Özeti
Yazılımlar üzerinde gerçekleştirilen testler ne kadar iyi bir biçimde sınıflandırılabilirse yazılım test uzmanı bu testler hakkında o kadar fazla bilgiye sahip olur ve testler
bir o kadar başarıya ulaşır. Bu açıdan yazılım testlerinin sınıflandırılması büyük önem taşımaktadır. Yazılımlar üzerinde gerçekleştirilen testlerin en önmeli
sınıflandırmalarından biri seviyelerine göre sınıflandırmadır ve aşağıdan yukarıya sırasıya birim testleri, birleştirme testleri, sistem testleri ve kabul testleridir. Birim
testleri, yazılım tasarımının en küçük biriminin (yazılım bileşeni ya da modül) doğrulanması için yapılan çalışmalara verilen addır.
Birim testleri tamamlandıktan ve birimlerdeki hatalar, aksaklıklar giderildikten sonra birleştirme testlerine geçilir. Birleştirme testlerinin amacı, birden fazla biriminin bir
araya getirilerek uyumlu bir şekilde ve hatasız çalışması, her birinin tek tek değil de bir bütün içinde, tasarımda belirtildiği şekilde kendi üzerlerine düşen görevleri
yerine getirip getirmediğini kontrol etmektir. Sistem testleri, isminden de anlaşılacağı üzere bir sistemin ortaya çıkması sonucunda gerçekleştirilen testlerdir. Kabul
testleri ise çalıştırılmadan önce yazılımın son kez test edilmesi ve müşteriler tarafından kabul edilip edilmeyeceğinin anlaşılmasıdır.
Yazılım testleri üzerinde gerçekleştirilen bir diğer önemli sınıflandırma fonksiyonalitesine göre yapılan sınıflandırmadır. Bu sınıflandırmaya göre yazılım testleri
fonksiyonel testler ve fonksiyonel olmayan testler olmak üzere ikiye ayrılır. Fonksiyonel olan testler test aktivitelerinde odaklanılan, sistemin işlevsel yönünü ele alan
testlere verilen isimdir.
Bir yazılımın temelini oluşturan ve bir girdiye göre beklenen çıktının verilip verilmediğinin kontrol edildiği test durumları bu testler ile belirlenir. Fonksiyonel olmayan
testler, bir yazılım uygulamasının işlevsel olmayan yönlerini (performans, kullanılabilirlik, güvenilirlik vb.) kontrol etmeye yönelik bir test türüdür. Yazılım test
sınıflandırmalarından bir diğer önemli olanı yaklaşımına göre sınıflandırmadır. Burada kutu yaklaşımı ele alınmıştır ve bu sınıflandırmada kara kutu testleri, beyaz kutu
testleri ve gri kutu testleri olmak üzere üç ayrı test kategorisi bulunmaktadır. Kara kutu testi, test edilen yazılım bileşeni, sistem, uygulama vb’nin iç yapısıyla, kod ya
da tasarımla ilgilenmeyen ve bir yazılım bileşeni, sistem, uygulamanın performans, hız, güvenlik, kullanışlılık vb gibi kriterlerinin test edildiği bir yaklaşımdır. Beyaz kutu
testi, kara kutu testinin aksine test edilen yazılım bileşeni, sistem, uygulama vb’nin iç yapısıyla, kod ve tasarımla ilgilenen ve kodun nasıl yazıldığı, doğru yapıların
kullanılıp kullanılmadığı, spagetti ya da ölü kod olup olmadığı, kodun daha verimli hale getirilip getirilemeyeceği gibi sorulara cevap bulmaya çalışan bir test türüdür.
Gri kutu testi kara kutu ve beyaz kutu testlerinin birleşimidir. Bu testi gerçekleştiren kişinin yazılımın veri tabanına ve dokümanlara erişimi vardır. Böylece tasarıma ve
verilere uygun test dokümanı üretebilir. Yani uygulamanın iç işlemlerine kısmen erişime izin verir. Ancak kodlara erişimi yoktur, kodları inceleyemez.

Kaynakça

ISTQB Yazılım Testi Terimler Sözlüğü, 2014

Ş. Ay, K-Means Algoritması, https://medium.com/deep-learning-turkiye/k-means-algoritmas%C4%B1-b460620dd02a, 2019

O. Eser, Yazılım Test Seviyeleri, https://medium.com/@ozaneseriu/yazilim-test-sevi%CC%87yeleri%CC%87-593a17a16d7f, 2019

O. Yener, Test Çeşitleri, https://www.orhanyener.net/yazilim-testi-2/yazilim-test-cesitleri/, 2021

A. Aslan, Unittest (Birim Testi) Nedir?, https://medium.com/@ahmetaslan_78691/unittest-birim-testi-nedir-aea2c7377330, 2017

G. Gökalp, Entegrasyon (Integration) Testi Nedir ve Tipleri Nelerdir, https://www.gokhan-gokalp.com/entegrasyon-integration-testi-nedir-ve-tipleri-nelerdir/, 2015

G. Şit, Yazılım Test Seviyeleri: Birim Testi, Entegrasyon Testi, https://www.mobilhanem.com/yazilim-test-seviyeleri-birim-testi-entegrasyon-testi/, 2020

F. Kabakçı, Entegrasyon Testiı (Integration Test), https://fatihkabakci.com/article-ENTEGRASYON_TESTI(INTEGRATION_TEST), 2015

E. Aktürk, Regresyon ve Tekrar(Onay) Testi Nedir ?, https://emineakturkblog.wordpress.com/2019/06/12/regresyon-ve-tekraronay-testi-nedir/, 2019

G. Gulec, Yazılım Test Türleri: Fonksiyonel Olmayan Testler, http://gizemgulec.com/2020/05/yazilim-test-turleri-fonksiyonel-olmayan-testler/, 2020

59
H. T. İnel, Yazılım Sistemlerinde Yük & Performans Testi, https://medium.com/trendyol-tech/yaz%C4%B1l%C4%B1m-sistemlerinde-y%C3%BCk-performans-
testi-part-1-af825ccf7d69, 2019

Ünite Soruları

Soru-1 :

Aşağıdakilerden hangisi bir yazılımda bir birim olarak kabul edilmez?

(•) - Bir modül

(•) - Bir veri tabanı

(•) - Bir arayüz

(•) - Bir akış şeması

(•) - Bir dokümantasyon

Cevap-1 :

Bir veri tabanı

Soru-2 :

Veri yollarını aşağıdaki birim testlerin hangisinde test edilmesi beklenir?

(•) - Algoritma testi

(•) - Arayüz testi

(•) - Veri tabanı tablosu testi

(•) - Dokümantasyon testi

(•) - Ara birim testi

Cevap-2 :

Algoritma testi

Soru-3 :

Testi gerçekleştiren kişinin yazılımın veri tabanına ve dokümanlara erişimi varken kodlara erişimi bulunmuyorsa bu kişi ne tür test yapıyor olabilir?

(•) - Kara Kutu Testi

(•) - Beyaz Kutu Testi

(•) - Mavi Kutu Testi

(•) - Gri Kutu Testi

(•) - Kırmızı Kutu Testi

Cevap-3 :

Gri Kutu Testi

Soru-4 :

60
Verilen şeklin ifade ettiği kavramın yazılımdaki karşılığı hangi kavram ile ifade edilebilir?

(•) - Analiz

(•) - Entegrasyon

(•) - Yükleme

(•) - Kullanma

(•) - Tasarım

Cevap-4 :

Entegrasyon

Soru-5 :

Tüm modüllerin aynı anda teste dildiği birleştirme testi türü aşağıdakilerden hangisidir?

(•) - Aşağıdan Yukarıya Test

(•) - Yukarıdan Aşağıya Test

(•) - Big Bang Testi

(•) - Regresyon Testi

(•) - Tekrar Testi

Cevap-5 :

Big Bang Testi

Soru-6 :

Aşağıdaki isimlerin hangisine sahip bir yazılım testi bulunamaz?

(•) - Birin güvenlik testi

(•) - Birim performans testi

(•) - Birim birleştirme testi

(•) - Birim hız testi

(•) - Birim yük testi

Cevap-6 :

Birim birleştirme testi

Soru-7 :

“Kullanıcılar, tasarımın çalışma şeklini öğrendikten sonra gerçekleştirecekleri işlemleri ne kadar hızlı yapabiliyorlar?” sorusunun cevabı bir
yazılımın hangi özelliğini ölçmeyi sağlar?
61
(•) - Verimlilik

(•) - Öğrenilebilirlik

(•) - Memnuniyet

(•) - Hatırlanabilirlilik

(•) - Hatalar

Cevap-7 :

Verimlilik

Soru-8 :

Web üzerinde çalışan bir yazılıma aynı anda bağlanabilecek kişi sayısının tespit edilmesi için gerçekleştirilen test, aşağıdaki şıklarda verilen
kategori ikililerinden hangisi içerisine girer?

(•) - Sistem – Fonksiyonel Olmayan

(•) - Sistem – Fonksiyonel

(•) - Birim – Fonksiyonel Olmayan

(•) - Birim – Fonksiyonel

(•) - Kabul – Fonksiyonel 

Cevap-8 :

Sistem – Fonksiyonel Olmayan

Soru-9 :

Aşağıdakilerden hangisi yazılım testlerinde bir “seviyelerine göre sınıflandırma” değildir?

(•) - Birim Testi

(•) - Birleştirme Testi

(•) - Veritabanı Testi

(•) - Sistem Testi

(•) - Kabul Testi

Cevap-9 :

Veritabanı Testi

62
7. YAZILIM TESTLERİNDE KUTU YAKLAŞIMI
Giriş
Bir önceki bölümde de açıklandığı gibi yazılımlar üzerinde gerçekleştirilen testler farklı şekillerde sınıflandırılmaktadır. Bu gruplardan en önemlilerinden biri de
kullandıkları yaklaşıma göre yapılan sınıflandırmadır. Bu sınıflandırmanın ana elemanları kara kutu yaklaşımı, beyaz kutu yaklaşımı ve gri kutu yaklaşımıdır. Bu
bölümde bu yaklaşımlar arasındaki farklar tespit edilmeye çalışılacaktır.

7.1. Kara Kutu Yaklaşımı

Kara kutu testi, uygulamanın iç yapısıyla, kod ya da tasarımla ilgilenmez, işlevsellik ve fonksiyonel ihtiyaçlara göre test yapılır. Kara kutu testi, “fonksiyonel testi,
kapalı test ya da opak test” olarak da adlandırılır. Kara kutu testinde kod incelenmez ve özel bir uygulama ya da programa ihtiyaç duyulmaz. Şekil 7.1.’de kara kutu
yaklaşımı genel şeması gösterilmiştir.

Şekil 7.1. Kara Kutu Yaklaşımı Genel Şeması

Tabi doğası itibariyle kara kutu yaklaşımı kullanan testler yazılımdaki her hatayı bulamaz.
Bu yaklaşımla yapılacak olan testler ile en kolay bulunabilecek hatalar

 Doğru olmayan ya da kayıp fonksiyonlar

 Ara yüz hataları

 Veri yapılarındaki hatalar ya da haricî veritabanı bağlantısı hataları

 Davranış ya da performans hataları

 Başlatma ve sonlandırma hataları

şeklinde ifade edilebilir.

Kara kutu yaklaşımı ile gerçekleştirilen en önemli testler aşağıdaki gibi ifade edilebilir:

Kurgusuz Test (Ad-Hoc Testi): Bir yazılım bileşeni üzerinde gerçekleştirilecek olan diğer testlerin sürelerini ve kapsama alanlarını belirlenmesi için kullanılır.
Planlama ve kurgu yapılmadan hızlıca geliştirildiği için bu ismi almıştır. Bu test aslında testin nasıl yapılacağını ifade eden bir isme sahiptir, diğer bir deyişle neyin test
edildiğini, açıklamaz. Örneğin kurgusuz güvenlik testi de olabilir, kurgusuz birim test de olabilir, ya da kurgusuz yük testi de olabilir.

Araştırma Testi: Bir yazılım bileşeni üzerinde gerçekleştirilecek olan test aşamasından önce öğrenilmesi için kullanılır.

Fonksiyonellik Testi: Genel bir isimdir. Fonksiyonel gereksinimlerin test edilmesidir, beklenen sonuçlar alınıyorsa testlerin yazılmasına devam edilir.

Stres Testi: Aynı işlemin aynı anda birçok kez yapılması sonuçların izlenmesidir.
Yazılım bileşeninin dayanıklılığı ve verdiği tepki belirlenir.

Yük Testi: Yazılım bileşeninin hangi koşullarda ve noktada çökeceğini tespit etmek için kullanılır.

Kullanılabilirlik Testi: Kullanıcı arayüzünün önemli olduğu uygulamalarda yapılan testtir.

Duman Testi: Yazılım bileşeninin küçük testleri başarı ile geçtiğini ve büyük testlere hazır olduğunu belirler.

Yenilenme Testi: Yazılım bileşeninin bir hataya karşı ne kadar sürede eski haline geleceğini anlamak için kullanılır.

Seviye Testi: Yazılım bileşeninin uç limitlerinin test edildiği seviye testinde, sistem uç limitlere kadar zorlanır ve bu limit belirlenir.

Kullanıcı Kabul Testi: Kullanıcının yazılım bileşenini test edip, beklentileri karşılayıp karşılamadığını incelediği testtir.

Alfa Testi: Yazılım bileşeninin geliştirme merkezine çağrılan kullanıcının uygulamada yaptıklarına göre geliştiricilerin gerekli bilgileri not aldığı testtir.

Beta Testi: Dağıtılan yazılım bileşeninin beta versiyonunu test eden kullanıcıların sistemi incelediği ve geri dönüşlerini geliştiriciye bildiridiği testtir.

Kara Kutu yaklaşımının avantaj ve dezavantajları Tablo 7.1.de ifade edilmiştir.

Tablo 7.1. Kara Kutu Yaklaşımının Avantaj Ve Dezavantajları

63
Kara Kutu yaklaşımı kendi içerisinde de çeşitli farklı yaklaşımlar kullanmaktadır.
Bu yaklaşımlar ve sıklıkla kullanılan İngilizce karşılıkları şu şekildedir  (Mutluçağ, 2017): 

 Denklik Sınıfı (Equivalence Partitioning)

 Sınır Değer (Boundary Value)

 Karar Tablosu (Decision Table)

 Sınıflandırma Ağacı (Classification Tree)

 İkili Test (Pairwise Test)

 Durum Geçişi (State Transition)

 Kullanıcı Senaryosu (Use Case)

Aşağıda bu yöntemlerin açıklamaları yer almaktadır (Khan, 2021).

Denklik Sınıfı (Equivalence Partitioning)

Denklik Sınıfı tekniğinin uygulanması iki aşamalıdır (Reid, 1997). En basit tanımıyla aynı özelliği gösteren (denk) test koşullarının gruplandırılması ve belirlenen
grupların her birinden seçilen kısıtlı veri seti ile uygulamaların test edilmesidir. Bu teknikte kritik nokta denklik sınıflarını iyi bir şekilde belirlemektir. Denklik sınıfları
belirlenirken değerler (girdi ve ya çıktı) aynı davranışı göstermesi gereken gruplara ayrılır. Genel olarak üç farklı tipte denklik sınıfı vardır. Bunlar Sürekli Değer
Aralığı, Ayrık Değerler ve Tek Seçimli Değerler’dir. Sürekli Değer Aralığı’nda girdi ya da çıktılara uygulanacak değerler birbirini takip eder ve değerler arasında
herhangi bir boşluk yoktur. Şekil 7.2.’de sürekli değer aralığının şematik gösterimi verilmiştir.

Şekil 7.2. Sürekli Değer Aralığının Şematik Gösterimi

Örneğin uygulamada oda sıcaklığı değerini girdi olarak alan bir fonksiyon olduğunu düşünelim. Burada, oda sıcaklığı, uygulamanın şekline, kullanılan verilere vb göre
farklı şekillerde kaydedilebilir. Örneğin 15 derece gibi bir tamsayı, 15,2 derece gibi tek ondalık, 15,27 derece gibi 2 ondalık veya 15,270005 derece gibi çoklu
ondalık şeklinde yazılabilir. Burada görüldüğü üzere sayıların sonsuz olmasından ötürü herhangi iki değer arasında mutlaka bir değer ile karşılaşılır. Verilen uygulama
içerisinde içerisinde sıcaklığın 10 ila 100 derece arasındaki değerlerinin geçerli diğerlerinin geçersiz olduğunu varsayalım. Belirtilen gereksinim için denklik sınıfları şu
şekilde olacaktır:

 [-∞, 10): geçersiz sınıf

 [10-100]: geçerli sınıf

 (100, +∞]: geçersiz sınıf

Buna göre -1000 ve -1 değerlerinin; 15 ve 75 değerlerinin, 105 ve 1000 değerlerinin uygulama açısından anlamı aynı olacaktır ve bu ikililerin uygulamaya aynı
davranışı sergiletmesi beklenir. Bu sebeple üç denklik sınıfı olduğundan üç tane test senaryosu oluşturulması ve test senaryolarını test ederken denklik sınıfı
içerisindeki herhangi bir değeri test senaryosunun girdisi olarak kullanmak, yazılımı test etmek açısından yeterli olacaktır.

Ayrık Değerler’de sadece belirli değerleri alan girdi ya da çıktılar geçerli, diğerleri geçersiz olmaktadır. Şekil 7.3’te ayrık değerlerin şematik gösterimi verilmiştir.

Şekil 7.3. Ayrık Değerler Şematik Gösterim

Örneğin öğrencilerin bir derste gruplar halinde sunum yapacağını ve sunumların 2, 4 ya da 5 kişilik gruplar halinde yapılabileceğini varsayalım. Buna göre
oluşabilecek denklik sınıfları

64
(2, 4, 5) geçerli sınıf, (1), (3), (5) geçersiz sınıflar şeklinde olacaktır. Burada tüm seçenekler dört denklik sınıfı içerisine yerleştirildiğinden dört adet test senaryosu
oluşturulması gerekecektir.

Tek seçimli denklik sınıfında sadece bir tane geçerli değer vardır. Diğer tüm değerler geçersizdir. Örneğin sadece kişilere kredi veren bir bankayı düşünürsek şirket,
kamu, dernek veya vakıf bizim için geçersiz olacaktır. Tek seçimli değerlerde hazırlanacak test senaryosu bir geçerli (kişi) ve bir geçersiz olmak üzere en az 2
tanedir. Şekil 7.4’te tek seçimlik değerin şematik gösterimi yer almaktadır.

Şekil 7.4.  Tek Seçimli Değerler Şematik Gösterimi

Denklik Sınıfı Tekniği pek çok kara kutu testinde kullanılan bir tekniktir ve birçok durumda fayda sağlamaktadır. Ancak bu tekniği kullanırken dikkat edilmesi
gereken noktalar bulunmaktadır. Bu noktalar şu şekilde maddelendirilebilir:

1. Genellikle bir denklik sınıfı içerisinde yer alan bir değer, testin uygulanması için yeterlidir. Yeterli zaman ve bütçe mevcutsa bir denklik sınıfı için birden fazla test
senaryosu hazırlanabilir ancak 2. ve daha sonraki test senaryolarının ilk test senaryosunun bulamadığı kusurları bulma ihtimali düşüktür.

2. Tüm geçersiz veri değerlerine sahip test senaryosu hazırlamak doğru bir yaklaşım değildir. Bunun yerine test senaryolarının sadece bir geçersiz değeri girdi olarak
kullanması daha sağlıklıdır. Neticede geçersiz sınıfların hepsi sistem için aynı anlama gelmektedir.

Sınır Değer (Boundary Value)

Bir yazılım bileşeninde hataları bulmak için yazılımdaki tek noktaya odaklanmak yerine değişkenin alt ve üst sınırlarını kontrol ederek yapılan testlerdir (Murnane,
2007). Bu tekniğin kullanılma sebebi, sınır değerlerin değişimin gerçekleştiği ve bu sebeple hataya en yatkın değerler olmasıdır. Sınır değeri tekniği birçok hatanın
gizlendiği sınır değerlerine odaklanır.
Bu tekniğinin uygulanması üç aşamalıdır.

1. Denklik sınıfları belirlenir,

2. Her bir denklik sınıfının sınır değerleri tanımlanır,

3. Her bir sınır değeri için

 kendisinin,

 kendisinden bir önceki değerin,

 kendisinden bir sonraki değerin

girdi olduğu test senaryoları hazırlanır. Örneğin aşağıda verilen kod parçası için bu yöntemi uygulayalım.

Burada görüldüğü üzere girdi değerinin 10’dan büyük eşit olması ve 50’den büyük olması halinde x1; diğer durumlarda ise x2 işleminin gerçekleştirilmesi için bir kod
parçası yazılmıştır. Buna göre buradaki denklik sınıfları

şeklinde tasarlanır. Buna ek olarak sınır değerler, 10, 50 ve bunların 1 eksik ve 1 fazlaları olan 9, 11, 49 ve 51 şeklindedir. Buna göre üç adet denkli sınıfı ve 9, 10,
11, 49, 50, 51 değerleri için test senaryoları oluşturulması gerekmektedir. Bu durumda tüm değerler denenmiş olacaktır.

Karar Tablosu (Decision Table)

Gereksinimleri belirlenmiş çok koşullu karmaşık yazılımlar için kullanılır (Martyn, 2006).
İş kuralları bir tablo üzerine yazılıp girdiler için alınabilecek değerler ve hangi girdi için hangi çıktının alınabileceği bu tabloda gösterilir. Görülebilecek bütün test
senaryoları bu tabloya yazılır. Karar tablosu test tekniğinin uygulanması iki aşamada olmaktadır.

1. Girdi koşullarının tanımlanması,

2. Girdi koşullarına bağlı olarak alınacak aksiyonların belirlenmesi

65
Basit bir örnek üzerinde bu tekniği uygulayalım. Bir iş yerinde bir sekreter alımı için belirlenen şartların aşağıdaki gibi olduğunu varsayalım. Bu alım için üç adet
kritere bakılmaktadır ve ancak ve ancak bu üç kriterin birden sağlanması halinde işe alım gerçekleşmektedir. Bu şartlar adayın kadın olması, en az iki yıl deneyimli
olması ve bekar olması şeklindedir. Buna göre toplamda seçenek (test edilecek sınıf) bulunmakta ve bunlardan ancak bir tanesi geçerli sınıf, diğer
yedisi geçersiz sınıf olmaktadır. Tablo 7.2.’de karar tablosu örneği gösterilmiştir.

Tablo 7.2. Karar Tablosu Örneği

Kadın mı? En az iki yıl deneyimli mi? Bekar mı? Geçerli/ geçersiz
Hayır Hayır Hayır Geçersiz
Hayır Hayır Evet Geçersiz
Hayır Evet Hayır Geçersiz
Hayır Evet Evet Geçersiz
Evet Hayır Hayır Geçersiz
Evet Hayır Evet Geçersiz
Evet Evet Hayır Geçersiz
Evet Evet Evet Geçerli

Görüldüğü üzere tam ve kompakt bir şekilde sunulan uygulama davranışlarını ele alındığı düşünüldüğünde karar tablolarından test senaryolarını oluşturmak oldukça
kolaydır.

Sınıflandırma Ağacı (Classification Tree)

Test için kullanılan nesnenin hiyerarşik olarak denklik paylarının bir ağaç görünümünde modelleyerek bu payların birbirleriyle olan ilişkileri üzerinden test senaryoları
üreten bir tekniktir (Guidotti ve diğ., 2019).

İkili Test (Pairwise Test)

Testi yapılan yazılımın fonksiyonunun birden fazla kombinasyona sahip olduğu durumlarda test senaryo sayısını önemli ölçüde azaltmaya yarayan bir test tekniğidir.
Bir girdi girilip, bir çıktı alınan senaryolardan ziyade iki girdi girilip hata bulunabilirliğini arttırmaktadır. Bu teknik zamandan önemli ölçüde kazanç sağlamaktadır.
Yazılımlarda bulunan birçok hatanın kök neden analizi yapıldığında bir değişkenin değerinin diğer bir değişkene bağlı olduğu görülür. Bununla birlikte çoğu hatanın iki
değişkenin değerleri arasındaki etkileşimlerin testlerinde keşfedildiği anlaşılmıştır. Buna göre anlaşılacağı üzere değişkenlerin değerleri arasındaki etkileşim test
edildiğinde hata yakalama şansı artmaktadır.

Durum Geçişi (State Transition)

Yazılımın geçmişteki ve şu anki durumları değerlendirilerek yapılır. Burada durumlar arası geçişler test edilir. Başarılı sonlanan geçişler ve başarısız geçişler bir
diyagram haline getirilir.

Durum geçişi test tekniği durum geçişi diyagramlarına dayanmaktadır. Durum geçiş diyagramları, bir sistemin daha önce ne olduğu veya geçerli ve geçersiz emir çıkışı
olduğunda bir şeyi hatırlamak zorunda kaldığı durumlarda bu bilgiyi kaydetmek için sıklıkla kullanılan bir araçtır. Durum geçişi diyagramı içerisinde kullanılan terimler
kısaca şu şekildedir:

 Durum: Bir sistemin bir veya daha fazla olay için beklediği haldir. Diyagramda “daire” ile belirtilir.

 Başlangıç Durumu: Durum makinesinin işlemlere başladığı durumdur.

 Kabul/Final Durumu: İşlemlerin kabul edilir bir noktaya geldiğini ifade eden durumdur. Her yapıda bulunmak zorunda değildir.

 Geçiş: Bir olay nedeniyle sistemin bulunduğu durumdan başka bir duruma geçmesidir.  Diyagramda “ok” ile belirtilir.

 Olay: Sistemin durumunun değişmesine sebep olan şeydir. Diyagramda “ok” üzerindeki “yazı-etiket” ile belirtilir.

 Aksiyon/Eylem: Durum değişikliği ile başlatılan işlem. Diyagramda “ok” üzerindeki “/” işareti sonrasındaki “komut” ile belirtilir.

Örneğin bir bankamatiğe bir bankamatik kartının yerleştirilmesi ve PIN kodunun girilmesini bir durum geçişi diyagramı ile ifade edelim. Buradaki durumlar normal
şartlar altında Başla, PIN’i bekle, deneme, hesaba erişim sağla şeklinde olmalıdır. Ancak PIN’in yanlış girilebileceği de mümkün olduğundan bu da durumlar
içerisine yerleştirilmelidir. Örneğin toplamda PIN için üç kez deneme hakkı verilmesi ve üç kez doğru PIN girilemediği takdirde sistemin kartı yutması durumlarını da
senaryoya ekleyelim. Bu durumda olaylar kartı sok, PIN’i gir, PIN tamam, PIN uygun değil olayları bulunmaktadır. Buna göre Şekil 7.5.’te bu senaryonun durum
geçişi örneği verilmiştir.

Şekil 7.5. Durum Geçişi Örneği

Kullanıcı Senaryosu (Use Case)

Bu teknikte fonksiyonel olan ve fonksiyonel olmayan gereksinimler kullanılarak test senaryosu üretilir. Bu teknikteki en önemli özellik senaryoların açık ve detaylı
olmasıdır.  Temel olarak test yöntemi bir kullanıcı ve bu kullanıcının sistemden beklediği durumların oluşup oluşmadığını ölçümler.
66
7.2. Beyaz Kutu Yaklaşımı
Beyaz kutu testi, uygulamanın kodunu temel alır ve programın çalışmasını, iç yapılarını test eder. Cam kutu, açık kutu, temiz kutu olarak da adlandırılan beyaz kutu
testinde, testi yapan kişi sorunlu kısmı bulmak için kodu incelemektedir. Beyaz kutu testi, ekstra kod parçasını çıkararak kodun optimizasyonunu sağlar. Hangi
verinin yazılan kodu en iyi şekilde test edeceğini belirler. Ancak, kodu inceleyip tek tek hata bulmak zor bir işlemdir ve bu test yapıldığında maliyet artar. Şekil
7.6’da beyaz kutu yaklaşımının genel şeması verilmiştir.

Şekil 7.6. Beyaz Kutu Yaklaşımı Genel Şeması

Beyaz kutu yaklaşımı ile gerçekleştirilen en önemli testler aşağıdaki gibi ifade edilebilir:

Birim Test: Yazılım geliştiriciler tarafından gerçekleştirilen bu teknikte küçük kod blokları test edilir.

Statik ve Dinamik Analiz: Statik analiz kodu sıralı bir şekilde inceleyip hataları araştırırken, dinamik analiz, kodun çalışmasını denetler.

Açıklama Kapsamı: Kod içindeki bütün açıklamaların test edilmesi ve bunların sorunsuz çalıştığının garanti altına alınmasıdır.

Güvenlik Testi: Sistemin güvenliğiyle; izinsiz erişimler, kod bozulması, hacklenme gibi konulardan nasıl korunacağı ile ilgilenir. Sistem açıklarını tespit edip, bu
açıkların giderilmesiyle ilgilenir.

Değişim Testi: Sistemdeki hata düzeltildikten sonra yapılan bir testtir.

Beyaz Kutu yaklaşımının avantaj ve dezavantajları Tablo 7.3.’te verilmiştir.

Tablo 7.3. Beyaz Kutu Yaklaşımının Avantaj ve Dezavantajları

Beyaz Kutu Yaklaşımı’nda kullanılan en önemli test teknikleri aşağıda verilmiştir (Hussain ve Singh, 2015).

1) Ortam Kontrolü: Kod üzerinde yapılan en temel testlerden biridir. Özellikle programlama dilini yeni öğrenen kişiler tarafından gerçekleştirilmelidir.

2) Kod Yürütme: Bu yöntemde, test edilen kod adım adım yürütülerek hatalar bulunmaya çalışılır.

3) Resmî İnceleme: Burada kodlar üzerinde resmî bir inceleme yapılması planlanmıştır.
Bu resmî inceleme yazılım geliştirme ekibi tarafından yapılabileceği gibi farklı bir kuruluş tarafından da yapılabilir.

4) Akış Kontrolü Testi: Burada yazılımın planlaması diğer bir deyişle akışının nasıl olacağı test edilir.

5) Temel Yol Testi: Akış Kontrolü Testi’ne benzerlik göstermektedir. Burada bir yazılımın temelde takip etmesi gereken temel yol üzerinde test işlemleri
gerçekleştirilir.

6) Veri Akış Testi: Yine Akış Kontrolü’ne benzerlik gösteren bir test türüdür ve yazılımda verinin nasıl ilerleyeceği test edilir.

7) Döngü Testi: Yazılımdaki döngüler üzerinde gerçekleştirilen bir test türüdür. Döngüler, yazılımda pek çok konuda fikir veren yapılar odluğundan döngüler
üzerinde gerçekleştirilen bir test yazılım hakkında da pek çok veriye sahip olunmasını sağlayacaktır.

7.3. Gri Kutu Yaklaşımı

Kara kutu ve beyaz kutu testlerinin birleşimidir. Test uzmanının veri tabanına ve dokümanlara erişimi vardır. Böylece tasarıma ve verilere uygun test dokümanı
üretebilir. Yani uygulamanın iç işlemlerine kısmen erişime izin verir.  Şekil 7.7.’de Gri Kutu Yaklaşımı Genel Şeması verilmiştir (Jehan ve diğ., 2013; Tyler ve
Soundarajan, 2017).

67
Şekil 7.7. Gri Kutu Yaklaşımı Genel Şeması

Bu yöntemin avantaj ve dezavantajları şu şekilde (Tablo 7.4) ifade edilebilir.

Tablo 7.4. Gri Kutu Yaklaşımının Avantaj ve Dezavantajları

Avantajları Dezavantajları
Analistlerin test durumlarını planlaması kolaydır. Koda ulaşılamadığından test kapsamı dardır.
Tarafsız test işlemi sağlar. Test edilmemiş birçok test senaryosu kalmaktadır.
Test yapan kişiler konu hakkında bilgi sahibidir. Test senaryolarının bilinçsiz bir şekilde tekrar edilmesi söz konusu olabilir.

Gri Kutu Yaklaşımı’nda en çok kullanılan teknikler ise aşağıda açıklanmıştır:

1) Ortogonal Dizi Testi: Bu tür testler, akla gelebilecek tüm karışımların alt kümesi olarak kullanılır.

2) Matris Testi: Kafes testinde görevin durum raporu ifade edilir.

3) Regresyon Testi: Yazılımda değişiklikler yapıldığı takdirde gerçekleştirilen ve yapılan değişikliklerin yazılımda bir sorun oluşturup oluşturmadığını inceleyen test
türüdür.

4) Model Testi: Model testi, yapısal mühendisliği ve konfigürasyonu için uygulamayı kontrol eder.

Tablo 7.5.’te her üç kutu yaklaşımı ile gerçekleştirilen testlerin genel bir karşılaştırılması verilmiştir.

Tablo 7.5. Kara Kutu – Beyaz Kutu – Gri Kutu Yaklaşımı Karşılaştırması

Kara Kutu Yaklaşımı Beyaz Kutu Yaklaşımı Gri Kutu Yaklaşımı

Yalnızca temel yönleri analiz eder, yani iç yapı
İç Yapı Bilgisi İç yapı bilgisi tamamen mevcuttur. Kısmî bir iç yapı bilgisi mevcuttur.
bilgisi hiç yoktur.
Bu özellikte iki yaklaşımın arasında
Kapsam ve Zaman Az kapsamlı ve az zaman alıcıdır. Çok kapsamlı ve çok zaman alıcıdır.
kalmaktadır.
Parça Parça Test Testler genellikle tek parça halinde yapılır Testler birçok parçaya bölünerek yapılır Testler birkaç parçaya bölünerek yapılır
Testçi dışında genellikle son kullanıcı/müşteri Testçi dışında genellikle yazılım geliştirici Testçi dışında genellikle son kullanıcı/müşteri
Testi Gerçekleştiren
tarafından yapılır tarafından yapılır tarafından yapılır
Dış Etkiler Dış etkiler test için oldukça önemlidir. Dış etkiler test için önemsizdir. Dış etkiler test için kısmî derecede önemlidir.
Algoritma Testine
Algoritma testine uygun değildir Algoritma testine uygundur Algoritma testine uygun değildir
Uygunluk

Bölüm Özeti
Bu bölümde yazılım testlerindeki kutu yaklaşımı ele alınmıştır. Temelde Kara Kutu, Beyaz Kutu ve Gri Kuru olmak üzere üç adet kutu yaklaşımı bulunmaktadır.

Kara Kutu Yaklaşımı ile gerçekleştirilen yazılım testleri, uygulamanın iç yapısıyla, kod ya da tasarımla ilgilenmez, yazılımın işlevsellik ve fonksiyonel ihtiyaçlarını
inceler. Kara Kutu Yaklaşımı ile gerçekleştirilen en önemli testler kurgusuz testler, araştırma testleri, fonksiyonellik testleri, stres testleri, yük testleri, kullanılabilirlik
testleri, duman testleri, yenilenme testleri, seviye testleri, kullanıcı kabul testleri, alfa testleri ve beta testleridir.
Kara Kutu yaklaşımı uygulanırken çeşitli farklı teknikler kullanılmaktadır. Bu tekniklerin bazıları Denklik Sınıfı, Sınır Değer, Karar Tablosu, Sınıflandırma Ağacı, İkili
Test, Durum Geçişi ve Kullanıcı Senaryosudur. Denklik Sınıfı Tekniği en basit tanımıyla aynı özelliği gösteren (denk) test koşullarının gruplandırılması ve belirlenen
grupların her birinden seçilen kısıtlı veri seti ile uygulamaların test edilmesidir. Sınır Değer Tekniği, bir yazılım bileşeninde hataları bulmak için yazılımdaki tek noktaya
odaklanmak yerine değişkenin alt ve üst sınırlarını kontrol ederek yapılan testlerdir. Karar Tablosu gereksinimleri belirlenmiş çok koşullu karmaşık yazılımlar için
kullanılır, kurallar bir tablo üzerine yazılıp girdiler için alınabilecek değerler ve hangi girdi için hangi çıktının alınabileceği bu tabloda gösterilir. Sınıflandırma Ağacı
Tekniği kullanılan nesnenin hiyerarşik olarak denklik paylarının bir ağaç görünümünde modelleyerek bu payların birbirleriyle olan ilişkileri üzerinden test senaryoları
üreten bir tekniktir. İkili Test, testi yapılan yazılımın fonksiyonunun birden fazla kombinasyona sahip olduğu durumlarda test senaryo sayısını önemli ölçüde azaltmaya
yarayan bir test tekniğidir. Durum Geçişi Tekniği yazılımın geçmişteki ve şu anki durumları değerlendirilerek yapılır. Burada durumlar arası geçişler test edilir.
Kullanıcı Senaryosu Tekniği’nde fonksiyonel olan ve fonksiyonel olmayan gereksinimler kullanılarak test senaryosu üretilir.

Beyaz Kutu Yaklaşımı ile gerçekleştirilen yazılım testleri, uygulamanın kodunu temel alır ve programın çalışmasını, iç yapılarını test eder. Beyaz Kutu Yaklaşımı ile
gerçekleştirilen en önemli testler birim test, statik ve dinamik analiz, açıklama kapsamı, güvenlik testi, değişim testi şeklindedir. Beyaz Kutu Yaklaşımı’nda kullanılan
en önemli test teknikleri ise Ortam Kontrolü, Kod Yürütme, Resmî İnceleme, Akış Kontrolü Testi, Temel Yol Testi, Veri Akış Testi, Döngü Testi şeklindedir.

Gri Kutu Yaklaşımı, Kara Kutu ve Beyaz Kutu yaklaşımlarının birleşimidir. Bu testi yapan test  uzmanının veri tabanına ve dokümanlara erişimi vardır. Böylece
tasarıma ve verilere uygun test dokümanı üretebilir. Yani uygulamanın iç işlemlerine kısmen erişime izin verir. Ancak koda doğrudan erişimi yoktur ve kodu
inceleyemez. Gri Kutu Yaklaşımı’nda en çok kullanılan teknikler ise Ortogonal Dizi Testi, Matris Testi, Regresyon Testi ve Model Testi’dir.

Kaynakça

ISTQB Yazılım Testi Terimler Sözlüğü, 2014

S. Mutluçağ, Kara Kutu Test Tekniği ve Uygulanması, https://www.mobilhanem.com/kara-kutu-test-teknigi-ve-uygulanmasi/, 2017

B. Tyler, N. Soundarajan, Black-Box Testing of Grey-Box Behavior, FATES, International Workshop on Formal Approaches to Software Testing,  Formal
Approaches to Software Testing, Sayfa: 1-14, 2003

T. Hussain, S. Singh, A Comparative Study of Software Testing Techniques Viz. White Box Testing Black Box Testing and Grey Box Testing, International Journal
of Allied Practice, Research and Review, IJAPRR International Peer Reviewed Refereed Journal, Sayı. 2(5), Sayfa: 1-8, 2015

S. Jehan, I. Pill, F. Wotawa, SOA Grey Box Testing -- A Constraint-Based Approach, IEEE Sixth International Conference on Software Testing, Verification and
Validation Workshops, 18-22 Mart 2013

68
M. E. Khan, Different Approaches To Black Box Testing Technique For Finding Errors, July 2021: Top Read Articles in Software Engineering & Applications
Research Articles, IJSEA, International Journal of Software Engineering & Applications, 2021

S. C. Reid, An empirical analysis of equivalence partitioning, boundary value analysis and random testing, Fourth International Software Metrics Symposium, 5-7
Kasım 1997

T. Murnane, K. Reed, R. Hall, On the Learnability of Two Representations of Equivalence Partitioning and Boundary Value Analysis, ASWEC, Australian
Software Engineering Conference, 10-13 Nisan 2007

K. S. Martyn, Decision-Making in a Corporate Boardroom: Inside the Black-Box, PhD Thesis, 2006

R. Guidotti, A. Monreale, S. Ruggieri, F. Turini, F. Giannotti, D. Pedreschi, A Survey of Methods for Explaining Black Box Models, ACM Computing Survey,
Sayı. 51(5), Sayfa:
1-42, 2019

Ünite Soruları

Soru-1 :

Yazılım test yaklaşımlarındaki kutunun rengi neye göre belirlenir?

(•) - Yazılımın geliştirildiği programama dili

(•) - Testi yapan kişiler

(•) - Yazılımın iç yapısına ulaşılıp ulaşılmaması

(•) - Testin uygulanma sıklığı

(•) - Testin ne zaman yapıldığı

Cevap-1 :

Yazılımın iç yapısına ulaşılıp ulaşılmaması

Soru-2 :

Aşağıdakilerden hangisi Beyaz Kutu Testi’nin Kara Kutu Testi’nden daha maliyetli olmasının sebeplerinden biri değildir?

(•) - daha uzun sürede gerçekleştirilmesi

(•) - daha ayrıntılı olması

(•) - daha teknik olması

(•) - daha çok modülün incelenmesi

(•) - kimi zaman özel araçlar gerektirmesi

Cevap-2 :

daha çok modülün incelenmesi

Soru-3 :

Verilen şekil yazılım testindeki kutu yaklaşımlarını göstermektedir. Buna göre X, Y ve Z ile gösterilen yerlere sırasıyla aşağıdakilerden hangisi
getirilmelidir?

69
(•) - Beyaz Kutu – Kara Kutu – Gri Kutu

(•) - Kara Kutu – Beyaz Kutu – Gri Kutu

(•) - Gri Kutu – Beyaz Kutu – Kara Kutu

(•) - Gri Kutu – Kara Kutu – Beyaz Kutu

(•) - Kara Kutu – Gri Kutu – Beyaz Kutu

Cevap-3 :

Kara Kutu – Gri Kutu – Beyaz Kutu

Soru-4 :

Verilen şekilde aşağıdakilerden hangisi mevcut değildir?

(•) - Durum

(•) - Aksiyon

(•) - Geçiş

(•) - Olay

(•) - Final Durumu

Cevap-4 :

Aksiyon

Soru-5 :

“Kara Kutu Testleri, Beyaz Kutu Testleri’nden daha ………………dir.” cümlesindeki boşluğa aşağıdakilerden hangisi getirilemez?

(•) - az kapsamlı

(•) - az zaman alıcı

(•) - az maliyetli

(•) - pratik

(•) - teknik

Cevap-5 :

70
teknik

Soru-6 :

Aşağıdakilerden hangisi hem bir yazılım testinin hem de bir Kara Kutu Tekniği’nin ortak adıdır?

(•) - Sözdisimsel Test

(•) - Dinamik Test

(•) - Analitik Test

(•) - İkili Test

(•) - Eşli Test

Cevap-6 :

İkili Test

Soru-7 :

    if(input>=10 and input<50)

               then do x1;

else

                do x2;

şeklinde verilen bir kod parçasında, Denklik Sınıfı Tekniği’ne göre test edilmesi gereken toplam kaç adet sınıf bulunmaktadır?

(•) - 1

(•) - 2

(•) - 3

(•) - 4

(•) - 5

Cevap-7 :

Soru-8 :

Bir bankadaki sıra numaralarının 100-200, 500-600 ve 1000-1100 arasında olduğu ifade edilmektedir. Buna göre bu sıra numaraları baz alınarak
yapılacak bir Kara Kutu Testi’nin hangi tekniğe göre yapılması en uygun olur?

(•) - Denklik Sınıfı

(•) - Karar Tablosu

(•) - İkili Test

(•) - Durum Geçişi

(•) - Kullanıcı Senaryosu

Cevap-8 :

Denklik Sınıfı

Soru-9 :

Bir test senaryosunda 10-20 arasındaki değerler geçerli bir sınıfı, diğer tüm değerler ise geçersiz sınıfı ifade ediyorsa ve test için Sınır Değeri
Tekniği kullanılıyorsa, aşağıdaki değerlerden hangisinin test edilmesi beklenmez?

(•) - 10

(•) - 20

(•) - 9

71
(•) - 19

(•) - 15

Cevap-9 :

15

72
8. YAZILIM TEST OTOMASYONLARI
Giriş
Yazılım testleri farklı şekillerde sınıflandırılabilmektedir. Bu sınıflandırmalardan önemlilerden birisi de yazılım testinin kim tarafından ve nasıl yapıldığıdır. Yazılım testleri
insanlar tarafından manuel olarak yapılabildiği gibi makineler veya yazılımlar tarafından otomatik olarak da yapılabilir. Her iki test şeklinin de avantaj ve dezavantajları
mevcuttur ancak aynı testin çok fazla sayıda yapılması gereken, ya da pek çok farklı girdi ile test edilmesi gereken durumlarda mutlaka yazılım test otomasyonlarına
ihtiyaç duyulmaktadır. Bu bölümde yazılımları otomatik olarak test eden yazılım test otomasyonlarının bazıları tanıtılmış ve bu otomasyonlar farklı kriterlere göre
karşılaştırılmıştır.

8.1. Yazılım Test Otomasyonu Kavramı

Yazılım testleri, yazılım uygulamalarındaki muazzam büyüme nedeniyle son on yılda popüler bir kavram haline gelmiştir. Yazılım testinin birincil motivasyonu, yazılımın
müşteri ve kullanıcılar tarafından gerektiği gibi çalıştığını ve her zaman doğru sonuçları ürettiğini kanıtlamaktır. Ayrıca yazılım mühendisliğinde risk yönetiminin kritik
bir kavram olduğu (Masso ve diğ., 2020) ve yazılımdaki risklerin belirlenmesi için test sürecinin kullanılabileceği bilinmektedir. Uygun testler genellikle test
planlamasını, test ortamları oluşturmayı, sonuçları görüntülemeyi ve test senaryolarını içerir. Yazılım testleri, farklı kriterlere göre birkaç gruba ayrılabilir. Yazılım
testleri, birincil amaçlarına, testlerin yapılış zamanına, fonksiyonelitesine göre sınıflandırılır. Ayrıca seviye olarak dört seviyede tanımlanabilirler. Bunlar birim testi,
entegrasyon testi, sistem testi ve kabul testidir (Elbaum ve diğ., 2003; Bertolino, 2007; Kundu, 2012; Hedayati ve diğ., 2015; Falah ve diğ., 2015). Başka bir
sınıflandırma, testçilerin sistem hakkındaki bilgilerinden değerlendirilebilen kara kutu/beyaz kutu testidir (Monier ve
El-mahdy, 2015). Bunların dışında yazılım testleri, testlerin içeriğine göre veri tabanı testi, mobil uygulama testi, arayüz testi, web uygulaması testi gibi gruplara
ayrılabilir. Tüm bu test türleri ile ilgili tüm yazılım test süreçleri iki farklı yöntemle gerçekleştirilebilir: (1) insanlar tarafından yapılan testler (manuel testler), (2)
makineler/diğer yazılımlar tarafından yapılan testler (otomasyon testleri/otomatik testler). Otomasyon testi, test planı kapsamını en üst düzeye çıkarmak ve
kullanımdaki yazılım güvenilirliğini ve kalitesini artırmak için bir çözümdür (Catelani ve diğ., 2011). Genellikle testlerin bir alt kümesini çalıştırma, sonuçları yakalama,
test senaryolarını çalıştırma, otomatik olarak kurma, çevresel değişkenleri kaydetme ve işlemeyi ve sonuçları kapsamlı ve net bir şekilde analiz etme yeteneklerini
içerir. Otomasyon testin faydalarından biri, insan hatalarının ortadan kaldırılmasına yardımcı olmasıdır. Otomasyon testler ayrıca manuel testlerden daha hızlıdır ve bu
da maliyet düşüşlerine yol açabilir (Gupta ve diğ., 2015). Bu nedenle, son yıllarda yazılım testi için manuel test yerine otomasyon testi sıklıkla tercih edilmeye
başlanmıştır. Tablo 8.1.’de otomasyon testleri ile manuel testlerin genel bir karşılaştırması sunulmuştur.

Tablo 8.1. Otomasyon Testleri ve Manuel Testlerin Karşılaştırılması

Otomasyon Testi Manuel Test

Daha hızlıdır. Daha yavaştır.
Birçok testi defalarca çalıştırabilir. Bir veya iki defa çalıştırılacak olan testlerde kullanılması uygundur.
Sık sık değişiklik içeren regresyon testlerinde verimli çalışır. Regresyon testlerini yapmak zordur.
Karmaşık projelerde kolaylık sağlar. Karmaşık projeler için uygun değildir.
Maliyetli olabilir. Genellikle daha az maliyetlidir.
Kullanıcı ara yüzü testlerinde verimsiz olabilir. Kullanıcı ara yüzü testlerinde daha verimlidir.
Daha doğru, daha stabil sonuçlar üretebilir. Sonuçları otomasyon testleri kadar güvenilir değildir.

8.2. Yazılım Test Otomasyonlarının Karşılaştırılması

Web uygulaması testi, bazen hafife alınsa da, herhangi bir web uygulaması geliştirmenin önemli bir parçasıdır. Web uygulaması testi için izlenmesi gereken beş ana
adım vardır. Birincisi, özellikle web uygulamasının doğru çalışıp çalışmadığından emin olmak için kullanılan fonksiyonellik testidir (Rufus, 2014; Angmo ve Sharma,
2014). İkinci adım, web uygulama test cihazının web sunucusu ile uygulama sunucusu arasında verimli bir etkileşim olup olmadığını kontrol ettiği arayüz testidir.
Üçüncü adım, web uygulamasının gerekli tüm cihazlar ve çeşitli tarayıcılarla uyumlu olmasını sağlayan uyumluluk testidir. Tarayıcı uyumluluğu ve işletim sistemi
uyumluluğu gibi birden çok uyumluluk testi öğesi vardır. Dördüncü adım, test cihazının uygulamanın tüm uygulamalara yanıt verip vermediğini ve ağır yük altında
çalışıp çalışmadığını kontrol ettiği performans testidir. Bir web uygulamasında test etmenin son adımı, uygulamanın yetkisiz erişime veya kötü amaçlı yazılımlar ve
diğer virüsler yoluyla her türlü zararlı eyleme karşı korunmasını sağlayan güvenlik testidir (Lucca ve Fasolino, 2006).

Web uygulama testinin çeşitli avantajları vardır. Web uygulamasının tam doğruluğunu sağlar, web uygulamasının yayınlanmadan önce performansına ve işleyişine olan
güveni arttırır, gelecekteki riskleri azaltır, tekrarlayan çabaları azaltır, otomasyon test aracı olarak bilinen bir araçla maliyetleri ve zamanı azaltır, ve müşteri
memnuniyetini artırır. Testler sayesinde web uygulama kalitesi maksimuma ulaşılır (Gogna, 2014; Sharma ve Angmo, 2014). Bir tasarımcı veya proje yöneticisi aynı
anda baktığında sorunların üstesinden gelir, daha iyi sonuçlar üreten yüksek kaliteli web uygulamaları sağlar (Li ve diğ., 2014). Tüm bu işlemler için sıklıkla web
tabanlı test otomasyonları kullanılmaktadır.

Günümüzde birçok web tabanlı test otomasyonu bulunmaktadır. Bunların en çok bilinenleri  Acunetix, FitNesse, JMeter, Katalon Studio, LoadRunner, HP Birleşik
Fonksiyonel Test (HP UFT) olarak da bilinen QTP (QuickTest Professional), Ranorex Studio, Sahi Pro, Selenium, Telerik Test Studio, TestComplete, TestIO,
TestingWhiz ve Webload’dır. Bu araçlara ilişkin bazı kısa açıklamalar aşağıda verilmiştir.

Acunetix: 2005 yılında geliştirilen Acunetix, Cross-Site Scripting, SQL Injection, XML Injection, Kötü Amaçlı Dosya Dahil Etme, Sınırsız URL Erişimi, HTTP
Yanıt Bölme, Bilgi Sızıntısı gibi 4500'ün üzerinde web uygulaması zafiyetini tespit edip raporlayabilen bir araçtır. İlk olarak 2014'te Windows için geliştirilmiş ancak
2018’de bir Linux sürümü piyasaya sürülmüştür. Örnek bir Acunetix test raporu Şekil 8.1.’de verilmiştir (Acunetix, 2020).

73
Şekil 8.1. Örnek Bir Acunetix Test Raporu

FitNesse: Bir web sunucusu, bir wiki ve kabul testi için özel olarak kullanılan yazılımlar için otomatik bir test aracıdır. FitNesse projesi 2004 yılında Java'da Fit
classic Java ile başlamış ve 2010 yılına kadar yeni eklentilerle yeni sürümler oluşturulmuştur. Örnek bir FitNesse test raporu Şekil 8.2.'de verilmiştir (Fitnesse,
2020).

Şekil 8.2. Örnek Bir FitNesse Test Raporu

JMeter: Apache tarafından 1998 yılında geliştirilen JMeter, hem dinamik hem de statik kaynaklar ve dinamik web uygulamaları için bir araçtır. JMeter, bir sunucu,
nesne veya ağ grubu üzerindeki ağır yükü simüle etmek veya birçok yük türü altında bir web uygulamasının genel performansını analiz etmek için kullanılır, veri
tabanları, mesaj odaklı ara yazılımlar ve internet protokolleri gibi birçok farklı uygulamanın testlerini yükleme ve gerçekleştirme yeteneğini analiz edebilir. Örnek bir
JMeter test raporu Şekil 8.3'te verilmiştir (Jmeter, 2020).

Şekil 8.3. Örnek Bir JMeter Test Raporu

Katalon Studio (veya Katalon): Kullanıcıların platformlar arası otomatik testler oluşturmasına yardımcı olmak için kullanılır. 2015 yılında geliştirilen araç, tüm
işletim sistemleri, tarayıcılar ve cihazlarla uyumludur. Birçok web tabanlı otomatik araçtan farklı olarak Katalon'un hem açık kaynaklı (Katalon Studio) hem de
lisanslı (Katalon Studio Enterprise ve Katalon Runtime Engine) sürümleri vardır. Örnek bir Katalon Studio test raporu Şekil 8.4'te verilmiştir (Katalon, 2020).

74
Şekil 8.4. Örnek Bir Katalon Studio Test Raporu

LoadRunner: 1993 yılında MicroFocus tarafından sunulan LoadRunner, 50’den fazla teknoloji ve uygulama ortamı için basitleştirilmiş ve hızlı performans testleri
sunmaktadır. Bugüne kadar 40’tan fazla sürümü sunulan LoadRunner, herhangi bir uygulamaya gerçek iş yüklerini uygulamak ve son kullanıcı yanıt sürelerini
yakalamak için yüzlerce veya binlerce eşzamanlı sanal kullanıcıyı kullanarak test yapabilir. Örnek bir LoadRunner test raporu Şekil 8.5’te verilmiştir (Microfocus,
2020).

Şekil 8.5. Örnek Bir Loadrunner Test Raporu

HP Birleşik İşlevsel Test (HP UFT) olarak da bilinen QTP (QuickTest Professional):  Kullanıcılara web, mobil ve masaüstü platformlarında otomatik
uygulamalar yürütmek ve oluşturmak için etkileşimli araçlar sağlayan bir araçtır. QTP 2001 yılında geliştirilmiştir ve bugüne kadar birçok versiyonu üretilmiştir.
Aracın özellikleri; veriye dayalı test, karmaşık nesneler, genişletilebilirlik, otomatik dokümantasyon, hata işleme mekanizması ve benzersiz işleme mekanizması
şeklindedir. Örnek bir QTP test raporu Şekil 8.6’da verilmiştir (Qtp, 2020).

Şekil 8.6. Örnek Bir Qtp Test Raporu

Ranorex Studio: Tüm mobil, masaüstü ve web uygulamalarını kapsayan web uygulaması test otomasyon araçlarından biridir. Özelliklerden bazıları kayıt ve
oynatma, GUI tanıma, yeniden kullanılabilir test kodu ve çeşitli araçlarla entegrasyondur. Araç, sağlam nesne tanıma sağlar, web çerçevelerini ve web teknolojilerini
destekler, testçilerin web öğesi tanımlama olarak adlandırdığı şeyi gerçekleştirir, mevcut çözümlerle bütünleşir ve çeşitli faydalı özelliklere sahiptir. Örnek bir Ranorex
Studio test raporu Şekil 8.7’de verilmiştir (Ranorex, 2020).

75
Şekil 8.7. Örnek Bir Ranorex Studio Test Raporu

Sahi Pro (Sahi): Testçilerin karşılaştığı günlük sorunları çözmek için tasarlanmış bir araçtır. Sahi, tasarımı ve işlevselliği açısından benzersiz bir şekilde testçi
merkezlidir. Masaüstü, mobil ve web testi için tüm işletim sistemlerinde tüm tarayıcılarda kullanılabilir. Diğer birçok araçla entegre edilebilirken, farklı test türleri için
verimli bir araçtır. Örnek bir Sahi Pro test raporu Şekil 8.8’de verilmiştir (Sahi Pro, 2020).

Şekil 8.8. Örnek Bir Sahi Pro Test Raporu

Selenium: Web tabanlı otomatik araçlar akla gelen ilk araç olan Selenium, ilk olarak 2004 yılında geliştirilmiştir. Selenium, farklı türde yazılım testlerini destekleyen
popüler bir web uygulama aracıdır. Web uygulamalarının geliştirilmesine yardımcı olmada belirli rollere sahip çeşitli bileşenlerden oluşan karmaşık bir araçtır.
Selenium, çeşitli platformları, işletim sistemlerini, programlama dillerini ve tarayıcıları desteklediği için yaygın olarak kullanılan web tabanlı otomatik bir araçtır. Aracın
en önemli dezavantajlarından biri yerel bir raporlama olanağı sunmamasıdır. Örnek bir Selenium test raporu Şekil 8.9’da verilmiştir (Selenium, 2020).

Şekil 8.9. Örnek Bir Selenium Test Raporu

Telerik Test Studio: Farklı uygulama türleri için Windows tabanlı otomatik bir araçtır. Kullanıcılara hızlı ve kolay bir şekilde otomatik testler oluşturma, bunları iş
akışını takip ederek Sürekli Entegrasyon/Sürekli Teslimat ortamına entegre etme, hataları daha erken bulma ve daha kaliteli bir yazılım ürünü gönderme yetkisi verir.
Fonksiyonel test, performans testi, yük testi ve mobil test gibi çeşitli test türlerini gerçekleştirebilir. Örnek bir Telerik Test Studio test raporu Şekil 8.10’da verilmiştir
(Telerik Test Studio, 2020).

Şekil 8.10. Örnek Bir Telerik Test Studio Test Raporu

76
TestComplete: 1999 yılında geliştirilmiş işlevsel bir otomatik test platformudur. TestComplete, mobil, web ve masaüstü testi olmak üzere üç önemli modül içerir ve
modüllerin her biri, otomatik testler oluşturma işlevselliğini içerir. TestComplete, yetenekli bir destek ekibine sahip kolay, güvenilir ve hızlı bir araçtır. Örnek bir
TestComplete test raporu Şekil 8.11’de verilmiştir (TestComplete, 2020).

Şekil 8.11. Örnek Bir TestComplete Test Raporu

TestIO: Genellikle kalabalık testler için kullanılan bir web test aracıdır. Esnek testlerle kalite güvencesi darboğazlarını ortadan kaldırabilir, tek bir kapsama alanını
yüzlerce platforma ve cihaza genişletebilir ve profesyonel test uzmanlarından birinin ürün üzerinde tarafsız bir bakış açısına sahip olmasını sağlayabilir. Cihazlar,
tarayıcılar ve platformlarla yüksek uyumluluğa sahiptir. Örnek bir TestIO test raporu Şekil 8.12'de verilmiştir (TestIO, 2020).

Şekil 8.12. Örnek Bir TestIO Test Raporu

TestingWhiz: Mobil test, regresyon testi, veriye dayalı test, veri tabanı testi, büyük patlama testi vb. gibi çeşitli test türlerini destekler. TestingWhiz’in, hem büyük
hem de küçük uygulamalar için kullanımı çok kolaydır. Test ederken akıllı ve tekrar kullanılabilir kayıt tekniklerine sahiptir. Ayrıca, araç tarafından uygulanan test
komutları, test iş yüklerini optimize etmek ve otomasyon projelerinin verimliliğini artırmak için kodlama becerisine sahip olmayan kullanıcılar tarafından bile
kullanılabilir. Ancak, araç ücretsiz olarak sağlanmaz; abonelik gerektirir, istek üzerine hazırdır ve bir web uygulamasını baştan sona tarayamaz. Örnek bir
TestingWhiz test raporu Şekil 8.13'te verilmiştir (TestingWhiz, 2020).

Şekil 8.13. Örnek Bir TestingWhiz Test Raporu

Webload: 1997 yılında geliştirilen Webload, özellikle yük/performans testi için kullanılan test araçlarından biridir. Webload'ın birinci ve ikinci sürümleri arasında uzun
bir süre vardır. 2010 yılında ikinci ve üçüncü versiyonlar sunulmuş ve sonrasında sürekli olarak yeni versiyonlar geliştirilmiştir. Webload birçok entegrasyon aracını,
tarayıcıyı, platformu ve ayrıca bulut uygulamalarını destekler. Webload ile, bir test cihazı, tek bir yük yanıt gereksinimini karşılama yolunda durabilecek sorunları ve
darboğazları tam olarak belirleyebilir. Örnek bir Webload test raporu Şekil 8.14’te verilmiştir (Radview, 2020).

Şekil 8.14. Örnek Bir Webload Test Raporu

77
Bu kısımda yukarıda açıklanan web testi otomasyon araçları, genel özellikleri, gereksinimler, teknik uyumluluklar, test özellikleri ve teknik destek açısından
karşılaştırılmıştır.

8.2.1. Genel Özelliklere Göre Karşılaştırma

Genel Özellikler, bir aracın ilk akla gelen özelliklerini ifade eder. Bu özellikler, “Testin Stili”, “Açık Kaynaklı/Lisanslı”, “Maliyet” ve “Kararlı Sürüm”dür. Test stili,
otomasyon yazılımının testi nasıl yaptığını açıklar. API Testi, Masaüstü Testi, Mobil Test, Web Testi ve bunların kombinasyonları şeklinde değerler alabilir. Açık
Kaynaklı/Lisanslı, aracın bir lisansına sahip olup olmadığını gösterir. Maliyet, aracın fiyatını ifade eden sayısal bir değerdir. Araçların ücretleri, günlük, aylık veya tek
seferlik satın alma gibi farklı şekillerde belirtilebilir. Kararlı sürüm, bir aracın en son güncellenen sürümü anlamına gelir. Yazılım mühendisliği sürekli gelişen bir alan
olduğundan yazılımlar zaman içinde değişip değişmekte ve ayrıca diğer yazılımlar için farklı ihtiyaçlar ortaya çıkabilmektedir. Bu açıdan bir aracın güncellenmesi
gerekmektedir. Bu karşılaştırma işlemi Tablo 8.2’de verilmiştir.

Tablo 8.2. Web Tabanlı Otomasyon Araçlarının Genel Özelliklerine Göre Karşılaştırılması

Kararlı
Adı Test Stili Açık Kaynaklı / Lisanslı Maliyet
Sürüm
Acunetix Web testi Lisanslı Müşteri ihtiyaçlarına göre -
FitNesse Web testi Açık kaynaklı Ücretsiz Nisan 2019
JMeter Mobil test, web testi Açık kaynaklı Ücretsiz Kasım 2019
Katalon Studio (Açık Katalon Studio (Ücretsiz)
kaynaklı)
Business technik destek (yıllık $2500)
Katalon API testi, masaüstü testi, mobil Katalon Studio Enterprise
Ekim 2019
Studio test, web testi (Lisanslı) Enterprise technik destek (yıllık $5500)

Katalon Runtime Engine Enterprise Premium technik destek (Müşteri ihtiyaçlarına göre
(Lisanslı) değişiklik göstermektedir)
50 sanal kullanıcı lisansı (ücretsiz)
LoadRunner Masaüstü testi,  web testi Lisanslı 2020
Daha fazlası (günlük $1,40)
Deneme sürümü (ücretsiz)

QTP (HP Runtime Engine (yıllık $2300)

Temmuz
Masaüstü testi,  web testi Lisanslı
UFT) 2019
Uft One (yıllık $3200)

Volume Pricing  (Müşteri ihtiyaçlarına göre)

Deneme sürümü (ücretsiz)

Ranorex Runtime License Floating ($890)

Masaüstü testi, mobil test, web
Lisanslı Ekim 2019
Studio testi
Premium Node-Locked ($2990)

Premium Floating ($4990)

Deneme sürümü (ücretsiz)
Masaüstü testi, mobil test, web
Sahi Pro Lisanslı -
testi
Sahi Pro (yıllık $695)
Selenium Web testi Açık kaynaklı Ücretsiz 2018
Test Studio Web & Masaüstü (yıllık $2499)
Telerik Test Masaüstü testi, mobil test, web Haziran
Lisanslı
Studio testi 2019
Test Studio Ultimate (yıllık $3499)
Deneme sürümü (ücretsiz)

TestComplete Base (Euro 5170)

Haziran
TestComplete Masaüstü testi,  web testi Lisanslı
TestComplete Pro (Euro 8023) 2019

TeamSuite Bundle(Müşteri ihtiyaçlarına göre)

TestIO Web testi Lisanslı Talebe göre belirlenmektedir -
TestingWhiz Masaüstü testi,  web testi Lisanslı Talebe göre belirlenmektedir -
Webload Web testi Lisanslı Talebe göre belirlenmektedir 2016

Tablo 8.2’de gösterildiği gibi, bazı araçlar yalnızca bir benzersiz test stiline (web testi veya masaüstü testi) sahipken, diğer bazı araçlar birçok testi (API Testi,
Masaüstü Testi, Mobil Test ve Web gibi) destekler. Bu özellik, otomasyon aracı seçiminde büyük önem taşımaktadır.
Bir aracın bir uygulamada kullanılabilmesi için o uygulamaya uygun bir yapıya sahip olması gerekir. Tabloda gösterildiği gibi, 14 araç içinde yalnızca üç araç tamamen
açık kaynaklı ve ücretsizdir. Kalan lisanslı araçların ücretleri oldukça yüksektir. Bazı araçların belirli sürümleri veya deneme sürümleri ücretsiz olsa da, profesyonel
bir sürüme mutlaka ücret ödenmektedir. Bazı araçların fiyatları günlük veya aylık olarak belirtilirken, bazı araçların veya bazı sürümlerin ücretleri müşteri taleplerine
göre özelleştirilebilmektedir. Bu da yine aracın seçimi ile ilgili önemli bir kriterdir. Bu tablo, profesyonel destek arayan şirketler, profesyonel olmayan bireysel
kullanıcılar ve farklı rollere sahip aktörler için farklı pazar araçlarının, bu aktörlerin her birinin ihtiyaçlarına göre uygun bir araç bulabileceğini belirtmektedir. Araçlar
için kararlı sürüm özellikleri incelendiğinde hepsinin sık sık güncellendiği görülmektedir ve bu açıdan tüm araçların değişen yazılım ihtiyaçlarını karşılayabildiği ifade
edilebilir.

8.2.2. Gereksinimlere Göre Karşılaştırma

Bir aracın verimli bir şekilde kullanılabilmesi için gerekli bazı özellikler bulunmaktadır. Bunlar donanım gereksinimleri (CPU ve RAM) ve kullanıcı programlama bilgisi
gereksinimi şeklindedir. “Minimum donanım gereksinimi (CPU)”, aracı kullanmak için gereken minimum CPU özelliklerini ifade eder. Bu özellikte CPU hızı ve diğer
özellikler verilmiştir. “Minimum donanım gereksinimi (RAM)”, aracı kullanmak için gereken minimum ve önerilen RAM miktarlarını ifade eder. “Kullanıcı deneyimi
gereksinimi”, aracın kullanımı için kullanıcı deneyiminin gerekli olup olmadığını belirtir. Bu karşılaştırma işlemi Tablo 8.3’te verilmiştir.

78
Tablo 8.3. Web Tabanlı Otomasyon Araçlarının Gereksinimlere Göre Karşılaştırılması

Adı Minimum donanım gereksinimi (CPU) Minimum donanım gereksinimi (RAM) Kullanıcı deneyimi gereksinimi
Acunetix 64 bitlik işlemci Minimum: 2 GB Kullanması kolay
FitNesse - - Kullanması kolay
JMeter 4 ya da daha fazla çekirdekli işlemci Minimum: 16 GB Programlama deneyimi gerektirir
1 GB (32-bit için)
Katalon Studio 1 GHz, 32-bit (x86) veya 64-bit (x64) işlemci Kullanması kolay
2 GB (64-bit için)
Minimum: 2 GB
LoadRunner 1.6 GHz Intel Core, Pentium, Xeon, AMD Programlama deneyimi gerektirir
Önerilen: 4 GB
QTP (HP UFT) 1.6 GHz Minimum: 2 GB Kullanması kolay
Ranorex Studio 2 GHz Minimum: 1 GB Kullanması kolay
Sahi Pro - Minimum: 1,5 GB Programlama deneyimi gerektirir
Selenium 4x Dual-core AMD Minimum: 4 GB Programlama deneyimi gerektirir
Minimum: 1 GB
Telerik Test Studio x86 veya x64 1 GHz Pentium Kullanması kolay
Önerilen: 2 GB
TestComplete Intel Core i5 veya i7 Minimum: 8 GB Kullanması kolay
TestIO 800 MHz Minimum: 4 GB Kullanması kolay
TestingWhiz Intel Pentium 4 Minimum: 4 GB Programlama deneyimi gerektirir
Minimum: 1 GB
Webload Pentium III 800 MHz Kullanması kolay
Önerilen: 4 GB

Tablo 8.3, web tabanlı otomatik araçların donanım ve kullanıcı deneyimi gereksinimlerine göre bir karşılaştırmasını sunar. FitNesse ve Sahi Pro araçları dışındaki tüm
araçlar için tüm bilgiler tespit edilmiştir. Bu tablodaki kriterler aracın seçimini doğrudan etkilemese de, halihazırda seçili olan aracın kullanılıp kullanılamayacağı ve
kullanılmadan önce araç için hangi gereksinimlerin karşılanması gerektiği hakkında bilgi verir. Örneğin yeni bir kullanıcının FitNesse aracı ile test sürecini başlatması
hem açık kaynak kodlu olması hem de ücretsiz olması ve kullanımı kolay olması açısından faydalı olacaktır. Ancak FitNesse yalnızca web testi yapar ve mobil testler
için kullanılamaz. Ayrıca ihtiyaç duyduğu CPU konfigürasyonu hakkında tam bir bilgi olmadığı için test edilecek donanımda bir uyumluluk sorunu olabilir. Tablo 8.3
ayrıca araçların genellikle yüksek CPU'lara ve RAM'lere ihtiyaç duyduğunu gösterir. Bu durum, araçlar çalışırken en az bir başka yazılımın daha çalışıyor olması,
çeşitli veri işlemlerinin yapılması ve yazılım üzerinde raporlar oluşturulması şeklinde ifade edilebilir.
JMeter, platformlar arası olduğu için diğer araçlardan daha yüksek bir belleğe ihtiyaç duyar; Java'yı destekleyen tüm tarayıcıları ve IDE'leri destekler; başka bir
deyişle, yüksek uyumluluğa sahiptir. Bir aracı kullanmaya karar verdikten sonra yapılacak ilk işlemlerden biri aracın gereksinimlerini sağlamaktır. Görüldüğü gibi bazı
araçların kullanımı kolay olsa da Selenium gibi bazı popüler ve sık kullanılan araçlarda kullanıcının belirli programlama bilgisine sahip olması gerekmektedir. Başka
bir deyişle, test edenlerin test senaryolarını ve test senaryolarını bilmesi ve uygulaması yeterli değildir; bu vakaları ve prosedürleri yazmaları ve gerekirse değişiklik
yapmaları gerekir.

8.2.3. Teknik Uyumluluklara Göre Karşılaştırma

Bir otomasyon aracının kullanılabilirliğini en üst düzeye çıkaran özellik, birçok proje için bir araç sağladığı için uyumluluk olarak kabul edilebilir. Bu bölümde tartışılan
özellikler aşağıda açıklanmıştır. “Dil uyumluluğu”, aracın uygulamalar üzerinde hangi programlama dillerinde test edebileceğini ifade eder. “Platform uyumluluğu”,
aracın çalışabileceği işletim sistemlerini ve diğer platformları belirler. “Tarayıcı uyumluluğu”, aracın çalışabileceği en düşük web tarayıcı seviyesini ifade eder. “IDE
uyumluluğu”, araç tarafından desteklenen IDE'leri verir.
Bu karşılaştırma işlemi Tablo 8.4’te verilmiştir.

Bu tablodaki değerler otomasyon aracının teknik özellikleri ile ilgilidir. Programlama dili uyumluluğu, temel bir seçim kriteri olan, hangi programlama dilinin yazılan
uygulamalar üzerinde test edebileceği anlamına gelir. Bazı araçlar bu konuda sadece bir dili (JavaScript, VBScript) desteklerken, bazı araçlar birçok dili
destekledikleri için (C++, C#, DelphiScript, JavaScript, Jscript, Python, VBScript vb.) kullanılma olasılığını artırmaktadır. Araç seçimini etkileyen en kritik
faktörlerden bir diğeri de platform uyumluluğudur. Bu özellik araştırılırken bazı araçların tek bir sistemde (genellikle Windows) çalıştığı, bazı araçların ise çapraz
platformlarda çalıştığı gözlemlenmiştir. Burada dikkat çekici bir nokta, araçların genellikle MAC OS işletim sisteminde çalışmamasıdır. Buna göre, bu sistemle
çalışması gereken testçiler, sadece bazı araçlar arasından seçim yapmalıdır. Burada incelenen araçlar web tabanlı araçlar olduğu için genellikle tarayıcı destek
bölümünde herhangi bir kısıtlama yoktur. Başka bir deyişle, araçlar çoğunlukla tüm tarayıcılarda çalışır. Ancak QTP gibi bazı araçlarda tarayıcıların belirli bir
sürümden daha yüksek olması beklenmektedir. Bazı otomasyon araçları var olan IDE'leri kullanırken bazılarının kendi özgün IDE'lerini oluşturduğu görülmektedir.
Buradaki sınırlama, mevcut IDE'leri kullanan araçları kullanırken uyumluluk sorunlarını dikkate almaktır. Örneğin JMeter ve Selenium gibi araçlarda kullanılan
IDE'nin Java desteğine sahip olması beklenmektedir.

Tablo 8.4. Web Tabanlı Otomasyon Araçlarının Teknik Uyumluluklara Göre Karşılaştırılması

Adı Dil uyumluluğu Platform uyumluluğu Tarayıcı uyumluluğu IDE uyumluluğu

Acunetix CSS, HTML, Java, JavaScript, .NET Web tabanlı ortamlar Herhangi bir tarayıcı -
Eclipse’te Maven
FitNesse C++, C#, Delphi, Python, Ruby Çapraz platform Herhangi bir tarayıcı
veya  Ivy
Java’yi destekleyen
JMeter - Çapraz platform Herhangi bir tarayıcı
tüm IDE’ler
Katalon Windows 7, 8, 10, MacOS 10.11+, Linux (Ubuntu- Java, Android SDK,
Java/Groovy Herhangi bir tarayıcı
Studio tabanlı) Web sürücüler
Windows 7 (SP1) 32/64 bit, 8 64 bit,  Windows
LoadRunner C#, Java, JavaScript, VB, VBScript Herhangi bir tarayıcı -
Server 2012 64 bit, R2 (SP1) 64 bit
QTP (HP IE 6,7,8,10, Firefox 3.0 and
VBscript Windows 7 32/64 bits, Windows 7 (SP1) 32/64 bits Kendi IDEsi
UFT) later, Google Chrome
Ranorex Windows 2000,  XP, Vista, 7, Windows Server
Belli bir dil seçeneği yoktur Herhangi bir tarayıcı Kendi IDEsi
Studio 2003, 2008
Sahi Pro JavaScript Çapraz platform Herhangi bir tarayıcı Selenium IDE
79
 C#, Java, JavaScript, Perl, PHP, Java’yi destekleyen
Selenium Windows, macOS X, Linux Herhangi bir tarayıcı
Python, R, Ruby tüm IDE’ler
Internet Explorer, Microsoft
Windows 7, 8, 10 Edge,
Telerik Test AJAX, Angular, HTML, MVC,
Visual Studio IDE
Studio Silverlight, WPF
Windows Server 2008, 2012 Firefox, Google Chrome,
Opera
C++, C#, DelphiScript, JavaScript, Windows 7 (SP1), 8, 8.1, 10, Windows Server
TestComplete IE, Firefox, Google Chrome Kendi IDEsi
Jscript, Python, VBScript 2008 R2
TestIO - Web tabanlı ortamlar Herhangi bir tarayıcı -
TestingWhiz - Windows Herhangi bir tarayıcı Kendi IDEsi
Webload JavaScript Windows, Linux Herhangi bir tarayıcı Kendi IDEsi

8.2.4. Test Özelliklerine Göre Karşılaştırma

Bu kısımda ele alınan özellikler otomasyon araçlarının gerçekleştirdikleri testler ile ilgili araçlardır. “Diğer araçlarla entegrasyon”, aracın birlikte çalışabileceği diğer
araçları ifade eder. “Test türü”, aracın gerçekleştirdiği testleri tanımlar. Her bir otomasyon aracının uzmanlaştığı alanlar bulunmaktadır. Bazı araçlar, penetrasyon ve
güvenlik açığı gibi güvenliğe odaklanırken, diğerleri yük, stres ve performans gibi testlerle ilgilenir. Bu özellik genellikle bir test aracının en iyi hangi testleri
gerçekleştirebileceğini gösterir. “Test raporu, test sonuçlarının nasıl raporlanacağını ifade eder. Başka bir deyişle, elde edilen raporların formatı olarak tanımlanabilir.
Bu karşılaştırma işlemi Tablo 8.5’te verilmiştir.

Tablo 8.5. Web Tabanlı Otomasyon Araçlarının Test Özelliklerine Göre Karşılaştırılması

Adı Diğer araçlarla entegrasyon Test türü Test raporu

Acunetix GitHub, FortiWeb, Imperva, Jenkins, Jira, SecureSphere Penetrasyon, Güvenlik Açığı, Web HTML, PDF
FitNesse - Kabul -
JMeter BlazeMeter, Dynatrace, Jenkins, Meliora, TestLab, Visual Studio Yük, Performans, Stres CSV, HTML
Katalon Azure DevOps, Bamboo, CircleCI, Jenkins, Jira, qTest,
API, Mobil, Web CSV, HTML, PDF
Studio TestLink, TestRail, TeamCity, Travis CI, Microsoft Teams
LoadRunner - Yük, Performans -
QTP (HP CollabNet, iRise, Jira, Kovair, TeamForge, TestComplete,
API, GUI HTML
UFT) ServiceNow
Ranorex Veriye Dayalı, GUI, Anahtar Kelimeye Dayalı,
Azure DevOps, Bamboo, Hudson, Jenkins, Team City HTML, XML
Studio Kalite Güvencesi, Regresyon
Sahi Pro Bamboo, Jenkins, Selenium Agile, Fonksiyonalite, Yük, Performans XSL
Veriye Dayalı, GUI, Anahtar Kelime,
Selenium Birçok fiyat veya ücretsiz araçla entegre edilebilir Rapor yok
Regresyon, Birim, Web
Telerik Test
Bamboo, Jenkins, Jira, TeamCity, TFS Yük, Fonksiyonalite, Performans Junit, XML
Studio
Bamboo, Jenkins, Jira, QAComplete, Selenium, Team Kapsam, Veriye Dayalı, GUI, Anahtar Kelime,
TestComplete HTML, Junit, PDF, XML
Foundation Server Yük, Mobil, Regresyon, Birim, Web
TestIO GitHub, Jira, Redmine, Trello Beta, Keşif, Regresyon, Kullanılabilirlik CSV, XLS
Çapraz Tarayıcı, Veritabanı, Veriye Dayalı,
TestingWhiz Bamboo, Jenkins CSV, XLS
Mobil, Regresyon, Web
CSV, DOC, HTML, Junit, ODT,
Webload Amazon Web Services, Jenkins,  Selenium Kapasite, Yük, Gerilme
PDF, RTF, XLS, XLSX

Tablo 8.5'e bakıldığında FitNesse ve Load Runner için diğer entegresyon bilgileri desteğinin bulunmadığı görülmektedir. Diğer araçlara bakıldığında genellikle
Bamboo, Jenkins, Jira'nın hepsinde ortak olduğu görülür; bunların dışında birçok araçla entegre edilebildiği görülmektedir. Burada dikkat edilmesi gereken
hususlardan biri SAHI, TestComplete ve Webload aracının Selenium ile birleştirilebilmesidir. Bunların dışında Selenium, bu araçlar dışında ücretsiz veya lisanslı
birçok farklı araçla entegre çalışabilmesiyle bu özelliğikte öne çıkmaktadır. Bir test aracı seçiminde belki de en kritik faktör, gerçekleştirebileceği test türleridir.
Bilindiği gibi her araç her türlü testi yapamaz. Bazı araçlar güvenliğe odaklanırken, bazı araçlar performans topları ve türevlerine odaklanır ve bazı araçlar farklı test
türleriyle ilgilenir. Tablo 8.5'ten Acunetix'in güvenlik testleri yaptığı, FitNesse’in kabul testleri gerçekleştirdiği ve diğer araçlar farklı türde testler yapıldığı
görülmektedir. Buna göre uygulama üzerinde yapılacak test tipine göre bir araç seçilmesi esastır.

Testlerden elde edilen raporlar, araç seçimi için doğrudan bir kriter olmayıp, aracın verimli kullanılmasına yardımcı olabilecek bir özelliktir. Test raporu hakkında
bilgisi olmayan bazı araçlar dışında tüm araçların CSV, HTML, XML, PDF gibi standart formatları desteklediği;  Telerik, TestComplete ve Webload'ın da Junit
formatını desteklediği ve Webload'ın test raporu konusunda oldukça fazla seçeneğe sahip olduğu görülmektedir. Bu özelliğin şaşırtıcı sonuçlarından biri de web
tabanlı otomasyon araçları denilince birçok kişinin aklına gelen ilk araç olan Selenium'da rapor desteğinin olmamasıdır. Birçok açıdan diğer araçların önüne geçen
Selenium, bu özelliğinde en çok geride kalan araç haline gelmektedir.

8.2.5. Teknik Desteğe Göre Karşılaştırma

Bu alanda incelenen “Müşteri desteği”, aracın kullanan müşterilere destek verip vermediğini ifade eder. “Belge başlıkları”, araçların resmî web sitesindeki
dokümantasyon başlıklarını ifade eder. Bu özellik, birinin otomasyon aracının web sitesinde hangi bilgileri kolayca bulabileceğini anlatmaya yardımcı olur.
“Makaleler”, araçların resmî web sitesindeki çeşitli makaleleri ifade eder. Bir formatı olmamasına rağmen iki kategoride değerlendirilir: sınırlı sayıda makale ve çok
sayıda iyi organize edilmiş makale. “Bloglar”, aracın web sitesinde bir blog olup olmadığını gösterir. Belirli bir formatı yoktur; forumun varlığı/yokluğu ve özellikleri
hakkında genel bilgi verir. “Teknik personel”, araçları destekleyen bir teknik personelin olup olmadığı konusunda mevcut bilgileri sağlar. “Hata takibi” araçta hata
takip özelliğinin olup olmadığını ve varsa bu özelliğin hangi işlemleri yaptığını ifade eder. Bu karşılaştırma işlemi Tablo 8.6’da verilmiştir.

Tablo 8.6. Web Tabanlı Otomasyon Araçlarının Teknik Özelliklere Göre Karşılaştırılması

Adı Müşteri Belge başlıkları Makaleler Bloglar Teknik Hata takibi

80
 desteği personel
Vaka Çalışmaları, Destek, Videolar, Web Güvenlik Açıkları, Web Sınırlı Aktif bir 7/24 çevrimiçi Tanımlanan güvenlik
Acunetix İyi bir destek
Seminerleri sayıda blog destek açıklarını atama
Sınırlı
FitNesse - Özellikler, İndir, Eklentiler, Kullanım Kılavuzu Blog yok Hata izleme yok
sayıda
Ücretsiz Başlarken, Kullanım Kılavuzu, En İyi Uygulamalar, Bileşen Aktif bir
JMeter - - Hata raporu oluşturma
Topluluk Referansı blog
Ürünler, Fiyatlandırma, Destek
Katalon Sınırlı Aktif bir 7/24 çevrimiçi
İyi bir destek Şirket, Şimdi İndirin, Hata izleme yok
Studio sayıda blog destek
Oturum aç
Kaynaklar, Fiyatlandırma, Bize Ulaşın, Eğitim Merkezi, Ücretsiz
LoadRunner Sınırlı - Blog yok - Hata izleme yok
deneme
QTP (HP Aktif bir 7/24 çevrimiçi
İyi bir destek İyi organize edilmiş - altyazılı önemli belgeler Çok sayıda Hata izleme yok
UFT) blog destek
Ranorex Aktif bir 7/24 çevrimiçi
İyi bir destek Ürünler, Çözümler, Web Seminerleri, Destek, Şirket Çok sayıda Hata izleme yok
Studio blog destek
Ev, Özellikler, Hizmetler,
Sınırlı
Sahi Pro Sınırlı Blog yok - Hata izleme yok
sayıda
Fiyatlandırma, Ücretsiz Deneme
Profesyonel Aktif bir
Selenium Hakkında, İndirilenler, Projeler, Dokümantasyon, Destek, Blog - - Yeni hataları belirleme
destek yok blog
Demolar, Fiyatlandırma, Bloglar,
Telerik Test Sınırlı Aktif bir
İyi bir destek - Yeni hataları belirleme
Studio sayıda blog
Belgeler ve Destek, Arama
Özellikler, Kullanım Durumları, Entegrasyonlar, Kaynaklar Genel bir 7/24 çevrimiçi
TestComplete İyi bir destek Çok sayıda Hata izleme yok
Fiyatlandırma, Ücretsiz Deneme blog destek
Sınırlı Aktif bir 7/24 çevrimiçi
TestIO İyi bir destek Ürün, Test Çözümleri, Müşteriler, Fiyatlandırma, Kaynaklar Hata izleme yok
sayıda blog destek
Aktif bir 7/24 çevrimiçi
TestingWhiz İyi bir destek Çözümler, Özellikler, Entegrasyonlar, Fiyatlandırma, Kaynaklar Çok sayıda Hata izleme yok
blog destek
Genel bir 7/24 çevrimiçi
Webload İyi bir destek Çözümler, Özellikler, Entegrasyonlar, Fiyatlandırma, Kaynaklar Çok sayıda Hata izleme yok
blog destek

Bu tablonun özelliklerinin dezavantajlı yanı sayısal veya deterministik bir değere sahip olmaması ve sözlü ifadelerle tablolaştırılmaya çalışılmasıdır. Bu nedenle diğer
tablolara göre biraz daha özneldir. Tablo incelendiğinde JMeter için ücretsiz topluluklar şeklinde bazı araç ve desteklerin sınırlı müşteri desteği olduğu, FitNesse için
müşteri destek bilgisi almanın mümkün olmadığı ve Selenium için profesyonel bir desteğin bulunmadığı görülmektedir. Test araçları hakkında getirilebilecek en detaylı
bilgilerden biri web siteleri olduğu için web sitelerinin dokümantasyon başlıkları da aracın desteği hakkında bilgi vermektedir. Genel olarak birçok aracın detaylı
menü ve alt başlıklara sahip olduğu, bazı araçların sadece ana başlıklara sahip olduğu görülmekte ancak sonuç olarak her araçta yeterli dokümantasyon bilgisinin
olduğu anlaşılmaktadır.

Bu tabloda incelenen bir diğer özellik de bir aracın web sitesinde blog olup olmadığıdır. Araçların hem üreticilerinin hem de kullanıcılarının deneyimlerini paylaştığı bir
alan olan blog, bazen etkili bir problem çözme yöntemi olabilir. FitNesse, LoadRunner ve SAHI dışındaki tüm araçlarda blog sisteminin olduğu görülmektedir. Bir
test otomasyon aracında olarak teknik personel desteği de büyük önem taşımaktadır. Özellikle test otomasyonu sürecinde deneyimli olmayan kullanıcılar için aktif
teknik desteğin olması kullanıcı açısından kolaylaştırıcı bir unsurdur. Acunetix, Katalon Studio, QTP (HP UFT), Ranorex, TestComplete, TestIO, TestingWhiz ve
Webload araçlarında çevrimiçi 7/24 teknik destek sağlanmaktadır. Bu teknik destek, telefon, e-posta, web sitesi veya farklı şekillerde sağlanabilir. Bu tabloda
incelenen son özellik ve bu çalışma hata takibidir. Bir araçla getirilen hataların takip edilmesi ve izlenmesi anlamına gelen bu özellik, özellikle aracın uzun süreli
kullanımında istatistiksel fayda sağlayabilecek bir özelliktir. Ancak sadece Acunetix, JMeter, Selenium ve Telerik Test Studio için hata takip özelliği bulunmaktadır.
Bu hata izleme yapılarında, tespit edilen güvenlik açıklarını ekip üyelerine iyileştirme, hata raporu oluşturma ve hata günlüklerini hızlı bir şekilde listeleme, yeni hataları
belirleme ve mevcut bir hatanın durumunu kontrol etme görevleri olarak alınmaktadır.

Otomatik yazılım testi, yazılım test sürecinin en kullanışlı ve popüler yönlerinden biridir. Otomatik yazılım test araçları, kullanıcılara test sürecini hızlı gerçekleştirme,
mümkün olduğunca çok test senaryosu deneme ve önemli veri işlemlerini gerçekleştirme gibi avantajlar sağlar. Ayrıca güvenlik, güvenlik açığı, verimlilik, performans,
yük, stres vb. gibi bazı temel yazılım ölçümlerini ölçmek için kullanılırlar. Özellikle web tabanlı uygulamalar için otomatikleştirilmiş yazılım test araçları kritik bir role
sahiptir. Günümüzde otomatik araçların sayısı ve türü gelişip genişlediğinden, uyumlu programlama dilleri, işletim sistemleri, tarayıcılar da sürekli artmakta ve yazılım
testiyle ilgilenenler için birçok seçenek sunmaktadır. Bu her ne kadar avantajlı olsa da her aracın farklı özellikleri olduğundan ve her yazılım için faydalı bir test
sağlayamayacağından doğru aracın seçilememesi dezavantaj olabilir. Bu açıdan testçi, deneyeceği uygulamayı en iyi test eden araca karar vermelidir. Bu seçim süreci
sadece yazılım özelliklerine göre değil, birçok farklı kritere göre de gerçekleşmektedir. Bu kriterler, kullanılacak uygulamanın özellikleri, finansal koşullar, teknik
destek veya başka herhangi bir şeyle ilgili olabilir. Araçlar hakkında ne kadar çok şey bilinirse, o kadar rahat en uygun olan test aracı seçilir.

Bölüm Özeti
Yazılım test otomasyonları, manuel olarak yapılması zor olan, çok zaman alacak olan testlerde, daha stabil sonuçlara ihtiyaç duyulduğunda, aynı testi birçok kez
gerçekleştirmek gerektiğinde veya yüksek miktarda veri içeren veri setleri ile test yapmak gerektiğinde oldukça sıklıkla kullanılan test araçlarıdır. Yazılım test
otomasyonları kullanmak bahsi geçen durumlarda testi hızlandırabilir, daha stabil sonuçlara sahip olan testler elde etmeyi sağlayabilir ve benzeri başka faydalar
oluşturabilir. Ancak piyasada birçok yazılım test otomasyonu bulunmaktadır ve her birinin sahip olduğu özellikler birbirinden farklılıklar göstermektedir. Bu sebeple
her amaç için her yazılım test otomasyonu kullanılamaz ve doğru amaç için doğru yazılım test otomasyonu seçmek gereklidir. Doğru bir seçim yapılmadığında yazılım
test otomasyonu kullanmak yarardan çok zarar getirebilir ya da belki ücretsiz olan bir otomasyon ile yapılabilecek bir işlem binlerce dolara yapılmış olabilir. Bu
sebeple yazılım test otomasyonlarının iyi bir şekilde seçilmesi gerekmektedir. Literatürde bu araçları bibirleri ile farklı kriterlere göre karşılaştıran birçok çalışma
mevcuttur, bu çalışmaların tamamında hiçbir test yazılım otomasyonunun diğerlerinden kesin olarak iyi olmadığı, farklı kriterlerde en başarılı yazılım test
otomasyonunun değişkenlik gösterdiği, bu sebeple bir yazılım test otomasyonu seçerken bulunulan duruma ve incelenecek kriterlere göre hareket edilmesi gerektiği
ifade edilmiştir.
Bu bölümde özellikle web yazılımlarının test edilmesi için kullanılan yazılım test otomasyonları ele alınmış ve karşılaştırılmıştır. Bu bölümde ele alınan yazılım test
otomasyonları Acunetix, FitNesse, JMeter, Katalon Studio, LoadRunner, QTP (HP UFT), Ranorex Studio, Sahi Pro, Selenium, Telerik Test Studio, TestComplete,
TestIO, TestingWhiz ve Webload’dır. Bu yazılım test otomasyonları aşağıdaki kriterlere göre karşılaştırılmıştır.
81
Genel Özelliklere Göre

 Test Stili 

 Açık Kaynaklı/Lisanslı 

 Maliyet 

 Kararlı Sürüm

Gereksinimlere Göre

 Minimum donanım gereksinimi (CPU) 

 Minimum donanım gereksinimi (RAM) 

 Kullanıcı deneyimi gereksinimi

Teknik Uyumluluklara Göre

 Dil uyumluluğu 

 Platform uyumluluğu 

 Tarayıcı uyumluluğu 

 IDE uyumluluğu

Test Özelliklerine Göre

 Diğer araçlarla entegrasyon 

 Test türü 

 Test raporu

Teknik Desteğe Göre

 Müşteri desteği 

 Belge başlıkları 

 Makaleler 

 Bloglar 

 Teknik personel 

 Hata takibi

Genel Özellikler, bir aracın ilk akla gelen özelliklerini ifade eder. Bu özellikler, “Testin Stili”, “Açık Kaynaklı/Lisanslı”, “Maliyet” ve “Kararlı Sürüm”dür. Test stili”,
otomasyon yazılımının testi nasıl yaptığını açıklar. API Testi, Masaüstü Testi, Mobil Test, Web Testi ve bunların kombinasyonları şeklinde değerler alabilir. “Açık
Kaynaklı/Lisanslı”, aracın bir lisansına sahip olup olmadığını gösterir.  “Maliyet”, aracın fiyatını ifade eden sayısal bir değerdir. Aracıların ücretleri, günlük, aylık veya
tek seferlik satın alma gibi farklı şekillerde belirtilebilir. “Kararlı sürüm”, bir aracın en son güncellenen sürümü anlamına gelir.

Bir aracın verimli bir şekilde kullanılabilmesi için gerekli bazı özellikler bulunmaktadır.
Bunlar donanım gereksinimleri (CPU ve RAM) ve kullanıcı programlama bilgisi gereksinimi şeklindedir. “Minimum donanım gereksinimi (CPU)”, aracı kullanmak
için gereken minimum CPU özelliklerini ifade eder. “Minimum donanım gereksinimi (RAM)”, aracı kullanmak için gereken minimum ve önerilen RAM miktarlarını
ifade eder. “Kullanıcı deneyimi gereksinimi”, aracın kullanımı için kullanıcı deneyiminin gerekli olup olmadığını belirtir.

Bir otomasyon aracının kullanılabilirliğini en üst düzeye çıkaran özellik, birçok proje için bir araç sağladığı için uyumluluk olarak kabul edilebilir. “Dil uyumluluğu”,
aracın uygulamalar üzerinde hangi programlama dillerinde test edebileceğini ifade eder. “Platform uyumluluğu”, aracın çalışabileceği işletim sistemlerini ve diğer
platformları belirler. “Tarayıcı uyumluluğu”, aracın çalışabileceği en düşük web tarayıcı seviyesini ifade eder. “IDE uyumluluğu”, araç tarafından desteklenen IDE'leri
verir. “Diğer araçlarla entegrasyon”, aracın birlikte çalışabileceği diğer araçları ifade eder. “Test türü”, aracın gerçekleştirdiği testleri tanımlar. “Test raporu”, test
sonuçlarının nasıl raporlanacağını ifade eder. “Müşteri desteği”, aracın kullanan müşterilere destek verip vermediğini ifade eder. “Belge başlıkları”, araçların resmî
web sitesindeki dokümantasyon başlıklarını ifade eder.  “Makaleler”, araçların resmî web sitesindeki çeşitli makaleleri, “Bloglar”, aracın web sitesinde bir blog olup
olmadığını gösterir. “Teknik personel”, araçları destekleyen bir teknik personelin olup olmadığı konusunda mevcut bilgileri sağlar. “Hata takibi” araçta hata takip
özelliğinin olup olmadığını ve varsa bu özelliğin hangi işlemleri yaptığını ifade eder.

Kaynakça

J. Masso, F.J. Pino, C. Pardo, F. García, M. Piattini, Risk management in the software life cycle: A systematic literature review, Computer Standards and
Interfaces. 71 (2020), 103431.

A. Bertolino, Software testing research: Achievements, challenges, dreams. Future of Software Engineering Conference, 2007.

S. Kundu, Web Testing: Tool, Challenges and Methods, International Journal of Computer Science. 9 (2012)  481–486.

A. Hedayati, M. Ebrahimzadeh, A. A. Sori, Investigating into Automated Test Patterns in Erratic Tests by Considering Complex Objects, International Journal of
Information Technology and Computer Science. 7 (2015), 54–59.

B. Falah,  M. Akour, N. El Marchoum, Testing patterns in action: Designing a test pattern-based suite, International Review on Computers and Software. 10
(2015) 489–494.

S. Elbaum, S. Karre, G. Rothermel, Improving web application testing with user session data, International Conference on Software Engineering, 2003.
82
M. Monier, M. M. El-mahdy, Evaluation of automated web testing tools, International Journal of Computer Applications Technology and Research. 4 (2015) 405–
408.

M. Catelani, L. Ciani, V. L.Scarano, A. Bacioccola, Software automated testing: A solution to maximize the test plan coverage and to increase software reliability
and quality in use, Computer Standards and Interfaces, 33 (2011) 152–158.

V. Rufus, Angular JS Web Application Development Blueprints, Packt Publishing, ISBN: 1783285613, 2014.

R. Angmo, M. Sharma, Performance evaluation of web based automation testing tools. International Conference - Confluence The Next Generation Information
Technology Summit (Confluence), 2014.

G. A. Lucca, A. R. Fasolino, Testing Web-based applications: The state of the art and future trends,  Information and Software Technology. 48 (2006) 1172–
1186.

N. Gogna, Study of Browser Based Automated Test Tools WATIR and Selenium, International Journal of Information and Education Technology. 4 (2014) 336–
339.

M. Sharma, R. Angmo, Web based Automation Testing and Tool, International Journal of Computer Science and Information Technology. 5 (2014) 908–912.

Y. F. Li, P. K. Das, D. L. Dowe, Two decades of Web application testing – A survey of recent advances. Journal of Information Systems. 43 (2014) 20–54.

https://www.acunetix.com, [Erişim Tarihi: Nisan 2020]

http://docs.fitnesse.org/FrontPage, [Erişim Tarihi: Nisan 2020]

https://jmeter.apache.org, [Erişim Tarihi: Nisan 2020]

https://www.katalon.com,  [Erişim Tarihi: Nisan 2020]

https://www.microfocus.com/en-us/products/loadrunner-professional/overview, [Erişim Tarihi: Mayıs 2020]

https://www.tutorialspoint.com/qtp, [Erişim Tarihi: Mayıs 2020]

https://www.ranorex.com, [Erişim Tarihi: Mayıs 2020]

https://sahipro.com, [Erişim Tarihi: Mayıs 2020]

https://www.selenium.dev, [Erişim Tarihi: Mayıs 2020]

https://www.telerik.com/teststudio, [Erişim Tarihi: Mayıs 2020]

https://smartbear.com/product/testcomplete/overview, [Erişim Tarihi: Mayıs 2020]

https://test.io, [Erişim Tarihi: Mayıs 2020]

https://www.testing-whiz.com,  [Erişim Tarihi: Mayıs 2020]

https://www.radview.com, [Erişim Tarihi: Mayıs 2020]

Ünite Soruları

Soru-1 :

Bir yazılım test otomasyonunun Windows sistemi üzerinde çalışıp, Linux sistemi üzerinde çalışmıyor olması hangi kategoride incelenen bir
durumdur?

(•) - Dil uyumluluğu

(•) - Platform uyumluluğu

(•) - Test uyumluluğu

(•) - Tarayıcı uyumluluğu

(•) - IDE uyumluluğu

Cevap-1 :

Platform uyumluluğu

Soru-2 :

Bir yazılım test otomasyonu ile gerçekleştirilen bir yazılımın sonucunda önceki testlere ait bir istatistikî bilgi alınamıyorsa bu durumda bu yazılım
testinde aşağıdakilerden hangisi eksiktir?

(•) - Makaleler

(•) - Teknik destek

83
(•) - Test raporu

(•) - Teknik personel

(•) - Hata takibi

Cevap-2 :

Test raporu

Soru-3 :

“Sen henüz programlama yapmayı bilmiyorsun. Bu sebeple …………. yazılım test otomasyonunu kullanamazsın.” diyen bir kişinin cümlesindeki
boşluğa aşağıdaki yazılım test otomasyonlarından hangisi getirilemez?

(•) - LoadRunner

(•) - Selenium

(•) - Acunetix

(•) - Sahi Pro

(•) - JMeter

Cevap-3 :

Acunetix

Soru-4 :

Otomasyon testleri ve manuel testlerin hıza göre karşılaştırmasında aşağıdakilerden hangisi söylenebilir?

(•) - Genellikle otomasyon testleri daha hızlıdır.

(•) - Genellikle manuel testler daha hızlıdır.

(•) - Otomasyon testlerinin uygulanması yavaş, sonuç alınması hızlıdır.

(•) - Manuel testlerin uygulanması yavaş, sonuç alınması hızlıdır.

(•) - Herhangi bir yorum yapılamaz.

Cevap-4 :

Genellikle otomasyon testleri daha hızlıdır.

Soru-5 :

Bir yazılım test otomasyonu genellikle yazılımın verimliliği ile ilgileniyorsa aşağıdaki testlerden hangisini yapması beklenmez?

(•) - Performans testi

(•) - Yük testi

(•) - Stres testi

(•) - Germe testi

(•) - Penetrasyon testi

Cevap-5 :

Penetrasyon testi

Soru-6 :

Bir yazılım test otomasyonunun açık kaynaklı olup olmaması aşağıdaki özelliklerinden hangisini doğrudan etkiler?

(•) - Uyumluluk

(•) - Destek

(•) - Gereksinim

(•) - Sürüm
84
(•) - Maliyet

Cevap-6 :

Uyumluluk

Soru-7 :

Bir yazılım geliştirilmeye devam edildikçe yapılan bir yanlışın olup olmadığını belirleyen yazılım test otomasyonlarında aşağıdaki özelliklerin hangisi
bulunmaktadır?

(•) - Test raporu

(•) - Hata takibi

(•) - Entegrasyon

(•) - Tarayıcı uyumluluğu

(•) - Teknik destek

Cevap-7 :

Hata takibi

Soru-8 :

Bir yazılım test otomasyonu seçilirken aşağıdakilerden hangisi ile uyumluluğuna bakılmaz?

(•) - Programlama dilleri

(•) - Tarayıcılar

(•) - Platformlar

(•) - IDE’ler

(•) - Test uzmanları

Cevap-8 :

Test uzmanları

Soru-9 :

Bir yazılım test otomasyonunun donanım gereksinimleri genellikle aşağıdakilerden hangileri ile ölçülür?

(•) - CPU ve ROM

(•) - RAM ve HDD

(•) - CPU ve HDD

(•) - CPU ve RAM

(•) - ROM ve HDD

Cevap-9 :

CPU ve RAM

85
9. YAZILIM KALİTESİ
Giriş
Kalite en genel tanımıyla bir ürünün ihtiyaç ve gereksinimlere uyumluluğunun ölçülmesidir. Bu ürün elle tutulur, gözle görülür ve doğrudan ölçümleri
gerçekleştirilebilecek bir ürün olduğunda kalite ile ilgili hesapları yapmak nispeten kolaydır ancak yazılım gibi elle tutulmayan, gözle görülmeyen bir üründen
bahsedildiğinde hesaplamaları gerçekleştirmek oldukça zordur. Bu sebeple yazılımda kaliteyi ölçebilmek için farklı farklı birçok standart geliştirilmiştir. Bu bölümde
öncelikle kalite kavramı açıklanmış, sonrasında yazılım kalitesinden bahsedilmiş ve yazılım kalitesini ölçmek için kullanılan standartlar hakkında bilgi verilmiştir.

9.1. Kalite Kavramı

Kalite, günümüzde her alanda karşımıza çıkan ve pek çok farklı tanımı yapılan bir kavramdır. Aşağıda bu tanımların bazıları verilmiştir:

 “Kalite ihtiyaçları karşılama yeteneğidir.”

 “Kalite kullanıcı gereksinimlerine uygunluktur.”

 “Kalite ilk seferde doğrusunu yapmaktır.”

 “Kalite amaçlanan kullanıma uygunluktur”.

Şekil 9.1’de kalite ile ilgili genel bir şema verilmiştir (Danismend, 2020).

Şekil 9.1. Kalite İle İlgili Kavramlar

Bu şekilde de görüldüğü üzere kalite birçok alt bileşenin birleşmesinden oluşmaktadır. Bu alt bileşenler Kalite Kontrol, Kalite Yönetimi, Kalite Denetimi, Kalite
Sistemi ve Kalite Güvencesi şeklinde ifade edilebilir. Bu kavramlar ileriki aşamalarda, yeri geldikçe daha ayrıntılı bir şekilde açıklanacaktır ancak burada da giriş
seviyesinde birer tanım verilmesi uygun görülmüştür.

Kalite Kontrol: Kalite kontrolü, bir sürecin kalite etkinliğini azaltacak durumlara karşı tedbir alarak kaliteye hakim olma anlamına gelir. Kalite kontrolünün temel
amacı müşteri beklentilerinin ve işletmelerin stratejik amaçlarının en ekonomik seviyede karşılanabileceği ürünün üretimi için gerekli planların geliştirilip uygulanarak
etkin bir şekilde sürekliliğinin sağlanmasıdır. Eğer kontrol temel olarak, kalite yönetim kararlarında kullanılmazsa yönetim tümüyle kaliteyi yönetemez (Öztürk, 2013;
James, 1996).

Kalite Yönetimi: Kuruluş içinde kaliteyi amaç edinen, kuruluştaki tüm çalışanların katılımına dayanan, müşteri memnuniyetini referans alan topluma ve kuruluşun
içindeki her yerde yarar sağlayan yönetim biçimidir. Kalite sistemi müşteri talepleri ile başlar ve ürünün tasarımdan maliyetine kadar tüm süreçleri kapsar. Kalite
yönetimi planlama, kontrol ve geliştirme olarak
3 temel süreçten oluşmaktadır. Bu süreçler Kalite Planlama, Kalite Kontrol ve Kalite Geliştirme’dir.

Kalite Denetimi: Kalite denetimi, kalite sisteminin yeterli bir şekilde anlaşılıp uygulandığını veya uygulanmadığını gösteren bir araştırma ve inceleme faaliyetidir
(Kalite Sistem, 2011).

Kalite Sistemi: En genel anlamda, bir kuruluşta hedeflenen kalitenin gerçekleşmesi amacı ile sürdürülen planlı ve sistematik faaliyetlerin bütünüdür (Peşkircioğlu,
1997).

Kalite Güvencesi: Kalite Yönetiminin, kalite şartlarının yerine getirileceğini dair güvence sağlamaya odaklanan bir parçasıdır.

Kalite kavramı ile ilgili pek çok doğru bilinen yanlış mevcuttur. Bu doğru bilinen yanlışlar aşağıda özetlenmiştir:

 Doğru Bilinen Yanlış 1: Kalite soyut bir kavramdır ve ölçülemez.

 Doğru Bilinen Yanlış 2: Daha iyisini yapmanın maliyeti başlangıçta karşılanamaz.

 Doğru Bilinen Yanlış 3: Kalite problemlerine en alt kademede çalışanlar sebep olur.

 Doğru Bilinen Yanlış 4: Kaliteyi, kurumların kalite ile ilgili bölümleri başlatır.

Doğru Bilinen Yanlış 1: Kalite soyut bir kavramdır ve ölçülemez.

Gerçek: Kalitenin soyut bir kavram olduğu doğrudur ancak pek çok farklı kritere (örneğin, uygunsuzluğun maliyeti, hata maliyeti) bağlı olarak ölçülmesi mümkündür.
Ayrıca kalite ilgili olarak esas gereken ölçülmesi ya da sayısal değerlere çevrilmesi değil, kendi içerisinde kıyaslanmasıdır. Diğer bir deyişle bir yazılım bileşeninin
kalitesinin x birim ya da y birim olarak ifade edilmesinden çok bu yazılım bileşeninin kalitesinin başka bir yazılım bileşeni kalitesinden daha fazla ya da daha az
olmasının belirlenebilmesi önem arz etmektedir.
86
Doğru Bilinen Yanlış 2: Daha iyisini yapmanın maliyeti başlangıçta karşılanamaz.

Gerçek: Kaliteyi baştan sağlamanın (hata önleme) maliyeti, sonradan sağlamaya çalışmanın (hata bulma ve düzeltme) maliyetinden daha azdır. Çünkü başta hataların
önlenmesi için belli tedbirler alınması gerekmektedir. Halbuki hata oluştuktan sonra hatanın tespit edilmesi, kategorize edilmesi ve düzeltilmesi için çok daha fazla
maliyet gerekli olacaktır.

Doğru Bilinen Yanlış 3: Kalite problemlerine en alt kademede çalışanlar sebep olur.

Gerçek:  Genellikle en alt kademede çalışanlar, daha üst kademede çalışanlardan daha az hata maliyetine sebep olur. Çünkü sahip oldukları yetkiler sınırlıdır.

Doğru Bilinen Yanlış 4: Kaliteyi, kurumların kalite bölümleri başlatır.

Gerçek: Kalite anlayışı üst yönetim seviyesinde başlar ve tüm çalışanlar tarafından benimsenmelidir.

Bir ürün veya hizmet üzerinde kalitenin sağlanması ile ilgili geleneksel ve gelişmiş çeşitli anlayışlar söz konusudur. Geleneksel anlayış, oluşan hataları ayıklama üzerine
temellendirilmiştir, bir ürün veya hizmetin tanımlanmış gereksinimleri karşılayıp karşılamadığının tespitinde kullanılan teknikler ve uygulanan faaliyetler ile ilgilidir, söz
konusu ürün ve hizmet üzerinden kaliteyi sağlama hedefine sahiptir ve genellikle kalite kontrol olarak ifade edilir. Gelişmiş anlayış, hataları oluşmadan önleme üzerine
temellendirilmiştir, bir ürün veya hizmetin tanımlanmış gereksinimleri karşılanmasını yeterli derecede güvence altına almak için gerekli olan, tüm planlanmış ve
sistematik faaliyetler ile ilgilidir, söz konusu ürünü ve hizmeti oluşturan sistem üzerinden kaliteyi sağlama anlayışına sahiptir ve genellikle kalite güvencesi olarak ifade
edilir. Süreç, belirli bir hedefe ulaşmak için gerçekleştirilen
(ve kullandığı girdileri çıktılara dönüştüren) adımlar zinciri olarak ifade edilebilir.

Ürün yoluyla kalite gerçekleştirilmek istendiğinde,

 Üretim hattını durdurmak yerine; kaza eseri olduğunu varsayarak hatalı ürünler birleştirilir.

 Hataların giderilmesi sonraya bırakılır.

 Çalışan hatayı tekrarlamamaya zorlanır, bu sebeple bazen daha çok hata yapar.

 Çalışanların hataları saklamasına neden olur, bu da projede birçok soruna neden olabilir.

 Yönetimin çalışanlara karşı tavır almasına sebep olabilir.

Süreç yoluyla kalite gerçekleştirilmek istendiğinde,

 Hatalı bir ürün tespit edildiğinde; bunun ürünü geliştiren sürecin bir problemi olduğu varsayılarak üretim hattı durdurulur.

 Hatanın kaynağı bulunur ve iyileştirilir.

 Çalışanları hataları bulmaya ve sistemi iyileştirmeye teşvik eder.

 Yönetsel rollerde çalışanların görev almasını sağlar.

 Alt kademede çalışanların görev almasını sağlar.

Süreç yönetimi, istatistiksel süreç kontrolü olarak adlandırılır ve “Değişkenlik endüstriyel yaşamın bir gerçeğidir ve istatistiksel yöntemlerle yönetilebilir.” şeklinde
ifade edilir. Burada bahsi geçen değişiklik kabul edilebilir değişiklik (“common causes”) ve kabul edilemez değişiklik (“special causes”) olarak iki kategori içerisinde
incelenir. Kabul edilebilir değişkenlik, her üretim sisteminin, iç bileşenleri sebebiyle belirli seviyede değişkenliğe sebep olması, kabul edilemez değişkenlik ise sistemin
işleyişindeki özel durumlar, ürün özelliklerinde önemli değişkenlige sebep olması şeklinde ifade edilebilir. Kabul edilemez değişiklikler de tecrübeli çalışanlar
tarafından tespit edilerek giderilebilir.

Kalite maliyeti, bir ürün ve sürecin kaliteli olması için gereli olan maliyet ya da ürünler ve onları üreten süreçler mükemmel olduğunda ortadan kalkacak toplam
maliyet olarak ifade edilebilir. Bu kavram üretim ve hizmet sektörlerinde yaygın olarak kullanılmaktadır, süreçteki zayıf halkaların tespit edilerek kalite maliyetinin
düşürülmesini hedefler. Temel olarak

 Uygunsuzluk maliyeti

 Uygunluğu sağlama maliyeti

 Hata maliyeti

 Hata bulma maliyeti

 Hata önleme maliyeti

gibi farklı maliyetlerden oluşmaktadır.

Uygunsuzluk maliyeti: Herhangi bir üründe ya da hizmette ya da süreçte kalitenin sağlanmasını başarmak mümkün olmadığında ödenen bedel olarak ifade
edilebilir. Genellikle hatalar bu maliyete sebep olur. Bir ürünün müşteriye/kullanıcıya teslimatından önce oluşan hatalara iç hatalar (internat failures) ve bir ürünün
müşteriye/kullanıcıya teslimatından sonra oluşan hatalara dış hatalar (external failures) adı verilmektedir.

Uygunluğu sağlama maliyeti: Herhangi bir üründe ya da hizmette ya da süreçte kaliteyi sağlamak için ödenen bedeldir. Bu maliyet, kalitesizliği tespit etmenin
maliyeti (appraisal costs) ve kalitesizliği önlemenin maliyeti (prevention costs) şeklinde gruplandırılır.

Hata maliyeti: Ürünün sağlaması beklenen özelliklerle ilişkilidir ve müşteri ihtiyaçlarını karşılayamama sonucunda ortaya çıkan hataların maliyeti olarak ifade
edilebilir.  İç ve dış hata maliyetleri toplanarak hesaplanır. Burada iç hata maliyeti; tekrar çalışma (“rework”), tekrar test (“re-test”), dış hata maliyeti ise müşteriden
dönen ürün, müşteri şikayetleri gibi maliyetlerdir.

Hata Bulma Maliyeti (“Appraisal Costs”): Ürün veya hizmetin, kalite standartlarına ve performans gereksinimlerine uyduğunu ölçmek, değerlendirmek veya
denetlemek ile ilgilidir. Hata giderme etkinlikleri,  gözden geçirmeler, ürün denetlemeler, beta testler bu kısımda ele alınmaktadır.

Hata Önleme Maliyeti (“Prevention Costs”): Bir ürün veya hizmetin hata maliyetini (“failure costs”) ve hata giderme maliyetini (“appraisal costs”) en aza
indirmek üzere tasarlanmış etkinliklerle ilişkilidir. Hata önleme yaklasımlarının keşfi, uygulaması ve iyileştirilmesi için yatırım gerektirir. Hata önleme etkinlikleri, eğitim,
87
araç ve yöntemler, kalite planlama, süreç yönetimi Kurumsal Olgunluk ve Kalite Maliyeti bu kısımda ele alınmaktadır.

9.2. Yazılım Kalitesi Kavramı

Geliştirilen yazılımın kalitesi, yazılımın nasıl geliştirildiğine büyük ölçüde bağlıdır.
Örneğin Çağlayan Modeli kullanıldığında sırasıyla Analiz, Tasarım, Gerçeklestirme, Test ve Bakım aşamaları gerçekleştirilir ve kalite, yazılım geliştirme aşamaları
boyunca yazılım ürününe yerleştirilmek zorundadır. Bu modelde kalitenin baştan itibaren planlanmaması halinde, kaliteyi ürünün en sonunda sağlamaya çalışmak hem
zordur, hem de böyle bir durumda maliyet çok yüksek olur.

Tecrübeli bir mühendisin bile yaklaşık olarak her 7-10 satırda bir hata ürettiği, bu durumun orta ölçekli bir projede binlerce satırlık hataya karşılık geldiği, hataların
çoğunun test aşamasında düzeltilmesi gerektiği ve testler uzadıkça maliyetin arttığı, teslimatın geciktiği, ürün kalitesinin düşeceği, bakım maliyeti geliştirme maliyetinin
artacağı düşünüldüğünde yazılımların kaliteli olmasının önemli olduğu görülmektedir. Kaliteli yazılım ile ilgili birçok farklı tanımlama yapılmış olmasına rağmen genel
olarak tüm tanımlarda ortak olarak bulunan maddeler şu şekilde ifade edilebilir. Kaliteli yazılım;

 kabullenebilir düzeyde hata seviyesine sahip,

 müşteri ve kullanıcı gereksinimlerini karşılayan,

 amaçlanan kullanıma uygun,

 zamanında (veya en azından küçük bir gecikme ile) tamamlanmış,

 belirlenen bütçe sınırları içinde (veya en azından küçük bir farklılıkla) gerçekleştirilmiş,

 var olan kanunlara, kurallara, standartlara uyumlu,

 gerekli olduğunda bakımı sağlanabilen

yazılımdır.

Şekil 9.2.’de yazılım kalitesi ile ilgili bir şema görülmektedir (Danismend, 2020).

Şekil 9.2. Yazılım Kalitesi İle İlgili Kavramlar

Bu şekildeki yazılım kelitesi ile ilgili kavramlara bakıldığında aşağıdaki gibi olduğu görülür.

 İnsan Kaynakları Yönetimi,

 Proje Yönetimi,

 Ar-Ge Yönetimi,

 Teknoloji Yönetimi,

 Yazılım Mühendisliği,

 Kalite Yönetimi,

 Bilgi Kaynakları Yönetimi

Bir yazılımın kalitesiz olma sebepleri ise müşteri/kullanıcı tarafındaki sebepler ve yazılım ekibi tarafındaki sebepler olarak gruplandırılabilir.

Müşteri/kullanıcı tarafındaki sebepler;

 gereksinimlerin sağlanamayışı,

 kolay anlaşılabilir ve kullanılabilir olmaması,

 istenilen zamanda bakım yapılabilir olmaması,

 eğitim desteğinin yetersiz olması

yazılım ekibi tarafındaki sebepler;

 geciken ya da bitmeyen projeler,

88
 yüksek maliyet,

 çalışanların tatminsizliği,

 firmaya olan güven kaybı

şeklinde ifade edilebilir.

Kalite yazılımı, makul bir hata veya kusursuz olan, zaman içinde ve belirtilen bütçe dâhilinde teslim edilen, gereksinimleri ve/veya beklentileri karşılayan ve bakımı
mümkün olan bir yazılımı ifade eder. Yazılım mühendisliği bağlamında, yazılım kalitesi hem fonksiyonel kaliteyi hem de yapısal kaliteyi yansıtmaktadır.

Yazılım Fonksiyonel Kalitesi: Fonksiyonel gereksinimlere veya özelliklere bağlı olarak belirli bir tasarımı ne kadar iyi karşıladığını ifade eder.

Yazılım Yapısal Kalitesi: Sağlamlık veya sürdürülebilirlik gibi fonksiyonel gereksinimlerin sunulmasını ve yazılımın doğru şekilde üretilme derecesini destekleyen
fonksiyonel olmayan gereksinimlerin ele alınmasıyla ilgilenir (Şen, 2021).

Yazılımlardaki hataların ortaya çıkma noktası ilerledikçe bu hataları düzeltme maliyetleri de artmaktadır. Şekil 9.3. bu durumu göstermektedir.

Şekil 9.3. Yazılım Hatalarını Düzeltme Maliyeti

Yazılım kalitesi ile ilgili en önemli kavramlar, Yazılım Kalite Kontrol ve Yazılım Kalite Güvencesi (YKG) kavramlarıdır. Yazılım Kalite Kontrol, oluşan hataları
ayıklamaya yönelik olarak yapılan faaliyetlerdir. Sistematik olarak ve belirli zamanlarda yapılır. Yazılım Kalite Güvencesi ise hataların oluşmasını önlemeye yönelik
olarak yapılan faaliyetlerdir. Sistematiktir ancak zamana yayılmış bir şekilde kullanılır.

Yazılım Kalite Güvencesi, yazılımın gelisşirilmesi ve bakımı boyunca kaliteyi sağlamanın maliyet-etkin yoludur. Kalitenin yazılım ürününe yerleştirilmesi için, proje
yasam döngüsü boyunca üretilen ürünlerinin ve uygulanan süreçlerinin, tanımlı gereksinimlere uyduğunu güvence altına almayı hedefler. Proje yasam döngüsü boyunca
çeşitli etkinlikleri planlayarak, isleterek ve izleyerek hataların erken tespit edilmesine hizmet eder. Şekil 9.4.’te Yazılım Kalite Güvencesi gösterilmektedir.

Şekil 9.4. Yazılım Kalite Güvencesi

Yazılım Kalite Güvencesi,  yazılım ürünün istenilen kalitede olmasını güvence altına alan ve gelistirme süreci boyunca uygulanan etkinlikleri içerir. Doğrulama ve
Geçerleme (D&G), yazılım gelistirme sürecinin her aşamasındaki çıktıların, istenilen özelliklere uygunluğunu kontrol etmeye yarayan etkinliklerdir. Test ise, bir
üründeki hataların ortaya çıkarılması etkinliğidir. Bu üç işlem arasındaki ilişki aşağıdaki gibidir:

YKG > D&G > Test

Yazılım Kalite Güvencesi elde edilirken statik ve dinamik çeşitli yöntemler kullanılmaktadır. Statik yöntemler, kodu çalıştırmadan gerçekleştirilen yöntemlere verilen
isimdir.
Bu yöntemlere örnek olarak gereksinim ve tasarım belgeleri ile kodun denetimi veya gözden geçirilmesi verilebilir. Burada, inceleme (“inspection”), gözden geçirme
(“review”) ve denetleme (“audit”) gibi kavramlara başvurulur. Dinamik yöntemler ise kod çalıştırılarak gerçekleştirilir. Bu yöntemlere örnek olarak ürünün veya
bileşenlerinin gerçeğe yakın testinin gerçekleştirilmesi ifade edilebilir. Burada, birim test, birleştirme/entegrasyon testi, sistem testi ve kabul testi alınır.

Yazılım kalitesinden bahsedilirken ele alınması gereken diğer önemli kavramlar ise doğrulama (“verification”) ve geçerlemedir (“validation”). Doğrulama, müsterinin
istediği ürünü, doğru şekilde geliştirmeyi güvence altına alır. Mühendislik adımlarının doğru uygulanıp uygulanmadığın kontrol eder. Her aşamada, bir önceki aşamada
yapılması taahhüt edilen işlemlerin gerçekleştirilip gerçekleştirilmediği ve tanımlanan gereksinimlere göre uyumsuzluk veya eksiklik olup olmadığı üzerinde çalışılır.
Geçerleme ise müşterinin istediği, (doğru) ürünü geliştirmeyi güvence altına alır, mühendislik ürününün müşteri ihtiyaçlarına uyup uymadığının kontrolüdür. Her
aşamanın çıktısının müsteri gereksinimlerini karşılayıp karşılamadığını tespit etmeye çalışır.

Şekil 9.5’te Yazılım Geliştirme ve Doğrulama ve Geçerleme Aşamaları görülmektedir.

89
Şekil 9.5. Yazılım Geliştirme ve Doğrulama ve Geçerleme Aşamaları

Özet olarak Yazılım Kalite Güvencesi’nin amacı hataları bulmaktan çok önlemektir.
Bu amaçla,  en uygun yazılım geliştirme ortamının kurulması, gerekli süreçlerin ve talimatların tanımlanması, süreç uygulamalarının etkinliğini ölçme yöntemlerinin
belirlenmesi ve uyulacak standartların ve kullanılacak sablonların tanımlanması işlemlerini gerçekleştirir. Doğrulama, geçerleme ve test işlemlerinin amacı ise daha çok
oluşan hatayı bulmaktır.
Bu amaçla, statik olarak denetleme, gözden geçirme, ve inceleme ve dinamik olarak birim, birleştirme (entegrasyon), sistem, ve kabul testi gerçekleştirilir.

Büyük çaplı projelerde, yazılım geliştirme sürecinde sadece yazılıma yönelik planlama, kodlarını yazma, yazılan kodları test etme gibi önemli unsurlar yer
almamaktadır.
Bunlar dışında, projenin yönetilmesiyle ilgili, proje bütçesinin takip edilmesiyle ilgili ve geliştirilen ürünün müşterinin beklentilerini karşılayıp karşılamadığını kontrol
etmek, dolayısıyla müşteri ile sürekli bir iletişimde olmak, geliştirici takımların arasındaki ve/veya tedarikçiler arasındaki işbirliği, kısaca, iş akışı unsurlarının da
kontrol edilmesi gerekmektedir. Yazılımda kaliteyi bu kontrollerin tamamı oluşturmaktadır. Aşağıda, büyük çaplı bir projede karşılaşılan sözleşme koşulları, müşteri
ile tedarikçi ilişkileri, takım çalışması ve diğer geliştirici ekipleriyle işbirliği ile koordinasyon gibi önemli konular açıklanmıştır (Şen, 2021).

Sözleşme koşulları: Yazılım geliştirici ve müşteri arasındaki sözleşmede tanımlanan taahhütler ve koşullar sonucunda, yazılım geliştirme ve bakım faaliyetlerinin
aşağıdakiler ile başa çıkması gerekir:

 Geliştirilen yazılımın ve bakımın yerine getirilmesi gereken fonksiyonel gereksinimlerin tanımlanmış bir listesi.

 Proje bütçesi.

 Proje takvimi.

Yazılım geliştirme ve bakım projelerinin yöneticileri, sözleşmenin şartlarını yerine getirmek için faaliyetlerin denetlenmesinde önemli miktarda çaba harcamalıdır.

Müşteri-tedarikçi ilişkisi: Yazılım geliştirme ve bakım süreci boyunca, faaliyetler müşterinin gözetimi altındadır. Proje ekibi sürekli olarak müşteriyle işbirliği
yapmak zorundadır: değişiklik talebini değerlendirmek, projenin çeşitli yönleri ile ilgili eleştirilerini tartışmak ve geliştirme ekibi tarafından başlatılan değişiklikler için
onayını almak zorundadır.
Yazılım uzmanı olmayanlar tarafından geliştirilen yazılımlarda bu tür ilişkiler genellikle mevcut değildir.

Takım çalışması: Üç faktör genellikle projeyi bir profesyonele vermek yerine proje ekibinin kurulmasını motive eder:

 Zaman çizelgesi gereksinimleri. Diğer bir deyişle, proje süresi içinde üstlenilen iş yükü, projenin zamanında tamamlanması halinde birden fazla kişinin katılımını
gerektirmektedir. 

 Projeyi yürütmek için çeşitli uzmanlıklara duyulan ihtiyaç.

 Proje kalitesinin artırılması için profesyonel destek ve gözden geçirme isteği.

Diğer yazılım ekipleriyle işbirliği ve koordinasyon: Projelerin, özellikle büyük ölçekli projelerin, birden fazla ekip tarafından taşınması, yazılım sektöründe çok
yaygın bir olaydır. Bu durumlarda aşağıdakiler ile işbirliği gerekebilir:

 Aynı kuruluştaki diğer yazılım geliştirme ekipleri. 

 Aynı organizasyonda donanım geliştirme ekipleri. 

 Diğer tedarikçilerin yazılım ve donanım geliştirme ekipleri. 

 Projenin geliştirilmesinde yer alan müşterinin yazılım ve donanım geliştirme ekipleri.

Diğer yazılım sistemleri ile arayüzler: Günümüzde çoğu yazılım sistemi diğer yazılım paketleriyle arayüzler içermektedir. Bu arayüzler, elektronik sistemlerdeki
verilerin, diğer yazılım sistemleri tarafından işlenen verilerden bağımsız olarak, yazılım sistemleri arasında akmasına izin verir (Cura, 2021). Aşağıda bazı arayüz türleri
ifade edilmiştir:

 Diğer yazılım sistemlerinin yazılım sisteminize veri aktardığı giriş arayüzleri. 

 Yazılım sisteminizin işlenmiş verileri diğer yazılım sistemlerine aktardığı çıktı arabirimleri. 

 Tıbbi ve laboratuvar kontrol sistemlerinde, metal işleme ekipmanlarında vs. olduğu gibi, makinenin kontrol paneline giriş ve çıkış arayüzleri.

Sonuç olarak bir yazılımda kalitenin arttırılmasını sağlayan temel maddeler aşağıdaki gibi maddelendirilebilir (Kazan, 2021).

 Toplum/Topluluk Düşüncesi ile İlgili Kusurları Değiştirmek

 Yazılım Gereksinimlerini İyice Analiz Etmek

 Sık Sık Kod Düzeltmeleri Uygulamak

90
 Sık Sık Regresyon Testi Gerçekleştirmek

 Hata Analizi Yapmak

 Değişiklikleri Sürekli İncelemek

Toplum/Topluluk Düşüncesi ile İlgili Kusurları Değiştirmek: Hatalar, genel yazılım geliştirme yaşam döngüsü boyunca bir noktada kaçınılmazdır, ancak
geleneksel olarak yönetilen birçok kuruluş, kusur ve hata yönetimini, hataları geri almayı bir savaş olarak gösterir. Kusurların mahsur kaldığı ve gelişiyle mücadele
edecek sağlıklı süreçlerin planlanması ve yürütülmesi gerektiği konusunda nadiren kabuller vardır. Gelişimdeki kusurlar mutlaka istenmeyen birer kötülük olsa da,
amaç sadece hataları ortadan kaldırmak olmamalıdır, kusurların tanımlanmasını, hata ayıklanmasını ve çözümünü basitleştiren uygulamalar ve prosedürleri geliştirmek
de amaçlanmalıdır. Daha da önemlisi, bu süreçler gelişim yaşam döngüsünün erken döneminde uygulanmalı ve sürekli olarak geliştirilmelidir. Yerinde ve zamanında
sağlıklı uygulamaların kullanılması ile, kusurlar artık kaçınılmazlık olarak kabul edilmeyen bir şey haline gelebilir.  Özellikle tutumlar üzerinde daha geleneksel bakış
açılarına alışmış sağlam kuruluşlar için bu tutumdaki değişim zor olabilir, ancak tutumdaki değişim yukarıdan aşağı doğru bir süreç olmalıdır. Yürütücü ile yöneticiler,
kusurların (özellikle üretimde) kaçınılmaz olduğunu ve bunun yerine hataları istisna olarak gördüklerine dair algılarını değiştirmelidir. Algıdaki bu değişim sonunda,
şirket genelinde aşağı doğru hareket edecek ve sonuç olarak grupların kusurlarla ilgili tutumlarında bir paradigma kaymasına yol açacaktır. Bu, kuruluşun sorunları
nasıl ele aldığına dair değişikliklere yol açacak ve sonuçta üretim hatalarında büyük bir düşüş sağlanacaktır.

Yazılım Gereksinimlerini İyice Analiz Etmek: Düzenli olarak (haftalık, aylık vb) uygun bir zaman bloğunu bir kenara koymak ve projenin detaylı yazılım
gereksinimlerini tartışmak için ekip boyunca yöneticiler ile geliştirici liderleri ile görüşmek gerekir. Bu süreç, genel uygulama için tam olarak hangi gereklilikleri, ayrıca
detaylı bileşen veya özellik-odaklı gereklilikleri belirtilmelidir. Bu uygulamanın en büyük yararı, potansiyel tuzakların açığa çıkarılması ve aksi takdirde, yolun herhangi
bir yerinde ortaya çıkabilecek büyük bir eksikliğin önlenmesidir (Gencer ve Kayacan, 2017).

Sık Sık Kod Düzeltmeleri Uygulamak (Refactoring): Sağlam yazılım gereksinimlerini oluşturmak için sunulan sağlam bir planla birlikte, bir sonraki alışkanlık,
kuruluş çapında kod iyileştirme uygulamalarını uygulamak olmalıdır. Refactoring, temel davranışını değiştirmeden mevcut kodun yapısını geliştirmeyi ve yeniden
tasarlamayı amaçlamaktadır. Refactoring’in basit örnekleri, yanlış ad değişkenlerini veya yöntemlerini sabitlemeyi ve tekrarlanan kodları tek bir yönteme veya
fonksiyona indirgemeyi içerir. Herhangi bir kodun gözden geçirilmesi yoluyla üretim hatalarını azaltmanın en iyi yolu, kuruluşun oluşturduğu süreçlerin sık sık
uygulandığından emin olmaktır– tekrarlama, üretim ortamına ulaşmadan önce olası problemleri ve mevcut kusurları sürekli olarak yakalayan alışılmış süreçler
yaratacaktır (Adıyahşi, 2017).

Sık Sık Regresyon Testi Gerçekleştirmek: Regresyon testi, bileşenlerin değişikliklere uğramasından sonra, bu yazılım bileşenlerinin fonksiyonelliğini onaylayan
veya reddeden bir yazılım testi türüdür. Bir yazılım bileşeninde bir değişikliğin yapılması ve bir kusurun bulunması durumunda, konuyu doğrulamak ve çözümlemeye
çalışmak için regresyon testi gereklidir. Regresyon testi, her değişiklik sonunda, her günün sonunda, haftada bir, iki haftada bir, vb şeklinde düzenli bir program veya
temele göre gerçekleştirilmelidir. Regresyon testleri, daha önce keşfedilen bir sorun düzeltildiğinde de tipik olarak gerçekleştirilmelidir.
Genel olarak, ne kadar daha sık regresyon testi meydana gelirse, daha fazla sorun keşfedilebilir ve daha fazla sorun çözülebilir ve uygulamada daha da stabil olmaya
başladıkça, üretim hataları da önemli ölçüde azalacaktır.

Hata Analizi Yapmak: Her zaman, yazılım geliştirme yaşam döngüsünün bir noktasında bazı hatalar ve kusurlar görünecektir, bu yüzden ekibin sağlanan bu
avantajlardan tam anlamıyla yararlanması önemlidir. Özellikle, bir kusur yazılımın etkilenen bileşenleri üzerinde derin analiz yapma ve etkilenen tüm alanlara
iyileştirmeler yapma fırsatı sunar. Kuruluşun analiz yapmayı nasıl seçeceği, ekibe ve uygulamaya özel olacaktır, ancak belirli bir kusurun kök nedenini ele alırken
akılda tutulması gereken birkaç temel ilke vardır:

Kaliteyi Artırmayı Amaçlamak: Her şeyden önce, ortaya konan tüm ipuçları ve uygulamalar, yazılımın kalitesini gelecekteki iterasyonlar ile üretim sürümleri
boyunca iyileştirmeyi amaçlamaktadır. Böylelikle, hata analizi hem kusurları hem de kusur adaylarını mümkün olduğunca erken tespit etmeyi amaçlamalıdır.

Uzman Ekip Üyelerine Güvenmek: Kalite güvence bölümleri, özellikle büyük projeler için faydalıdır ve genellikle gereklidir, ancak geliştirme ekibinin kusuruna
neden olan kodları yazma veya bileşenleri üretme ile ilgili üyeleri ihmal etmemek gerekir. Bu üyeleri tespit etmenin amacı, herhangi bir yargılamaktan ya da onları
utandırmaktan ziyade, problemi analiz etmek ve en zarif çözümler ortaya çıkarmak için bu kişileri güçlendirmektir.

Sistematik Kusurları Önceliklendirmek: Tipik gelişim yaşam döngüsü boyunca, ekibin en iyi çabalarına rağmen, bir avuç kusur olma eğilimi olacaktır, bu –
tekrar tekrar ortaya çıkan sorunlar olan regresif kusurlardır. Bu tür sistematik kusurlar, analiz süreci sırasında önceliklendirilmeli ve büyük ölçüde, genel hata oranları
üzerinde en büyük etkiye sahip olacağı için, üzerinde yoğunlaşılmalıdır.

Değişiklikleri Sürekli İncelemek: Sürekli entegrasyon, sürekli dağıtım ve benzeri kavramlar son derece etkili uygulamalardır. Sürekli entegrasyon, genel temele
göre yazılım ürününü düzenli olarak ve otomatik olarak oluşturma ve test etme uygulamasıdır. Test sıklığı iş gereksinimlerine bağlı olacaktır, ancak şu anda mevcut
olan birçok güçlü araçla, bu işlem her yükleme için veya hatta paylaşılan depoya yapılan her bir taahhütte de meydana gelebilir. Sürekli teslimat bir uygulamadan
daha çok bir kavramdır: kod tabanının her zaman kullanıma hazır olması gerektiği fikridir. Bunun anlamı tartışmalı olmakla birlikte, çoğu uygulamadaki temel fikir,
uygulamanın bir aşama veya üretim ortamına tek tıklamayla (veya planlanmış ve otomatik olarak) tam olarak serbest bırakılması için hazır olması gerektiğidir. Son
olarak, sürekli uygulama bu sürekli uygulamaların doruk noktasıdır ve dağıtımların serbest bırakmalarının ya da yamaların gerçek dağıtımının gerçekleştiği ve daha
geniş kullanım için mevcut olduğu durumudur. Bazı kurumlar, bu süreçleri hızlandırmayı tercih ederler. Böylece, yeni, güncellenmiş yapıları günlük olarak üretim
ortamına uygulamaktadırlar.

9.3. Yazılım Olgunluk ve Yetenek Modelleri

Yazılımlarda her ne kadar diğer sektörlerdeki ürünler kadar keskin sertifikasyonlar bulunmasa da yazılımda kaliteyi sağlayabilmek için bazı olgunluk ve yetenek
modelleri kullanılmaktadır.

 CMM (Capability Maturity Model – Yetenek Olgunluk Modeli)

 ISO 9000

 TRILLIUM

 SPICE (Software Process Improvement and Capability Determination ISO 15504)

 TICKIT

9.3.1. CMM (Capability Maturity Model – Yetenek Olgunluk Modeli)

Olgunluk anketini kullanarak yazılım sürecini değerlendiren CMM, Amerikan Savunma Bakanlığı’nın 1970-1980 yıllarında yaşanan yazılım krizine çözüm bulması
amacıyla Carnegie Mellon Üniversitesi’nden yardım istemesi üzerine, üniversite bünyesinde kurulan Yazılım Mühendisliği Enstitüsü (Software Engineering Institute-

91
SEI) tarafından geliştirilmiş bir modeldir (Kalder, 2021). Genellikle büyük boyutlu firmalara hitap eden CMM’de, hem dışa karşı belgelendirme, hem de iç süreçlerin
detaylı bir şekilde değerlendirilmesi söz konusudur.

CMM 5 seviye (1-5 arası) sunar. Seviyelerin numara değerinin yanındaki parantezde seviyelerin sık kullanılan isimleri, (varsa) tanımın sonunda yer alan parantezde
ise içerisinde her seviyeye ait anahtar süreç alanları verilmiştir:

 1. (Initial) Başarının sadece bireylere bağlı olduğu “başlangıç” seviyesi.

 2. (Repeteable) Yazılı olmayan ve kısmen tutarlı süreçlerin olduğu “tekrarlanabilir” seviye (isterler yönetimi, proje planlaması, proje takibi, taşeron yönetimi, kalite
güvencesi, konfigürasyon yönetimi).

 3. (Defined) Şirket kültürünün yazılı hale geldiği “tanımlı” seviye (süreç odaklaması, süreç tanımı, eğitim programı, bütünleşik yazılım yönetimi, yazılım ürün
mühendisliği, gruplararası koordinasyon, ayrıntılı değerlendirme)

 4. (Managed) Tanımlı hale gelen süreçlerin artık ölçülebildiği, performans göstergelerinin değerlendirilebildiği “yönetilen” seviye (nicel süreç yönetimi, yazılım kalite
yönetimi)

 5. (Optimizing) Kurumsallaşmanın gerçekleşip, geri beslemelerin sistematik bir şekilde değerlendirilmeye başlandığı “en iyilenen” seviye (hata önleme teknoloji
değişim yönetimi, süreç değişim yönetimi)

CMM uygulaması için hiyerarşik olarak, seviye belirleme, bir sonraki seviyeye geçmeden önce eksiklikleri belirleme, eksiklikleri hiyerarşik sıraya dizme, eksikliklerin
giderilmesi için plan yapma, planı hayata geçirmek için kaynak ayırma ve uygulama, döngüye yeni baştan başlama aşamaları uygulanır.

CMM değerlendirme süreci 6 aşamadan oluşur:

 1. Kurumun seçildiği “seçim” aşaması.

 2. Değerlendirme sürecinin onaylandığı “taahhüt” aşaması.

 3. Değerlendirme grubunun eğitildiği “hazırlık” aşaması.

 4. Uygulamanın değerlendirildiği “değerlendirme” aşaması.

 5. Değerlendirmenin raporlandığı “rapor” aşaması.

 6. Değerlendirme izlendiği “takip” aşaması.

9.3.2. ISO 9000

International Standards Organization tarafından 1987 yılında yayınlanan, ISO 9000 serisi Kalite Sistemi ve Güvencesi Standartları özellikle Avrupa’da büyük ilgi
görmüştür. ISO 9000 kalite yönetimi ve kalite güvencesi için, ISO 9000-3 yazılımda kalite sistemi denetleyicileri ve uygulayıcılarına rehberlik için bir standarttır.
Yazılımda kalite için ISO 9001 öngörülebilir. Ancak bu standartlar bir süreç modelinden farklı olarak, dışarıya kalite güvencesi vermeye yönelik belgelendirmeye
önem verirler. Denetim mekanizmasına gereksinim duyan bu standartlar, şirket seviyesi hakkında detay değil, genel bir bilgi verirler. Kalite değerlendirme uygulaması
için hiyerarşik olarak, belgelendirilecek kurumunun seçilmesi, ön değerlendirme aktiviteleri, değerlendirme süreci, sürekli gözaltı aktiviteleri, yeniden değerlendirme
aşamaları uygulanır (ISO 2021).

ISO Standartlarında kullanılan kalite terimleri şu şekildedir:

Kalite, mevcut ve var olan karakteristiklerin şartları karşılama derecesine verilen isimdir. Kalite Politikası, kalite ile ilişkili olarak üst yönetim tarafından resmî olarak
formüle edilen şirketin yönelişini ve toplam hedefleri gösteren ifade bütününün metinleştirilmiş halidir. Kalite Yönetimi, bir organizasyonun yönetilmesi ve kontrolü için
koordine edilmiş faaliyetlerdir. Kalite Hedefleri, kalite ile ilişkili olarak istenen veya amaçlanan şeylerdir.

Kalite hedeflerinin SMART Olması sağlanmalıdır. Buradaki harfler aşağıdaki ifadelere karşılık gelir.

 S: Specified/belirli, 

 M: Measurable/Ölçülebilir 

 A: Achievable/Ulaşılabilir 

 R: Real/Gerçekçi 

 T: Timing/Zamana bağlı

Kalite ile ilgili diğer kavramlar ise aşağıdaki şekilde açıklanabilir:

 Kalite planlaması: Kalite Yönetiminin, kalite hedeflerinin belirlenmesi ve bu hedeflerin karşılanması için gerekli operasyonel proses ve ilgili kaynakların temini
konusunda odaklanmış bir parçasına verilen isimdir.

 Kalite Kontrol: Kalite şartlarının karşılanmasına odaklanmış kalite yönetiminin bir parçasına verilen isimdir.

 Kalite Güvence: Kalite şartlarının karşılandığı güvencesi vermeye odaklanmış kalite yönetiminin bir parçasına verilen isimdir.

 Çalışma Ortamı: İşin yapıldığı ortam şartlarına verilen isimdir.

 İyileştirme: Kuruluşun kalite şartlarını karşılama kabiliyetinin artırılmasına odaklanmış kalite yönetiminin bir parçasına verilen isimdir.

 Ürün: Prosesin bir sonucuna verilen isimdir.  Bunlar donanım, yazılım, servisler olabilir.

 Şartlar: Belirlenen, Genel olarak istenen veya yasal ihtiyaç ve beklentiler bütünüdür. Ürün, sistem veya müşteri ile ilişkili olabilir. Belirlenmiş şartlar yazılı hale
getirilmiş olan şartlardır. Şartlar değişik kaynaklar tarafından ortaya konulabilir.

 Düzeltici Faaliyet: Belirlenen bir uygunsuzluğun ana sebebini ortadan kaldırmak ve tekrarını engellemek için yapılan faaliyetlerdir.

92
 Önleyici Faaliyet: Potansiyel bir uygunsuzluğun (henüz ortaya çıkmamış) sebebini ortadan kaldırmak için yapılan faaliyetlerdir.

 Standart Dışı İzin: Şartlara uymayan ürünlere gerektiğinde (müşteri onayı gibi) şartlı/şartsız çıkış izni verme işlemidir.

 Serbest Bırakma: Prosesin bir sonraki aşaması ile devam etmek için verilen izinlerdir.

 Gözden Geçirme: Belirlenen hedefleri gerçekleştirmek için oluşturulan konuların uygunluğunu ve etkinliğini tespit için gerçekleştirilen faaliyetlerdir.

 Doğrulama: Belirlenen şartların karşılandığını gösteren objektif delillere dayalı olarak teyit işlemidir.

 Geçerli Kılma: Gerçek delillerin incelenmesi sonucunda istenen amaca ve uygulamaya dönük gerekliliklerin karşılandığının teyit edilmesidir.

 Objektif Delil: Bir şeyin bulunduğunu ve gerçek olduğunu gösteren bilgi veya verilerdir.

 Uygunsuzluk: Gerekliliklere uymama durumudur.

 Proses: Girdileri kaynak kullanarak çıktılara dönüştüren ve birbirleri ile ilişkili veya etkileşen faaliyetler bütünüdür.

ISO 9000'in sağladığı yararlar şu şekilde ifade edilebilir:

 Çalışanların kalite bilincinde artış sağlanması

 İşletmenin piyasa itibarında artış sağlanması (prestij)

 Pazarlama faaliyetlerinde rakiplerden farklılık sağlanması

 İşletmenin uluslararası geçerliliğe sahip bir kalite belgesi edinmesinin getirdiği ticarî avantajlardan yararlanabilme (ihracat için kalitenin belge ile ispatlanabilmesi)

 Müşteri memnuniyetinde ve müşteri sadakatinde artış sağlanması

 Hata oranlarında, firelerde, yeniden işlemelerde azalma sağlanması

 Girdi, üretim ve son kontrollerin etkin olarak yapılabilmesi

 Tedarikçilerin seçiminde, değerlendirilmesinde ve takibinde kolaylık sağlanması

 İşletme içi yetki ve sorumlulukların tespitinde ve dağıtılmasında kolaylık sağlanması

 İşletme faaliyetlerinin standartlaştırılmasını sağlayacak dokümantasyonun (altyapının) oluşturulması

 Geçmişe yönelik kayıtların düzenli bir şekilde tutulmasını sağlayacak altyapının oluşturulması

 Veriler ve istatistiksel ölçümler doğrultusunda durum analizlerinin yapılabilmesi ve geleceğe yönelik kararlarda bu analiz sonuçlarının kullanılabilmesi

9.3.3. TRILLIUM

Teknolojik olgunluk içeren ve iyileşmeyi bu olgunlukla düzenleyen yol haritası (road-map) yaklaşımını getiren Trillium modeli, Kanada telekom sektörü tarafından
geliştirilmiştir (Özkan, 2021). Yol haritası kavramı, ürün geliştirme süreci içerisinde bir organizasyon alanı, ihtiyacı ya da öğesine odaklanan ilgili uygulamalar seti
olarak tanımlanabilir. Trillium modeli 5 seviye sunmaktadır:

 1. Başarının sadece bireylere bağlı ve riskin yüksek olduğu “yapılanmamış” seviye (unstructured).

 2. Başarının iyi bir proje yönetimi ile ancak sağlanabildiği “tekrarlanabilen ve proje yönelimli” seviye (repeatable and project oriented).

 3. Tanımlı süreçlerin değerlendirilebildiği “tanımlı ve süreç yönetimli” seviye (defined and process oriented).

 4. Süreç değişim yönetiminin uygulanabildiği “yönetilen ve bütünleşik” seviye (managed and integrated).

 5. Metodolojilerin yaygın olarak kullanıldığı ve riskin düşük olduğu “tam bütünleşik” seviye (fully integrated).

Trillium 8 yetenek alanından oluşur:

 1. Organizasyon süreç kalitesi

 2. İnsan kaynakları geliştirme ve yönetimi

 3. Süreç

 4. Yönetim

 5. Kalite

 6. Sistem geliştirme uygulamaları

 7. Geliştirme ortamı

 8. Müşteri desteği

9.3.4. SPICE (Software Process Improvement and Capability Determination ISO 15504)

ISO/IEC, yazılım sürecinin iyileştirilmesi ve yetenek düzeyinin belirlenmesi amacıyla 1993’ten bu yana SPICE adı altında standartlar geliştirmektedir. Her boyutta
firmaya hitap eden SPICE, ISO’daki genellemelerin aksine detay bilgi verir.

SPICE süreç değerlendirmesi, kendi kendine değerlendirme ile (organizasyon içerisinden), grup tabanlı değerlendirme ile (organizasyon içerisinden bir grup), sürekli
değerlendirme ile (otomasyona girmiş bir veri toplama süreci ile) ya da bağımsız değerlendirme ile (organizasyondan bağımsız uzman tarafından) yapılabilir.
93
İki boyuttan (yazılım süreçleri ve yetenek düzeyleri) oluşan SPICE’a göre, birinci boyutu (yazılım süreçleri) oluşturan kategoriler 5 sınıfa ayrılır:

 1. Müşteri-satıcıya direkt etkisi olan süreçler

 2. Mühendislik süreçleri

 3. Projeyi oluşturan ve yöneten süreçler (yönetim)

 4. Destek süreçleri

 5. Organizasyon süreçleri

İkinci boyut olan yetenek boyutunda ise 6 yetenek seviyesi (0-5 arası) vardır:

 0. (Incomplete) Başarının sadece bireylere bağlı olduğu “eksik” seviye

 1. (Performed) Planlama yapılmadan, süreçlerin genel olarak yerine getirildiği “var olan” seviye

 2. (Managed) Süreçlerin tanımlandığı, iş planının uygulandığı “yönetilen” seviye (managed)

 3. (Established) Organizasyonda belgelendirilmiş standart süreçler ve uygulamaların olduğu “yerleşmiş” seviye

 4. (Predictable) Denetim altındaki süreçte detaylı performans ölçümleri toplanabildiği “kestirilebilir” seviye

 5. (Optimizing) Geribeslemelerle sürekli iyileştirilen “en iyilenen” seviye

9.3.5. TICKIT

ISO 9001’in karşılaştığı bir takım güçlükler nedeniyle ISO 9000-3 çıkarılmış, onun da yetersiz kalması üzerine İngiltere kaynaklı TICKIT modeli ortaya çıkarılmıştır.
TICKIT, değerlendirdiği kalite sisteminde ISO 9001 standardına göre uyumsuzluk olup olmadığını araştırır.

TICKIT içinde kullanılan anahtar dokümanlar aşağıdaki şekildedir:

 ISO 9001:1994, Kalite Sistemi Standardı, tasarım, geliştirme, kurma (installation) ve servis için bir model tanımlar.

 ISO 9002:1994, Kalite Sistemi Standardı ikinci bölümüdür. ISO 9001’den farkı tasarım aktivitelerini içermez.

 ISO 9000-3:1991, yazılım için kalite sistemlerinin uygulayıcıları ve denetimcileri için özel rehberlik bilgileri verir.  

TickIT Scheme sertifikasyon sürecindeki değerlendirme en az iki aşamalı bir süreçtir:

Organizasyonun kalite sistemi, standarda (TickIT için: ISO 9001) göre muhakeme edilir.

Organizasyon, pratikte gerçekten kendi kalite sistemine ve standarda uyumlu çalışıp çalışmadığı denetlenir, ve kalite sisteminin etkinlik derecesine bakılır (Yazılımcılar
Dünyası, 2017).

Bölüm Özeti
Kalite “ihtiyaçları karşılama yeteneği”, “kullanıcı gereksinimlerine uygunluk”, “ilk seferde doğrusunu yapmak”, “amaçlanan kullanıma uygunluk” gibi farklı farklı
şekillerde tanımlanmaktadır. Kalite; kalite kontrol, kalite yönetimi, kalite planlama,  kalite geliştirme, kalite denetimi, kalite sistemi, kalite güvencesi gibi kavramların
birleşiminden oluşmaktadır. Yazılım testinde olduğu gibi yazılım kalitesinde de pek çok doğru bilinen yanlış mevcuttur. Bunlar genel olarak 

Doğru Bilinen Yanlış 1: Kalite soyut bir kavramdır ve ölçülemez.

Doğru Bilinen Yanlış 2: Daha iyisini yapmanın maliyeti başlangıçta karşılanamaz.

Doğru Bilinen Yanlış 3: Kalite problemlerine en alt kademede çalışanlar sebep olur.

Doğru Bilinen Yanlış 4: Kaliteyi, kurumların kalite ile ilgili bölümleri başlatır.

şeklindedir.

Kalite maliyeti, bir ürün ve sürecin kaliteli olması için gereli olan maliyet ya da ürünler ve onları üreten süreçler mükemmel olduğunda ortadan kalkacak toplam
maliyet olarak ifade edilebilir. Temel olarak, uygunsuzluk maliyeti, uygunluğu sağlama maliyeti, hata maliyeti, hata bulma maliyeti ve hata önleme maliyeti gibi farklı
maliyetlerden oluşmaktadır.

Kaliteli yazılım;

 kabullenebilir düzeyde hata seviyesine sahip,

 müşteri ve kullanıcı gereksinimlerini karşılayan,

 amaçlanan kullanıma uygun,

 zamanında (veya en azından küçük bir gecikme ile) tamamlanmış,

 belirlenen bütçe sınırları içinde (veya en azından küçük bir farklılıkla) gerçekleştirilmiş,

 var olan kanunlara, kurallara, standartlara uyumlu,

 gerekli olduğunda bakımı sağlanabilen

yazılımlardır.

94
Yazılımlarda her ne kadar diğer sektörlerdeki ürünler kadar keskin sertifikasyonlar bulunmasa da yazılımda kaliteyi sağlayabilmek için bazı olgunluk ve yetenek
modelleri kullanılmaktadır. Bu modeller

 CMM (Capability Maturity Model – Yetenek Olgunluk Modeli)

 ISO 9000

 TRILLIUM

 SPICE (Software Process Improvement and Capability Determination ISO 15504)

 ve

 TICKIT’tir.

Kaynakça

https://www.kesir.com.tr/kalite-yonetim-ve-isg-kalite

http://danismend.com/kategori/altkategori/yazilimda-kalite/

A. Öztürk, Kalite Yönetimi ve Planlaması, Ekin Yayıncılık, Bursa, ISBN 978-9944-141-79-6

P. James, Total Quality Management, Prentice Hall Europe, Hertfordshire, ISBN 0-13-207119-3

http://www.kalitesistem.com/ebulten/ocak2011/gidaguvenligi_2.htm

http://ismailsen.com.tr/yazilim-kalite-guvencesi-ve-standartlar/

T. Cura, Yönetim Bilişim Sistemler, AUZEF Ortak Ders Kitabı

H. Kazan,  Proje Yönetimi, AUZEF Ortak Ders Kitabı

C. Gencer, A. Kayacan, Yazılım Proje Yönetimi: Şelale Modeli ve Çevik Yöntemlerin Karşılaştırılması, Bilişim Teknolojileri Dergisi, 10(3), Sayfa: 335-352, 2017

A. Adıyahşi, Refactoring Prensipleri - Niçin Refactoring Yapmalıyız, 2017

Kalder Ankara, Yazılımda Kalitenin Önemi, 2021

ISO Kalite Yönetim Sistemleri, 2021

M. Özkan, Yazılımda Kalite, 2021

Yazılımcılar Dünyası, 2017

Ünite Soruları

Soru-1 :

Aşağıdakilerden hangisi kalite ile ilgili temel kavramlardan biri değildir?

(•) - Kalite kontrol

(•) - Kalite güvencesi

(•) - Kalite denetimi

(•) - Kalite oluşturma

(•) - Kalite yönetimi

Cevap-1 :

Kalite oluşturma

Soru-2 :

Aşağıdakilerden hangisi kalite ile ilgili doğru bilinen bir yanlış değildir?

(•) - Kalite test ile tamamen paralel olarak ilerler.

(•) - Kalite soyut bir kavramdır ve ölçülemez.

(•) - Daha iyisini yapmanın maliyeti başlangıçta karşılanamaz.

(•) - Kalite problemlerine en alt kademede çalışanlar sebep olur.

(•) - Kaliteyi, kurumların kalite ile ilgili bölümleri başlatır.

95
Cevap-2 :

Kalite test ile tamamen paralel olarak ilerler.

Soru-3 :

Ürün ve/veya hizmetlerin hedeflenen amaçlara uygun olup olmadığını tespit etme maliyeti genel olarak aşağıdaki isimlerin hangisi ile anılmaktadır?

(•) - Hata Bulma Maliyeti

(•) - Analiz Maliyeti

(•) - Tasarım Maliyeti

(•) - Hata Önleme Maliyeti

(•) - Planlama Maliyeti

Cevap-3 :

Hata Bulma Maliyeti

Soru-4 :

Aşağıdakilerden hangisi bir yazılımın kalitesiz olmasının müşteri/kullanıcı tarafındaki sebeplerinden biri değildir?

(•) - gereksinimlerin sağlanamayışı

(•) - kolay anlaşılabilir ve kullanılabilir olmaması

(•) - çalışanların tatminsizliği

(•) - istenilen zamanda bakım yapılabilir olmaması

(•) - eğitim desteğinin yetersiz olması

Cevap-4 :

çalışanların tatminsizliği

Soru-5 :

Aşağıdakilerden hangisi bir yazılımın kalitesiz olmasının yazılım ekibi tarafındaki sebeplerinden biri değildir?

(•) - yüksek maliyet

(•) - çalışanların tatminsizliği

(•) - firmaya olan güven kaybı

(•) - istenilen zamanda bakım yapılabilir olmaması

(•) - geciken ya da bitmeyen projeler

Cevap-5 :

istenilen zamanda bakım yapılabilir olmaması

Soru-6 :

Yazılım Kalite Güvencesi (YKG), Doğrulama ve Geçerleme (D&G) ve test arasındaki ilişki aşağıdakilerden hangisi ile ifade edilebilir?

(•) - YKG > Test > D&G

(•) - D&G > YKG > Test

(•) - Test > D&G > YKG

(•) - D&G > Test > YKG

(•) - YKG > D&G > Test

Cevap-6 :

YKG > D&G > Test

96
Soru-7 :

Aşağıdaki şekilde A, B ve C ile verilenler sırasıyla aşağıdakilerden hangisi olabilir?

(•) - Tasarım – Birim Testi – Bakım

(•) - Birim Testi – Bakım – Tasarım

(•) - Bakım – Tasarım – Birim Testi

(•) - Tasarım – Bakım – Birim Testi

(•) - Birim Testi – Tasarım – Bakım

Cevap-7 :

Tasarım – Birim Testi – Bakım

Soru-8 :

Bir yazılım projesinin boyutunun çok büyük olması ve birçok kişi tarafından geliştirilmesi, aşağıdakilerden hangisinin kalitede rol oynamasına sebep
olmaktadır?

(•) - Sık Sık Kod Düzeltmeleri Uygulamak

(•) - Diğer yazılım ekipleriyle işbirliği ve koordinasyon

(•) - Diğer yazılım sistemleri ile arayüzler

(•) - Yazılım Gereksinimlerini İyice Analiz Etmek

(•) - Sık Sık Regresyon Testi Gerçekleştirmek

Cevap-8 :

Diğer yazılım ekipleriyle işbirliği ve koordinasyon

Soru-9 :

Refactoring nedir?

(•) - Kod Düzeltmeleri Uygulamak

(•) - Yazılım Gereksinimlerini Analiz Etmek

(•) - Regresyon Testi Gerçekleştirmek

(•) - Uzman Ekip Üyelerine Güvenmek

(•) - Sistematik Kusurları Önceliklendirmek

Cevap-9 :

Kod Düzeltmeleri Uygulamak

97
10. YAZILIM KALİTE METRİKLERİ
Giriş
Daha önceki bölümlerde de ifade edildiği gibi yazılımlar elle tutulur, gözle görülür ürünler olmadıklarından yazılımlar ile ilgili ölçümler yapmak oldukça zordur. Hele ki
kalite gibi subjektif bir kavramın ölçülmesi daha da zor olacaktır. Bu sebeple yazılım ürünlerinin kalitesini ölçmek için çeşitli farklı metrik grupları ve otomatik araçlar
geliştirilmiştir. Bu bölümde yazılımların kalitesini ölçmek için kullanılan farklı metrik grupları ve yazılım araçları açıklanmıştır.

10.1. Genel Kalite Metrikleri

Bir yazılımın kalitesinin ölçülmesi ile ilgili birçok metrik bulunmaktadır. Bu metrikler kendi içlerinde de çeşitli şekillerde gruplandırılabilirler. En önemli gruplar

 Fonksiyonalite Metrikleri

 Taşınabilirlik Metrikleri

 Sürdürülebilirlik Metrikleri

 Kullanılabilirlik Metrikleri

 Verimlilik Metrikleri

 Güvenlik/ Güvenilirlik Metrikleri

 İzlenebilirlik Metrikleri

 Uyumluluk Metrikleri

şeklinde ifade edilebilir.

10.1.1. Fonksiyonalite Metrikleri

Fonksiyonalite metrikleri bir yazılım bileşeni ya da sisteminin işlevleri yerine getirip getirmediğini inceleyen metriklerdir. Fonksiyonalite, doğruluk ve birlikte
çalışabilirlik bu kategori altında ele alınmaktadır.

Fonksiyonalite: Bir yazılımın belirlenen ve varsayılan ihtiyaçları yerine getiren fonksiyonları sağlayabilme yeteneğidir. Şekil 10.1.’de fonksiyonalite metriğinin temsilî
bir gösterimi verilmiştir (Kavan İnşaat, 2018)

Şekil 10.1. Fonksiyonalitenin Temsilî Bir Gösterimi

Doğruluk: Yazılım ürününün doğru veya kabul edilen sonuçları ya da etkilerini istenen hassasiyet derecesinde sağlayabilme yeteneğidir.  Şekil 10.2.’de doğruluk
metriğinin temsilî bir gösterimi verilmiştir (Warren, 2021).

Şekil 10.2. Doğruluğun Temsilî Bir Gösterimi

Birlikte çalışabilirlik: Yazılımın bir veya daha fazla bileşen veya sistem ile etkileşimde olabilme yeteneğidir. Şekil 10.3.’te birlikte çalışabilirlik metriğinin temsilî bir
gösterimi verilmiştir (Blochchain Türkiye, 2020).

Şekil 10.3. Birlikte Çalışabilirliğin Temsilî Bir Gösterimi

98
10.1.2. Taşınabilirlik Metrikleri

Taşınabilirlik metrikleri bir yazılım bileşeni ya da sisteminin birçok farklı ortamda rahat bir şekilde çalışıp çalışmadığını inceleyen metriklere verilen isimdir.
Günümüzde mobil teknolojilerin, bulut teknolojilerinin ve Nesnelerin Interneti kavramının yaygınlaşması neticesinde önemi gittikçe artan bu metrik grubu içerisinde
taşınabilirlik, uyarlanabilirlik, kurulabilirlik ve değiştirilebilirlik metrikleri yer almaktadır.

Taşınabilirlik: Yazılımın bir ortamdan başka bir ortama ne kadar kolay taşınabildiğinin ölçüsüdür.

Uyarlanabilirlik: Yazılım ürününün, farklı özellikteki ortamlara ekstra bir aksiyon gerektirmeden adapte edilebilme yeteneğidir.  Şekil 10.4.’te uyarlanabilirliğin
temsilî bir gösterimi verilmiştir (Ksb, 2021).

Şekil 10.4. Uyarlanabilirliğin Temsilî Bir Gösterimi

Kurulabilirlik: Yazılımın belli bir ortama kurulabilme yeteneğidir.

Değiştirilebilirlik: Bir yazılımın başka bir yazılımın yerine aynı amaçlar doğrultusunda aynı ortam üzerinde kullanılabilmesi yeteneğidir.

10.1.3. Sürdürülebilirlik Metrikleri

Bir yazılım bileşeninin ya da sisteminin uzun süre boyunca verimli bir şekilde kullanılabilmesi ve yapılan değişiklikler neticesinde de kullanılmaya devam edebilmesi
anlamına gelen bu kategori altında sürdürülebilirlik, çözümlenebilirlik, kararlılık, test edilebilirlik ve bakım yapılabilirlik metrikleri yer almaktadır.

Sürdürülebilirlik: Bir yazılımda hataların giderilmesi, yeni gereksinimlerin karşılanması, gelecek bakımların kolaylaştırılması veya değişen ortama uydurulmasının
kolaylığıdır. Şekil 10.5.’te sürdürülebilirliğin temsilî bir gösterimi verilmiştir (Prysmian Group, 2021).

Şekil 10.5. Sürdürülebilirliğin Temsilî Bir Gösterimi

Çözümlenebilirlik: Yazılım ürünündeki eksikliklere veya hata nedenlerine ya da değiştirilmesi gereken parçalara tanı konulabilmesi yeteneğidir.

Kararlılık: Bir yazılımın, değişikliklerin sebep olabileceği beklenmeyen etkileri önleme yeteneğidir.

Test edilebilirlik: Yazılımın üzerinde değişiklik yapıldıktan sonra da test edilmesine olanak verme yeteneğidir.

Bakım yapılabilirlik: Yazılımın değiştirilme kolaylığıdır.

10.1.4. Kullanılabilirlik Metrikleri

Bir yazılım bileşeni ya da sistemi ne kadar hatasız ne kadar işlevsel olursa olsun eğer kullanıcılar tarafından rahat bir şekilde kullanılamıyorsa bir anlamı yoktur. Buna
göre kullanılabilirlik metrikleri kategorisi oldukça önemlidir. Kullanılabilirlik, çekicilik, öğrenilebilirlik, işletilebilirlik ve anlaşılabilirlik metrikleri bu kategori içerisine
girmektedir.

Kullanılabilirlik: Yazılımın, belirlenmiş koşullar altında kullanıldığında, kullanıcı için çekici, kolay kullanılır, öğrenilebilir ve anlaşılabilir olma yeteneğidir. Şekil
10.6.’da kullanılabilirliğin temsilî bir gösterimi verilmiştir (Alagöz Bilişim, 2021).

Şekil 10.6. Kullanılabilirliğin Temsilî Bir Gösterimi

Çekicilik: Yazılım ürününün kullanıcının ilgisini çekme yeteneğidir.

Öğrenilebilirlik: Yazılımın, kullanıcının ürünün kullanımını öğrenmesini sağlama yeteneğidir.

99
İşletilebilirlik: Yazılımı kullanıcıya sağladığı çalıştırılma ve kontrol edilebilme yeteneğidir.

Anlaşılabilirlik: Kullanıcının, yazılımın kendisi için kullanışlı olup olmadığını, kullanım koşullarını ve nasıl kullanılacağını anlayabileceği yazılım ürünü yeteneğidir. Şekil
10.7.’de anlaşılabilirliğin temsilî bir gösterimi verilmiştir (Durmuş, 2018).

Şekil 10.7. Anlaşılabilirliğim Temsilî Bir Gösterimi

10.1.5. Verimlilik Metrikleri

Bir yazılım bileşeninin ya da sisteminin en az girdi ile en çok çıktıyı/ürünü verme yeteneğini inceleyen bu metrik kategorisinde yer alan metrikler verimlilik, etkinlik ve
performanstır.

Verimlilik: İki şekilde tanımlanır.

 Bir yazılımın belirlenen şartlar altında kullanılan kaynakların miktarına bağlı olarak uygun performansı sağlama yeteneğidir.

 Kullanılan kaynak miktarına bağlı olarak bir sürecin planlanan çıktıyı üretebilme yeteneğidir.

Etkinlik: Planlanan sonucu üretebilme yeteneğidir.

Performans: Bir sistemden veya bileşenden beklenen fonksiyonalitenin işlem süresi ve verim oranı kısıtları dahilinde başarılı bir şekilde gerçekleştirilme derecesidir.
Şekil 10.8.’de performansın temsilî bir gösterimi verilmiştir (Yönetim Günlüğü, 2013).

Şekil 10.8. Performansın Temsilî Bir Gösterimi

10.1.6. Güvenlik/Güvenilirlik Metrikleri

Bir yazılım bileşeninin güvenli olması yani kolay kolay çökmemesi ve güvenilir olması yani her durumda doğru sonuç üretmesi yeteneklerinin incelendiği metrik
kategorisidir. İçerisinde güvenlik, güvenilirlik, kurtarılabilirlik, sağlamlık, olgunluk ve hata toleransı metrikleri yer almaktadır.

Güvenlik: Yazılımın fonksiyonlarına veya verilerine yetkisiz erişimi ne kadar önleyebildiğinin derecesidir.

Güvenilirlik: Belirli durumlar altında, belirli bir zaman aralığında veya belirli sayıda operasyonel iş için yazılımın beklenilen işlevselliklerini yerine getirebilme
yeteneğidir.
Şekil 10.9’da güvenilirliğin temsilî bir gösterimi verilmiştir (Ergül, 2006).

Şekil 10.9. Güvenilirliğin Temsilî Bir Gösterimi

Kurtarılabilirlik: Arıza sonrasında, yazılımın eski performans seviyesine geri dönmesi ve arızanın neden olduğu veri kayıplarını giderebilme yeteneğidir.

Sağlamlık: Bir bileşenin veya sistemin geçersiz girdiler veya stresli çevresel koşullarda fonksiyonunu yerine getirebildiğinin derecesidir. Şekil 10.10’da sağlamlığın
temsilî bir gösterimi verilmiştir (Keskin, 2017).

100
Şekil 10.10. Sağlamlığın Temsilî Bir Gösterimi

Olgunluk: Süreçlerin ve iş uygulamalarının etkinliği ve verimliliği açısından bir kurumun sahip olduğu yeterliliktir.

Hata Toleransı: Yanlış girdiler olmasına rağmen bir sistem veya bileşenin normal operasyonuna devam edebilme yeteneğidir.

10.1.7. İzlenebilirlik Metrikleri

Bir yazılım bileşeni veya sisteminin takip edilebilirliği anlamına gelen izlenebilirlik metrikleri kategorisinde yer alan metrikler izlenebilirlik, dikey izlenebilirlik, yatay
izlenebilirlik, karmaşıklık ve elverişliliktir.

İzlenebilirlik: Gereksinimlerin testlerle ilişkilendirilmesi gibi, yazılım ve dokümantasyonun içinde birbiriyle ilgili öğelerin ilişkilendirilmesidir. Şekil 10.11’de
izlenebilirliğin temsilî bir gösterimi verilmiştir (Asbcert, 2021).

Şekil 10.11. İzlenebilirliğin Temsilî Bir Gösterimi

Dikey izlenebilirlik: Gereksinimlerin yazılım geliştirme dokümanlarının katmanlarından bileşenlere kadar izlenmesidir.

Yatay izlenebilirlik: Bir test seviyesindeki gereksinimlerin test dokümanlarının katmanları arasında izlenilebilmesidir (Örneğin test planı, test tasarım spesifikasyonu,
test senaryosu spesifikasyonu ve test süreci spesifikasyonu veya test betiği).

Karmaşıklık: Bir bileşen ya da sistemin tasarım ve/veya içyapısının anlaşılmasının, bakımının ve doğrulanmasının zorluğunu gösteren derecedir. Şekil 10.12’de
karmaşıklığın temsilî bir gösterimi verilmiştir (Demirtaş, 2018).

Şekil 10.12. Karmaşıklığın Temsilî Bir Gösterimi

Elverişlilik: Bir bileşen veya sistemin kullanılması gerektiğinde, operasyonel ve erişilebilir olma derecesidir.

10.1.8. Uyumluluk Metrikleri

Bazı noktalarda taşınabilirlik ile paralellik gösteren uyumluluk metrikleri bir yazılım bileşeni veya sisteminin farklı işletim sistemleri, farklı donanımlar, farklı yazılım
versiyonları, farklı IDE’ler, farklı web tarayıcıları gibi elemanlar kullanıldığında da aynı şekilde kullanılabilme yeteneği olarak ifade edilir. Uyumluluk, tutarlılık,
eşzamanlılık, yerelleştirilebilirlik ve ölçeklenebilirlik bu kategori altında yer alan metriklerdir.

Uyumluluk: Yazılımın standartlara, sözleşme hükümlerine veya kanun ve benzeri yönergelerdeki düzenlemelere uygunluğudur.

Tutarlılık: Bir bileşen ya da sistemin dokümanları ve parçaları arasındaki standardizasyon, tutarlılık ve çelişkiden uzaklık derecesidir.

Eşzamanlılık: Yazılımın aynı anda aynı kaynaklara birden fazla istekte bulunma yeteneğidir.

Yerelleştirilebilirlik: Yazılımın farklı dillerde, saat dilimlerinde vb. kullanılabilmesidir. Şekil 10.13’te yerelleştirilebilirliğin temsilî bir gösterimi verilmiştir (Games,
2021).

101
Şekil 10.13. Yerelleştirilebilirliğin Temsilî Bir Gösterimi

Ölçeklenebilirlik: Yazılım ürününün daha fazla yük kaldıracak şekilde yükseltilme yeteneğidir. Şekil 10.14’te ölçeklenebilirliğin temsilî bir gösterimi verilmiştir
(Kobibt, 2021).

Şekil 10.14. Ölçeklenebilirliğin Temsilî Bir Gösterimi

10.2. Yordamsal Kod Metrikleri

Yordamsal Kod Metrikleri: Yordamsal Programlama yaklaşımı kullanılarak gerçekleştirilen yazılımların ölçülmesi için kullanılan metriklerdir. McCabe, Kod satır
sayısı ve Halstead metrikleri bu alanda kullanılan metrikler olarak ifade edilebilir.  NATO’nun katkılarıyla 1968 yılında düzenlenen ilk Yazılım Mühendisliği
konferansında, Yazılım Krizi’nin ortaya çıktığı ve yazılım sistemlerinin gittikçe daha karmaşık hale geldiği ifade edilmiştir. Programlama alanındaki gelişmelerin
ilerlemesiyle, daha yüksek soyutlama düzeyinde yazılım geliştirilmesini sağlamıştır. Bu değişimi; Assembly programlama dili, makine kodunun kullanılması, 3. nesil
olarak ifade edilebilen C gibi yordamsal (procedural) diller, SQL (Structured Query Language – Yapılandırılmış Sorgu Dili) gibi 4. nesil diller, C++ gibi nesneye
yönelik programlama dilleri, C gibi yordamsal programlama dillerinde geliştirilmiş kodlar için kullanılabilen metrikler açıklanmaktadır. Böylece, benzer şekilde
nesneye yönelik programlamada da metotlar yer aldığı için buradaki metot seviyesindeki metrikleri o yaklaşımlarda kullanmaya imkân sağlamıştır. En çok bilinen ve
kullanılan yordamsal kod metrikleri, McCabe ve Halstead metrikleridir.

 McCabe Metrikleri: 1976 yılında McCabe, çevrimsel karmaşıklık (cyclomatic complexity) adını verdiği ve yazılımın kontrol akışını ölçen bir metod geliştirmiştir.
Bu metod, metriklerin karmaşıklığını ölçerek bakım yapılabilirliği ve test süreci zor olan modülleri belirlemeyi sağlamaktadır. McCabe metrikleri içerisinde, en fazla
popülerlik kazanan metrik çevrimsel karmaşıklık olup daha birçok McCabe metriği mevcuttur. 

 Halstead Kod Metrikleri: Yazılım ölçümü konusunda Maurice Halstead, Thomas McCabe ile birlikte öncü isimler olarak verilebilir. Halstead, kendi yaklaşımına
göre yazılım bilimi metriklerini (software science metrics), temel ve türetilmiş metrikler olarak iki temel gruba ayırmıştır.

10.3. Nesneye Yönelik Kod Metrikleri

Nesneye Yönelik Kod Metrikleri: Nesneye Yönelik Programlama yaklaşımı kullanılarak gerçekleştirilen yazılımların ölçülmesi için kullanılan metriklerdir.

 QMOOD (Quality Model for Object Oriented Design – Nesneye Yönelik Tasarım İçin Kalite Modeli),

 Chidamber-Kemerer metrik kümesi 

 MOOD (Metrics for Object Oriented Design – Nesneye Yönelik Tasarım için Metrikler) metrik kümeleri

bu kod metriklerine örnek olarak verilebilir (Chidamber ve Kemerer, 1994). 1990 yıllarında nesneye yönelik sistemler için birçok metrik önerilmiş olmasına rağmen
bunlardan en çok kullanılanları Chidamber-Kemerer metrik grubudur. Birçok araç geliştiricisi ve araştırmacı bu metrikleri kullanmıştır. Metriklerin kısaltmaları,
sıklıkla kullanılan İngilizce karşılıkları, Türkçe isimleri ve açıklamaları aşağıda yer almaktadır.

 WMC (Weighted Method per Class – Sınıfın Ağırlıklı Metot Sayısı): Chidamber & Kemerer Yazılım Metrik Seti’ne ait bir metriktir. Bir sınıfta yer alan
metot sayısıdır. Bu metrik, tüm sınıfların karmaşıklığını gösterir. WMC kullanarak, proje ekibi geliştirme çabaları tahmin edilebilir (Chidamber ve Kemerer, 1994;
Virtual Machinery, 1998).

 DIT (Depth of Inheritance Tree – Kalıtım Ağacının Derinliği): Chidamber & Kemerer Yazılım Metrik Seti’ne ait bir metriktir. Bir sınıftan kalıtım
ağacındaki kök elemana olan en uzak yolun uzaklığıdır. Ağaçlarda alt düğüm ve kök arasındaki maksimum derinlik anlamına gelir. Burada kalıtım ağacı, sınıfların
yapısını gösterir. Kök üst sınıftır ve alt düğümler alt sınıflardır.

 NOC (Number of Children – Alt Sınıf Sayısı): Chidamber & Kemerer Yazılım Metrik Seti’ne ait bir metriktir. Bir sınıftan türeyen sınıfların sayısı ya da sınıfın
çocuklarının sayısıdır. Her sınıfın kendisine ait bir NOC değeri bulunmaktadır.

 CBO (Coupling between Object Classes – Nesne Sınıfları Arasındaki Bağımlılık):

Chidamber & Kemerer Yazılım Metrik Seti’ne ait bir metriktir. Bir sınıfın kalıtım dışında bağlı olduğu farklı sınıfların sayısını ifade eder. A sınıfı B sınıfının özelliklerini
(attribute) veya operasyonlarını kullanıyorsa, A sınıfının B sınıfına bağlı (coupled) olduğu söylenir. CBO değeri bu özelliğe sahip olan tüm sınıfların sayısının
toplamıdır.

 RFC (Response for a Class – Sınıfın Tetiklediği Metot Sayısı): Chidamber & Kemerer Yazılım Metrik Seti’ne ait bir metriktir. Bir sınıf içerisinde yer alan
kalıtımdan gelen metot sayısı ile metot sayısının toplamıdır. RFC arttığında test ve debug işlemi zorlaşır.

 LCOM (Lack of Cohesion in Methods – Metotlardaki Uyum Eksikliği): Chidamber & Kemerer Yazılım Metrik Seti’ne ait bir metriktir. Her özellik
(attribute) için o özelliği kullanan metotların yüzdesi belirlenip ortalaması alındıktan sonra bu değerin 100’den çıkarılması ile bulunan değerdir. Sınıf içi kohezyon
yüksek olması gerekirken, sınıflar arası bağlılık (coupling) düşük olmalıdır.

 MHF (Method Hiding Factor – Metot Gizleme Faktörü): MOOD (Brito e Abreu olarak da adlandırılır) Metrik Seti’ne ait bir metriktir. Burada gizleme
kapsülleme anlamına gelmektedir (Abreu ve diğ., 1996) ve kapsüllenen yöntem sayısı ile ilgili bir metriktir. MHF ile kapsüllenen yöntem sayısı arasındaki ilişki
aşağıdaki şekilde ifade edilebilir.

MHF = 1 – (Görünen Metotlar – (Toplam Metot Sayısı – 1))

102
 AHF (Attribute Hiding Factor – Özellik Gizleme Faktörü): MOOD Metrik Seti’ne ait bir metriktir. MHF’ye benzer şekilde burada gizleme kapsülleme
anlamına gelmektedir. Ancak burada kapsüllenen eleman metot değil özelliklerdir. AHF ile kapsüllenen özellik sayısı arasındaki ilişki aşağıdaki şekilde ifade edilebilir.

AHF = 1 – (Görünen Özellikler – (Toplam Özellik Sayısı – 1))

 MIF (Method Inheritance Factor – Metot Kalıtım Faktörü): MOOD Metrik Seti’ne ait bir metriktir. Kalıtım işlemine uğramış metotların tüm metotlara
oranı olarak hesaplanır. 0-100 arasında bir değere sahiptir. Çok düşük ya da çok yüksek bir orana sahip olmaması yazılım açısından daha uygun görülmektedir ve
optimal bir oranda olması beklenmektedir. Mood Metrik Setini oluşturan Fernando Brito e Abreu, kabul edilebilir MIF oranının %80’den daha düşük olması
gerektiğini ifade etmiştir. MIF hesaplama formülü aşağıdaki gibidir.

MIF = kalıtım işlemine uğramış metot sayısı/tüm metotların sayısı

 AIF (Attribute Inheritance Factor – Özellik Kalıtım Faktörü): MOOD Metrik Seti’ne ait bir metriktir. Kalıtım işlemine uğramış özelliklerin tüm özelliklere
oranı olarak hesaplanır. 0-100 arasında bir değere sahiptir. AIF hesaplama formülü aşağıdaki gibidir.

AIF = kalıtım işlemine uğramış özellik sayısı/tüm özelliklerin sayısı

 POF (Polimorphism Factor – Polimorfizm Faktörü): MOOD Metrik Seti’ne ait bir metriktir. Olası tüm değişik polimorfizm seçeneklerinin sayısını gösterir.
Geçersiz kılınan metot sayısının, geçersiz kılınabilecek tüm yöntemlerin sayısına oranı olarak hesaplanır. 0-100 arasında bir değere sahiptir. POF 100’e eşitse,
türetilmiş sınırlardaki tüm olası metotlar geçersiz kılınmış anlamına gelmektedir. Eğer POF 0’a eşitse hiçbir metot geçersiz kılınmamıştır.

 COF (Coupling Factor – Eşleme Faktörü): MOOD Metrik Seti’ne ait bir metriktir. Sınıflar arasındaki eşleştirme sayısının olası tüm eşleştirmelere oranı
şeklinde hesaplanır. 0-100 arasında bir değere sahiptir. C1 ve C2 2 sınıf olmak üzere, eğer C1 C2’nin metotlarını çağırır ve C2’nin değişkenlerine ulaşabilirse, bu
durumda C1’in C2 ile eşleşmiş olduğu söylenebilir. Ancak C2, C1 ile eşleşmiş değildir.
İki sınıf arasındaki iletişim tek yönlüdür.

 ANA (Average Number of Ancestors – Ortalama Ata Sayısı): Bansiya ve Davis tarafından oluşturulmuş olan QMOOD Metrik Seti’ne aittir. Bu metrik kök
sınıftan bir yapıdaki tüm sınıflara olan yollardaki sınıfların sayısını ifade eder (Bansiya ve Davis, 2002). Bu metrik, kullanıcılara projenin kalıtım durumu ile ilgili fikir
vermektedir.

 CAM (Cohesion Among Methods of Class – Sınıf Metotları Arasındaki Uyum): QMOOD Metrik Seti’ne ait bir metriktir. Bu değer, bir metotun
parametreleri ile bir sınıftaki tüm parametre türlerinin maksimum bağımsız kümesinin kesişimi şeklinde hesaplanır (Sandhu ve diğ,, 2005). Değer aralığı 0-1
arasındadır. En düşük değer olan 0 en kötü durumu, en yüksek değer olan 1 en iyi durumu ifade eder.

 CIS (Class Interface Size – Sınıf Arayüz Boyutu): QMOOD Metrik Seti’ne ait bir metriktir. Bir sınıftaki açık (public) metotların sayısıdır.

 DAM (Data Access Metric –  Veri Erişim Metriği): QMOOD Metrik Seti’ne ait bir metriktir. Bir sınıftaki özel (private ve protected) metotların tüm
metotlara oranıdır (Goyal ve  diğ., 2014). Değer aralığı 0-1 arasındadır. Genel olarak yüksek DAM oranı tercih edilmektedir.

 DCC (Direct Class Coupling – Doğrudan Sınıf Eşleme): QMOOD Metrik Seti’ne ait bir metriktir. Başka bir sınıfla ilişkisi olan sınıfların sayısını ifade
etmektedir. Burada ilişki olarak ifade edilen, türetme, mesajlaşma, özellik belirtme vb herhangi bir şey olabilir.

 MOA (Measure Of Aggregation – Toplama Ölçüsü): QMOOD Metrik Seti’ne ait bir metriktir. Veri türlerini kontrol eder ve kullanıcı tarafından oluşturulmuş
veri türlerinin sayısını elde etmeye çalışır. Kullanıcı tarafından tanımlanmış veri türleri kullanılıyorsa MOA değeri artacaktır. 

 MFA (Measure of Functional Abstraction – Fonksiyonel Soyutlama Ölçüsü): QMOOD Metrik Seti’ne ait bir metriktir. Kalıtım işlemine uğramış
metotların toplam metotların sayısına oranıdır. Değer aralığı 0-1 arasındadır.

 NOM (Number of Methods – Metotların Sayısı): QMOOD Metrik Seti’ne ait bir metriktir. Bir sınıftaki tüm metotların sayısını ifade eder.

10.4. Yazılım Kalite Metrikleri ile İlgili Araçlar

Günümüzde yazılım kalitesinin ölçülmesi ile ilgili pek çok araç bulunmaktadır. Bu bölümde bu araçlar incelenmiştir.

10.4.1. Understand

Understand kaynak kodu anlama, metrikler ve standart testlerine odaklanan statik bir analiz aracıdır. Büyük miktarda eski veya yeni oluşturulmuş kaynak kodunun
korunmasına ve anlaşılmasına yardımcı olmak için tasarlanmıştır. Platformlar arası, çok dilli, bakım odaklı bir IDE sağlar. Analiz edilen kaynak kodu C, C++, C#,
Objective C/Objective C++, Ada, Assembly, Visual Basic, COBOL, Fortran, Java, JOVIAL, Pascal/Delphi, PL/M, Python, VHDL ve Web (PHP, HTML, CSS,
JavaScript ve XML) dillerinde yazılmıştır. Ayrıntılı bir çapraz platform, sözdizimi renklendirici bir “akıllı” düzenleyici ve çeşitli grafiksel tersine mühendislik görünümü
kullanarak kod navigasyonu sunar (Scientific Toolworks, 2021).
Bir dizi görsel, belge ve metrik araç aracılığıyla statik kod analizine olanak tanıyan özelleştirilebilir bir entegre geliştirme ortamıdır (IDE) (Dragomir, 2015).
Yazılım geliştiricilerin kaynak kodlarını anlamalarına, korumalarına ve belgelemelerine yardımcı olmak için oluşturulmuştur. İlişkilerin akış çizelgelerini sağlayarak ve
sağlanan bir kaynak koddan değişkenler ve prosedürler sözlüğü oluşturarak kodun anlaşılmasını sağlar (Martin, 2011). Entegre bir geliştirme ortamı olarak işlev
görmenin yanı sıra, ölçümler ve raporlar, standartlar testi, dokümantasyon, arama, grafik oluşturma ve kod bilgisi için araçlar sağlar. Milyonlarca satır kod içeren
projeleri analiz etme yeteneğine sahiptir ve birden çok dilde yazılmış kod tabanları ile çalışır (Adkins ve Jones, 2015). Aslen Ada için geliştirilmiş olup, artık birkaç
yaygın programlama dilinde geliştirmeyi desteklemektedir (Loren ve Johnson-Laird, 2015). Eclipse geliştirme ortamıyla entegrasyon da desteklenir. Understand,
devlet, ticarî ve akademik kullanım için, yazılımları hem analiz etmek hem de geliştirmek için birçok farklı endüstride global olarak kullanılmaktadır. Gömülü sistemler
için kod doğrulama (Adkins ve Jones, 2015), yazılım danışmanlığı (Loren ve Johnson-Laird, 2015), tersine mühendislik ve dokümantasyon (Brett, 2013) ve kaynak
kodu değişiklik analizi (Phillips ve Mok, 2015) gibi belirli kullanımlar için farklı uygulamaları gerçekleştirebilir. Şekil 10.15.’te örnek bir Understand aracı görüntüsü
gösterilmiştir.

103
Şekil 10.15. Örnek Bir Understand Aracı Görüntüsü

10.4.2. Sonargraph

Sonargraph, bir yazılım sistemini teknik kalite açısından izlemeye ve geliştirme sürecinin tüm aşamalarında yazılım mimarisi, metrikler ve diğer yönlerle ilgili kuralları
uygulamaya olanak tanıyan güçlü bir statik kod analizörüdür. Sonargraph platformu Java, C#, Python 3 ve C/C++'ı destekler ve yazılım mimarisini tanımlamak için
Groovy tabanlı komut dosyası oluşturma motoru ve DSL (etki alanına özel dil) gibi güçlü özellikler içerir (Eshow, 2015).
Sonargraph, Java, C#, C veya C++ ile yazılmış yazılımların statik kod analizi için ticarî bir araçtır. Kaynak kodu ayrıştırarak, analiz edilen kodun bellekte bağımlılık
ve ölçüm modelini oluşturur. Model bağımlılıkları daha sonra kullanıcının sistemin yapısını anlayabilmesi için grafiksel olarak görselleştirilebilir. Ayrıca araç, yazılım
mimarisi için tasarlanmış alana özgü bir dile dayalı olarak bir mantıksal mimari modelinin (yazılımın amaçlanan yapısı) tanımlanmasına izin verir. Mantıksal modeli
gerçek bağımlılık yapısıyla karşılaştırarak Sonargraph, tüm mimari ihlalleri (amaçlanan yapıdan sapmalar) bulur ve listeler.
Ayrıca Sonargraph, kullanıcının sorunlu kod bölümlerini saptamasına ve projesinin genel teknik kalitesini tahmin etmesine yardımcı olan çok çeşitli yazılım ölçümlerini
hesaplar. Ayrıca, genellikle istenmeyen olarak kabul edilen yinelenen kod bloklarını bulmaya da yardımcı olur. Groovy tabanlı bir komut dosyası oluşturma motoru,
kullanıcının kullanıcı tanımlı ölçümleri hesaplamasına ve özelleştirilmiş kod denetleyicileri oluşturmasına olanak tanır (Wikiwand, 2021). Şekil 10.16.’da örnek bir
Sonargraph aracı görüntüsü gösterilmiştir.

Şekil 10.16. Örnek Bir Sonargraph Aracı Görüntüsü

10.4.3. Findbugs

FindBugs, Java programlarındaki olası hataları tespit eden Bill Pugh ve David Hovemeyer tarafından oluşturulan açık kaynaklı bir statik kod analizörüdür (Ertemel,
2009; Markus, 2013; Ibm, 2021). FindBugs, kaynak kodu yerine Java bayt kodu (bytecode) üzerinde çalışır. Yazılım, bağımsız bir GUI uygulaması olarak dağıtılır.
Eclipse (Findbugs, 2015), NetBeans (NetBeans, 2015), IntelliJ IDEA (Code Google,  2015), Gradle, Hudson, Maven (Findbugs Maven, 2021), Bamboo
(Qaplug, 2021) ve Jenkins (Gleclaire, 2021) için de eklentiler mevcuttur. Yapılan kontrollerin sayısını artırmak için FindBugs'a ek kural setleri eklenebilir (Fb-
contrib, 2021).  Findbugs, Java programlarının statik kod analizi için açık kaynaklı bir araçtır. Kusurları ve/veya şüpheli kodu bulmak için sözde hata deseni için bayt
kodunu tarar (Methodsandtools, 2021). Şekil 10.17.’de örnek bir FindBugs aracı görüntüsü gösterilmiştir.

Şekil 10.17. Örnek Bir FindBugs Aracı Görüntüsü

10.4.4. Metrics

Metrics Eclipse projesinin bir uzantısı olarak geliştirilmiş başka bir açık kaynaklı programdır. Eclipse geliştirme ortamındaki Java programı, yaygın olarak kullanılan
birçok yazılım metriğini otomatik olarak ölçerek ve geliştiriciye rapor vererek entegre bir biçimde çalışabilir.
Statik fonksiyonların sayısı, türetme derinliği, bağımlılık, fonksiyonların karmaşıklığı, soyutlama sayısı gibi metrikler bunlardan sadece birkaçıdır. Metrikler ayrıca
yazılımdaki bağımlılıkları grafiksel olarak gösterme yeteneğine de sahiptir. Bu sayede geliştiricilerin yazılımdaki bağımlılıkları görsel olarak daha iyi analiz etmeleri
mümkün olmaktadır (Metrics Sourceforge, 2021). Şekil 10.18.’de örnek bir Metrics aracı görüntüsü gösterilmiştir.

104
Şekil 10.18. Örnek Bir FindBugs Aracı Görüntüsü

10.4.5. PMD

PMD, statik bir kaynak kod analizörüdür. Kullanılmayan değişkenler, boş yakalama blokları, gereksiz nesne oluşturma vb. gibi yaygın programlama kusurlarını bulur.
Esas olarak Java ve Apex ile ilgilidir, ancak JavaScript, Visualforce, PLSQL, Apache Velocity, XML, XSL'yi de destekler. Ek olarak, kopyala-yapıştır dedektörü
olan CPD'yi içerir. CPD, Java, C, C++, C#, Groovy, PHP, Ruby, Fortran, JavaScript, PLSQL, Apache Velocity, Scala, Objective C, Matlab, Python, Go, Swift
ve Apex ve Visualforce'da çoğaltılmış kod bulur (Pmd Github, 2021).

10.4.6. Coverlipse

Coverlipse, uygulama ve yazılım kodu ile gereksinimler ve test senaryoları arasındaki örtüşme ilişkisini inceleyen açık kaynaklı bir Eclipse eklentisidir. Program,
yazılım geliştirmenin bu üç temel aşaması arasındaki örtüşme ilişkilerini analiz ederek aralarındaki boşlukları ortaya çıkarır (Coverlipse, 2021).

10.4.7. Checkstyle

Checkstyle (Ertemel, 2009), Java kaynak kodunun kodlama kurallarına uyup uymadığını kontrol etmek için yazılım geliştirmede kullanılan statik bir kod analiz
aracıdır. CheckStyle programı, yazılım yapısından ziyade formatla ilgilenen başka bir açık kaynaklı yazılım aracıdır. Mevcut Java kodu üzerinde format analizi
yaparak geliştiricilerin kod yazma standartlarına uygun olarak çalışmasına yardımcı olur. Kurumun kendi yazı standartlarını oluşturabileceği bu yazılım, aynı zamanda
genel kabul görmüş bazı uluslararası yazı standartlarına da sahiptir (Checkstyle Sourceforge, 2021).

10.4.8. Coverity

Coverity, esasen tek bir araç değil temel olarak statik kod analiz araçlarından ve dinamik kod analiz hizmetlerinden oluşan bir yazılım geliştirme ürünleri markasıdır.
Araçlar, mühendislerin ve güvenlik ekiplerinin C, C++, Java, C#, JavaScript ve daha fazlasıyla yazılmış özel kaynak kodundaki kusurları ve güvenlik açıklarını
bulmasını sağlar (Wikiwand, 2021).

10.4.9. SDMetrics

SDMetrics, kod üzerinde değil, UML tasarım dokümanları üzerinde çeşitli görsel ve sayısal analizler yapabilen ticari bir programdır. Yazılımın tasarımını tasarım
aşamasından,
yani geliştirme aşamasından önce analiz ederek, program bağımlılık ve karmaşıklık ile ilgili birçok uygunsuzluğu ortaya çıkarabilir. Bu aşamada erken teşhis, maliyet
açısından da önemli olabilir. Ayrıca, eksik veya yanlış tasarımı ve dairesel bağımlılıklar veya adlandırma kuralları gibi stil yönergelerine uyumu otomatik olarak
algılamak için tasarım kurallarını da kontrol eder (Sdmetrics, 2021). Şekil 10.19.’da örnek bir SDMetrics aracı görüntüsü gösterilmiştir.

Şekil 10.19. Örnek Bir SDMetrics Aracı Görüntüsü

Bölüm Özeti

105
Bir yazılımın kalitesinin ölçülmesi ile ilgili birçok metrik bulunmaktadır. Bu metrikler Fonksiyonalite Metrikleri, Taşınabilirlik Metrikleri, Sürdürülebilirlik Metrikleri,
Kullanılabilirlik Metrikleri, Verimlilik Metrikleri, Güvenlik/Güvenilirlik Metrikleri, İzlenebilirlik Metrikleri ve Uyumluluk Metrikleri gibi genel gruplara ayrıldığı gibi
yordamsal kod metrikleri ve nesneye yönelik kod metrikleri gibi de gruplandırılabilir.

Fonksiyonalite Metrikleri,

 fonksiyonalite,

 doğruluk,

 birlikte çalışabilirlik;

Taşınabilirlik Metrikleri,

 taşınabilirlik,

 uyarlanabilirlik,

 kurulabilirlik,

 değiştirilebilirlik;

Sürdürülebilirlik Metrikleri,

 sürdürülebilirlik,

 çözümlenebilirlik,

 kararlılık,

 test edilebilirlik,

 bakım yapılabilirlik;

Kullanılabilirlik Metrikleri,

 kullanılabilirlik,

 çekicilik,

 öğrenilebilirlik,

 işletilebilirlik,

 anlaşılabilirlik;

Verimlilik Metrikleri,

 verimlilik,

 etkinlik,

 performans;

Güvenlik/Güvenilirlik Metrikleri,

 güvenlik,

 güvenilirlik,

 kurtarılabilirlik,

 sağlamlık,

 olgunluk,

 hata toleransı;

İzlenebilirlik Metrikleri,

 izlenebilirlik,

 dikey izlenebilirlik,

 yatay izlenebilirlik,

 karmaşıklık,

 elverişlilik;

Uyumluluk Metrikleri,

 uyumluluk,

 tutarlılık,

106
 eşzamanlılık,

 yerelleştirilebilirlik,

 ölçeklenebilirlik

şeklindedir.

Yordamsal Kod Metrikleri; McCabe Metrikleri ve Halstead Kod Metrikleri şeklindedir.  

Nesneye Yönelik Kod Metrikleri ise

 WMC (Weighted Method per Class – Sınıfın Ağırlıklı Metot Sayısı),

 DIT (Depth of Inheritance Tree – Kalıtım Ağacının Derinliği),

 NOC (Number of Children – Alt Sınıf Sayısı),

 CBO (Coupling between Object Classes – Nesne Sınıfları Arasındaki Bağımlılık),

 RFC (Response for a Class – Sınıfın Tetiklediği Metot Sayısı),

 LCOM (Lack of Cohesion in Methods – Metotlardaki Uyum Eksikliği),

 MHF (Method Hiding Factor – Meot Gizleme Faktörü),

 AHF (Attribute Hiding Factor – Özellik Gizleme Faktörü),

 MIF (Method Inheritance Factor – Metot Kalıtım Faktörü),

 AIF (Attribute Inheritance Factor – Özellik Kalıtım Faktörü),

 POF (Polimorphism Factor – Polimorfizm Faktörü),

 COF (Coupling Factor – Eşleme Faktörü),

 ANA (Average Number of Ancestors – Ortalama Ata Sayısı),

 CAM (Cohesion Among Methods of Class – Sınıf Metotları Arasındaki Uyum),

 CIS (Class Interface Size – Sınıf Arayüz Boyutu),

 DAM (Data Access Metric -  Veri Erişim Metriği),

 DCC (Direct Class Coupling – Doğrudan Sınıf Eşleme),

 MOA (Measure Of Aggregation – Toplama Ölçüsü),

 MFA (Measure of Functional Abstraction – Fonksiyonel Soyutlama Ölçüsü),

 NOM (Number of Methods – Metotların Sayısı)

şeklindedir.

Yazılım metriklerini ölçmek için birçok araç geliştirilmiştir. Bu araçların en önemlileri ve sahip oldukları özellikler ise şu şekildedir:

 Understand: Kaynak kodu anlama, metrikler ve standart testlerine odaklanan statik bir analiz aracıdır.

 Sonargraph: Bir yazılım sistemini teknik kalite açısından izlemeye ve geliştirme sürecinin tüm aşamalarında yazılım mimarisi, metrikler ve diğer yönlerle ilgili
kuralları uygulamaya olanak tanıyan güçlü bir statik kod analizörüdür.

 Findbugs:  Java programlarındaki olası hataları tespit eden açık kaynaklı bir statik kod analizörüdür.

 Metrics: Eclipse projesinin bir uzantısı olarak geliştirilmiş açık kaynaklı bir programdır.

 PMD: Kullanılmayan değişkenleri, boş yakalama bloklarını, gereksiz nesne oluşturma vb. gibi yaygın programlama kusurlarını bulan statik bir kaynak kod
analizörüdür.

 Coverlipse: Uygulama ve yazılım kodu ile gereksinimler ve test senaryoları arasındaki örtüşme ilişkisini inceleyen açık kaynaklı bir Eclipse eklentisidir.

 Checkstyle: Java kaynak kodunun kodlama kurallarına uyup uymadığını kontrol etmek için yazılım geliştirmede kullanılan statik bir kod analiz aracıdır.

 Coverity: Synopsys'in temel olarak statik kod analiz araçlarından ve dinamik kod analiz hizmetlerinden oluşan bir yazılım geliştirme ürünleri markasıdır.

 SDMetrics: Kod üzerinde değil, UML tasarım dokümanları üzerinde çeşitli görsel ve sayısal analizler yapabilen ticarî bir programdır.

Kaynakça

http://www.kavaninsaat.com.tr/haberler/mimari-tasarim-nedir

M. Warren, Doğruluk Kontrolü Yapmanın Bize Nasıl Bir Faydası Olur?, https://www.kemalarikan.com/dogruluk-kontrolu-yapmanin-bize-nasil-bir-faydasi-olur.html

https://bctr.org/oecd-tedarik-zincirleri-icin-birlikte-calisabilirligi-ihtiyacini-vurguluyor-16132

https://www.ksb.com/ksb-tr/Products_and_Services/Otomasyon/Retrofits
107
https://tr.prysmiangroup.com/tr/cevresel-surdurulebilirlik

https://www.alagozbilisim.com/danismanlik/kullanilabilirlik-danismanligi

B. Durmuş, Çeviri Kalitesi İçin Temel Kriterler Nelerdir?,  https://www.nettercume.com.tr/ceviri-kalitesi-kriterleri

http://yonetimgunlugu.blogspot.com/2013/02/performans-degerlendirmesi.html

E. Kazan, Güvenilirlik, http://m.gencdergisi.com/4616-guvenilirlik.html

A. Keskin, Psikolojik sağlamlık nedir: Duygusal dayanıklılığı yüksek kişilerin 14 özelliği, https://www.uplifers.com/psikolojik-saglamlik-nedir-duygusal-dayanikliligi-
yuksek-kisilerin-14-ozelligi

https://www.asbcert.com.tr/kalite/izlenebilirlik-nedir

L. Demirtaş, Karmaşıklık Yanlılığı Nedir, Nasıl Aşılır?, http://opereysin.com/yaz-bi-yere/7199-karmasiklik-yanliligi-nedir-nasil-asilir

https://www.tr.games/2021/04/15/turkiyede-yerellestirmenin-onemi

https://www.kobibt.com.tr/erp-yazilimlarinda-olceklenebilirlik-neden-onemli

S. R. Chidamber and C. F. Kemerer, “A Metrics Suite for Object Oriented Design”, IEEE Transactions on Software Engineering, Sayı. 20(6), Sayfa: 476–493,
1994.

F. B. Abreu, “The MOOD Metrics Set”, ECOOP, European Conference on Object-Oriented Programming, Workshop on Metrics, 1995.

Virtual Machinery - Sidebar 3 - WMC, CBO, RFC, LCOM, DIT, NOC – “The Chidamber and Kemerer Metrics” http://www.virtualmachinery.com/sidebar3.htm

e Abreu, F. Brito, and Walcelio Melo. “Evaluating the impact of object-oriented design on software quality.”, IEEE International Software Metrics Symposium,
1996.

J. Bansiya, C. G. Davis, “A Hierarchical Model for Object-Oriented Design Quality Assessment”, IEEE Transactions on Software Engineering, Sayı. 28(1), 2002.

S. Parvinder, H. Singh, “A Critical Suggestive Evaluation of CK Metric.” PACIS, Pacific Asia Conference on Information Systems, 2005.

Goyal, P. Kumar, G. Joshi, “QMOOD metric sets to assess quality of Java program.”, ICICT, International Conference on Issues and Challenges in Intelligent
Computing Techniques,  2014.

H. O. Ertemel, “Nesneye dayali yazilim geliştirmede kalite ölçütlerinin incelenmesi”, Yüksek Lisans Tezi, Yildiz Teknik Universitesi Fen Bilimleri Enstitüsü, İstanbul,
2009.

https://scitools.com/documents/manuals/pdf/understand.pdf.

M. Dragomir, “Understand”. Softpedia.com. Softpedia, 2015.

G. Martin, “The Project-Ready Designer”. No. 248. Circuit Cellar, 57, 2015.

F. Adkins, Luke Jones, “Machine Assisted Semantic Understanding”, INSuRE. Northeastern University, 2015.

L. Loren, Andy Johnson-Laird, “Computer Software-Related Litigation”, FCLR.org. Federal Courts Law Review, 2015.

R. Brett, “Source Code Analyzers as a Development Tool”, 2013.

M. Phillips, Amy Mok, “Spacecraft Flight Software Design Pattern Discovery”, Johns Hopkins Applied Physics Laboratory, 2015.

M. Eshow, “RTMA Source Code Change Analysis”, Aviation Systems Division. NASA, 2015.

https://www.wikiwand.com/en/Sonargraph

https://www.ibm.com/developerworks/java/library/j-findbug1

https://www.ibm.com/developerworks/java/library/j-findbug2

Sprunck Markus "Findbugs – Static Code Analysis of Java", 2013.

http://findbugs.sourceforge.net/downloads.html

https://netbeans.org/kb/docs/java/code-inspect.html

https://code.google.com/archive/p/idea-findbugs

https://code.google.com/archive/redirect/a/code.google.com/p/findbugs

idea?movedTo=http:%2F%2Fandrepdo.github.io%2Ffindbugs-idea%2F

https://qaplug.com

https://gleclaire.github.io/findbugs-maven-plugin

http://fb-contrib.sourceforge.net

http://www.methodsandtools.com/tools/findbugs.php

http://metrics.sourceforge.net

https://pmd.github.io/latest/index.html
108
http://coverlipse.sourceforge.net/index.php

https://checkstyle.sourceforge.io/index.html

https://www.sdmetrics.com/PRMar2011.html

https://www.wikiwand.com/en/Coverity

Ünite Soruları

Soru-1 :

Aşağıdakilerden hangisi yazılım kalite ölçümü için kullanılan metrikler arasında Taşınabilirlik grubu altında yer almaz?

(•) - Uyarlanabilirlik

(•) - Sürdürülebilirlik

(•) - Kurulabilirlik

(•) - Değiştirilebilirlik

(•) - Taşınabilirlik

Cevap-1 :

Sürdürülebilirlik

Soru-2 :

Aşağıdakilerden hangisi yazılım kalite ölçümü için kullanılan metrikler arasında Sürdürülebilirlik grubu altında yer almaz?

(•) - Kararlılık

(•) - Çözümlenebilirlik

(•) - Kullanılabilirlik

(•) - Bakım yapılabilirlik

(•) - Test edilebilirlik

Cevap-2 :

Kullanılabilirlik

Soru-3 :

Aşağıdakilerden hangisi yazılım kalite ölçümü için kullanılan metrikler arasında Kullanılabilirlik grubu altında yer almaz?

(•) - Öğrenilebilirlik

(•) - Çekicilik

(•) - İşletilebilirlik

(•) - Anlaşılabilirlik

(•) - Performans

Cevap-3 :

Performans

Soru-4 :

Aşağıdakilerden hangisi yazılım kalite ölçümü için kullanılan metrikler arasında Güvenlik/Güvenilirlik grubu altında yer almaz?

(•) - Verimlilik

(•) - Hata Toleransı

(•) - Kurtarılabilirlik
109
(•) - Sağlamlık

(•) - Olgunluk

Cevap-4 :

Verimlilik

Soru-5 :

Aşağıdakilerden hangisi yazılım kalite ölçümü için kullanılan metrikler arasında İzlenebilirlik grubu altında yer almaz?

(•) - Karmaşıklık

(•) - Dikey izlenebilirlik

(•) - Elverişlilik

(•) - Yatay izlenebilirlik

(•) - Güvenilirlik

Cevap-5 :

Güvenilirlik

Soru-6 :

Aşağıdakilerden hangisi yazılım kalite ölçümü için kullanılan metrikler arasında Uyumluluk grubu altında yer almaz?

(•) - Eşzamanlılık

(•) - Güvenlik

(•) - Yerelleştirilebilirlik

(•) - Ölçeklenebilirlik

(•) - Tutarlılık

Cevap-6 :

Güvenlik

Soru-7 :

1 – (Görünen Metotlar – (Toplam Metot Sayısı – 1)) şeklinde hesaplanan yazılım kalite metriği aşağıdakilerden hangisidir?

(•) - Attribute Inheritance Factor – Özellik Kalıtım Faktörü

(•) - Method Inheritance Factor – Metot Kalıtım Faktörü

(•) - Response for a Class – Sınıfın Tetiklediği Metot Sayısı

(•) - Cohesion Among Methods of Class – Sınıf Metotları Arasındaki Uyum

(•) - Method Hiding Factor – Metot Gizleme Faktörü

Cevap-7 :

Method Hiding Factor – Metot Gizleme Faktörü

Soru-8 :

1 – (Görünen Özellikler – (Toplam Özellik Sayısı – 1)) şeklinde hesaplanan yazılım kalite metriği aşağıdakilerden hangisidir?

(•) - Attribute Hiding Factor – Özellik Gizleme Faktörü

(•) - Polimorphism Factor – Polimorfizm Faktörü

(•) - Coupling Factor – Eşleme Faktörü

(•) - Average Number of Ancestors – Ortalama Ata Sayısı

(•) - Data Access Metric – Veri Erişim Metriği

110
Cevap-8 :

Attribute Hiding Factor – Özellik Gizleme Faktörü

Soru-9 :

“……………….. bir yazılım sistemini teknik kalite açısından izlemeye ve geliştirme sürecinin tüm aşamalarında yazılım mimarisi, metrikler ve diğer
yönlerle ilgili kuralları uygulamaya olanak tanıyan güçlü bir statik kod analizörüdür” şeklinde verilen cümlede boşluğa aşağıdakilerden hangisi
getirilmelidir?

(•) - Sonargraph

(•) - Coverlipse

(•) - SDMetrics

(•) - Checkstyle

(•) - Metrics

Cevap-9 :

Sonargraph

111
11. KULLANILABİLİRLİK KAVRAMI VE TESTİ
Giriş
Bir ürünün arka tarafı, tekniği, malzemeleri, yapılış şekli ne kadar iyi olursa olsun eğer kullanışlı değilse kullanıcılar bu ürünü tercih etmeyecektir. Aynı durum
yazılımlar için de geçerlidir. Ne kadar başarılı bir şekilde kodlanmış olursa olsun eğer ön yüzü kullanıcıya hitap etmiyorsa o yazılımın kullanılabilirliği oldukça sınırlı
olacaktır. Ancak yazılım geliştirenler ile kullanıcılar olaya kimi zaman çok çok farklı bir şekilde baktıkları için yazılım geliştiricilerin kullanıcı gibi düşünmesi mümkün
olmaz ve bu sebeple de üretilen yazılımın kullanılabilirliğini ölçmek, belirlemek, tespit etmek oldukça zor olur. Bu bölümde kullanılabilirlik kavramı ve kullanılabilirliğin
belirlenmesi için kullanılan testlere yer verilmiştir.

11.1. Kullanılabilirlik Kavramı

Yalnızca yazılım testlerinde değil her noktada karşımıza çıkan kullanılabilirlik kavramı, bir ürünün kullanıcıları tarafından kolay, rahat ve konforlu bir şekilde
kullanılması anlamına gelmektedir. Kullanılabilirlik ISO 9241′e göre; “bir ürünün potansiyel kullanıcıları tarafından, belirli bir kullanım bağlamı içinde, amaçlanan
kullanım hedeflerine ulaşmak için, ne derece etkin, verimli ve tatmin edici bir şekilde kullanılabilmesi” olarak tanımlanmaktadır. Bu tanım 3 önemli parçadan
oluşmaktadır. Bunlar potansiyel kullanıcı, kullanım bağlamı ve kullanım hedefleridir.

Potansiyel Kullanıcı: Bir ürünü satın alan kişi ile kullanan kişi her zaman aynı olmayabilir. Hatta dijital ürünlerin çoğunda bu iki grup birbirinden farklıdır. Bu
durumda ürünü satın alan kişiye test ettirmek sıkça yapılan bir hatadır, bunun yerine gerçekten ürünü kullanacak kişinin test etmesi daha doğru sonuçlar ortaya
çıkarabilecektir. Örneğin bir eve ADSL modem alınacaksa büyük ihtimalle bu modemin parasını verip satın alacak ola anne/baba bu modemi en az kullanacak kişiler
olacaktır, evdeki çocuklar ise internetin en yoğun kullanıcısı olacaktır. Bu noktada ürünü gidip anne/babaya test ettirmek çok da doğru bir hareket olmayabilir.

Kullanım Bağlamı: Bu kavram ürünün nerede kullanılacağı ile ilişkili bir kavramdır. Örneğin ürün bir banka ATM’si ise kapalı ortamda test etmek yeterli
olmayabilir, çünkü bu ATM’ler sokaklarda bulunmakta, dışarı şartları ile (örneğin güneş ışığı) çalışmaktadır. Yine benzer şekilde ürün bir mobil uygulama ise onu
masaüstü bilgisayarda test etmenin hiçbir anlamı yoktur, mutlaka bir mobil cihaz üzerinde test edilmelidir.

Kullanım Hedefleri: Oluşturulan ürün farklı özelliklere sahipse ancak bir yazılımda onun tüm özellikleri kullanılmayacaksa bu durumda yalnızca kullanılacak olan
özelliklerini test etmek gereklidir. Bu özellikler o ürünün kullanım hedefleridir.

Kullanılabilirlik genellikle öğrenilebilirlik, verimlilik, hatırlanabilirlik, hatalar ve memnuniyet olmak üzere 5 bileşen ile tanımlanır (Ioxdigital, 2021):

· öğrenilebilirlik, sistemin ne kadar kolay öğrenilebildiğini;

· verimlilik, sistemin ne kadar az hatayla, hızlı ve verimli kullanılabildiğini;

· hatırlanabilirlik, belirli bir süre kullanılmasa bile daha sonra tekrar kullanıldığında sistem kullanımının kolaylıkla hatırlanabilmesini;

· hatalar, kullanıcıların hata yapma oranının düşük olmasını ve hata yapıldığında kolaylıkla düzeltilebilmesini;

· memnuniyet, kullanıcıların sistemi kullanırken ne kadar tatmin olup ve olumlu veya olumsuz düşüncelerinin ölçüsünü;

ifade etmektedir. Şekil 11.1’de bu kavramların İngilizceleri yer almaktadır.

Şekil 11.1. Kullanılabilirlik Kavramı

Kullanılabilirlik ile ilgili en önemli prensipler aşağıdaki gibidir:

112
1. En iyi tahmininiz yeterince iyi değildir: Kullanılabilirlik sürecinin varlığının en basit nedeni elinizden gelenin en iyisini yaparak kullanıcılar için en ideal arayüzün
oluşturulamayacağı gerçeğidir. Kullanıcılar tahmin edilemeyecek çıkarımları yapmakta ustadırlar. Arayüz, kullanıcıları anladıkça daha verimli bir hale gelecektir.
Bunun için arayüzü tasarladıktan sonra bunu hedef kitleye uygun kullanıcılarla doğrulatmak ilk adım olacaktır.

2. Kullanıcılar her zaman haklıdır: Tasarımcılar, kullanıcılar sitede sorun yaşadığında herhangi bir kötü düşünceye sahip olmamalıdır. Eğer arayüz sistem kritik
değilse (yani kullanıcılar onu kullanmadığı anda ölümcül durumlarla karşı kaşı kalmayacaksa) kullanıcılar siteyi ya da programı öğrenmek için çok fazla
çabalamayacaktır.

3. Kullanıcılar her zaman haklı değildir: Kullanıcılar aslında her zaman da haklı değillerdir. Tasarım sürecinde onlar için neyin daha iyi olacağını onlara sormak
kullanıcıları çok farklı yönlere götürebilir. Müşteriler hakkında şöyle denmiştir: “Eğer müşterilerime ne istediklerini sormuş olsaydım, daha hızlı bir at istediklerini
söylerlerdi”. Bu yüzden kullanıcıları dinlemek yerine ne yaptıklarına bakmak daha anlamlı sonuçlar doğuracaktır.

4. Kullanıcılar tasarımcı değildir: Yukarıdaki maddeye benzer bir şekilde kullanıcıların tasarım hakkındaki yorumlarını dinlemek çok bir yarar sağlamayacaktır.
Çünkü onların dediklerinden çok yaptıkları önemlidir.

5. Tasarımcılar kullanıcı değildir: Tasarımcı körlüğü tasarımı yapan kişinin arayüzün mükemmel ve hatasız olduğunu düşünmesi olayıdır. Ayrıca tasarımcı ve
programcı kişiler genellikle üst düzey internet kullanıcılarıdır. Çoğu kullanıcı sistemi onların kullandığı şekilde kullanmayacaktır. Bu yüzden bir tasarımcı kendi
tasarladığı arayüzün kendisi rahat kullandığı için kullanılabilir olduğunu düşünmemelidir.

6. Genel Müdürler kullanıcı değildir: Arayüzleri genellikle ilk olarak beğenmesi gereken kişi olan Genel Müdür’ler de kullanıcı grubuna genellikle dahil değildir.

7. Az çoktur: Sistemin her fonksiyonalitesini bir arayüze toplayıp kullanıcıların hepsini anlamasını beklemek ütopik bir düşüncedir. Az çoktur yazısında da
belirttiğimiz gibi öncelikle şu soruyu kendimize sormamız gerekir: “Eğer Google’ın arama özelliğindeki kadar fonksiyona bizim sitemiz sahip olsaydı nasıl bir
anasayfamız olurdu?”

8. Detaylar önemlidir. Küçük detaylar kullanılabilirliği arttırmada oldukça önemlidir: Kullanılabilirlik testleri bu tarz ufak ama sonuçları önemli olacak
detayları bulmanın en iyi yoludur. 9. Yardım genelde yardım etmez: Yardım ve dökümantasyon bölümü genellikle kullanıcılara yardım etmemektedir. Kullanıcıların
bilgi dolu sayfalar arasında aslı ihtiyacı olan bölümü bulması da ayrı bir kullanılabilirlik sorunudur. Yardım bölümünün sağlanmış olması karmaşık arayüzler oluşturmak
için bahane değildir.

10. Kullanılabilirlik bir süreçtir: Kullanılabilirlik sadece arayüz tamamlanmaya yakın akla gelen bir süreç olmamalıdır. Kullanılabilirlik, arayüz tasarımının başından
sonuna tasarımla beraber yürüyen bir süreçtir.

11.2. Kullanılabilirlik Testi

Kullanılabilirlik Testi, bir ürünü veya hizmeti temsilî kullanıcılar ile test ederek değerlendirmek anlamına gelir. Bu test türü, Kullanıcı Arabirimleri (Kullanıcı Arayüzü)
ve Kullanıcı Deneyimi'ni test etmeyi içerir. Bir yazılım uygulamasını kullanıcının bakış açısından kullanmada kolaylık sağlar. Günümüzde rekabetin zirvede olduğu,
kullanıcı dostu, benzersiz ve sorunsuz uygulamalar yaratmak son derece önemlidir. Kuruluşların bu hedefe ulaşmalarına yardımcı olmak için, kullanılabilirlik testi
yazılım/uygulama geliştirme aşamasında erkenden uygulanmaktadır.

Bu tür testlerinin faydaları şunlardır:

· Uygulamayı anlama, öğrenme, uyarlama kolaylığı sağlar.

· Sorunun tanımlanmasına izin verir.

· Piyasaya sürüldüğü sırada ürünün doğruluğunu sağlar.

· Yazılım uygulamasının genel performansını iyileştirmek için gereken değişiklikleri tanımlar.

· Kullanıcı deneyimi ve memnuniyetini doğrular.

Günümüzde çok farklı alanlarda kullanılabilirlik testleri uygulanmaktadır. Bunlardan yazılım testi ile ilgili olan bazı alanlar ve bu alanlarda yakın zamanda yapılan
çalışmalar aşağıda ifade edilmiştir.

· Web sitelerinin kullanılabilirliğinin incelenmesi (Bağan, 2020; Eyice Başev, 2020; Kocaağa, 2021; Menekşe Dalveren ve Peker, 2021)

· Engelli kullanıcıların mobil uygulamaları kullanması (Eken, 2020)

· E-öğrenme ortamlarına ilişkin kullanılabilirlik araştırmaları (Sözer ve diğ., 2020; Tilgel 2020)

· Sistemlerin kullanılabilirliğinin değerlendirilmesi (Tunç ve Külcü, 2020; Doluküp ve Hakbilen, 2021)

· Donanımsal cihazların arayüzlerinin kullanılabilirliğinin incelenmesi (Kaya ve Altın Gümüşsoy, 2021)

Kullanılabilirlik seviyesinin ölçülmesi için çeşitli yöntemler bulunur. Söz konusu test yöntemleri şu şekilde sıralanabilir:

1. Online Göz İzleme: İnternet sitesine giren kişinin ekranın hangi kısmına ne kadar süre boyunca baktığı ile ilgili bilgi edinilmesi amaçlanır. Kişinin ekranın hangi
kısmına daha çok baktığı öğrenilerek daha çok dikkat çekilmesi istenen unsurlar o kısımlara yerleştirilir. Böylelikle web sitesi daha etkin ve verimli bir şekilde
kullanılmış olur.

2. Mouse Hareketi ve Tıklama Haritası: Bu yöntemdeki amaç ise web sitesinde zaman geçiren kişinin mouse hareketlerinin ortalama düzeyine bakılarak tasarım
iyileştirmesi yapabilmektir.

3. Laboratuvar Testleri: Bu test türünde testi yapan kişi tarafın web sitesi kullanıcısı incelenir. Web sitesini kullanan kişinin davranışları ve eğilimleri not edilir.

4. Geri Bildirim Testleri: Bu testte yazılımı tecrübe eden kişiler yorumlarını ve düşüncelerini ifade eder. Elde edilen bilgiler ve yorumlar sayesinde inceleme yapılır.
Buna göre yazılım değiştirilip düzeltilir.

5. Modere Edilen Online Kullanıcı Testi: Bu yöntemde ise web sitesi kullanıcıları araştırmacı tarafından yönlendirilerek test uygulanır. Uzaktan yapılan bir test
yöntemidir.

113
6. Modere Edilmeyen Online Kullanıcı Testi: Modere edilen kullanıcı testinden daha farklıdır. Farklı olduğu yön ise araştırmacılar tarafından önceden belirlenen
bir senaryonun kullanıcıya sırayla uygulatılmasıdır.

7. A/B Testi: Bu yöntem sayesinde web sitesi ara yüzünün çeşitli versiyonlarının etkinliği ile verimliliğinin ölçülmesi hedeflenir.

Kullanılabilirlik testleri 5 aşamada gerçekleştirilmektedir. Bunlar test planını hazırlama, test ortamını hazırlama, katılımcı ayarlama, testi yürütme ve verileri analiz etme
şeklindedir. Şekil 11.2’de bu 5 aşama gösterilmektedir (User spots, 2021).

Şekil 11.2. Kullanılabilirlik Testi Süreçleri

1. Test Planını Hazırlama: Test planı, başlamadan önce süreci, neler yapılacağının kurgulandığı aşamadır. Kullanılabilirlik testi oturumunun ayrıntılarını planlamak
birçok yönden tüm sürecin en önemli parçasıdır. Test sürecinin başlangıcında verilen kararlar ilerleme şeklini ve elde edilen sonuçları belirleyecektir. Proje bilgisi
tanımlanır, incelenecek/üzerinde durulacak konular belirlenir.

2. Test Ortamını Hazırlama: Test edilecek kişiler için yaratılacak ortamdır. En öncelikli yapılması gereken, test edilecek kişiyle iletişime geçerek kesin bir gün ve
zaman belirlemek ve bunu takvime eklemek olacaktır. Bunu analog takvimlerle de gerçekleştirmek mümkündür ancak dijital ortamlardaki Google Calendar gibi
uygulamaları kullanarak eş zamanlı olarak kullanıcılara bildirim gönderilebilir.

‍ . Katılımcı Ayarlama: Toplu mailler ve mesaj gibi yollarla kullanıcı tespiti yapılabilir, ilgi çekici olmak ve insanları kabul etmeye teşvik etmek için mailin içeriğinde
3
testin gerçekleşeceği tarih, yer, süresi, anketin sonucunda verilecek ödül gibi bilgilere yer verilmelidir.

4. Test Yürütme: İlk önce pilot testler yaparak her şeyin hazır olduğuna, ağ bağlantısında problem olmadığına, cihazların çalışabilir durumda olduğuna emin olmak
gerekir. Sonrasında gerçek anlamda teste başlanabilir. Şekil 11.3’te bir test yürütme şeması gösterilmiştir.

Şekil 11.3. Bir Test Yürütme Şeması

5. Verileri Analiz Etme: ‍Kullanıcının kendisiyle yapılacak bir işlemin kalmadığı bölümdür. Burada, bu noktaya kadar elde edilen çıktıların analiz edilmesi
gerekmektedir. Burada Airtable, Excel gibi çeşitli tablo uygulamaları ya da farklı programlar kullanarak veriler analiz edilebilir.

Kullanılabilirlik testleri, değerlendirme yaparken çeşitli metrikler kullanmaktadır. Bunlardan bazıları ölçümlenebilirken bazıları algılanan metriklerdir. Örneğin etkililik
ve verimlilik ölçülebilir ancak memnuniyet ancak algılanabilir ve kullanıcının verdiği değerlendirmeye göre alınabilir. Bunları gerçekleştirirken kullanım testi esnasında
114
bazı sayısal değerler toplamak gerekir. Örneğin

· senaryo tamamlama oranı

· senaryo sırası sayfa ziyareti

· senaryo memnuniyeti

· test memnuniyeti

· karşılaşılan problemler, bizi bu temel istatistiklere ulaştıran verilerdir.

· ortalama görev zamanı

· görev tamamlama oranı

· ortalama hata sayısı

· görev sonrası memnuniyet

gibi veriler kullanılabilirlik testi ile ilgili önemli veriler olarak karşımıza çıkar. Buradaki veriler arasında özellikle son veri olan memnuniyet verisinin ölçülmesi oldukça
zordur. Yukarıda bu verinin doğrudan ölçülemediği ancak algılandığı zaten ifade edilmiştir. Bu verinin ve gerekli olduğu takdirlerde farklı verilerin ölçülmesi için
Kullanılabilirlik Testi Ölçekleri kullanılmaktadır.

Kullanılabilirlik ölçeği, 1986 yılında dijital sektöründe olan John Brooke tarafından kullanılabilirlik değerlendirmesi yapmak amacıyla geliştirilmiş basit ve hızlı bir
ölçektir. Firmalar ürünlerinin insanlar üzerindeki etkisini daha iyi görebilmek ve geribildirim alarak geliştirebilmek için bu yöntemi kullanırlar. Kısaca, kullanıcıların bir
ürün veya sistemle alakalı memnuniyetlerini ölçmeye yarayan, standardize edilmiş anketlerdir. İngilizce’de System Usability Scale – SUS, Türkçe’de Sistem
Kullanılabilirlik Testi – SKÖ şeklinde kullanılır ancak tahmin edilebileceği üzere genellikle İngilizce kısaltması kullanılmaktadır. Bu ölçeklerin kullanılabilmesi için
güvenilir, geçerli ve hassas olması gerekmektedir. Bu kavramlar aşağıdaki gibi tanımlanmaktadır:

· güvenilirlik (reliability) bir testin her uygulanışında sonuçların tutarlı çıkmasını,

· ‍geçerlilik (validity) kullanılan testin amaçlanan konuyu ölçmesini,

· hassaslık (sensitivity) verilen cevaplara göre sonucun anlamlı olarak değişebilmesini

ifade eder.

Şekil 11.4’te güvenilirlik ve geçerlilik kavramları sembolize edilmiştir.

Şekil 11.4. Güvenilirlik ve Geçerlilik Kavramları

Kullanılabilirlik Testi Ölçekleri çalışma sonrası uygulanan ölçekler ve çalışma sırasında uygulanan ölçekler olarak 2’ye ayrılabilir.

Çalışma sonrası uygulanan ölçekler, çalışma sonunda, yani tüm senaryolar tamamlandıktan sonra, kullanıcıya sunulur, kullanıcının deneyimlediği ürün hakkındaki hem
fiziksel hem de deneyime dayalı çıkarımlarını ölçmek ister. Kullanıcıyı ürünü ilk kullanmaya başladığı andan son ana kadar analiz edebilir. Çalışma sonrasında
kullanılan en önemli ölçekler aşağıda maddelendirilmiştir.

Software Usability Scale/Sistem Kullanılabilirlik Ölçeği (SUS/SKÖ): Anket formatındadır ve 10 sorudan oluşmaktadır. Hızlı ve kolay bir şekilde sistemin
kullanılabilirlik seviyesini ölçümlendirir. 68 puanın altındaki değerler ortalamanın altında kalmaktadır ve hedef 68 puan ve üzeri değeri yakalamak olmalıdır. Şekil
11.5’te bu ölçeğin standart bir versiyonu gösterilmektedir.

115
Şekil 11.5. Sistem Kullanılabilirlik Ölçeği

Questionnaire for User Interaction Satisfaction/Kullanıcı Etkileşimi Memnuniyeti Anketi (QUIS/KEMA): Kullanıcıların arayüz hakkındaki genel düşüncelerini ölçtüğü
gibi arayüzün genel görünüşü, arayüzün dili ve sistemin öğrenilebilirliği gibi konularda da bulgu sağlar. Şekil 11.6’da bu ölçeğin bir versiyonu gösterilmektedir.

Şekil 11.6. Kullanıcı Etkileşimi Memnuniyeti Anketi

Software Usability Measurement Inventory/Yazılım Kullanılabilirlik Ölçüm Envanteri (SUMI/YKÖE): 50 soru ile bir arayüzü, beş farklı başlık altında
inceleyen bir ankettir. Verimlilik (Efficiency), Etki (Affect), Yardımcılık (Helpfulness), Hakimiyet (Control), Öğrenilebilirlik (Learnability) başlıkları altında topladığı
bilgilerden sonuç elde eder. Şekil 11.7’de bu ölçeğin bir versiyonu gösterilmektedir.

116
Şekil 11.7. Yazılım Kullanılabilirlik Ölçüm Envanteri

Post-Study System Usability Questionnaire/Çalışma Sonrası Sistem Kullanılabilirlik Anketi (PSSUQ/ÇSSKA): 16 soru ile bir web sitesinin veya
uygulamanın genel kullanılabilirliğinin yanı sıra;

· sistem kalitesini (1–6),

· bilgi kalitesini (7–12),

· arayüz kalitesini (13–15)

ölçen bir ankettir. Şekil 11.8’de bu ölçeğin bir versiyonu gösterilmektedir.

Şekil 11.8. Çalışma Sonrası Sistem Kullanılabilirlik Anketi

Standardized Universal Percentile Rank Questionnaire/Standartlaştırılmış Evrensel Yüzdelik Sıra Anketi (SUPR-Q/SEYSA): Web sitelerini; kullanılabilirlik,
güvenilirlik, görünüş ve sadıklık açısından değerlendiren 13 adımlı bir ankettir. Şekil 11.9’da bu ölçeğin bir versiyonu gösterilmektedir.

117
Şekil 11.9. Standartlaştırılmış Evrensel Yüzdelik Sıra Anketi

Çalışma sırasında uygulanan ölçekler‍, çalışma süreci devam ederken belirli aralıklarla uygulanan ölçeklerdir. Verilen göreve göre senaryo bitimlerinde ya da
başlangıçlarında uygulanabilir. Çalışma sonrası uygulanan ölçeklerle benzerlik gösterirler fakat uygulanma zamanları farklıdır. Çalışma sırasında kullanılan en önemli
ölçekler aşağıda maddelendirilmiştir.

After-Scenario Questionnaire/Senaryo Sonrası Anketi (ASQ/SSA): Her bir senaryo sonunda sorulan 3 maddelik bir ankettir. PSSQU ile aynı formattadır. Şekil
11.10’da bu ölçeğin bir versiyonu gösterilmektedir.

Şekil 11.10. Senaryo Sonrası Anketi

Single Ease Question/Tek Kolay Soru (SEQ/TKS): Her bir senaryo sonrası kullanıcılara, yaşadıkları baskın zorluk hakkında sorulan tek soruluk ankettir. 5 ve 7
seçenekli olan versiyonları vardır, bunlardan 7 seçenekli olan daha çok önerilir. Şekil 11.11’de bu ölçeğin bir versiyonu gösterilmektedir.

118
Şekil 11.11. Tek Kolay Soru

Subjective Mental Effort Question/Öznel Zihinsel Çaba Sorusu (SMEQ/ÖZÇS): Senaryonun zorluğunu kullanıcıya 0–150 arasında puanlatan tek soruluk ankettir.
Şekil 11.12’de bu ölçeğin bir versiyonu gösterilmektedir.

Şekil 11.12. Öznel Zihinsel Çaba Sorusu

Expectation Rating/Beklenti Derecelendirmesi (ER/BD): Kullanıcıya senaryoyu gerçekleştirmeden önce ve gerçekleştirdikten sonra yaşadığı baskın zorluk sorulur ve
karşılaştırma imkanı sunar. Şekil 11.13’de bu ölçeğin bir versiyonu gösterilmektedir.

119
Şekil 11.13. Beklenti Derecelendirmesi

Bölüm Özeti
Kullanılabilirlik kavramı, bir ürünün kullanıcıları tarafından kolay, rahat ve konforlu bir şekilde kullanılması anlamına gelmektedir. Bir ürünü satın alan kişi ile kullanan
kişi her zaman aynı olmayabilir. Bu durumda ürünü satın alan kişiye test ettirmek sıkça yapılan bir hatadır, bunun yerine gerçekten ürünü kullanacak kişinin test etmesi
daha doğru sonuçlar ortaya çıkarabilecektir. Bunun dışında ürünlerin kullanılacakları ortamlara ve kullanım hedeflerine uygun şekilde test edilmeleri gerekmektedir.
Kullanılabilirlik genellikle öğrenilebilirlik, verimlilik, hatırlanabilirlik, hatalar ve memnuniyet olmak üzere 5 bileşen ile tanımlanır:

· öğrenilebilirlik, sistemin ne kadar kolay öğrenilebildiğini;

· verimlilik, sistemin ne kadar az hatayla, hızlı ve verimli kullanılabildiğini;

· hatırlanabilirlik, belirli bir süre kullanılmasa bile daha sonra tekrar kullanıldığında sistem kullanımının kolaylıkla hatırlanabilmesini;

· hatalar, kullanıcıların hata yapma oranının düşük olmasını ve hata yapıldığında kolaylıkla düzeltilebilmesini;

· memnuniyet, kullanıcıların sistemi kullanırken ne kadar tatmin olup ve olumlu veya olumsuz düşüncelerinin ölçüsünü;

ifade etmektedir.

Kullanılabilirlik ile ilgili çeşitli prensipler mevcuttur ve bu prensiplere uyulduğunda başarılı kullanılabilirlik testleri gerçekleştirilebilmektedir. Bu prensipler

· En iyi tahmininiz yeterince iyi değildir

· Kullanıcılar her zaman haklıdır

· Kullanıcılar her zaman haklı değildir

· Kullanıcılar tasarımcı değildir

· Tasarımcılar kullanıcı değildir

· Genel Müdürler kullanıcı değildir

· Az çoktur

· Detaylar önemlidir. Küçük detaylar kullanılabilirliği arttırmada oldukça önemlidir

· Yardım genelde yardım etmez

· Kullanılabilirlik bir süreçtir

şeklindedir.

Kullanılabilirlik Testi, bir ürünü veya hizmeti temsili kullanıcılar ile test ederek değerlendirmek anlamına gelir. Bu tür testler, uygulamayı anlama, öğrenme, uyarlama
kolaylığı sağlar, sorunun tanımlanmasına izin verir, piyasaya sürüldüğü sırada ürünün doğruluğunu sağlar, yazılım uygulamasının genel performansını iyileştirmek için
gereken değişiklikleri tanımlar, test görevinin tamamlanma süresi izlenebilir, kullanıcı deneyimi ve memnuniyetini doğrular. Kullanılabilirlik için kullanılan test yöntemleri
şu şekildedir:

· Online Göz İzleme

· Mouse Hareketi ve Tıklama Haritası

· Laboratuvar Testleri

· Geri Bildirim Testleri

120
· Modere Edilen Online Kullanıcı Testi

· Modere Edilmeyen Online Kullanıcı Testi

· A/B Testi

Kullanılabilirlik testleri test planını hazırlama, test ortamını hazırlama, katılımcı ayarlama, testi yürütme ve verileri analiz etme şeklinde 5 aşamadan oluşmaktadır.

Kullanılabilirlik testleri, değerlendirme yaparken çeşitli metrikler kullanmaktadır. Bunlardan bazıları senaryo tamamlama oranı, senaryo sırası sayfa ziyareti, senaryo
memnuniyeti, test memnuniyeti, karşılaşılan problemler, ortalama görev zamanı, görev tamamlama oranı, ortalama hata sayısı, görev sonrası memnuniyettir.

Kullanılabilirlik Testi Ölçekleri çalışma sonrası uygulanan ölçekler ve çalışma sırasında uygulanan ölçekler olarak 2’ye ayrılabilir. Çalışma sonrası uygulanan ölçekler,
çalışma sonunda, yani tüm senaryolar tamamlandıktan sonra, kullanıcıya sunulur, kullanıcının deneyimlediği ürün hakkındaki hem fiziksel hem de deneyime dayalı
çıkarımlarını ölçmek ister. Kullanıcıyı ürünü ilk kullanmaya başladığı andan son ana kadar analiz edebilir. Çalışma sonrasında kullanılan en önemli ölçekler aşağıda
maddelendirilmiştir.

· Sistem Kullanılabilirlik Ölçeği

· Kullanıcı Etkileşimi Memnuniyeti Anketi

· Yazılım Kullanılabilirlik Ölçüm Envanteri

· Çalışma Sonrası Sistem Kullanılabilirlik Anketi

· Standartlaştırılmış Evrensel Yüzdelik Sıra Anketi

Çalışma sırasında uygulanan ölçekler‍, çalışma süreci devam ederken belirli aralıklarla uygulanan ölçeklerdir. Verilen göreve göre senaryo bitimlerinde ya da
başlangıçlarında uygulanabilir. Çalışma sonrası uygulanan ölçeklerle benzerlik gösterirler fakat uygulanma zamanları farklıdır. Çalışma sırasında kullanılan en önemli
ölçekler aşağıda maddelendirilmiştir.

· Senaryo Sonrası Anketi

· Tek Kolay Soru

· Öznel Zihinsel Çaba Sorusu

· Beklenti Derecelendirmesi

Kaynakça

https://www.ioxdigital.com/rehberler/kullanici-testleri#Kullanilabilirlik-testi

https://www.userspots.com/rehber/kullanilabilirlik-testi-nasil-yapilir

https://www.userspots.com/rehber/kullanilabilirlik-testi-olcekleri

https://www.mediaclick.com.tr/tr/blog/kullanilabilirlik-nedir

S. K. Tunç, Ö. Külcü, “Elektronik Belge Yönetim Sistemlerinin Sezgisel Değerlendirme Yöntemi ile Kullanılabilirlik Açısından Değerlendirilmesi”, Bilgi Dünyası
Dergisi, Sayı. 21(2), (20. Yıl Özel Sayısı), Sayfa: 270 – 297, 2020

İ. Eken, “Görme Engelli Kullanıcıların Mobil Erişebilirliği: Kullanılabilirlik Yaklaşımı ile Sosyal Medya Uygulamalarının Analizi”, International Journal of Cultural and
Social Studies, Sayı. 6(1), Sayfa: 375 – 391, 2020

B. Sözer, N. Özdamar, H. Pilancı, “Yabancı dil öğrenimi için hazırlanan e-öğrenme ortamlarına ilişkin kullanılabilirlik araştırmalarının incelenmesi”, Açıköğretim
Uygulamaları ve Araştırmaları Dergisi, Sayı. 6(4), Sayfa: 174 – 207, 2020

N. Kocaağa, “Çevrim içi Ortamlarda Kullanılabilirlik ve Müşteri Memnuniyeti İlişkisi: E-bebek Üzerine bir Araştırma”, İstanbul Medipol Üniversitesi, Sosyal
Bilimler Enstitüsü, Yüksek Lisans Tezi, 2020

S. E. Başev, “Web Uygunluk Analizi: Hepsiburada.Com Ve N11.Com Karşılaştırılması”, Diyalektolog, Sayı. 24, Sayfa: 103 – 123, 2020

B. Bağan, “Web Page Redesign With The User Experience Component Of Usability: The TKSD Case Study”, Kadir Has Üniversitesi, Yüksek Lisans Tezi, 2020

İ. Doluküp, G. Hakbilen, “Kurumsal Kalite Sisteminin Kullanılabilirliğinin Değerlendirilmesi”, Sağlıkta Performans ve Kalite Dergisi, Sayı. 18(1), Sayfa: 89 – 108,
2021

G. G. Menekşe Dalveren, S. Peker, “Üniversite Web Sitesi Ana Sayfalarının Kullanılabilirliğinin Değerlendirilmesi: Göz İzleme Yaklaşımı”, European Journal of
Science and Technology, Sayı. 25, Sayfa: 782 – 789, 2021

A. Kaya, Ç. Altın Gümüşsoy, “TV ve Set Üstü Cihaz Arayüzlerinin Kullanılabilirliğinin Değerlendirmesinde Makine Öğrenmesinin Kullanımı”, European Journal of
Science and Technology, Sayı. 26, Sayfa: 41 – 46, 2021

Ünite Soruları

Soru-1 :

Aşağıdakilerden hangisi kullanılabilirlik kavramını meydana getiren bileşenlerden biri değildir?

121
(•) - Öğrenilebilirlik

(•) - Verimlilik

(•) - Analitiklik

(•) - Memnuniyet

(•) - Hatırlanabilirlik

Cevap-1 :

Analitiklik

Soru-2 :

Aşağıdakilerden hangisi kullanılabilirlik ile ilgili prensipler içerisinde birbirine ters özellik gösteren 2 prensiptir?

(•) - En iyi tahmininiz yeterince iyi değildir/En iyi tahmininiz yeterince iyidir

(•) - Kullanıcılar tasarımcı değildir/Tasarımcılar kullanıcı değildir

(•) - Genel Müdürler kullanıcı değildir/Kullanıcılar genel müdür değildir

(•) - Kullanıcılar her zaman haklıdır/Kullanıcılar her zaman haklı değildir

(•) - Yardımlar genelde yardım etmez/Yardımlar genelde yardım eder

Cevap-2 :

Kullanıcılar her zaman haklıdır/Kullanıcılar her zaman haklı değildir

Soru-3 :

Aşağıdakilerden hangisi kullanılabilirlik testlerinin faydaları arasında yer almaz?

(•) - Sorunun tanımlanmasına izin verir

(•) - Kullanıcı deneyimi ve memnuniyetini doğrular.

(•) - Piyasaya sürüldüğü sırada ürünün doğruluğunu sağlar

(•) - Uygulamayı anlama, öğrenme, uyarlama kolaylığı sağlar

(•) - Test görevinin tamamlanma bütçesi izlenebilir.

Cevap-3 :

Test görevinin tamamlanma bütçesi izlenebilir.

Soru-4 :

Aşağıdaki testlerden hangisi, “İnternet sitesine giren kişinin ekranın hangi kısmına ne kadar süre boyunca baktığı ile ilgili bilgi edinilmesi
amaçlanır.” tanımına uymaktadır?

(•) - Online Göz İzleme

(•) - Laboratuvar Testleri

(•) - Geri Bildirim Testleri

(•) - A/B Testi

(•) - Mouse Hareketi

Cevap-4 :

Online Göz İzleme

Soru-5 :

Aşağıdakilerden hangisi kullanılabilirlik testi süreçleri arasında yer almaz?

(•) - Test Yürütme

(•) - Test Analizi

122
(•) - Katılımcı Ayarlama

(•) - Test Ortamını Hazırlama

(•) - Test Planını Hazırlama

Cevap-5 :

Test Analizi

Soru-6 :

 100 puan üzerinden 68 puan alınmasının hedef olduğu kullanılabilirlik testi aşağıdakilerden hangisidir?

(•) - Sistem Kullanılabilirlik Ölçeği

(•) - Kullanıcı Etkileşimi Memnuniyeti Anketi

(•) - Yazılım Kullanılabilirlik Ölçüm Envanteri

(•) - Çalışma Sonrası Sistem Kullanılabilirlik Anketi

(•) - Standartlaştırılmış Evrensel Yüzdelik Sıra Anketi

Cevap-6 :

Sistem Kullanılabilirlik Ölçeği

Soru-7 :

Kullanıcılara senaryodaki görevleri tamamlama ile ilgili soruların sorulduğu anket aşağıdakilerden hangisidir?

(•) - Standartlaştırılmış Evrensel Yüzdelik Sıra Anketi

(•) - Beklenti Derecelendirmesi

(•) - Öznel Zihinsel Çaba Sorusu

(•) - Tek Kolay Soru

(•) - Senaryo Sonrası Anketi

Cevap-7 :

Senaryo Sonrası Anketi

Soru-8 :

Bir ürünün nerede kullanılacağı aşağıdaki kavramlardan hangisi ile ifade edilmektedir?

(•) - Potansiyel Kullanıcı

(•) - Kullanım Bağlamı

(•) - Kullanım Hedefleri

(•) - Kullanım Şekli

(•) - Kullanılabilirlik Analizi

Cevap-8 :

Kullanım Bağlamı

Soru-9 :

Aşağıdakilerden hangisi bir kullanılabilirlik testi olarak düşünülemez?

(•) - Donanımsal cihazların arayüzlerinin değerlendirilmesi

(•) - E-öğrenme ortamları ile klasik öğrenme ortamlarının kullanıcılar açısından değerlendirilmesi

(•) - Web sitelerinin kullanılabilirliğinin incelenmesi

(•) - Engelli kullanıcıların mobil uygulamaları kullanması

123
(•) - Sistemlere dışarıdan yapılan saldırıların tespit edilmesi

Cevap-9 :

Sistemlere dışarıdan yapılan saldırıların tespit edilmesi

124
12. GÖZDEN GEÇİRME
Giriş
Proje dokümanlarının manuel olarak incelenmesine gözden geçirme denir. Yazılımın çalıştırılmadan, yürütülmeden test edilebildiği bir test test tekniğidir. Diğer bir
tanımla kod çalıştırılarak uygulamayı kontrol eden dinamik testin tamamlayıcı yanıdır. Gözden geçirme, yazılımın tasarımındaki olası hataları bulmak için yapılan
işlemlerdir. Yazılımı test etmenin bir yoludur ve dinamik testler yapılmadan önce gerçekleştirilebilir. Gereksinimler, tasarımlar, kod, test planları, test gereksinimleri,
test senaryoları, test komut dosyaları, kullanım kılavuzları veya web sayfaları gibi tüm yazılım ürünlerinin gözden geçirilmesidir.

12.1. Gözden Geçirme Testi Süreci Aktiviteleri

Gözden geçirme testi süreci

· Planlama (Planning)

· Başlama (Kick-off)

· Kişisel Hazırlık (Preparation)

· Sonuçları İnceleme/Değerlendirme/Kaydetme (Gözden Geçirme Toplantısı) (Review Meeting)

· Yeniden Çalışma (Rework)

· Takip (Follow up)

ana aktivitelerinden oluşur. Şekil 12.1’de bir gözden geçirme testi yapısı görülmektedir (Ceylan, 2021).

Şekil 12.1. Bir Gözden Geçirme Testi Yapısı

Bu ana aktivitelerin altında yer alan alt aktiviteler ise şu şekildedir:

1. Planlama

· Gözden geçirme kriterini belirleme

· Gözden geçirmeye katılacak kişilerin seçilmesi ve rol paylaşımı

· Belgenin hangi bölümlerinin gözden geçirileceğini seçme

· Daha resmî gözden geçirme türleri için (örneğin, teftişler) giriş ve çıkış kriterlerinin tanımlanması

· Giriş kriterlerinin karşılandığının kontrol edilmesi (daha resmî gözden geçirme türleri için)

· Katılımcılara kapsamın, hedeflerin, sürecin, rollerin ve çalışma ürünlerinin açıklanması

· Rollerle birlikte gözden geçirme çeşidi, aktiviteler ve kontrol listeleri gibi gözden geçirme özelliklerinin belirlenmesi

2. Başlama

· Belgeleri dağıtma

· Katılımcılara hedefleri, süreci ve belgeleri açıklama

· Gözden geçirmenin başlatılması

3. Kişisel Hazırlık

· Belgeleri gözden geçirerek gözden geçirme toplantısına hazırlanma

· Potansiyel hataların analiz edilmesi, bunlar için bir sorumlu ve durumun atanması

· Katılımcıların varsa gözden geçirme ile ilgili sorularının cevaplanması

4. Gözden Geçirme Toplantısı

· Belgelenen sonuçlar üzerinden tartışma

· Hataları not etme, hatalarla ilgili kararlar verme

125
· Toplantılar sırasında sorunları inceleme/değerlendirme ve kaydetme

· Gözden geçirme kararı vermek için gözden geçirme bulgularının çıkış kriterlerine göre değerlendirilmesi

· Belirlenen olası hataların iletilmesi (örneğin bir gözden geçirme toplantısında)

· Kalite özelliklerinin değerlendirilmesi ve dokümante edilmesi

5. Yeniden Çalışma

· Bulunan hataları düzeltme (Genellikle gözden geçirilen ürünün sahibi/yazar tarafından yapılır.)

· Hataların güncel durumunu kaydetme (Resmî gözden geçirmelerde)

· Gözden geçirilen çalışma ürününde tespit edilen hataların çözülmesi (genellikle çalışma ürününün yazarı/oluşturucusu tarafından yapılan)

· Hataların (gözden geçirilen çalışma ürünüyle bağlantılı başka bir çalışma ürününde bulunduğunda) uygun kişi veya ekibe iletilmesi

6. Takip

· Hataların ele alınıp alınmadığını kontrol etme

· Metrikleri toplama

· Çıkış kriterini kontrol etme

· Hataların giderilmesi ve raporlama

· Olanaklar dâhilinde yorumu yapan kişinin onayını da alarak, güncellenmiş hata durumlarının (resmî gözden geçirmelerde) kaydedilmesi

· Değişiklik gerektiren bulgular için hata raporlarının oluşturulması

· Metriklerin toplanması (resmî gözden geçirme türleri için)

· Çıkış kriterlerinin karşılandığının kontrol edilmesi (resmî gözden geçirme türleri için)

· Çıkış kriterleri sağlandığında çalışma ürününün kabul edilmesi. Bir çalışma ürünü gözden geçirmesinin sonuçları, gözden geçirme türüne ve resmî olup olmamasına
bağlı olarak değişir.

12.2. Gözden Geçirme Sürecindeki Farklı Rol ve

Sorumluluklar
Gözden geçirme sürecindeki farklı rol ve sorumluluklar aşağıdaki şekilde ifade edilebilir:

· Yönetici

· Moderatör

· Yazar

· Gözden Geçiriciler

· Katip (Yazıcı veya Kaydedici)

Şekil 12.2’de bu rol ve sorumluluklar sembolize edilmiştir.

Şekil 12.2. Gözden Geçirme Rol ve Sorumluluklar

Bu rollerin sahip olduğu görev ve yetkiler aşağıdaki gibi ifade edilebilir.

1. Yönetici

· Gözden geçirme planlamasından sorumludur.

· Gözden geçirmelerin uygulanmasına karar verir.

· Personel, bütçe ve zaman tahsis eder.

· Mevcut maliyet etkinliğini izler.

· Sürecin verimli işletilmesiyle ilgili kararları verir.

126
· Önerilen değerlendirmelerin uygulanıp uygulanmayacağına karar verir.

· Uygulanacak önerileri proje takvimine ekler ve gözden geçirme toplantısının hedeflerine ulaşılıp ulaşılmadığına karar verir.

2. Moderatör

· Doküman veya doküman grubunun gözden geçirilme işlemini yapar.

· Gözden geçirmenin planlanmasını, toplantının gerçekleştirilmesini ve toplantı sonrasında takiplerin yapılmasını yönetir.

· Gerekirse moderatör çeşitli bakış açıları arasında aracılık yapar.

3. Yazar

· Gözden geçirilecek dokümanların sahibidir.

4. Gözden Geçiriciler

· Gerekli hazırlıklardan sonra gözden geçirilen dokümandaki bulguları (örn. hatalar) tanımlayan ve açıklayan, teknik veya alan bilgisine sahip kişilerdir. Kontrol edici
veya müfettiş adı da verilir.

· Gözden geçiricilerin gözden geçirme sürecinde farklı bakış açılarını temsil etmesi ve tüm gözden geçirme toplantılarında yer alması gerekir.

· Konunun uzmanları, projede çalışan kişiler, çalışma ürünü üzerinde söz sahibi olan paydaşlar ve/veya belirli teknik veya iş tecrübesine sahip kişiler olabilir.

5. Katip (Yazıcı veya Kaydedici)

· Toplantı sırasında tanımlanan tüm sorunları, problemleri ve açık noktaları kayıt altına alır.

· Her bir gözden geçirme faaliyeti sırasında bulunan bulguları bir araya getirir ve sıraya koyar.

· Gözden geçirme toplantısında belirlenen yeni potansiyel hataları, açık noktaları ve kararları kaydeder.

· Bazı gözden geçirme çeşitlerinde bir kişi birden fazla rol oynayabilir ve her rolle ilgili görevler gözden geçirme çeşidine göre değişiklik gösterebilir.

· Ek olarak, gözden geçirme sürecini, özellikle hataların, açık noktaların ve kararların kaydedilmesini destekleyen araçların ortaya çıkmasıyla, çoğu zaman bir
yazıcıya gerek duyulmaz.

12.3. Başarılı
Bir Gözden Geçirmeye Katkıda Bulunan Faktörler
Gözden geçirme, yazılımlar için oldukça önemli bir işlemdir ve pek çok faydası bulunmaktadır. Bu konudaki yapılan çalışmalardan bazılarının sonuçları aşağıdaki
gibidir (Alptekin, 2008).

· Jet Propulsion Laboratory şirketinin NASA için geliştirdiği bir yazılım üzerinde yaptığı 300 kod gözden geçirmenin şirkete getirisinin 7,5 milyon dolar olduğu tahmin
edilmektedir.

· Bir başka çalışmada müşteri ortamında bulunan hataların 2900 dolara mal olduğu fakat kod gözden geçirmeler ile bulunan hataların 146 dolara indiği görülmüştür.

· Hewlett-Packard denetim programında bire on kazanç dönüşümü alınmıştır.

· Aetna Sigorta Şirketi ve AT&T Bell Laboratuarları kod gözden geçirmelerle kod üretkenliğini arttırmıştır (Wiegers, 2008).

· ModSoft’da 6 yıl süreyle yapılmış çalışmada proje maliyetine %1–%2 arasında bir maliyet eklenerek problem gözlenmesinde %40 düşüş yaşandığını görülmüştür
(Baker, 1997).

Bu çalışmalardan da görüldüğü gibi üretkenlik kod gözden geçirmelerle beraber artmaktadır. Bunun nedeni erken safhadan yakalanan hataların düzeltilmesinin
maliyetinin, sonradan yakalanma maliyetinden çok daha az oluşudur. Başarılı bir gözden geçirme gerçekleştirmek için uygun gözden geçirme çeşidi ve tekniği
kullanılmalıdır. Bunun yanında, gözden geçirmenin sonucunu etkileyecek bir dizi başka faktör vardır. Gözden geçirmenin organizasyonel başarı faktörleri aşağıdaki
gibidir:

· Her gözden geçirme, gözden geçirme planlaması sırasında tanımlanan ve ölçülebilir çıkış kriterleri olarak kullanılan net hedeflere sahip olmalıdır.

· Hedeflere ulaşmak için uygun olan ve gözden geçirilecek çalışma ürünlerinin ve katılımcıların türüne ve seviyesine uygun gözden geçirme çeşitleri uygulanmalıdır.

· Gözden geçirme tekniklerinin tümü, kontrol listesine dayalı veya role dayalı gözden geçirme gibi, gözden geçirilecek çalışma ürünündeki hataların etkili bir şekilde
bulunmasına yardımcı olmalıdır.

· Kullanılan tüm kontrol listeleri ana riskleri ele almalı ve güncel olmalıdır.

· Büyük dokümanlar küçük parçalar halinde ele alınmalı ve gözden geçirilmelidir.

· Katılımcıların hazırlanmak için yeterli zamanı olmalıdır.

· Gözden geçirmeler, uygun şekilde önceden bildirimle planlanmalıdır.

· Yönetim, gözden geçirme sürecini desteklemelidir.

Gözden geçirmelerin kişilere bağlı başarı faktörleri aşağıdaki gibidir:

· Gözden geçirme hedeflerini yerine getirmek için doğru kişiler sürece dâhil olmalıdır; örneğin, dokümanı çalışmalarında kullanabilecek farklı beceri gruplarına veya
bakış açılarına sahip kişiler bu konu ile ilgili olarak dahil olmalıdır.

· Test uzmanları, gözden geçirmeye katkıda bulunan ve bu sayede çalışma ürünü hakkında bilgi sahibi olan değerli gözden geçiriciler olarak görülmelidir, bu da
onların daha etkin testler hazırlamasına ve bu testleri erkenden hazırlamasına olanak sağlamalıdır.

127
· Katılımcılar detaylara yeterince zaman ayırmalı ve özen göstermelidir.

· Gözden geçirmeler küçük parçalar üzerinde yapılmalıdır, böylece gözden geçiriciler bireysel gözden geçirme ve/veya (yapılıyorsa) gözden geçirme toplantısı
sırasında konsantrasyonlarını kaybetmezler.

· Belirlenen hatalar olumlu bir şekilde karşılanmalı, takdir edilmeli ve nesnel olarak değerlendirilmelidir.

· Toplantı iyi yönetilmelidir, böylece katılımcılar bunu zamanlarının faydalı bir şekilde kullanımı olarak görebilirler.

· Gözden geçirme bir güven ortamında gerçekleştirilmelidir; çıktı, katılımcıların kişisel olarak değerlendirilmesinde kullanılmamalıdır.

· Katılımcılar; sıkılma, öfke veya diğer katılımcılara düşmanlık olarak anlaşılabilecek beden dilinden ve davranışlardan kaçınmalıdır.

· Özellikle teftişler gibi daha resmî gözden geçirme çeşitleri için yeterli eğitim sağlanmalıdır.

· Öğrenme ve süreç iyileştirme kültürü desteklenmelidir.

Gözden geçirmeleri başarısız kılan faktörler ise aşağıdaki gibi ifade edilebilir (Wong, 2006; Wiegers, 1998):

· Proje Takviminde İyi Planlanmamış Gözden Geçirmeler

· İyi Tanımlanmamış Gözden Geçirme Süreci

· Eğitim Eksikliği

· Gözden Geçirme Ekibinin Yetkin Kişileri İçermemesi

· İyi Tanımlanmamış Rol ve Sorumluluklar

· Gözden Geçirmeler İçin Yetersiz Kaynak Planlama

· Eksik Gözden Geçirme Materyalleri

· Yetersiz Bireysel Hazırlık

· Amacını Aşan Eleştiriler

· Toplantı Gündeminden Sapma

12.4. Farklı Gözden Geçirme Çeşitleri

Çeşitli gözden geçirme çeşitleri bulunmaktadır. Bunların en önemlileri gayrı resmî gözden geçirme, üzerinden geçme, teknik gözden geçirme ve teftiştir.

Gayri resmî gözden geçirme: (örneğin; çalışma arkadaşının kontrol etmesi, eşleştirme, eşli gözden geçirme): buradaki ana amaç potansiyel hataların bulunmasıdır,
diğer amaçlar ise yeni fikirler veya çözümler üretmek ve küçük problemleri hızla çözmek şeklinde ifade edilebilir. Bu gözden geçirme isminden de anlaşılacağı üzere
resmî (dokümante edilmiş) bir sürece dayanmaz, dolayısıyla bir gözden geçirme toplantısı düzenlenmeyebilir. Bu işlem birçok kişi tarafından gerçekleştirilebilir.

· Sonuçlar dokümante edilebilir.

· Gözden geçiricilere bağlı olarak faydası değişir.

· Kontrol listelerinin kullanımı isteğe bağlıdır.

· Çevik yazılım geliştirmede çok yaygın kullanılır.

Üzerinden geçme: buradaki ana amaçlar hataların bulunması, yazılımın iyileştirilmesi, alternatif uygulamaların dikkate alınması, standartlara ve gereksinimlere
uygunluğun değerlendirilmesidir, diğer amaçlar ise teknikler veya yöntem farklılıkları hakkında fikir alışverişinde bulunmak, katılımcıların eğitimi ve fikir birliğine
varmaktır. Bu yöntemde gözden geçirme toplantısından önceki bireysel hazırlık isteğe bağlıdır, gözden geçirme toplantısı genellikle çalışma ürününün yazarı tarafından
yönetilir. Bu toplantıda bir yazıcının olması zorunludur ancak kontrol listelerinin kullanımı isteğe bağlıdır. Senaryolar, provalar veya simülasyonlar şeklinde olabilir,
potansiyel hata kayıtları ve gözden geçirme raporları oluşturulabilir, gayrı resmîden, çok resmî olan haline kadar değişiklik gösterebilir.

Teknik gözden geçirme: buradaki ana amaçlar, fikir birliğine varmak ve potansiyel hataların bulunmasıdır, diğer amaçlar ise kalitenin değerlendirilmesi ve çalışma
ürünü için güven oluşturulması, yeni fikirler üretilmesi, alternatif çözümleri göz önünde bulundurarak gelecekteki iş ürünlerini iyileştirmek için paydaşları motive etmek
ve olanak sağlamak şeklinde ifade edilebilir. Buradaki gözden geçiriciler yazarın teknik olarak dengi olan diğer veya aynı disiplinlerdeki teknik uzmanlardan
seçilmelidir. Gözden geçirme toplantısından önce bireysel hazırlık gereklidir. Gözden geçirme toplantısı isteğe bağlı olup, ideal olarak eğitimli bir moderatör
(genellikle çalışma ürününün geliştirilmesine dâhil olmayan kişiler) tarafından yönlendirilir. Bir yazıcı bulunması zorunludur, idealde çalışma ürünü yazarından farklı biri
olmalıdır. Kontrol listelerinin kullanımı isteğe bağlıdır. Potansiyel hata kayıtları ve gözden geçirme raporları genellikle oluşturulur.

Teftiş: buradaki ana amaçlar, potansiyel hataların bulunması, çalışma ürünündeki kaliteyi değerlendirmek ve güven oluşturmak, çalışma ürününü yazanların öğrenmesi
ve kök neden analizi yoluyla gelecekteki benzer hataları önlemek; diğer amaçlar ise ürün sahiplerini gelecekteki çalışma ürünlerini ve yazılım geliştirme sürecini
iyileştirmeye motive etmek ve olanak sağlamak, fikir birliği sağlamak şeklinde ifade edilebilir. Kurallara ve kontrol listelerine dayanarak, resmî, dokümante çıktılarla
tanımlanmış bir süreci izler. Zorunlu olan, açıkça tanımlanmış roller kullanır ve (gözden geçirme toplantısında çalışma ürününü yüksek sesle okuyacak) özel bir
okuyucu yer alabilir. Gözden geçirme toplantısından önce bireysel hazırlık gereklidir. Gözden geçiriciler çalışma ürünü yazarının dengi veya çalışma ürünü ile ilgili
diğer disiplinlerde uzman kişilerdir. Belirlenen giriş ve çıkış kriterleri kullanılır. Yazıcı olması zorunludur. Gözden geçirme toplantısı eğitimli bir moderatör (çalışma
ürünü yazarı dışında) tarafından yönetilir. Yazar; gözden geçirme lideri, okuyucu veya yazıcı olarak görev yapamaz. Potansiyel hata kayıtları ve gözden geçirme
raporu oluşturulur. Metrikler toplanır ve teftiş süreci de dâhil olmak üzere tüm yazılım geliştirme sürecini iyileştirmek için kullanılır. Tek bir çalışma ürününe, birden
fazla gözden geçirme çeşidi uygulanabilir. Birden fazla gözden geçirme çeşidi kullanılıyorsa, uygulama sıralaması değişebilir. Örneğin, çalışma ürününün teknik gözden
geçirmeye hazır olduğundan emin olmak için teknik gözden geçirmeden önce gayri resmî bir gözden geçirme yapılabilir. Yukarıda açıklanan gözden geçirme çeşitleri
eş-gözden geçirme olarak benzer organizasyonel seviyedeki meslektaşlar tarafından yapılabilir. Gözden geçirme sürecinde bulunan hata çeşitleri, özellikle gözden
geçirilen çalışma ürününe bağlı olarak değişiklik gösterir.

12.5. Gözden Geçirme Tekniği Uygulaması

128
Hataları bulmak için bireysel gözden geçirme (bireysel hazırlık) faaliyeti sırasında uygulanabilecek birkaç gözden geçirme tekniği vardır. Bu teknikler yukarıda
açıklanan gözden geçirme çeşitlerinde kullanılabilir. Tekniklerin etkinliği kullanılan gözden geçirme çeşidine bağlı olarak değişebilir. Çeşitli gözden geçirme türleri için
farklı bireysel gözden geçirme tekniklerinin örnekleri aşağıda listelenmiştir:

· Kurgusuz Gözden Geçirme

· Senaryolar ve Provalar

· Role Dayalı Gözden Geçirme

· Bakış Açısına Dayalı Gözden Geçirme

Kurgusuz Gözden Geçirme: Kurgusuz gözden geçirmede gözden geçiricilere bu görevin nasıl gerçekleştirilmesi gerektiği hakkında çok az rehberlik sağlanır veya
hiç sağlanmaz. Gözden geçiriciler genellikle çalışma ürününü sırayla okur ve karşılaştıkları sorunları dokümante eder. Kurgusuz gözden geçirme çok az hazırlık
gerektiren ve yaygın kullanılan bir tekniktir. Bu teknik büyük ölçüde gözden geçiricilerin becerilerine bağlıdır ve farklı gözden geçiriciler tarafından bildirilen birçok
benzer sorunun bulunmasına yol açabilir. Kontrol listesine dayalı gözden geçirme gözden geçiricilerin gözden geçirme başlangıcında (örneğin moderatör tarafından)
dağıtılan kontrol listelerine dayanarak sorunları belirlediği sistematik bir tekniktir. Gözden geçirme kontrol listesi deneyimle elde edilen ve olası hatalara dayanan bir
dizi sorudan oluşur. Kontrol listeleri gözden geçirilmekte olan çalışma ürününe özel olmalı ve önceki gözden geçirmelerde kaçırılan sorun türlerini kapsayacak şekilde
düzenli olarak güncellenmelidir. Kontrol listesine dayalı tekniğin en önemli avantajı tipik hata çeşitlerinin sistematik bir şekilde kapsanmasıdır. Bireysel gözden
geçirmelerde sadece kontrol listesini takip etmekle yetinmemeye ve kontrol listesinin dışındaki hataları da aramaya özen gösterilmelidir.

Senaryolar ve Provalar: Senaryoya dayalı gözden geçirmede gözden geçiricilere çalışma ürününü nasıl okuyacaklarına ilişkin rehberler sağlanır. Senaryoya dayalı
yaklaşım, (çalışma ürünü, kullanım senaryoları gibi uygun bir biçimde dokümante edilmişse) çalışma ürünü üzerinde “provalar” yapılmasını sağlayarak gözden
geçiricilerin işini kolaylaştırır. Bu senaryolar, gözden geçiricilere hata çeşitlerini bulma konusunda basit kontrol listelerinden daha iyi rehberlik sağlar. Kontrol listesine
dayalı gözden geçirmelerde olduğu gibi diğer hata çeşitlerini (örneğin, eksik özellikler) kaçırmamak için, gözden geçiricilerin dokümante senaryolarla
sınırlandırılmaması gerekir.

Role Dayalı Gözden Geçirme: Role dayalı gözden geçirme, gözden geçiricilerin çalışma ürününden etkilenen her bir paydaşın rolleri gözünden çalışma ürününü
değerlendirdiği bir tekniktir. Genellikle roller arasında farklı son kullanıcı grupları (deneyimli, deneyimsiz, kıdemli, çocuk vb.) ve kurumdaki belirli roller (kullanıcı
yöneticisi, sistem yöneticisi, performans testi uzmanı vb.) yer alır.

Bakış Açısına Dayalı Gözden Geçirme: Bakış açısına dayalı okumada, role dayalı gözden geçirmeye benzer şekilde, gözden geçiriciler bireysel gözden geçirme
aşamasında farklı paydaş bakış açılarını dikkate alır. Tipik paydaş bakış açıları arasında son kullanıcı, pazarlama, tasarımcı, test uzmanı veya kurum yönetimi yer alır.
Farklı paydaş bakış açılarının kullanılması bireysel gözden geçirmede daha fazla derinliğe ulaşılmasını sağlar ve gözden geçiriciler tarafından benzer sorunları bulunma
olasılığını azaltır. Bakış açısına dayalı okuma ayrıca gözden geçiricilerin, çalışma ürününü kullanmaya çalışmasını da gerektirir. Örneğin bir test uzmanı, gereksinimler
üzerinde son kullanıcını bakış açısına dayalı bir okuma yapıyorsa, gerekli tüm bilgilerin dâhil edilip edilmediğini görmek için taslak kabul testleri oluşturmaya
çalışacaktır. Ayrıca, bakış açısına dayalı okumalarda kontrol listelerinin kullanılması beklenir. Yapılan çalışmalar, bakış açısına dayalı okumanın gereksinimleri ve
teknik çalışma ürünlerini gözden geçirmek için en etkili teknik olduğunu göstermiştir. Farklı paydaş bakış açılarını sürece dâhil etmek ve risklere dayanarak uygun
şekilde ağırlıklarını belirlemek önemli başarı faktörlerinden biridir.

Bölüm Özeti
Gözden geçirme planlama, başlama, kişisel hazırlık, gözden geçirme toplantısı, yeniden çalışma, takip aşamalarından oluşmaktadır. Gözden geçirme işleminde
yönetici, moderatör, yazar, gözden geçiriciler ve katip rolleri bulunmaktadır. Yönetici gözden geçirme planlamasından sorumlu kişidir, moderatör doküman veya
doküman grubunun gözden geçirilme işlemini yapan kişidir, yazar gözden geçirilecek dokümanların sahibi veya bunlardan sorumlu olan kişidir, gözden geçiriciler
gerekli hazırlıklardan sonra gözden geçirilen dokümandaki bulguları (örn. hatalar) tanımlayan ve açıklayan, teknik veya alan bilgisine sahip kişilerdir, katip toplantı
sırasında tanımlanan tüm sorunları, problemleri ve açık noktaları kayıt altına alan kişidir. Gözden geçirmenin başarılı olması için organizasyonel ve kişisel başarı
faktörleri bulunmaktadır: örneğin her gözden geçirme, gözden geçirme planlaması sırasında tanımlanan ve ölçülebilir çıkış kriterleri olarak kullanılan net hedeflere
sahip olmalıdır, gözden geçirme hedeflerini yerine getirmek için doğru kişiler sürece dâhil olmalıdır. Gözden geçirmeleri başarısız kılan faktörler ise

· Proje Takviminde İyi Planlanmamış Gözden Geçirmeler

· İyi Tanımlanmamış Gözden Geçirme Süreci

· Eğitim Eksikliği

· Gözden Geçirme Ekibinin Yetkin Kişileri İçermemesi

· İyi Tanımlanmamış Rol ve Sorumluluklar

· Gözden Geçirmeler İçin Yetersiz Kaynak Planlama

· Eksik Gözden Geçirme Materyalleri

· Yetersiz Bireysel Hazırlık

· Amacını Aşan Eleştiriler

· Toplantı Gündeminden Sapma

şeklinde ifade edilebilir.

Literatürde farklı gözde geçirme teknikleri bulunmaktadır, bunların en önemlileri

· Gayri Resmî Gözden Geçirme

· Üzerinden Geçme

· Teknik Gözden Geçirme

· Teftiş

şeklindedir.
129
Gayri resmî gözden geçirmedeki ana amaçlar potansiyel hataların bulunmasıdır, diğer amaçlar ise yeni fikirler veya çözümler üretmek ve küçük problemleri hızla
çözmektir. Üzerinden geçmedeki ana amaçlar hataların bulunması, yazılımın iyileştirilmesi, alternatif uygulamaların dikkate alınması, standartlara ve gereksinimlere
uygunluğun değerlendirilmesidir, diğer amaçlar ise teknikler veya yöntem farklılıkları hakkında fikir alışverişinde bulunmak, katılımcıların eğitimi ve fikir birliğine
varmaktır. Teknik gözden geçirmedeki ana amaçlar, fikir birliğine varmak ve potansiyel hataların bulunmasıdır, diğer amaçlar ise kalitenin değerlendirilmesi ve çalışma
ürünü için güven oluşturulması, yeni fikirler üretilmesi, alternatif çözümleri göz önünde bulundurarak gelecekteki iş ürünlerini iyileştirmek için paydaşları motive etmek
ve olanak sağlamaktır. Teftişteki ana amaçlar potansiyel hataların bulunması, çalışma ürünündeki kaliteyi değerlendirmek ve güven oluşturmak, çalışma ürününü
yazanların öğrenmesi ve kök neden analizi yoluyla gelecekteki benzer hataları önlemek; diğer amaçlar ise ürün sahiplerini gelecekteki çalışma ürünlerini ve yazılım
geliştirme sürecini iyileştirmeye motive etmek ve olanak sağlamak, fikir birliği sağlamaktır.

Çeşitli gözden geçirme türleri için farklı bireysel gözden geçirme tekniklerinin örnekleri aşağıda listelenmiştir:

· Kurgusuz Gözden Geçirme

· Senaryolar ve Provalar

· Role Dayalı Gözden Geçirme

· Bakış Açısına Dayalı Gözden Geçirme

Kurgusuz gözden geçirmede gözden geçiricilere bu görevin nasıl gerçekleştirilmesi gerektiği hakkında çok az rehberlik sağlanır veya hiç sağlanmaz. Senaryoya dayalı
gözden geçirmede gözden geçiricilere çalışma ürününü nasıl okuyacaklarına ilişkin rehberler sağlanır. Role dayalı gözden geçirme, gözden geçiricilerin çalışma
ürününden etkilenen her bir paydaşın rolleri gözünden çalışma ürününü değerlendirdiği bir tekniktir. Bakış açısına dayalı gözden geçirmede role dayalı gözden
geçirmeye benzer şekilde, gözden geçiriciler bireysel gözden geçirme aşamasında farklı paydaş bakış açılarını dikkate alır.

Kaynakça

Y. K. Wong, “Modern software review:techniques and technologies”, USA, IRM Pres, 2006

K. E. Wiegers, “Seven Deadly Sins of Software Reviews”, Software Development Magazine, 1998

K. Wiegers, P. Moore “ Lightweight Tool Support For Effective Code Reviews”, 2008

R, A. Baker, “Code review enhance software quality”, 19th International Conference on Software Engineering, Boston, Massachusetts, United States, 570-571,
1997

M. T. Alptekin, “Yazılımda kod gözden geçirme sürecinde Kod kalitesi ölçümünün sürece ve Yazılım kalitesine etkisinin incelenmesi”, İstanbul Teknik Üniversitesi,
Fen Bilimleri Enstitüsü, Yüksek Lisans Tezi, 2008

Ünite Soruları

Soru-1 :

Aşağıdakilerden hangisi gözden geçirme testi sürecinde yer alan aktivitelerden biri değildir?

(•) - Yeniden Çalışma

(•) - Sonuçları İnceleme

(•) - Başlama

(•) - Kişisel Hazırlık

(•) - Analiz

Cevap-1 :

Analiz

Soru-2 :

Aşağıdakilerden hangisi gözden geçirmenin başlama aşamasında gerçeekleştirilen bir işlemdir?

(•) - Gözden geçirme kriterini belirleme

(•) - Belgeleri gözden geçirerek gözden geçirme toplantısına hazırlanma

(•) - Belgeleri dağıtma

(•) - Bulunan hataları düzeltme

(•) - Metrikleri toplama

Cevap-2 :

Belgeleri dağıtma

130
Soru-3 :

Aşağıdakilerden hangisi gözden geçirme sürecinde yer alan rollerden biri değildir?

(•) - Yönetici

(•) - Analist

(•) - Yazar

(•) - Moderatör

(•) - Katip

Cevap-3 :

Analist

Soru-4 :

Aşağıdakilerden hangisi gözden geçirme sürecinde yazar için söylenebilir?

(•) - Gözden geçirme planlamasından sorumlu olan kişidir.

(•) - Müfettiş adı da verilen kişidir.

(•) - Toplantı sırasında tanımlanan tüm sorunları, problemleri ve açık noktaları kayıt altına altına alan kişidir.

(•) - Doküman veya doküman grubunun gözden geçirilme işlemini yapan kişidir.

(•) - Gözden geçirilecek dokümanların sahibi veya bunlardan sorumlu olan kişidir.

Cevap-4 :

Gözden geçirilecek dokümanların sahibi veya bunlardan sorumlu olan kişidir.

Soru-5 :

Aşağıdakilerden hangisi gözden geçirmeleri başarısız kılan faktörlerden biri değildir?

(•) - Eğitim Eksikliği

(•) - Eksik Gözden Geçirme Materyalleri

(•) - Kullanılan Yanlış Araçlar

(•) - Yetersiz Bireysel Hazırlık

(•) - Amacını Aşan Eleştiriler

Cevap-5 :

Kullanılan Yanlış Araçlar

Soru-6 :

Aşağıdakilerden hangisi en sıklıkla kullanılan gözden geçirme yöntemlerinden biri değildir?

(•) - Sistematik analiz

(•) - Gayrı resmî gözden geçirme

(•) - Üzerinden geçme

(•) - Teknik gözden geçirme

(•) - Teftiş

Cevap-6 :

Sistematik analiz

Soru-7 :

Aşağıdakilerden hangisi bireysel bir gözden geçirme tekniği değildir?

131
(•) - Kurgusuz Gözden Geçirme

(•) - Senaryolar ve Provalar

(•) - Role Dayalı Gözden Geçirme

(•) - Bakış Açısına Dayalı Gözden Geçirme

(•) - Analize Bağlı Gözden Geçirme

Cevap-7 :

Analize Bağlı Gözden Geçirme

Soru-8 :

Metrikleri toplama gözden geçirme aşamalarının hangisinde yer alan bir işlemdir?

(•) - Takip

(•) - Yeniden Çalışma

(•) - Gözden Geçirme Toplantısı

(•) - Başlama

(•) - Kişisel Hazırlık

Cevap-8 :

Takip

Soru-9 :

Uygulanacak önerileri proje takvimine eklemek gözden geçirme sürecindeki hangi rolün bir görevidir?

(•) - Yönetici

(•) - Moderatör

(•) - Yazar

(•) - Gözden geçiriciler

(•) - Katip

Cevap-9 :

Yönetici

132
13. YAZILIM TEST SERTİFİKASYONLARI
Giriş
Yazılım testi geçmişten günümüze, her geçen gün popülerliği artan bir konudur. Öyle ki yakın zamanda sadece yazılım testi ile ilgilenmesi beklenen iş alanları oluşmuş;
yazılım test uzmanı, yazılım test mühendisi vb kavramlar ortaya çıkmıştır. Bu popülerliğin artması ve daha fazla sayıda insanın bu alanda bir kariyer inşa etme isteğine
sahip olması ile birlikte kaçınılmaz olarak işverenlerin bu konu ile ilgilenen kişiler arasında bir seçim yapması gerekmektedir. Pek çok iş alanında olduğu gibi bu
alanda da kişilerin akredite olmaları için çeşitli kuruluşlar tarafından çeşitli sertifika programları ortaya çıkarılmıştır. Günümüzde yazılım testi sertifikası veren
kuruluşların sayısı oldukça yüksek olmasına rağmen kaliteli sertifikasyon sunan kuruluşların sayısı oldukça azdır. Bu bölümde bunların en önemlisi olan ISTQB
(International Software Testing Qualifications Board–Uluslararası Yazılım Testi Yeterlilikler Kurulu) ve ona bağlı bir şekilde kurulan TTB (Turkish Testing Board–
Türk Test Kurulu) incelenmiştir. Bu inceleme esnasında dünyada ve Türkiye’de yazılım testi ile ilgili yapılan çalışmalara da yer verilmiştir.

13.1. ISTQB
ISTQB, uluslararası alanda faaliyet gösteren bir yazılım test yeterlilik belgelendirme kuruluşudur (ISTQB, 2021). Kasım 2002'de Belçika'da kurulmuştur, yasal
olarak kayıtlı, kar amacı gütmeyen bir dernektir. ISTQB, yazılım testinde yeterliliklerin belgelendirilmesinde dünya çapında lider haline gelen “ISTQB Sertifikalı Test
Uzmanı” şemasını tanımlamıştır. ISTQB, yüzlerce uluslararası test uzmanının gönüllü çalışmasına dayalı bir organizasyondur. ISTQB’nin amaçları aşağıdaki şekilde
ifade edilebilir:

· Bir meslek olarak yazılım testinin değerini bireylere ve kuruluşlara tanıtmak

· Yetkinliklerin belgelendirilmesi yoluyla yazılım testçilerinin çalışmalarında daha verimli ve etkili olmalarına yardımcı olmak

· Test uzmanlarının bir Profesyonel Etik Kuralları ve onlara artan sorumluluklarını yerine getirmek ve daha fazla profesyonellik elde etmek için ihtiyaç duydukları bilgi
ve becerileri sağlayan çok seviyeli bir sertifika yolu aracılığıyla kariyerlerinde ilerlemelerini sağlamak

· Mevcut en iyi endüstri uygulamalarından ve en yenilikçi araştırmalardan yararlanarak test bilincini sürekli olarak geliştirmek ve bu bilgiyi herkes için ücretsiz olarak
erişilebilir hale getirmek

· Bilgi gövdesinin dünya çapında tutarlı bir şekilde sunulmasını sağlamak için eğitim sağlayıcılarını akredite etmek için kriterleri belirlemek

· Sınav sorularının içeriğini ve kapsamını, sınav sürecini ve resmî sınav kurumları tarafından sertifika verilmesini düzenlemek

· Üye kurulları ISTQB’ye kabul ederek yazılım testi sertifikalarını dünya çapında genişletmek, bu kurulların, ISTQB tarafından tanımlanan tüzük, tüzük ve süreçlere
bağlı kalmasını ve düzenli denetimlere katılmasını sağlamak

· Yazılım testinde bilgi, fikir ve yenilikleri paylaşmaya kendini adamış açık bir uluslararası topluluğu beslemek

· Akademi, hükümet, medya, meslek kuruluşları ve diğer ilgili taraflarla ilişkileri geliştirmek

· Yazılım testinde saygın bir bilgi kaynağı olarak öne çıkmayı sürdürerek, test hizmetlerinin etkinliğinin değerlendirilebileceği bir referans noktası sağlamak

Geçmişten günümüze ISTQB’nin gelişimi şu şekilde ifade edilebilir:

· 2002: ISTQB Avusturya, Danimarka, Finlandiya, Almanya, İsveç, İsviçre, Hollanda ve Birleşik Krallık olmak üzere 8 üye ülke kurulu tarafından kurulmuştur.

· 2003: İleri Seviye olarak nitelendirilen test müfredatı tamamlanmıştır.

· 2004: ISTQB Certified-Tester Advanced Level (İleri Seviye) için ilk sınavlar oluşturulmuştur.

· 2006: Üye kurullarının sayısı istikrarlı bir şekilde artmıştır.

· 2007: Temel ve İleri Seviye test müfredatları güncellenmiş ve geliştirilmiştir.

· 2009: Üye Kurullarının sayısı daha da artmış ve verilen sertifika sayısı 100.000'e ulaşmıştır.

· 2010: BCS, ISEB Test Uygulayıcı programını ISTQB Sertifikalı Test Uzmanı İleri Seviye lehine geri çekmiştir, ayrıca ilk “Uzman Seviyesi” sınavı için müfredat
yayınlanmıştır.

· 2011: Dünya çapında verilen sertifika sayısı 200.000'i geçmiştir, ayrıca Uzman Seviyesinde sertifika verilmeye başlanmıştır.

· 2012: İleri Düzey ders programının yeni versiyonu ve Terimler Sözlüğü Testi yapılmaya başlanmıştır. ISTQB Ortak Programı etkinleştirilmiştir. ISTQB Konferans
Ağı ve ISTQB Recognized Mobile Uygulaması etkinleştirilmiştir. ISTQB Uluslararası Yazılım Testi Mükemmellik Ödülü’nün ilk sayısı oluşturulmuştur.

· 2013: ISTQB’nin verdiği sertifika sayısı dünya çapında 300.000’i geçmiştir.

· 2014: Agile Tester Foundation Extension malzemeleri kullanıma sunulmuştur.

· 2015: ISTQB’nin verdiği sertifika sayısı dünya çapında 400.000’i geçmiştir. Model Tabanlı Test Cihazı (MBT) müfredatı kamuya açık hale getirilmiştir. ISTQB,
tarihi Core'a ek olarak Çevik ve Uzman akışlarıyla yeni ürün portföyü yayınlamıştır.

2021 Ocak ayı itibariyle ISTQB ile ilgili en önemli sayısal değerler aşağıdaki gibi ifade edilebilir.

· Üye Kurul Sayısı: 66

· Uygulanan sınav sayısı: 1.030.000’den fazla

· Verilen sertifika sayısı: 750.000’den fazla

· Üye Kurulları tarafından doğrudan kapsanan ülke sayısı: 129

133
· Akredite Eğitim Sağlayıcıları: 330

Aşağıdaki şekilde (Şekil 13.1) mavi renk üye ülkeleri ve global sınav sağlayıcıları gösterirken, gri renkler global sınav sağlayıcıları tarafından kapsanan ülkeleri
göstermektedir.

Şekil 13.1. ISTQB Ülke Dağılımı

ISTQB sertifikalarına sahip olmak için pek çok sebep sayılabilir. Bu sebepler aşağıda özetlenmiştir.

· Yüksek Kaliteli Müfredat: Tüm müfredatlar, akademi ve endüstriden önde gelen test uzmanları tarafından geliştirilmekte ve gözden geçirilmektedir.

· Küresel Tanınma: Sertifikalar, üye kurullar tarafından ISTQB politikalarının ve prosedürlerinin tutarlı bir şekilde uygulanması nedeniyle dünya çapında
tanınmaktadır.

· Ortak Dil: ISTQB Sözlüğü, meslek için ortak bir sözlük sağlamaktadır.

· Objektiflik: Test uzmanı yeteneklerinin değerlendirilmesi, ISTQB tarafından bağımsız olarak yürütülür ve yetkinliklerin objektif olarak doğrulanmasını sağlar.

· Etik Kurallara Bağlılık: Tüm ISTQB sertifikalı test uzmanları, ISTQB tarafından tanımlanan Etik Kurallarına bağlıdır.

· Genel Kullanılabilirlik: ISTQB sözlüğü ve ders programı, ISTQB web sitesinde ve Üye Kurulu web sitelerinde yerel dillerde ücretsiz olarak sunulmaktadır.

· Açıklık: ISTQB materyalleri gönüllülük esasına göre geliştirilir ve ISTQB çalışma gruplarına katılmak isteyen herkesin katkılarına açıktır.

· Bağımsızlık: ISTQB’in kar amacı gütmeyen doğası, içeriğin belirli metodolojiler veya teknolojiler tarafından kısıtlanmamasını ve çok çeşitli kaynaklardan en iyi
uygulamalardan yararlanabilmesini sağlar.

· Sürekli Gelişme: Müfredat ve diğer belgeler, dünya çapındaki İş Kuruluşlarının ihtiyaçlarını karşılamak ve mesleğin gelişimine ayak uydurmak için sürekli olarak
geliştirilmektedir.

· Profesyonel Duruş: Sertifikalı olmak, test uzmanlarının ISTQB tarafından belirlenen yüksek standartları karşılamasını sağlayarak bireyler ve kuruluşlar için
avantajlar sağlamaktadır.

ISTQB tarafından verilen sertifikalar üç farklı uzmanlık seviyesinde (Foundation–Temel Seviye, Advanced–İleri Seviye, Expert–Uzmanlık Seviyesi) yer almaktadır.
Bunun yanında özel uzmanlık gerektiren bazı alanlarla ilgili de sertifikaları bulunmaktadır. ISTQB tarafından verilen sertifikalar şekilde (Şekil 13.2) gösterilmiştir.

Temel Seviye: Bu müfredat, Temel Düzeyde Uluslararası Yazılım Test Kalifikasyonunun temelini oluşturur. ISTQB ulusal sınav kurumlarına eğitim sağlayıcıları
akredite etmelerini ve sınav sorularını kendi dillerinde türetmelerini sağlar. Eğitim sağlayıcılar, eğitim materyalleri üretecek ve akreditasyon için uygun öğretim
yöntemlerini belirleyecek ve müfredat, adayların sınava hazırlanmalarına yardımcı olmaktadır. Temel Seviye yeterliliği, yazılım testinde yer alan herkese yöneliktir.
Buna test uzmanları, test analistleri, test mühendisleri, test danışmanları, test yöneticileri, kullanıcı kabul test uzmanları ve yazılım geliştiricileri gibi rollerdeki kişiler
dahildir. Bu Temel Seviye yeterliliği, proje yöneticileri, kalite yöneticileri, yazılım geliştirme yöneticileri, iş analistleri, BT yöneticileri ve yönetim danışmanları gibi temel
yazılım testi anlayışı isteyen herkes için de uygundur. Temel Seviye Sertifika sahipleri, daha üst düzey bir yazılım testi yeterliliğine devam edebilmek için ilk önkoşulu
sağlamış olurlar.

134
Şekil 13.2. ISTQB Tarafından Uygulanan Sınavlar

İleri Seviye: Bu müfredat, İleri Düzeyde Uluslararası Yazılım Test Kalifikasyonunun temelini oluşturur. ISTQB, ulusal sınav kurumlarına eğitim sağlayıcıları akredite
etme ve sınav sorularını kendi dillerinde türetme olanağı sağlar. Eğitim sağlayıcılar, eğitim materyalleri üretecek ve akreditasyon için uygun öğretim yöntemlerini
belirleyecek ve müfredat, adayların sınava hazırlanmalarına yardımcı olacaktır. İleri Seviye yeterliliği, yazılım testinde kariyerlerinde ileri bir noktaya ulaşmış kişilere
yöneliktir. Buna test uzmanları, test analistleri, test mühendisleri, test danışmanları, test yöneticileri, kullanıcı kabul test uzmanları ve yazılım geliştiricileri gibi rollerdeki
kişiler dahildir. Bu İleri Seviye yeterlilik, proje yöneticileri, kalite yöneticileri, yazılım geliştirme yöneticileri, iş analistleri, BT direktörleri ve yönetim danışmanları gibi
yazılım testi konusunda daha derin bir anlayış isteyen herkes için de uygundur. İleri Seviye yazılım testi sertifikası almak için adayların Temel Sertifikaya sahip olmaları
ve İleri Seviyede kalifiye olarak kabul edilmek için yeterli pratik deneyime sahip olduklarını inceleyen Sınav Kurulu’nu tatmin etmeleri gerekir.

ISTQB sertifikalarının arasında ilk olarak alınması gereken “Foundation Level (Temel Seviye)” sertifikasıdır. Diğer sertifikaların başvuru şartlarında bu sertifikayı
almış olmak önkoşul olarak yer almaktadır. Ayrıca bu seviye adından da anlaşılacağı gibi yazılım testi hakkında temel bilgileri ölçtüğünden bu sertifikayı alacak
bilgilere sahip olmayan bir kişinin, daha üst seviyelerdeki daha uzmanlaşmış bilgilere sahip olunarak alınabilecek test sertifikası sınavlarını geçmeleri çoğunlukla
mümkün olmayacaktır. Bu sertifikayı aldıktan sonra “Agile”, “Core” veya uzmanlık alanlarını içeren “Speciality” gibi üç farklı kategoride yer alan sertifikaları almak
için diğer sınavlara girmek mümkündür. ISTQB halihazırda var olan sertifikalara ek olarak sürekli yenilerini çıkarmaya devam etmektedir, böylece zamanla kişilerin
kendilerine daha uygun sertifika programları bulma olasılıkları yükselmektedir. Ancak ne yazık ki ülkemizde bu sertifikaların tamamı alınamamaktadır. Türkiye’de
yapılan ISTQB sınavları sadece

· ISTQB Certified Tester Foundation Level (Temel Seviye)

135
· ISTQB Certified Tester Foundation–Agile Tester Extension (Çevik Test)

· Test Manager–ISTQB Certified Tester Advanced Level (Test Yöneticisi–İleri Seviye)

· Test Analyst–ISTQB Certified Tester Advanced Level (Test Analisti–İleri Seviye)

· Technical Test Analyst–ISTQB Certified Tester Advanced Level (Teknik Test Analisti–İleri Seviye)

şeklinde olmak üzere 5 adettir.

ISTQB, yazılım testi sertifikasyonu alanında uluslararası standarttır. İster test etme kariyerine yeni başlıyor olun, ister yıllardır bu alanda çalışıyor olun, bir ISTQB
sertifikası kazanmak önemli avantajlar sunar. Bu avantajlar aşağıdaki gibi ifade edilebilir:

· işverenlerin güvendiği becerilerin bağımsız, uluslararası kabul görmüş bir doğrulaması

· hem mevcut hem de gelecekteki istihdam için taşınabilir yetenek kanıtı

· kariyer ilerlemesini desteklemek için beceriler geliştirme ve genişletme

· profesyonel güvenilirliği artırma

ISTQB sertifikalarına sahip olmak hem kişisel hem kurumsal olarak prestij kazandırma anlamına da gelmektedir. Şekil 13.3’te firmalara sorulan “İş arkadaşlarınızın
ISTQB sertifikası almasını ister misiniz?” sorusuna 2016 ve 2020 yıllarında verilen cevapların oranını göstermektedir. Görüldüğü gibi 2016 yılında ve 2020 yılında
Evet deme oranı gittikçe artmıştır.

Şekil 13.3. İş arkadaşlarınızın ISTQB sertifikası almasını ister misiniz? Sorusuna Verilen Cevaplar

ISTQB sertifikalarının şirketler ve akredite eğitim sağlayıcılar için faydaları ise şu şekilde ifade edilebilir.

Şirketler için Faydaları

· ISTQB sertifikası, verimli ve uygun maliyetli test uygulamaları sayesinde geliştirilmekte olan uygulamaların daha yüksek düzeyde güvenilirliğini sağlayarak
müşterilere işe daha fazla güven vererek rekabet avantajı sağlayabilir.

· Sertifikalı personele sahip danışmanlık şirketleri, müşterilere daha üst düzey hizmetler sunarak gelirlerini ve marka değerini artırabilmektedir.

· ISTQB Ortak Programına Erişim sağlanabilmektedir.

· Yöneticilerin çoğunluğu ISTQB sertifikasının önemini gördüğünden, bu, şirkette (şirketin bölümleri/departmanları arasında) ortak anlayış söz konusu olduğunda ve
ISTQB'yi kullanma konusunda sertifika almanın büyük önem taşıdığını göstermektedir.

Akredite Eğitim Sağlayıcılar için Faydaları

· Eğitim kurumları ve danışmanlık şirketleri, uluslararası düzeyde tanımlanan süreç ve kurallara göre ISTQB Akredite Eğitmen Sağlayıcı olabilir.

· Akreditasyon, mevcut ve potansiyel müşterilere güvence sağlar ve güvenilirliği artırır.

· Akredite Eğitim Sağlayıcıları, sertifikalı eğitmenler, ISTQB kurulları tarafından kontrol edilen eğitim materyallerinin içeriği, kalitesi ve müfredat kapsamına sahip
olarak yüksek standartta bir eğitim verilmesini sağlar.

· ISTQB Sözlüğü ve ders programında yapılan değişiklikler önceden bildirilir.

· Akredite Eğitim Sağlayıcıları, ilgili logoları kullanma hakkına sahiptir ve ISTQB Web Sitesinde listelenmiştir.

13.2. TTB
TTB 2006 yılında yazılım test ve kalite alanında dünyanın en saygın gönüllü organizasyonu olan ISTQB’a bağlı olarak kurulmuştur (TTB, 2021). Bu tarihten itibaren,
Türkiye’deki bilişim profesyonellerinin yazılım testi alanında ISTQB standartlarında eğitilmesi ve sertifikalanması amacıyla çalışmalarına başlamıştır.

TTB faaliyetleri

136
· Türkiye Bilişim Sektörünün uluslararası pazarlarda rekabet edebilmesi için sektörün yazılım testi ve kalitesi konusunda bilgilendirilmesi

· ISTQB sınavlarının yapılarak sınavı kazanan adayların sertifikasyonu

· Yazılım testi konusunda uluslararası kabul görmüş içeriğin Türkçeleştirilmesi

şeklinde ifade edilebilir.

TTB, çeşitli etkinlikler yaparak ve yayınlar yayınlayarak hizmetlerini sürdürmektedir. Bunlar arasında TestIstanbul Konferansı önemli bir yer tutmaktadır. Ayrıca yıllık
olarak Türkiye Yazılım Kalite Raporu yayınlanmaktadır.

13.2.1. TestIstanbul

TestIstanbul konferansı 2010’dan beri gerçekleştirilen, yazılım testi üzerine çalışmaların tartışıldığı, onlarca konuşmacı ve binlerce katılımcının katıldığı yıllık
uluslararası bir konferanstır (TestIstanbul, 2021). Bugüne kadar Google, Oracle, Facebook, Netflix, Intechnica, GitHub, ThoughtWorks, SmartBear,
GamingWorks, Expedia.com, Turkish Airlines, Udemy, Huawei, AvivaSa, Migros, LCWaikiki, Kariyer.net, Turksat, Intertech, Keytorc, Turkcell, Mercedes-Benz,
Bilyoner, Mobven, TEB, Anadolu Sigorta, BKM, Garanti Teknoloji, Innova, Yapı Kredi, Havelsan, iyzico, Spotify, Nespresso, Testinium gibi sayısız kurum ve
kuruluşun katıldığı konferansta her yıl bir tema ele alınmaktadır. Konferansın teması her yıl aşağıdaki gibi belirlenmiştir.

· TestIstanbul 2010: Yazılım Testi: İşletme ve BT Arasında Kalite Köprüsü (Software Testing: Quality Bridge Between Business & IT)

· TestIstanbul 2011: Daha Fazla Kullanılabilirlik Testi, Daha İyi Kullanıcı Deneyimi (More Usability Testing, Better User Experience)

· TestIstanbul 2012: Daha İyi, Daha Hızlı Bir Yazılım İçin Test Otomasyonu (Test Automation For A Better, Faster Software)

· TestIstanbul 2013: Testin Geleceği: Yeni Teknikler ve Metodolojiler (Future Of Testing: New Techniques And Methodologies)

· TestIstanbul 2014: Mobil Test (Mobile Testing: Testing On The Move)

· TestIstanbul 2015: Performans Testi: İşletme Tarafından Yönlendirilen Yüksek Performans (Performance Testing: High Performance Driven By Business)

· TestIstanbul 2016: Test Veri Yönetimi (Test Data Management)

· TestIstanbul 2017: Çevik Test (Agile Testing)

· TestIstanbul 2018: Herhangi bir tema belirtilmemiş

· TestIstanbul 2019: Test Mühendisi X.0: Yazılım Testinde Parlak Bir Kariyer Fırsatı - Test Ekiplerinize Yeniden Enerji Verin (Test Engineer X.0: A Bright Career
Opportunity In Software Testing - Re-Energize Your Testing Teams!)

· TestIstanbul 2020: Test ve Test Otomasyonunda Robotik Proses Otomasyonu (RPA) Sürekli Test, Sürekli Entegrasyon ve DevOps (Robotic Process Automation
(RPA) In Testing And Test Automation, Continuous Testing, Continuous Integration & DevOps)

· TestIstanbul 2021: DevOps: Yazılım Testi ve Otomasyonla Güçlendirilir (Empowered By Software Testing & Automation)

Şekil 13.4.’te TestIstanbul konferansının 2021 yılı etkinliği görülmektedir.

Şekil 13.4. TestIstanbul 2021

13.2.2. Türkiye Yazılım Kalite Raporu

Türkiye’de 2011 yılı itibariyle yüzlerce bilişim profesyonelinin katılımıyla, yazılım projelerinin kalitesi konusunda kapsamlı analizleri içeren ve her yıl tekrarlanan
Türkiye Yazılım Kalite Raporu/Turkey Software Quality Report (TSQR) Yazılım Test ve Kalite Derneği tarafından sektörün bilgisine sunulmaktadır (Türkiye Yazılım
Kalite Raporu, 2021). TSQR Türkiye’de bulunan mevcut durumu göz önüne sermekle kalmamakla birlikte bilişim sektöründeki hedef ve trendlerin daha iyi

137
belirlenmesinde uzmanlara ışık tutmaktadır. TestIstanbul gibi her yıl farklı konuların ele alındığı raporda ele alınan konular yıllık olarak aşağıdaki şekilde ifade
edilebilir:

· Türkiye Yazılım Kalite Raporu 2011-2012: Test Organizasyonu ve Süreci, Test Otomasyon Araçları, Test Eğitimi, Kullanılabilirlik Testi

· Türkiye Yazılım Kalite Raporu 2012-2013: Test Organizasyonu ve Süreci, Test Otomasyon Araçları, Test Eğitimi, Kullanılabilirlik Testi

· Türkiye Yazılım Kalite Raporu 2013-2014: Test Organizasyonu ve Süreci, Test Otomasyon Araçları, Test Eğitimi, Kullanılabilirlik Testi

· Türkiye Yazılım Kalite Raporu 2014-2015: Mobil Uygulamalar

· Türkiye Yazılım Kalite Raporu 2015-2016: İş Odaklı Performans Testi

· Türkiye Yazılım Kalite Raporu 2016-2017: Test Veri Yönetimi

· Türkiye Yazılım Kalite Raporu 2017-2018: Çevik Test

· Türkiye Yazılım Kalite Raporu 2018-2019: Yazılım Geliştirme Yaşam Döngüsü

· Türkiye Yazılım Kalite Raporu 2019-2020: Yazılım Test Kariyeri

· Türkiye Yazılım Kalite Raporu 2020-2021: Robotik Süreç Otomasyonu

Şekil 13.5.’te Türkiye Yazılım Kalite Raporu 2020-2021 görünmektedir.

Şekil 13.5. Türkiye Yazılım Kalite Raporu 2020-2021

Bölüm Özeti
ISTQB, uluslararası alanda faaliyet gösteren bir yazılım test yeterlilik belgelendirme kuruluşudur. Kasım 2002’de Belçika'da kurulmuştur, yasal olarak kayıtlı, kar
amacı gütmeyen bir dernektir. ISTQB, yazılım testinde yeterliliklerin belgelendirilmesinde dünya çapında lider haline gelen “ISTQB Sertifikalı Test Uzmanı” şemasını
tanımlamıştır. ISTQB, yüzlerce uluslararası test uzmanının gönüllü çalışmasına dayalı bir organizasyondur. ISTQB’nin amaçları genel olarak yazılım testi konusunda
farkındalık yaratmak ve kişilere yetkinlik sağlamak olarak ifade edilebilir. ISTQB tarafından verilen sertifikalar üç farklı uzmanlık seviyesinde (Temel Seviye, İleri
Seviye, Uzmanlık Seviyesi) yer almaktadır. Bunun yanında özel uzmanlık gerektiren bazı alanlarla ilgili de sertifikaları bulunmaktadır. Türkiye’de yapılan ISTQB
sınavları

· Temel Seviye

· Çevik Testi

· Test Yöneticisi – İleri Seviye

· Test Analisti – İleri Seviye

· Teknik Test Analisti – İleri Seviye

şeklindedir.

TTB 2006 yılında yazılım test ve kalite alanında dünyanın en saygın gönüllü organizasyonu olan ISTQB’a bağlı olarak kurulmuştur. Bu tarihten itibaren, Türkiye’deki
bilişim profesyonellerinin yazılım testi alanında ISTQB standartlarında eğitilmesi ve sertifikalanması amacıyla çalışmalarına başlamıştır. TTB faaliyetleri; Türkiye
Bilişim Sektörünün uluslararası pazarlarda rekabet edebilmesi için sektörün yazılım testi ve kalitesi konusunda bilgilendirilmesi, ISTQB sınavlarının yapılarak sınavı
kazanan adayların sertifikasyonu ve yazılım testi konusunda uluslararası kabul görmüş içeriğin Türkçeleştirilmesi şeklinde ifade edilebilir. TTB, çeşitli etkinlikler
yaparak ve yayınlar yayınlayarak hizmetlerini sürdürmektedir. Bunlar arasında TestIstanbul Konferansı önemli bir yer tutmaktadır. Ayrıca yıllık olarak Türkiye Yazılım
Kalite Raporu yayınlanmaktadır.

138
TestIstanbul konferansı 2010’dan beri gerçekleştirilen, yazılım testi üzerine çalışmaların tartışıldığı, onlarca konuşmacı ve binlerce katılımcının katıldığı yıllık
uluslararası bir konferanstır. Bugüne kadar İşletme ve BT arasındaki iletişim, kullanılabilirlik testi, test otomasyonları, test konusundaki yeni teknikler ve
metodolojiler, mobil test, performans testi, test veri yönetimi, Çevik Test, test mühendisi, Robotik Proses Otomasyonu, Sürekli Test, Sürekli Entegrasyon ve
DevOps konuları ele alınmıştır. Türkiye’de 2011 yılı itibariyle yüzlerce bilişim profesyonelinin katılımıyla, yazılım projelerinin kalitesi konusunda kapsamlı analizleri
içeren ve her yıl tekrarlanan Türkiye Yazılım Kalite Raporu/Turkey Software Quality Report Yazılım Test ve Kalite Derneği tarafından sektörün bilgisine
sunulmaktadır.

Kaynakça

ISTQB, https://www.istqb.org/, 2021

TTB, https://www.turkishtestingboard.org/, 2021

TestIstanbul, https://testistanbul.org/, 2021

Türkiye Yazılım Kalite Raporu, https://www.turkishtestingboard.org/turkiye-yazilim-kalite-raporu/, 2021

Ünite Soruları

Soru-1 :

Aşağıdakilerden hangisi ISTQB tarafından Türkiye’de yapılan sınavlardan biri değildir?

(•) - Test Analisti – İleri Seviye

(•) - Test Yöneticisi – İleri Seviye

(•) - Çevik Test

(•) - Temel Seviye

(•) - Güvenlik Testi

Cevap-1 :

Güvenlik Testi

Soru-2 :

Aşağıdakilerden hangisi bir ISTQB sertifikası kazanmanın avantajlarından biri değildir?

(•) - İşverenlerin güvendiği becerilerin bağımsız, uluslararası kabul görmüş bir doğrulaması

(•) - Analiz ve implementasyon arasında köprü kurma

(•) - Profesyonel güvenilirliği artırma

(•) - Kariyer ilerlemesini desteklemek için beceriler geliştirme ve genişletme

(•) - Hem mevcut hem de gelecekteki istihdam için taşınabilir yetenek kanıtı

Cevap-2 :

Analiz ve implementasyon arasında köprü kurma

Soru-3 :

Ülkemizde her sene düzenli olarak yapılan ve yazılım testi konusunu ele alan konferansın adı nedir?

(•) - Turkish Testing Board

(•) - Testing Board

(•) - TestIstanbul

(•) - Test Analiz

(•) - Test Fabrikası

Cevap-3 :

TestIstanbul

Soru-4 :

139
TTB’nin açılımı nedir?

(•) - Turkish Testing Board

(•) - Turkish Testing Bill

(•) - Trade Testing Board

(•) - Trade Testing Bill

(•) - Testing Turkey Board

Cevap-4 :

Turkish Testing Board

Soru-5 :

Aşağıdakilerden hangisi ISTQB’nin sınavlarının seveiyelerini ifade eder?

(•) - Sıfır – Bir – İki

(•) - Sınır – Uç – İleri

(•) - Başlangıç – Orta – Son

(•) - Başlangıç – İleri – Uzman

(•) - A – B – C 

Cevap-5 :

Başlangıç – İleri – Uzman

Soru-6 :

Türkiye Yazılım Kalite Raporu ne kadar sıklıkta basılmaktadır?

(•) - Her gün

(•) - Haftada bir

(•) - 15 günde bir

(•) - Ayda bir

(•) - Yılda bir

Cevap-6 :

Yılda bir

Soru-7 :

ISTQB kısaltmasındaki T harfinin karşılığı nedir?

(•) - Turing

(•) - Tester - Testçi

(•) - Testing – Test

(•) - Trade - Ticaret

(•) - Traditional - Geleneksel

Cevap-7 :

Testing – Test

Soru-8 :

Aşağıdakilerden hangisi ISTQB’nin vermekte olduğu özel uzmanlık sertifikalarından biri değildir?

140
(•) - Güvenlik Testi

(•) - Test Otomasyon Mühendisi

(•) - Model Tabanlı Test

(•) - Kullanılabilirlik Testi

(•) - Beyaz Kutu Testi

Cevap-8 :

Beyaz Kutu Testi

Soru-9 :

Aşağıdakilerden hangisi ISTQB’nin vermekte olduğu özel uzmanlık sertifikalarından biri değildir?

(•) - Otomotiv Yazılım Testi

(•) - Mobil Yazılım Testi

(•) - Performans Testi

(•) - Siyah Kutu Testi

(•) - Kabul Testi

Cevap-9 :

Siyah Kutu Testi

141
14. TEMEL SEVİYE YAZILIM TEST SERTİFİKASYON SINAVI
Giriş
ISTQB tarafından verilen akredite eğitim kursları için Sertifikalı Test Uzmanı Temel Seviye Ders Programı aşağıdaki gibi altı bölüme ayrılmıştır.

Bölüm 1: 175 dakika Yazılım Testinin Temelleri

Bölüm 2: 100 dakika Yazılım Geliştirme Yaşam Döngüsü Boyunca Testler

Bölüm 3: 135 dakika Statik Testler

Bölüm 4: 330 dakika Test Teknikleri

Bölüm 5: 225 dakika Test Yönetimi

Bölüm 6: 40 dakika Yazılım Testleri için Araç Desteği

Buna göre toplamda en az 16,75 saat kurs alabilen kişilerin bu sınava girmeleri uygundur.

14.1. Yazılım Testinin Temelleri

KONU 1.1 Yazılım Testi nedir?

SORU 1.1.1 Yazılım testinin genel hedeflerini tanımlayın.

CEVAP:

· Belirtilen tüm gereksinimlerin yerine getirilip getirilmediğini doğrulamak

· Test nesnesinin eksiksiz olup olmadığının sağlamasını yapmak

· Hataları tespit etmek ve önlemek

· Sözleşmeden kaynaklanan, yasal veya düzenleyici gereksinimlere veya standartlara uymak

SORU 1.1.2 Test ile hata ayıklamanın farklarını belirtin.

CEVAP:

Testlerin yürütülmesi, yazılımdaki hataların neden olduğu arızaları gösterebilir. Hata ayıklama ise arızaların arkasında yatan hataları bulan, analiz eden ve düzelten
yazılım geliştirme faaliyetidir.

KONU 1.2 Yazılım Testi Neden Gereklidir?

SORU 1.2.1 Örnekler vererek yazılım testinin neden gerekli olduğunu açıklayın.

CEVAP:

Bilişim tarihi boyunca, yazılım ve sistemlerin uygulamaya alınması ve daha sonra var olan hatalar nedeniyle arızalara neden olması veya paydaşların ihtiyaçlarını
karşılamaması oldukça sık görülmüştür. Bununla birlikte uygun test tekniklerinin kullanılması, bu tekniklerin uygun test seviyelerinde ve yazılım geliştirme yaşam
döngüsünün uygun noktalarında uygulanması bu gibi sorunlu ürünleri azaltabilmektedir.

SORU 1.2.2 Yazılım testi ve kalite güvence arasındaki ilişkiyi tanımlayın ve testlerin kaliteyi nasıl artırdığına dair örnekler verin.

CEVAP:

İnsanlar testlerden bahsederken sıklıkla “kalite güvence” tabirini kullansa da, kalite güvence ve test aynı şey değildir. Daha büyük bir kavram olan kalite yönetimi bu
ikisini birbirine bağlar. Kalite yönetimi, bir kurumu kalite açısından yönlendiren ve kontrol eden tüm faaliyetleri içerir. Kalite yönetimi diğer faaliyetlerle birlikte kalite
güvenceyi ve kalite kontrolünü de içerir.

SORU 1.2.3 İnsan hatası, hata ve arıza arasındaki farkı ayırt edin.

CEVAP:

Bir kişinin yaptığı bir yazılım hatası (yanlışlık), yazılım kodunda veya ilgili başka bir çalışma ürününde bir hatanın (kusur) ortaya çıkmasına neden olabilir. Çalışma
ürününde bir hata oluşmasına neden olan bir yazılım hatası, bir hatayı tetikleyebilir, bu da ilgili bir çalışma ürününde başka bir hatanın ortaya çıkmasına neden olabilir.

SORU 1.2.4 Bir hatanın kök nedeni ile etkileri arasındaki farkı ayırt edin.

CEVAP:

Hataların kök nedenleri, hataların oluşmasına sebep olan en baştaki eylemler veya koşullardır. Hatalar, kök nedenlerini belirlemek için analiz edilebilir, böylece
gelecekte benzer hataların ortaya çıkma olasılığının azaltılması hedeflenir.

KONU 1.3 Yedi Test Prensibi

SORU 1.3.1 Yedi test prensibini açıklayın.

CEVAP:

Kitap içerisinde bu konuya değinildiğinden burada tekrar yer verilmemiştir.

142
KONU 1.4 Test Süreci

SORU 1.4.1 Proje bağlamının test süreci üzerindeki etkisini açıklayın.

CEVAP:

· Kullanılan yazılım geliştirme yaşam döngüsü modeli ve proje metodolojileri

· Ele alınan test seviyeleri ve test çeşitleri

· Ürün ve proje riskleri

· Kurumun faaliyet alanı

· Sözleşmeden kaynaklanan ve yasal gereksinimler

SORU 1.4.2 Test sürecindeki test faaliyetlerini ve ilgili görevleri tanımlayın.

CEVAP:

Test planlama, test hedeflerini belirleyen aktiviteler ve proje bağlamının dayattığı kısıtlamalar dâhilinde test hedeflerini yerine getirme yaklaşımını içerir.

Test gözetimi, test planında tanımlanan test gözetim metriklerini kullanarak planlanan ile gerçekleşen ilerlemenin sürekli karşılaştırılmasını içerir.

Test kontrolü, test planında belirlenen hedeflere ulaşmak için gerekli önlemlerin alınmasını içerir.

Test tasarımı sırasında test koşulları; üst seviye test senaryoları, üst seviye test senaryo grupları ve test yazılımları gibi ayrıntılar belirlenir. Bu nedenle, test analizi “ne
test edilecek?” sorusuna cevap verirken, test tasarımı “nasıl test edilecek?” sorusuna cevap verir.

Test uyarlama sırasında, test koşumu için eğer gerekiyorsa test yazılımı oluşturulur ve/veya tamamlanır; buna test senaryolarından test prosedürleri üretmek de
dâhildir. Dolayısıyla, test tasarımı “nasıl test edilecek?” sorusuna cevap verirken, test uyarlama “şu anda testleri koşmak için gerekli şeylere sahip miyiz?” sorusuna
cevap arar.

Test koşumu sırasında, test grupları test koşum çizelgesine uygun olarak çalıştırılır.

Test tamamlama aktiviteleri; test projesinde elde edilen deneyimi, proje boyunca üretilen test yazılımını ve elde edilen diğer ilgili bilgileri toplar ve bir araya getirir.

SORU 1.4.3 Test sürecini destekleyen çalışma ürünlerini tanımlayın.

CEVAP:

Test planlama çalışma ürünleri genellikle bir veya daha fazla test planı içerir. Test planı, diğer test çalışma ürünlerinin izlenebilirlik bilgileri sayesinde ilişkili olacağı test
esası hakkında bilgiler ve test gözetimi ve kontrolü sırasında kullanılacak çıkış kriterlerini içerir.

Test gözetimi ve kontrolü çalışma ürünleri genellikle, test ilerleme raporları ve test özet raporları dâhil olmak üzere birçok test raporu çeşitlerini içerir.

Test analizi çalışma ürünleri, tanımlanmış ve önceliklendirilmiş test koşullarını içerir; bu koşulların her biri idealde kapsadığı test esasının unsurlarına çift yönlü olarak
izlenebilir olmalıdır.

Test tasarımı, test analizinde belirlenen test koşullarını uygulamak için test senaryoları ve test senaryosu gruplarının belirlenmesi ile sonuçlanır. Girdi verileri ve
beklenen sonuçlar için somut değerlere atıfta bulunmadan, üst seviye test senaryoları tasarlamak genellikle iyi bir uygulamadır.

Test uyarlama çalışma ürünleri test prosedürleri ve bu test prosedürlerinin sıralanması, test grupları ve test koşum çizelgesini içermektedir.

SORU 1.4.4 Test esası ve test çalışma ürünleri arasında izlenebilirliğin sağlanmasının önemini açıklayın.

CEVAP:

Test çalışma ürünleri ve bu çalışma ürünlerinin isimleri önemli ölçüde değişmektedir. Bu değişikliklerden bağımsız olarak, etkin test gözetimi ve kontrolünü uygulamak
için, test süreci boyunca test esasının her unsuru ile bu unsurla ilişkili çeşitli test çalışma ürünleri arasında izlenebilirliğin oluşturulması ve sürdürülmesi önemlidir.

KONU 1.5 Test Etme Psikolojisi

SORU 1.5.1 Yazılım testinin başarısını etkileyen psikolojik faktörleri tanımlayın.

CEVAP:

Psikolojide yer alan “doğrulama sapması” tezine göre, mevcut görüş ve inançlara uymayan bilgilerin kabul edilmesi kolay değildir. Örneğin, yazılımcılar kodlarının
hatasız olmasını beklediklerinden, kodun hatalı olduğunu kabul etmelerini zorlaştıran bir doğrulama sapmasına sahiptirler. Doğrulama sapmasının yanında diğer bilişsel
eğilimler insanların testlerde elde edilen bilgileri anlamalarını veya kabul etmelerini zorlaştırabilir. Ayrıca, kötü haber elçilerini suçlamak ortak bir insani özelliktir ve
testlerde üretilen bilgiler sıklıkla kötü haberler içerir. Bu psikolojik faktörlerin bir sonucu olarak, projenin ilerlemesine ve ürün kalitesine büyük katkı sağlasa da, bazı
insanlar testleri yıkıcı bir faaliyet olarak algılayabilir. Bu algıları azaltmak için, hatalar ve arızalar hakkındaki bilgiler yapıcı bir şekilde iletilmelidir.

SORU 1.5.2 Test faaliyetleri için gereken bakış açısı ile yazılım geliştirme faaliyetleri için gereken bakış açısı arasındaki farkı açıklayın.

CEVAP:

Yazılım geliştirmenin temel amacı bir ürün tasarlamak ve üretmektir. Testlerin hedefleri ise ürünün doğrulanması ve sağlamasının yapılması, canlıya alınmadan önce
hataların bulunması ve benzeri işlerdir. Bunlar farklı düşünce tarzları gerektiren farklı işlerdir. Bu düşünce tarzlarını bir araya getirmek ürün kalitesinin artmasına
yardımcı olur. Bir düşünce tarzı, karar verme ve problem çözme için bir bireyin varsayımlarını ve tercih ettiği yöntemleri yansıtır. Bir test uzmanının düşünce tarzı
merak, profesyonel karamsarlık, eleştirel bir bakış açısı, ayrıntılara dikkat, iyi ve pozitif iletişim ve ilişkiler için motivasyon içermelidir. Bir test uzmanının düşünce
tarzı, test uzmanı deneyim kazandıkça gelişme ve olgunlaşma eğilimindedir. Bir yazılımcının düşünce tarzı, bir test uzmanının düşünce tarzının bazı unsurlarını içerebilir,
ancak yazılımcılar, genellikle çözümler tasarlamak ve oluşturmakla ilgilenir, bu çözümlerde neyin yanlış olabileceğini fazla düşünmez.

143
14.2. Yazılım Geliştirme Yaşam Döngüsü Boyunca Test
KONU 2.1 Yazılım Geliştirme Yaşam Döngüsü Modelleri

SORU 2.1.1 Yazılım geliştirme yaşam döngüsü içindeki yazılım geliştirme aktiviteleri ile test aktiviteleri arasındaki ilişkileri açıklayın.

CEVAP:

Yaygın yazılım geliştirme yaşam döngüsü modelleri sıralı yazılım geliştirme modelleri ve döngüsel ve artımlı yazılım geliştirme modelleridir.

Sıralı bir yazılım geliştirme modeli, yazılım geliştirme sürecini doğrusal, sıralı bir faaliyetler akışı olarak tanımlar. Bu, yazılım geliştirme sürecinde her aşamanın önceki
aşama tamamlandığında başlaması gerektiği anlamına gelir. Teorik olarak aşamaların kesişimi yoktur, ancak uygulamada takip eden aşamadan erken geri bildirim
almak faydalıdır.

Döngüsel yazılım geliştirme, ele alınan yazılım özelliklerinin genellikle sabit bir süreye sahip bir dizi döngüde belirlenmesi, tasarlanması, oluşturulması ve birlikte test
edilmesi anlamına gelir. Döngüler, daha önceki döngülerde geliştirilen yazılım özelliklerindeki değişikliklerin yanı sıra proje kapsamındaki değişiklikleri de içerebilir.

SORU 2.1.2 Yazılım geliştirme yaşam döngüsü modellerinin neden proje ve ürün özellikleri bağlamına uyarlanması gerektiğini açıklayın.

CEVAP:

Yazılım geliştirme yaşam döngüsü modelleri, proje bağlamına ve ürün özelliklerine göre seçilmeli ve uyarlanmalıdır. Proje hedefine, geliştirilen ürün çeşidine, kurum
önceliklerine ve belirlenmiş ürün ve proje risklerine göre uygun bir yazılım geliştirme yaşam döngüsü modeli seçilmeli ve uyarlanmalıdır.

KONU 2.2 Test Seviyeleri

SORU 2.2.1 Farklı test seviyelerini hedefler, test esası, test nesneleri, genel hatalar ve arızalar ile yaklaşımlar ve sorumluluklar açısından
karşılaştırın.

CEVAP:

Kitap içerisinde bu konuya değinildiğinden burada tekrar yer verilmemiştir.

KONU 2.3 Test Çeşitleri

SORU 2.3.1 Fonksiyonel ve fonksiyonel olmayan testleri karşılaştırın.

CEVAP:

Kitap içerisinde bu konuya değinildiğinden burada tekrar yer verilmemiştir.

KONU 2.4 Bakım Testleri

SORU 2.4.1 Bakım testleri için tetikleyicileri özetleyin.

CEVAP:

· Değişiklik: planlanan iyileştirmeler, düzeltici ve acil durum değişiklikleri, operasyonel ortamdaki değişiklikler, ticari paket yazılımın üst bir sürüme yükseltilmesi,
hatalar ve güvenlik açıkları için yamalar gibi.

· Taşıma: yeni ortamın ve değiştirilen yazılımın operasyonel testlerini gerektirebilen, bir platformdan diğerine taşıma gibi veya başka bir uygulamadan gelen verilerin
dönüştürülme ihtiyacı sonucu testlerinin yapılması gibi.

· Kullanımdan kaldırma: bir uygulamanın kullanım ömrünün sonuna gelinmesi gibi.

SORU 2.4.2 Bakım testlerinde etki analizinin rolünü açıklayın.

CEVAP:

Etki analizi, bir değişikliğin beklenen ve olası yan etkilerini, istenilen sonuçların elde edilip edilemeyeceğini ve değişiklikten etkilenecek alanları belirlemek amacıyla
yapılır. Etki analizi bir değişikliğin mevcut testler üzerindeki etkisinin belirlenmesinde de yardımcı olabilir. Sistemdeki yan etkilerin ve etkilenen alanların regresyon
testleri gerekli değişiklikler yapıldıktan sonra yapılmalıdır. Bir değişiklik yapılmadan önce, sistemin diğer alanlarında yaratacağı potansiyel sonuçlara dayanarak
değişikliğin yapılıp yapılmayacağına karar vermek için etki analizi yapılabilir.

14.3. Statik Testler

KONU 3.1 Statik Testlerin Temelleri

SORU 3.1.1 Farklı statik test teknikleri ile incelenebilecek çalışma ürünü çeşitlerini ayırt edin.

CEVAP:

Her türlü çalışma ürünü statik testler (gözden geçirme ve/veya statik analiz) kullanılarak incelenebilir.

SORU 3.1.2 Statik testlerin önemini tanımlamak için örnekler verin.

CEVAP:

Statik test teknikleri çeşitli faydalar sağlar. Yazılım geliştirme yaşam döngüsünün erken dönemlerinde uygulandığında statik testler, dinamik testler yapılmadan önce
hataların erkenden bulunmasına olanak sağlar. Erken bulunan hataların düzeltilmesi, özellikle yazılım canlıya alındıktan sonra veya yazılım yaşam döngüsünün ileri
aşamalarında bulunan hatalarla karşılaştırıldığında çok daha düşük maliyetlidir. Özellikle hata ile ilgili çalışma ürünlerinin güncellenmesi, onaylama ve regresyon
testlerinin yapılması için gereken ek maliyetler göz önüne alındığında, hataları bulmak için statik test tekniklerini kullanmak ve bu hataları hemen düzeltmek, test
nesnesindeki hataları bulmak için dinamik testleri kullanmaktan ve sonrasında bunları düzeltmekten neredeyse her zaman daha az maliyetlidir.

144
SORU 3.1.3 Hedeflerini, belirlenecek hata çeşitlerini ve bu tekniklerin yazılım yaşam döngüsü içindeki rolünü göz önünde bulundurarak statik ve
dinamik teknikler arasındaki farkları açıklayın.

CEVAP:

Statik ve dinamik testler, farklı türdeki hataları bularak birbirini tamamlarlar ancak elbette ki farklılıklar mevcuttur. Dinamik testlerle karşılaştırıldığında, statik testler
ile bulunması ve düzeltilmesi daha kolay ve daha ucuz olan yaygın hatalar şunlardır:

· Gereksinim hataları

· Tasarım hataları

· Kodlama hataları

· Standartlardan sapmalar

· Hatalı arayüz gereksinimleri

· Güvenlik açıkları

14.4. Test Tasarım Teknikleri

KONU 4.1 Test Tekniklerinin Kategorileri

SORU 4.1.1 Kara kutu test teknikleri, beyaz kutu test teknikleri ve tecrübeye dayalı test tekniklerinin özelliklerini, ortak yanlarını ve aralarındaki
farkları açıklayın.

CEVAP:

Hangi test tekniğinin kullanılacağı, bir dizi faktöre bağlıdır, bunlardan bazıları, birim veya sistem tipi, birim veya sistem karmaşıklığı, yasal standartlar, müşteri veya
sözleşme gereksinimleri, risk seviyeleri, risk çeşitleri, test hedefleri, mevcut dokümantasyon, test uzmanının bilgi ve yetenekleri, kullanılabilir araçlar, süre ve bütçe,
yazılım geliştirme yaşam döngüsü modeli, yazılımın beklenen kullanımı şeklindedir.

KONU 4.2 Kara Kutu Test Teknikleri

SORU 4.2.1 Test senaryolarını verilen gereksinimlerden üretmek için denklik paylarına ayırın.

CEVAP:

Denklik paylarına ayırma, verileri paylara (denklik sınıfları) ayırır; yazılım tarafından bir payın tüm üyelerinin benzer şekilde ele alınması beklenir. Hem geçerli hem de
geçersiz değerler için denklik payları vardır.

SORU 4.2.2 Test senaryolarını verilen gereksinimlerden üretmek için sınır değer analizi uygulayın.

CEVAP:

Sınır değer analizi, denklik paylarına ayırma tekniğinin genişletilmiş halidir, ancak yalnızca sayısal veya sıralı verilerden oluşan paylarda kullanılabilir.

SORU 4.2.3 Test senaryolarını verilen gereksinimlerden üretmek için karar tablosu testi uygulayın.

CEVAP:

Karar tablosu testlerinin de yer aldığı kombinasyonlu test teknikleri farklı test koşulları kombinasyonlarının nasıl farklı sonuçlar verdiğini test etmek için kullanılır.
Karar tabloları, bir yazılımın ele alması beklenen karmaşık iş kurallarını kaydetmenin iyi bir yoludur.

SORU 4.2.4 Test senaryolarını verilen gereksinimlerden üretmek için durum geçişi testi uygulayın.

CEVAP:

Birimler veya sistemler, mevcut veya geçmiş durumuna bağlı olarak gerçekleşen bir olaya farklı şekilde yanıt verebilir. Bir sistemin geçmiş davranışı, durumlar
kavramı kullanılarak özetlenebilir. Durum geçişi diyagramı, olası yazılım durumlarının yanı sıra, yazılımın ilgili durumlara nasıl girdiğini, çıktığını ve aralarındaki geçişleri
gösterir.

SORU 4.2.5 Test senaryosunun kullanım senaryosundan nasıl elde edileceğini açıklayın.

CEVAP:

Testler, farklı profildeki kullanıcıların yazılımla etkileşimleri modellemek için faydalanılan kullanım senaryolarından elde edilebilir; bu testler, kullanıcı gereksinimlerini
ele alır. Kullanım senaryoları, aktörler ve sistemlerle ilişkilidir.

KONU 4.3 Beyaz Kutu Test Teknikleri

SORU 4.3.1 Komut kapsamını açıklayın.

CEVAP:

Komut testi, kod içinde yer alan yürütülebilir komutların üzerinden geçilip bu komutların çalıştırılmasıdır. Kapsam, testler tarafından çalıştırılan komutların sayısının
test nesnesindeki çalıştırılabilir komutların toplam sayısına bölünmesi ile ölçülür ve yüzde olarak ifade edilir.

SORU 4.3.2 Karar kapsamını açıklayın.

CEVAP:

145
Karar testi, koddaki kararların üzerinden geçilip bu kararların çalıştırılması ve karar çıktılarına dayanarak kodun test edilmesidir. Kapsam, testler tarafından
çalıştırılan karar çıktılarının sayısının test nesnesindeki karar çıktılarının toplam sayısına bölünmesi ile ölçülür ve yüzde olarak ifade edilir.

SORU 4.3.3 Komut ve karar kapsamının önemini açıklayın.

CEVAP:

%100 komut kapsama yüzdesi sağlandığında koddaki tüm çalıştırılabilir komutların en az bir kez test edilmesi sağlanır, ancak tüm kararların tamamen test edilmesi
sağlanmaz. İki beyaz kutu tekniği arasında komut testleri, karar testlerine kıyasla daha az kapsama sağlayabilir. %100 karar kapsamı sağlandığında, tüm karar
çıktıları çalıştırılır; buna, doğru çıktının ve yanlış çıktının test edilmesi de dâhildir. Komut kapsama yüzdesi, kodda, diğer testler tarafından denenmemiş hataların
bulunmasına yardımcı olur. Karar kapsamı, ise diğer testlerin ele almadığı hem doğru hem de yanlış çıktıların ele alınmasını sağlar. %100 karar kapsamına ulaşılması
%100 komut kapsamına ulaşılmasını garanti eder (ancak bunun tersi geçerli değildir).

KONU 4.4 Tecrübeye Dayalı Test Teknikleri

SORU 4.4.1 Hata tahminlemeyi açıklayın.

CEVAP:

Hata tahminleme, test uzmanının bilgilerine dayalı olarak yanlışların, hataların ve arızaların oluşmasını sağlamak için kullanılan bir tekniktir. Hata tahminleme tekniğine
metodolojik bir yaklaşım, olası yanlışların, hataların ve arızaların bir listesini oluşturmak ve bu arızaları ve bunlara neden olan hataları ortaya çıkaracak testler
tasarlamaktır. Bu yanlış, hata, arıza listeleri tecrübeye, hata ve arıza verilerine dayanarak veya yazılımların neden başarısız olduğu hakkındaki genel bilgilerden yola
çıkarak oluşturulabilir.

SORU 4.4.2 Keşif testlerini açıklayın.

CEVAP:

Keşif testlerinde, test koşumu sırasında gayri resmî testler tasarlanır, koşturulur, kaydedilir ve dinamik olarak değerlendirilir. Test sonuçları, birim veya sistem
hakkında daha fazla bilgi edinmek ve daha fazla test gerektirebilecek alanlar için testler oluşturmak için kullanılır.

SORU 4.4.3 Kontrol listesine dayalı testi açıklayın.

CEVAP:

Kontrol listesine dayalı testlerde, test uzmanları bir kontrol listesinde bulunan test koşullarını kapsayacak şekilde testler tasarlar, uygular ve koşturur. Analizinin bir
parçası olarak, test uzmanları yeni bir kontrol listesi oluşturur veya mevcut bir kontrol listesini genişletir, ancak test uzmanları mevcut bir kontrol listesini değişiklik
yapmadan da kullanabilir. Bu kontrol listeleri tecrübe, kullanıcı için neyin önemli olduğu veya yazılımın niçin ve nasıl başarısız olabileceği bilgisine dayanarak
oluşturulabilir. Fonksiyonel ve fonksiyonel olmayan testleri desteklemek için kontrol listeleri oluşturulabilir.

14.5. Test Yönetimi

KONU 5.1 Test Organizasyonu

SORU 5.1.1 Bağımsız testlerin yararlarını ve sakıncalarını açıklayın.

CEVAP:

Testlerdeki bağımsızlık dereceleri (düşük bağımsızlık seviyesinden yüksek seviyeye) aşağıda sıralanmıştır:

· Bağımsız test uzmanı olmadan; yazılımcıların kendi kodlarını test etmesi

· Yazılımcıların diğer yazılımcıların kodlarını test etmesi veya yazılım geliştirme ekipleri veya proje ekibi içinde yer alan test uzmanlarının yazılımcıların kodlarını test
etmesi

· Kurum içinde, proje yönetimi veya üst düzey yöneticilere bağlı çalışan bağımsız test ekibi veya grubunun olması

· Kurumdan veya kullanıcılardan seçilen test uzmanlarının testleri yapması veya kullanılabilirlik, güvenlik, performans, yasal/uyumluluk veya taşınabilirlik gibi belirli
test çeşitlerinde uzmanlıklara sahip bağımsız test uzmanlarının testleri yapması

· Kurumun dışından gelen bağımsız test uzmanlarının ekip içine dahil edilerek veya ekip dışında yer alarak testleri yapması

SORU 5.1.2 Test yöneticisi ve test uzmanının görevlerini tanımlayın.

CEVAP:

Test yöneticisinin tipik görevleri:

· Kurum için test politikası ve test stratejisi geliştirmek veya bunları gözden geçirmek

· Proje ve test bağlamını göz önünde bulundurarak ve test hedeflerini ve risklerini anlayarak test faaliyetlerini planlamak

· Test planını/planlarını oluşturmak ve güncellemek

· Proje yöneticileri, ürün sahipleri ve diğer paydaşlarla birlikte test planını/planlarını koordine etmek

· Test bakış açılarını diğer proje faaliyetleriyle paylaşmak, örneğin entegrasyon planlama

· Testlerin analizini, tasarımını, uyarlanmasını ve koşturulmasını başlatmak, testin ilerlemesini ve sonuçlarını izlemek ve çıkış kriterlerinin durumunu kontrol etmek

· Elde edilen bilgilere dayanarak test ilerleme raporları ve test özet raporları hazırlamak ve göndermek

· Test sonuçlarına ve ilerlemesine dayanarak planlamayı revize etmek ve test kontrolü için gerekli önlemleri almak

146
· Hata yönetimi sistemi ve test yazılımı için gerekli yapılandırma yönetiminin kurulmasını desteklemek

· Test ilerlemesini ölçmek, testlerin ve ürünün kalitesini değerlendirmek için uygun metrikler oluşturmak

· Araç seçimi için bütçe önermek, pilot projeler için zaman ve çalışma ayırmak ve aracın/araçların kullanımında sürekli destek sağlama da dâhil olmak üzere test
sürecini destekleyecek araçların seçimini ve uygulanmasını desteklemek

· Test ortamının/ortamlarının uyarlanması hakkında karar vermek

· Kurum içinde test uzmanlarını, test ekibini ve test uzmanlığı mesleğini tanıtmak ve savunmak

· Test uzmanlarının becerilerini ve kariyerlerini geliştirmek

Test uzmanının tipik görevleri:

· Test planlarını gözden geçirmek ve planlara katkı yapmak

· Gereksinimleri, kullanıcı hikâyelerini ve kabul kriterlerini, spesifikasyonları ve test esasını analiz etmek, gözden geçirmek ve değerlendirmek

· Test koşullarını tanımlanmak ve dokümante etmek ve test senaryoları, test koşulları ve test esası arasındaki izlenebilirliği kaydetmek

· Genellikle sistem yönetimi ve ağ yönetimi ile koordinasyon içinde, test ortamı/ortamlarını tasarlamak, kurmak ve doğrulamak

· Test senaryolarını ve test prosedürlerini tasarlamak ve uyarlamak

· Test verilerini hazırlanmak ve elde etmek

· Ayrıntılı test yürütme çizelgesini oluşturmak

· Testleri koşturmak, sonuçlarını değerlendirmek ve beklenen sonuçlardan sapmaları dokümante etmek

· Test sürecini kolaylaştırmak için uygun araçları kullanmak

· Gerektiğinde testleri otomatikleştirmek

· Performans, güvenilirlik, kullanılabilirlik, güvenlik, uyumluluk ve taşınabilirlik gibi fonksiyonel olmayan testleri yapmak

· Diğerleri tarafından yapılan testleri gözden geçirmek

KONU 5.2 Test Planlama ve Tahminleme

SORU 5.2.1 Bir test planının amacını ve içeriğini özetleyin.

CEVAP:

Test planlama faaliyetleri aşağıdakileri içerebilir:

· Testlerin kapsamı, hedefleri ve risklerinin belirlenmesi

· Testlerdeki genel yaklaşımın belirlenmesi

· Test faaliyetlerinin yazılım yaşam döngüsü faaliyetlerine entegre edilmesi ve koordine edilmesi

· Neyin test edileceğine, çeşitli test faaliyetlerini gerçekleştirmek için gereken personele ve diğer kaynaklara ve test faaliyetlerinin nasıl yürütüleceğine ilişkin kararlar
verilmesi

· Test analizi, tasarım, uyarlama, koşturma ve değerlendirme faaliyetlerinin, belirli tarihlerde veya her döngü kapsamında zaman planlamasının yapılması

· Test gözetimi ve kontrolü için metriklerin seçilmesi

· Test faaliyetlerinin bütçelendirilmesi

· Test dokümantasyonunun detay seviyesinin ve yapısının belirlenmesi

SORU 5.2.2 Çeşitli test stratejilerinin birbirinden farklarını belirtin.

CEVAP:

Yaygın test stratejisi çeşitleri aşağıda verilmiştir:

· Analitik: Bazı faktörlerin analizine dayanır.

· Model Bazlı: Testler; fonksiyon, iş süreci, iç çalışma yapısı veya fonksiyonel olmayan bir özellik gibi, ürünün bazı özelliklerinin modellenmesine dayanarak
tasarlanır. Bu modellerin örnekleri arasında iş süreci modelleri, durum modelleri ve güvenilirlik büyüme modelleri bulunur.

· Metodik: Yaygın veya muhtemel arıza türlerinin sınıflandırması, önemli kalite özelliklerinin listesi veya kurum genelinde mobil uygulamalar veya web sayfaları için
görünüm ve çalışma standartları gibi bazı önceden tanımlanmış test kümelerinin veya test koşullarının sistematik olarak kullanılmasına dayanır.

· Süreç uyumluluk: Dış yönergeleri ve standartları baz alarak testlerin analiz edilmesini, tasarlanmasını ve uyarlanmasını içerir. Bu kurallar ve standartlara örnek
olarak sektörel standartlar, süreç dokümantasyonu, test esasının titiz bir şekilde tanımlanması ve kullanılması ile belirlenen veya kurumun uygulanmasını zorunlu
tuttuğu veya kurumun uygulamasının zorunlu olduğu herhangi bir süreç veya standart olabilir.

· Yönlendirmeli: Temel olarak test ekibinin dışında veya kurum dışından paydaşların, alan uzmanlarının veya teknoloji uzmanlarının tavsiyesi, rehberliği veya
talimatları ile yönlendirilir.

147
· Regresyon hassasiyetli: Yazılımın mevcut çalışan özelliklerinin bozulmasını engelleme amacıyla hayata geçirilmektedir. Mevcut test yazılımının yeniden
kullanımını, geniş regresyon testi otomasyonunu ve standart test gruplarını içerir.

· Tepkisel: Testler, önceden planlanmak yerine, test edilen birim veya sisteme ve test koşumu sırasında meydana gelen olaylara verilen tepkilerle şekillenir. Testler
tasarlanır, uyarlanır ve önceki test sonuçlarından elde edilen deneyimler baz alınarak koşturulur.

SORU 5.2.3 Potansiyel giriş ve çıkış kriterlerine örnekler verin.

CEVAP:

Tipik giriş kriterleri aşağıda verilmiştir:

· Test edilebilir gereksinimlerin, kullanıcı hikâyelerinin ve/veya modellerin var olması

· Önceki test seviyelerinin çıkış kriterlerini karşılayan test öğelerinin varlığı

· Test ortamının kullanılabilir olması

· Gerekli test araçlarının kullanılabilir olması

· Test verilerinin ve diğer gerekli kaynakların varlığı

Tipik çıkış kriterleri aşağıda verilmiştir:

· Planlanan testlerin koşturulmuş olması

· Belirlenmiş bir kapsama seviyesine ulaşılmış olması

· Çözülemeyen hataların sayısının önceden kararlaştırılmış bir limitin dahilinde olması

· Tahmini kalan hata sayısının yeterince düşük olması

· Değerlendirilen güvenilirlik seviyeleri, performans, kullanılabilirlik, güvenlik ve diğer ilgili kalite özelliklerinin yeterli olması

SORU 5.2.4 Belirli bir test senaryosu grubunun test koşumunu planlamak için önceliklendirme kriterlerini ve teknik ve mantıksal bağımlılıkları
uygulayın.

CEVAP:

Çeşitli test senaryoları ve test prosedürleri üretildikten ve test gruplarına ayrıldıktan sonra, test grupları, çalıştırılma sırasını belirleyen bir test koşum çizelgesinde
düzenlenebilir. Test koşum çizelgesi; önceliklendirme, bağımlılıklar, onaylama testleri, regresyon testleri ve testleri koşturmak için en verimli sıralama gibi faktörleri
dikkate almalıdır. İdeal olarak, test senaryoları öncelik seviyelerine göre çalışma sırasına alınır, genellikle en yüksek önceliğe sahip test senaryoları önce koşturulur.
Ancak, test senaryolarının veya test edilen özelliklerin bağımlılıkları varsa, bu yöntem çalışmayabilir.

SORU 5.2.5 Testlerle ilgili çalışmaları etkileyen faktörleri tanımlayın.

CEVAP:

Ürünün özellikleri

· Ürünle ilgili riskler

· Test esasının kalitesi

· Ürün boyutu

· Ürünün karmaşıklığı

· Kalite gereksinimleri (ör. güvenlik, güvenilirlik)

· Test dokümantasyonu için gereken ayrıntı düzeyi

· Yasal ve düzenlemeler için uyumluluk gereksinimleri

Yazılım geliştirme süreci özellikleri

· Kurumun kararlılığı ve olgunluğu

· Kullanılan yazılım geliştirme modeli

· Test yaklaşımı

· Kullanılan araçlar

· Test süreci

· Zaman baskısı

Testi yapacak kişilerin özellikleri

· Kişilerin becerileri ve özellikle benzer projeler ve ürünlere (ör. alan bilgisi) ilişkin deneyimleri

· Ekip uyumu ve liderlik test sonuçları

· Belirlenen hataların sayısı ve önem derecesi

148
· Yeniden yapılması gereken iş miktarı

SORU 5.2.6 İki tahminleme tekniği arasındaki farkı açıklayın: metrik bazlı teknik ve uzman bazlı teknik

CEVAP:

· Metrik bazlı teknik: önceki benzer projelerin metriklerine veya tipik değerlere dayanarak test eforunu tahmin etme

· Uzman bazlı teknik: testi gerçekleştirecek kişilerin tecrübesine veya uzmanlara dayanarak test eforunu tahmin etme

KONU 5.3 Test Gözetimi ve Kontrolü

SORU 5.3.1 Testlerde kullanılan metrikleri anımsayın.

CEVAP:

· Test senaryosu hazırlamada yapılan planlı işlerin yüzdesi

· Test ortamı hazırlamada yapılan planlı işlerin yüzdesi

· Test senaryosunun koşturulması

· Hata bilgileri

· Gereksinimlerin, kullanıcı hikâyelerinin, kabul kriterlerinin, risklerin veya kodun test kapsamı

· Görev tamamlama, kaynak tahsisi, kaynak kullanımı ve çalışma

· Maliyet/hata bulma faydasının karşılaştırılması veya maliyet/testi çalıştırma faydasının karşılaştırılması da dâhil olmak üzere testlerin maliyeti

SORU 5.3.2 Test raporlarının amaçlarını, içeriklerini ve hedef kitlelerini özetleyin.

CEVAP:

Test ilerleme raporları ve test özet raporları genellikle aşağıdakileri içerir:

· Gerçekleştirilen testlerin özeti

· Bir test dönemi sırasında neler olduğuna dair bilgiler

· Test faaliyetlerinin zaman çizelgesindeki, süresindeki veya çalışma miktarındaki sapmalar da dâhil olmak üzere plandan sapmalar

· Çıkış kriterleri veya Tamamlandı tanımına göre testlerin ve ürün kalitesinin durumu

· İlerlemeyi engellemiş veya engellemeye devam eden faktörler

· Hata metrikleri, test senaryoları, test kapsamı, faaliyet ilerlemesi ve kaynak tüketimi

· Kalan riskler

· Üretilen yeniden kullanılabilir test çalışma ürünleri

KONU 5.4 Yapılandırma Yönetimi

SORU 5.4.1 Yapılandırma yönetiminin testleri nasıl desteklediğini özetleyin.

CEVAP:

Testleri uygun şekilde desteklemek için yapılandırma yönetimi aşağıdakilerin gerçekleştirilmesini içerebilir:

· Tüm test öğeleri özgün bir şekilde tanımlanmış, versiyon kontrolü yapılmış, değişiklikleri izlenmiş ve birbirleriyle ilişkilendirilmiştir.

· Test için yazılan tüm yazılımlar benzersiz bir şekilde tanımlanmış, versiyon kontrolü yapılmış, birbirleriyle ve test öğesinin/öğelerinin versiyonlarıyla ilgili değişiklikler
için izlenmiş, böylece test süreci boyunca izlenebilirlikleri korunmuştur.

· Tanımlanan tüm dokümanlar ve yazılım öğeleri, test dokümantasyonunda açık bir şekilde belirtilmiştir.

KONU 5.5 Riskler ve Testler

SORU 5.5.1 Olasılık ve etkiyi kullanarak risk seviyesini tanımlayın.

CEVAP:

Risk, gelecekte olumsuz sonuçlara yol açacak bir olayın gerçekleşme olasılığını içerir. Risk seviyesi, olayın olasılığı ve etkisi (zararı) ile belirlenir.

SORU 5.5.2 Proje ve ürün risklerinin farklarını belirtin.

CEVAP:

Ürün risklerine örnekler aşağıda verilmiştir:

· Yazılım, gereksinime göre amaçlanan fonksiyonları yerine getiremeyebilir.

· Yazılım; kullanıcı, müşteri ve/veya paydaş ihtiyacına göre amaçlanan fonksiyonları yerine getiremeyebilir.

· Sistem mimarisi, fonksiyonel olmayan bazı gereksinimleri uygun şekilde desteklemeyebilir

149
· Bazı durumlarda belirli bir hesaplama yanlış yapılabilir.

· Bir döngü kontrol yapısı yanlış kodlanmış olabilir.

· Yüksek performanslı olması beklenen bir işlemin yanıt süreleri yetersiz olabilir.

· Kullanıcı deneyimiyle ilgili geri bildirimler, ürün beklentilerini karşılamayabilir.

Proje riski, gerçekleşmesi durumunda, projenin hedeflerine ulaşma imkânı üzerinde olumsuz etkiye sahip olabilecek durumları içerir. Proje risklerine örnekler aşağıda
verilmiştir:

· Proje sorunları

· Kurumsal sorunlar

· Politik sorunlar

· Teknik sorunlar

· Tedarikçi sorunları

SORU 5.5.3 Ürün risk analizinin testlerin bütünlüğünü ve kapsamını nasıl etkileyebileceğini örnekler vererek açıklayın.

CEVAP:

Risk bazlı bir yaklaşımda ürün risk analizinin sonuçları aşağıdaki amaçlar için kullanılır:

· Kullanılacak test tekniklerinin belirlenmesi

· Koşulacak testlerin seviyelerinin ve çeşitlerinin belirlenmesi

· Koşulacak testlerin kapsamının belirlenmesi

· Kritik hataların mümkün olduğunca erken belirlenmesi için testlerin önceliklendirilmesi

· Riski azaltmak için testlere ek olarak yapılabilecek potansiyel aktivitelerin belirlenmesi

14.6. Yazılım Test Araç Desteği

KONU 6.1 Test araçlarındaki önemli hususlar

SORU 6.1.1 Test araçlarını amaçlarına ve destekledikleri test faaliyetlerine göre sınıflandırın.

CEVAP:

Testlerin ve test yazılımının yönetimini destekleyen araçlara örnekler aşağıda verilmiştir:

· Test yönetim araçları ve uygulama yaşam döngüsü yönetimi araçları

· Gereksinim yönetim araçları

· Hata yönetim araçları

Test tasarım araçlarına örnekler aşağıda verilmiştir:

· Test tasarım araçları

· Model Bazlı test araçları

· Test verisi hazırlama araçları

· Test güdümlü yazılım geliştirme araçları

Test koşumu ve kaydetme faaliyetlerini desteklemek için kullanılan araçlara örnekler verilmiştir:

· Test koşum araçları

· Kapsam araçları

· Birim testi çerçeve araçları

Performans ölçümü ve dinamik analiz araçlarına örnekler aşağıda verilmiştir:

· Performans testi araçları

· İzleme araçları

· Dinamik analiz araçları

SORU 6.1.2 Test otomasyonunun yararlarını ve risklerini tanımlayın.

CEVAP:

Kitap içerisinde bu konuya değinildiğinden burada tekrar yer verilmemiştir.

SORU 6.1.3 Test koşumu ve test yönetim araçlarına dair önemli hususları hatırlayın.
150
CEVAP:

Test aracının düzgün ve başarılı şekilde hayata geçirilmesi için, bir kurumda test koşumu ve test yönetimi araçlarını seçerken ve entegre ederken göz önünde
bulundurulması gereken bazı hususlar vardır. Test koşumu araçları, otomatikleştirilmiş test betikleri kullanarak test nesnelerini koşturur. Bu tür bir araç, genellikle
belirgin bir fayda elde etmek için önemli ölçüde çalışma gerektirir.

KONU 6.2 Araçların etkin kullanımı

SORU 6.2.1 Araç seçimi için temel prensipleri belirtin.

CEVAP:

Kurum için araç seçiminde dikkate alınması gereken ana hususlar şunlardır:

· Kurumun olgunluğunun, güçlü ve zayıf yönlerinin değerlendirilmesi

· Araçlar tarafından desteklenen gelişmiş bir test süreci için fırsatların belirlenmesi

· Araç uyumluluğu ve entegrasyonunu sağlamak için hâlihazırda organizasyon içinde kullanımda olan derleme ve sürekli entegrasyon araçları

· Aracın ücretsiz bir deneme süresi boyunca kullanılabilir olup olmadığı konusu

· Tedarikçi değerlendirmesi veya ticarî olmayan araçlar için destek

· Aracın kullanımında koçluk, mentörlük ve destek için dâhili gereksinimlerin belirlenmesi

· Doğrudan araçla/araçlarla çalışacak kişilerin test becerilerini dikkate alarak eğitim ihtiyaçlarının değerlendirilmesi

· Somut bir iş senaryosuna dayanan bir fayda/maliyet oranının tahmini

SORU 6.2.2 Araçları daha iyi anlamak için pilot proje kullanımının hedeflerini sayın.

CEVAP:

Araç seçimi ve başarılı bir kavram kanıtlama tamamlandıktan sonra, seçilen aracın kurumda kullanıma başlanması genellikle pilot bir projeyle başlar, bu proje ile
aşağıdakiler hedeflenir:

· Araç hakkında derinlemesine bilgi edinmek, güçlü ve zayıf yönlerini anlamak.

· Aracın mevcut süreç ve uygulamalara nasıl uyacağını değerlendirmek ve gereken değişiklikleri belirlemek.

· Aracı ve test varlıklarını kullanmanın, yönetmenin, saklamanın ve bakımını yapmanın yol ve yöntemlerine karar vermek.

· Aracın sağladığı faydaların kabul edilebilir bir maliyet ile sağlanıp sağlanamayacağını değerlendirmek.

· Aracın toplamasını ve raporlamasını istediğiniz metrikleri anlamak ve bu metriklerin kaydedilip raporlanabilmesini sağlamak için aracı yapılandırmak.

SORU 6.2.3 Bir kurumdaki test araçlarının değerlendirilmesi, uyarlanması, dağıtımı ve desteğinin devam etmesi için başarı faktörlerini tanımlayın.

CEVAP:

· Aracın kullanımı için süreçleri uyarlamak ve geliştirmek

· Araç kullanıcıları için eğitim, koçluk ve mentorluk sağlamak

· Aracın kullanımı süresince elde edilen bilgileri toplamak için bir yöntem belirlemek

· Araç kullanımını ve faydalarını izlemek

· Belirli bir aracın kullanıcılarına destek sağlamak

· Kullanıcılardan geribildirimleri toplamak

Bölüm Özeti
Bu bölümde ISTQB’nin Temel Seviye (Başlangıç Seviyesi) Sınavı ve olabilecek alternatif cevaplar verilmiştir. Bu sınavda sorulan sorular şu şekildedir:

· Yazılım testinin genel hedeflerini tanımlayın.

· Test ile hata ayıklamanın farklarını belirtin.

· Örnekler vererek yazılım testinin neden gerekli olduğunu açıklayın.

· Yazılım testi ve kalite güvence arasındaki ilişkiyi tanımlayın ve testlerin kaliteyi nasıl artırdığına dair örnekler verin.

· İnsan hatası, hata ve arıza arasındaki farkı ayırt edin.

· Bir hatanın kök nedeni ile etkileri arasındaki farkı ayırt edin.

· Yedi test prensibini açıklayın.

· Proje bağlamının test süreci üzerindeki etkisini açıklayın.

· Test sürecindeki test faaliyetlerini ve ilgili görevleri tanımlayın.

151
· Test sürecini destekleyen çalışma ürünlerini tanımlayın.

· Test esası ve test çalışma ürünleri arasında izlenebilirliğin sağlanmasının önemini açıklayın.

· Yazılım testinin başarısını etkileyen psikolojik faktörleri tanımlayın.

· Test faaliyetleri için gereken bakış açısı ile yazılım geliştirme faaliyetleri için gereken bakış açısı arasındaki farkı açıklayın.

· Yazılım geliştirme yaşam döngüsü içindeki yazılım geliştirme aktiviteleri ile test aktiviteleri arasındaki ilişkileri açıklayın.

· Yazılım geliştirme yaşam döngüsü modellerinin neden proje ve ürün özellikleri bağlamına uyarlanması gerektiğini açıklayın.

· Farklı test seviyelerini hedefler, test esası, test nesneleri, genel hatalar ve arızalar ile yaklaşımlar ve sorumluluklar açısından karşılaştırın.

· Fonksiyonel ve fonksiyonel olmayan testleri karşılaştırın.

· Bakım testleri için tetikleyicileri özetleyin.

· Bakım testlerinde etki analizinin rolünü açıklayın.

· Farklı statik test teknikleri ile incelenebilecek çalışma ürünü çeşitlerini ayırt edin.

· Statik testlerin önemini tanımlamak için örnekler verin.

· Hedeflerini, belirlenecek hata çeşitlerini ve bu tekniklerin yazılım yaşam döngüsü içindeki rolünü göz önünde bulundurarak statik ve dinamik teknikler arasındaki
farkları açıklayın.

· Kara kutu test teknikleri, beyaz kutu test teknikleri ve tecrübeye dayalı test tekniklerinin özelliklerini, ortak yanlarını ve aralarındaki farkları açıklayın.

· Test senaryolarını verilen gereksinimlerden üretmek için denklik paylarına ayırın.

· Test senaryolarını verilen gereksinimlerden üretmek için sınır değer analizi uygulayın.

· Test senaryolarını verilen gereksinimlerden üretmek için karar tablosu testi uygulayın.

· Test senaryolarını verilen gereksinimlerden üretmek için durum geçişi testi uygulayın.

· Test senaryosunun kullanım senaryosundan nasıl elde edileceğini açıklayın.

· Komut kapsamını açıklayın.

· Karar kapsamını açıklayın.

· Komut ve karar kapsamının önemini açıklayın.

· Hata tahminlemeyi açıklayın.

· Keşif testlerini açıklayın.

· Kontrol listesine dayalı testi açıklayın.

· Bağımsız testlerin yararlarını ve sakıncalarını açıklayın.

· Test yöneticisi ve test uzmanının görevlerini tanımlayın.

· Bir test planının amacını ve içeriğini özetleyin.

· Çeşitli test stratejilerinin birbirinden farklarını belirtin.

· Potansiyel giriş ve çıkış kriterlerine örnekler verin.

· Belirli bir test senaryosu grubunun test koşumunu planlamak için önceliklendirme kriterlerini ve teknik ve mantıksal bağımlılıkları uygulayın.

· Testlerle ilgili çalışmaları etkileyen faktörleri tanımlayın.

· İki tahminleme tekniği arasındaki farkı açıklayın: metrik bazlı teknik ve uzman bazlı teknik

· Testlerde kullanılan metrikleri anımsayın.

· Test raporlarının amaçlarını, içeriklerini ve hedef kitlelerini özetleyin.

· Yapılandırma yönetiminin testleri nasıl desteklediğini özetleyin.

· Olasılık ve etkiyi kullanarak risk seviyesini tanımlayın.

· Proje ve ürün risklerinin farklarını belirtin.

· Ürün risk analizinin testlerin bütünlüğünü ve kapsamını nasıl etkileyebileceğini örnekler vererek açıklayın.

· Test araçlarını amaçlarına ve destekledikleri test faaliyetlerine göre sınıflandırın.

· Test otomasyonunun yararlarını ve risklerini tanımlayın.

· Test koşumu ve test yönetim araçlarına dair önemli hususları hatırlayın.

· Araç seçimi için temel prensipleri belirtin.

152
· Araçları daha iyi anlamak için pilot proje kullanımının hedeflerini sayın.

· Bir kurumdaki test araçlarının değerlendirilmesi, uyarlanması, dağıtımı ve desteğinin devam etmesi için başarı faktörlerini tanımlayın.

Kaynakça

ISTQB, https://www.istqb.org/, 2021

TTB, https://www.turkishtestingboard.org/, 2021 

Ünite Soruları

Soru-1 :

Aşağıdaki sorulardan hangisi Yazılım Test Temelleri başlığı altında ele alınamaz?

(•) - Yazılım testinin genel hedeflerini tanımlayın

(•) - Test ile hata ayıklamanın farklarını belirtin

(•) - Yazılım testinin neden gerekli olduğunu açıklayın

(•) - Yazılım testi ve kalite güvence arasındaki ilişkiyi tanımlayın

(•) - Yazılım geliştirme yaşam döngüsü modellerinin neden proje ve ürün özellikleri bağlamına uyarlanması gerektiğini açıklayın

Cevap-1 :

Yazılım geliştirme yaşam döngüsü modellerinin neden proje ve ürün özellikleri bağlamına uyarlanması gerektiğini açıklayın

Soru-2 :

Aşağıdaki sorulardan hangisi Yazılım Geliştirme Yaşam Döngüsü Boyunca Test başlığı altında ele alınamaz?

(•) - Yazılım geliştirme yaşam döngüsü içindeki yazılım geliştirme aktiviteleri ile test aktiviteleri arasındaki ilişkileri açıklayın

(•) - Farklı test seviyelerini hedefler, test esası, test nesneleri, genel hatalar ve arızalar ile yaklaşımlar ve sorumluluklar açısından karşılaştırın

(•) - Test faaliyetleri için gereken bakış açısı ile yazılım geliştirme faaliyetleri için gereken bakış açısı arasındaki farkı açıklayın

(•) - Fonksiyonel, fonksiyonel olmayan ve beyaz kutu testlerini karşılaştırın

(•) - Bakım testleri için tetikleyicileri özetleyin

Cevap-2 :

Test faaliyetleri için gereken bakış açısı ile yazılım geliştirme faaliyetleri için gereken bakış açısı arasındaki farkı açıklayın

Soru-3 :

Aşağıdaki sorulardan hangisi Test Tasarım Teknikleri başlığı altında ele alınamaz?

(•) - Kara kutu test teknikleri, beyaz kutu test teknikleri ve tecrübeye dayalı test tekniklerinin özelliklerini, ortak yanlarını ve aralarındaki farkları açıklayın

(•) - Test senaryolarını verilen gereksinimlerden üretmek için denklik paylarına ayırın

(•) - Farklı statik test teknikleri ile incelenebilecek çalışma ürünü çeşitlerini ayırt edin

(•) - Test senaryosunun kullanım senaryosundan nasıl elde edileceğini açıklayın

(•) - Komut kapsamını açıklayın

Cevap-3 :

Farklı statik test teknikleri ile incelenebilecek çalışma ürünü çeşitlerini ayırt edin

Soru-4 :

Aşağıdaki sorulardan hangisi Yazılım Test Araç Desteği başlığı altında ele alınamaz?

(•) - Statik testlerin önemini tanımlamak için örnekler verin

(•) - Araç seçimi için temel prensipleri belirtin

153
(•) - Araçları daha iyi anlamak için pilot proje kullanımının hedeflerini sayın

(•) - Bir kurumdaki test araçlarının değerlendirilmesi, uyarlanması, dağıtımı ve desteğinin devam etmesi için başarı faktörlerini tanımlayın

(•) - Test koşumu ve test yönetim araçlarına dair önemli hususları hatırlayın

Cevap-4 :

Statik testlerin önemini tanımlamak için örnekler verin

Soru-5 :

Aşağıdaki sorulardan hangisi Test Yönetimi başlığı altında ele alınamaz?

(•) - Çeşitli test stratejilerinin birbirinden farklarını belirtin

(•) - Statik ve dinamik teknikler arasındaki farkları açıklayın

(•) - Potansiyel giriş ve çıkış kriterlerine örnekler verin

(•) - Belirli bir test senaryosu grubunun test koşumunu planlamak için önceliklendirme kriterlerini ve teknik ve mantıksal bağımlılıkları uygulayın

(•) - Testlerle ilgili çalışmaları etkileyen faktörleri tanımlayın

Cevap-5 :

Statik ve dinamik teknikler arasındaki farkları açıklayın

Soru-6 :

Aşağıdaki sorulardan hangisi Test Yönetimi başlığı altında ele alınamaz?

(•) - İki tahminleme tekniği arasındaki farkı açıklayın: metrik bazlı teknik ve uzman bazlı teknik

(•) - Bir test planının amacını ve içeriğini özetleyin

(•) - Test yöneticisi ve test uzmanının görevlerini tanımlayın

(•) - Test araçlarını amaçlarına ve destekledikleri test faaliyetlerine göre sınıflandırın

(•) - Bağımsız testlerin yararlarını ve sakıncalarını açıklayın

Cevap-6 :

Test araçlarını amaçlarına ve destekledikleri test faaliyetlerine göre sınıflandırın

Soru-7 :

Aşağıdakilerden hangisi ISTQB Temel Seviye Sınavı’nda yer alan bir konu değildir?

(•) - Yazılım Testi nedir?

(•) - Test araçlarındaki önemli hususlar

(•) - Yedi Test Prensibi

(•) - Test Uzmanları

(•) - Test Süreci

Cevap-7 :

Test Uzmanları

Soru-8 :

Aşağıdakilerden hangisi ISTQB Temel Seviye Sınavı’nda yer alan bir konu değildir?

(•) - Test İsimleri

(•) - Test Etme Psikolojisi

(•) - Yazılım Geliştirme Yaşam Döngüsü Modelleri

(•) - Test Seviyeleri

154
(•) - Test Çeşitleri

Cevap-8 :

Test İsimleri

Soru-9 :

Aşağıdakilerden hangisi ISTQB Temel Seviye Sınavı’nda yer alan bir konu değildir?

(•) - Test Tekniklerinin Kategorileri

(•) - Test Analizi

(•) - Test Organizasyonu

(•) - Test Planlama ve Tahminleme

(•) - Test Gözetimi ve Kontrolü

Cevap-9 :

Test Analizi

155