Yazılım Test Süreçleri

Yazılım Testine Giriş

Dr. Öğr. Üyesi Oğuz Emre Kural

2025

Giriş

Classroom

Sınıf Kodu: jqy6dzns
classroom.google.com → Sınıfa katıl → kodu girin (bil.omu.edu.tr ile).

Değerlendirme

Vize (40%)
Final (60%)
- Ders içi anlatım (40%)
- Dönem sonu sınavı (60%)

Öğrenme Kazanımları

Bu dersin sonunda;

Yazılım yaşam döngüsü (SDLC) ve yazılım testinin SDLC içindeki yerini tanımlayabilecek.
Yazılım testinin temel amaçlarını (kaliteyi doğrulama, hatayı erken yakalama, risk azaltma) açıklayabilecek.
Yazılım süreci/süreç modeli kavramlarını test perspektifiyle ilişkilendirerek yorumlayabileceksiniz.

Yazılım Testi Nedir?

Yazılım Testi

Yazılım testi, bir yazılım ürününün veya sisteminin belirlenen gereksinimleri karşılayıp karşılamadığını, beklenen davranışları sergileyip sergilemediğini ve kullanıcı ihtiyaçlarını ne ölçüde karşıladığını değerlendirmek amacıyla yürütülen sistematik bir süreçtir.
Bu süreç, yazılımda bulunabilecek hataları, kusurları veya eksiklikleri tespit etmeyi ve bu sorunların giderilmesini sağlamayı amaçlar.
Yazılım testi, yazılım geliştirme yaşam döngüsünün (SDLC) kritik bir parçasıdır ve hem manuel hem de otomatik yöntemlerle gerçekleştirilebilir.

Tanımdan da anlaşılacağı gibi, yazılım testi, yazılımın fonksiyonelliğini, performansını, güvenilirliğini, güvenliğini ve kullanılabilirliğini değerlendirmeyi içeren kapsamlı bir süreçtir.
Statik test yöntemleri, kodu çalıştırmadan incelemeyi içerirken (örneğin, kod incelemeleri, statik analiz), dinamik test yöntemleri, kodu çeşitli girdilerle çalıştırmayı ve çıktılarını beklenen sonuçlarla karşılaştırmayı içerir.

Testin önemi

Günümüzün rekabetçi pazarında, yazılım kalitesi, bir ürünün veya hizmetin başarısı için belirleyici bir faktördür.
Hatalı veya kalitesiz bir yazılım, müşteri memnuniyetsizliğine, maddi kayıplara, itibar zedelenmesine ve hatta bazı durumlarda hayati risklere yol açabilir.
Yazılım testi, bu olumsuz sonuçları en aza indirgemek ve kaliteli bir ürün sunmak için olmazsa olmazdır.

Yazılım testinin önemi şu noktalarda özetlenebilir:

Hataların Erken Tespiti: Yazılım geliştirme sürecinin erken aşamalarında hataların tespit edilmesi, bu hataların düzeltilmesini daha az maliyetli ve daha az zaman alıcı hale getirir.
Yazılım Kalitesinin Artırılması: Test süreci, yazılımın işlevsel, performans, güvenlik ve kullanılabilirlik açısından kalitesini artırır.
Kullanıcı Memnuniyeti: Test edilmiş ve hatasız bir yazılım, kullanıcıların beklentilerini karşılar ve güvenilirlik sağlar.

Maliyet Tasarrufu: Hataların ürün piyasaya sürüldükten sonra tespit edilmesi, hem finansal hem de itibar kaybına neden olabilir. Test süreci, bu tür riskleri minimize eder.
Güvenlik ve Güvenilirlik: Özellikle finans, sağlık ve savunma gibi kritik sektörlerde, yazılımın güvenli ve güvenilir olması hayati önem taşır. Test süreci, bu gereksinimleri karşılamaya yardımcı olur.
Yasal ve Regülasyon Uyumu: Bazı sektörlerde yazılımların belirli standartlara ve yasal gerekliliklere uygun olması zorunludur. Test süreci, bu uyumun sağlanmasında önemli bir rol oynar.

Yazılım testi yapılmayan sistemlerde muhtemel sorunlar

Fonksiyonel Hatalar: Kullanıcıya yanlış bilgi gösterme, hesaplamaların yanlış yapılması.

Performans Sorunları: Yoğun kullanıcı trafiği altında çökme veya yavaşlama.

Güvenlik Açıkları: Kredi kartı bilgileri gibi hassas verilerin sızdırılması.

Kullanıcı Deneyimi Problemleri: Karmaşık veya kullanılamayan arayüzler.

Gerçek dünya örnekleri

NASA Mars Climate Orbiter (1999) → Metrik ve imperial sistem dönüşüm hatası nedeniyle $125 milyon değerindeki uzay aracı kaybedildi. 170 km fazladan yaklaştığı için yer çekimine kapıldı.
Facebook Veri Sızıntısı (2019) → Güvenlik testi eksikliği nedeniyle 500 milyon kullanıcının (tüm kullanıcıların yaklaşık 20%’si) kişisel bilgileri sızdırıldı.
Knight Capital Group (2012) → Hatalı bir yazılım güncellemesi sonucu 45 dakika içinde $440 milyon zarar edildi.

Bug (Yazılım Hatası) Nedir?

Bug, yazılım hatası olarak da bilinir ve bir yazılım programındaki, yanlış veya istenmeyen sonuçlar üretebilen ya da programın doğru çalışmasını engelleyen bir hatadır.
Yazılım testinde, bug yalnızca bir hata anlamına gelmez; aynı zamanda yazılımın kalitesini etkileyen herhangi bir sorunu ifade eder.
Yazılım hataları farklı isimlerle de anılabilir, bunlar arasında: kusur (defect), arıza (fault), problem, hata (error), olay (incident), anormallik (anomaly), başarısızlık (failure), farklılık (variance) ve tutarsızlık (inconsistency) gibi terimler yer alır.

Bug türleri

Bug’lar çeşitli kategorilere ayrılabilir. Yazılım testinde karşılaşılan en yaygın bug türleri:

Bug Türü	Bug Türü
Fonksiyonel Bug’lar	Performans Bug’ları
Mantıksal Bug’lar	Uyumluluk Bug’ları
İş Akışı Bug’ları	Kullanılabilirlik Bug’ları
Birim Seviyesi Bug’ları	Sistem Seviyesi Entegrasyon Bug’ları
Eşzamanlılık Bug’ları (Concurrency Bugs)	Sınırların Dışında Bug’lar (Out of Bound Bugs)
Güvenlik Bug’ları

`Fonksiyonel` buglar

Bir yazılım bileşeninin veya özelliğinin beklendiği gibi çalışmaması durumunda ortaya çıkar.
Örneğin,
- Bir giriş düğmesinin tıklandığında hiçbir işlem yapmaması veya bir hesaplama işlevinin yanlış sonuç vermesi fonksiyonel bir bug olarak kabul edilir.

`Mantıksal` buglar

Yazılımın akışında veya mantığında bir hatadan kaynaklanır.
Yanlış değişken atamaları, hatalı koşul ifadeleri veya yanlış hesaplamalar gibi kodlama hataları, mantıksal bug’lara örnek olarak verilebilir.
Örneğin,
- Bir hesap makinesi uygulamasında, iki sayının toplanması yerine çarpılması. Kullanıcı 5 + 3 işlemini yapmak istediğinde, uygulama 15 sonucunu döndürür.

def topla(num1, num2):
    return num1 * num2

`İş akışı` bugları

Yazılımın kullanıcı arayüzündeki adımlar veya işlemler arasındaki akışta bir hatadan kaynaklanır.
Örneğin,
- Bir online kayıt formunda, tüm alanlar doldurulduktan ve “Gönder” düğmesine tıklandıktan sonra, kullanıcının ana sayfaya yönlendirilmesi gerekirken, tekrar boş bir form sayfasına yönlendirilmesi.

`Birim seviyesi` buglar

Yazılımın en küçük birimlerinde (fonksiyon, metot, sınıf vb.) bulunan bug’lardır. Bu bug’lar genellikle birim testleri sırasında bulunur ve nispeten kolayca düzeltilebilir.

`Eşzamanlılık` bugları (Concurrency Bugs)

Çoklu iş parçacığı (multi-threading) veya paralel işlem yapan yazılımlarda ortaya çıkan bug’lardır.
Bu bug’lar, paylaşılan kaynaklara erişim sırasında yaşanan çakışmalardan kaynaklanabilir ve veri kaybına veya sistem çökmelerine yol açabilir.

`Güvenlik` bugları

Yazılımın güvenlik açıklarına yol açan bug’lardır.
SQL enjeksiyonu, cross-site scripting (XSS) veya yetkisiz erişim gibi güvenlik açıkları, kullanıcı verilerinin çalınmasına, sistemin ele geçirilmesine veya diğer güvenlik ihlallerine neden olabilir.

`Performans` bugları

Yazılımın performans gereksinimlerini karşılayamaması sonucu ortaya çıkan bug’lardır.
Yavaş yükleme süreleri, uzun yanıt süreleri veya yüksek kaynak kullanımı gibi performans sorunları, kullanıcı deneyimini olumsuz etkileyebilir.

`Uyumluluk` bugları

Yazılımın farklı ortamlarda, cihazlarda veya platformlarda doğru şekilde çalışmamasından kaynaklanan bug’lardır.
Örneğin, bir web sitesinin farklı tarayıcılarda farklı görüntülenmesi veya bir mobil uygulamanın farklı işletim sistemi sürümlerinde çökmesi bir uyumluluk bug’ıdır.

`Kullanılabilirlik` bugları

Yazılımın kullanıcı dostu olmamasıyla ilgili bug’lardır.
Karmaşık veya anlaşılmaz bir kullanıcı arayüzü, kullanıcı hatalarına yol açabilir ve ürünün kullanımını zorlaştırabilir.

Örnekler:
- Karmaşık navigasyon: Kullanıcının aradığı bilgiye veya özelliğe ulaşmasının zor olması.
- Anlaşılması zor hata mesajları: Kullanıcının hatayı anlamasını ve düzeltmesini zorlaştıran mesajlar.
- Yetersiz geri bildirim: Kullanıcının işlemlerin sonucu hakkında yeterli bilgi alamaması.
- Erişilebilirlik sorunları: Engelli kullanıcıların yazılımı kullanamaması. (örneğin, ekran okuyucu uyumsuzluğu)

Sistem seviyesi entegrasyon bugları

Farklı yazılım birimleri veya modülleri entegre edildiğinde ortaya çıkan bug’lardır.
Bu bug’lar, farklı geliştiriciler tarafından yazılan kodların birbiriyle uyumsuzluğundan veya arayüz hatalarından kaynaklanabilir.

Örnekler:
- Bir e-ticaret sitesinde, ödeme sisteminin sipariş yönetim sistemiyle entegre olamaması ve ödemelerin işlenememesi.
- Bir bankacılık sisteminde, hesap bilgileri modülünün kredi kartı modülü ile doğru şekilde haberleşememesi ve yanlış bakiye bilgilerinin görüntülenmesi.
- Birbirine API ile bağlı olan 2 uygulamanın, API versiyon değişikliği sebebiyle haberleşememesi.

Sınır dışı buglar (Out of Bound Bugs / Input Validation Bug)

Kullanıcının beklenmeyen veya geçersiz girdiler sağlaması sonucu ortaya çıkan bug’lardır.
Örnekler:
- Bir sayısal alana metin girilmesi.
- Bir tarih alanına geçersiz bir tarih formatı girilmesi (örneğin, 30 Şubat).
- Bir metin alanına izin verilen maksimum karakter sayısından daha fazla karakter girilmesi.

Bug’ların Maliyeti

Yazılım projelerinde hataların (bug’ların) maliyeti, tespit edildikleri aşamaya bağlı olarak önemli ölçüde değişir.
Hatalar ne kadar geç keşfedilirse, hem maddi hem de manevi maliyetleri o kadar artar.
Erken aşamada tespit edilen bir hatanın düzeltilmesi kolay ve ucuzdur, ancak aynı hata üretim ortamına çıktıktan sonra keşfedilirse, düzeltme maliyeti katlanarak artabilir ve müşteri memnuniyetini, marka itibarını ve hatta insan hayatını bile olumsuz etkileyebilir.

Örnek Senaryo

Diyelim ki bir banka uygulaması geliştiriyoruz.
Eğer kullanıcıların para transferi yapmasını engelleyen bir hata, gereksinim aşamasında tespit edilirse, sadece gereksinim belgesi güncellenerek sorun çözülebilir.
Ancak aynı hata, uygulama yayınlandıktan sonra tespit edilirse, binlerce kullanıcının işlem yapamamasına, banka için büyük maddi kayıplara ve itibar kaybına yol açabilir.

Gerçek Dünya Örneği: Patriot Füze Savunma Sistemi Hatası (1991)

Olay:

ABD Savunma Kuvvetleri’ne ait Patriot füze savunma sistemi, 1990-1991 Körfez Savaşı sırasında Irak Scud füzelerine karşı bir karşı saldırı olarak ilk kez kullanıldı. Patriot, oldukça başarılı bir anti-füze sistemi olarak kabul edilmesine rağmen, düşman füze saldırılarına karşı birkaç kez başarısız oldu.

Sonuç:

En bilinen olaylardan biri, Suudi Arabistan’ın Dhahran kentinde 28 ABD askerinin hayatını kaybetmesine neden olan saldırıdır. Bu olay, Patriot sisteminin düşman füze saldırısını engelleyememesi nedeniyle gerçekleşmiştir.

Hata Sebebi:

Daha sonra yapılan incelemelerde, bu başarısızlığın bir yazılım hatasından kaynaklandığı tespit edilmiştir.
- Anti-füze sisteminin saatinde bulunan basit bir zamanlama hatası, sistemin 14 saatten sonra füzeleri doğru şekilde takip edememesine neden oldu.
- Dhahran’daki Patriot füze sistemi 100 saatten fazla süredir çalışır durumdaydı, bu da sistemin hassasiyetinin zamanla ciddi şekilde bozulmasına yol açtı.

Zaman, sistemin iç saatinden alınarak hesaplanıyordu.
Zaman, saniyenin onda biri cinsinden tutuluyordu ve bu değeri saniyeye çevirmek için 1/10 ile çarpılıyordu.
Ancak, bu işlem 24 bitlik bir sabit nokta (fixed-point) register kullanılarak yapıldığı için hassasiyet kaybı yaşandı.
Zaman değeri yaklaşık 100 saat boyunca birikerek 0.34 saniyelik bir hata oluşturdu.
Scud füzesi saatte 1,676 m/s hızla hareket ettiğinden, bu hata nedeniyle füze yaklaşık 570 metre (0.34 saniye * 1676 m/s) yanlış konumlandırıldı.

Patriot Missile Calc. Bug

Yazılım Geliştirme Yaşam Döngüsü ve Testin Yeri

Yazılım projelerinin başarısı, düzenli bir süreç yönetimi ve hataların erken tespit edilmesiyle doğrudan ilişkilidir.
Bu nedenle, Yazılım Geliştirme Yaşam Döngüsü (Software Development Life Cycle - SDLC), yazılımın planlanmasından bakım aşamasına kadar olan sürecini tanımlayan sistematik bir yaklaşımdır.

Yazılım geliştirme yaşam döngüsü nedir?

SDLC, yazılım geliştirme sürecini belirli aşamalara bölen ve her aşamada belirli görevlerin, girdilerin ve çıktılarının tanımlandığı bir metodolojidir.
Bu süreç, yazılımın en iyi şekilde tasarlanmasını, geliştirilmesini, test edilmesini ve bakımının yapılmasını sağlar.

SDLC’nin Amaçları:

Yazılım geliştirme sürecini daha düzenli ve yönetilebilir hale getirmek.
Hata tespitini erken aşamalara çekerek maliyetleri düşürmek.
Son kullanıcıya daha güvenli ve kaliteli bir ürün sunmak.
Yazılımın sürdürülebilir ve genişletilebilir olmasını sağlamak.

SDLC’nin aşamaları

SDLC Modelleri

Farklı SDLC modelleri vardır ve her birinin kendine özgü avantajları ve dezavantajları bulunur.
En yaygın kullanılan SDLC modellerinden bazıları şunlardır:
- Şelale Modeli (Waterfall Model)
- Çevik Model (Agile Model)
- Spiral Model (Spiral Model)
- V-Modeli (V-Model)
- RAD Model
- Prototipleme

Şelale Modeli

En eski yazılım yaşam döngüsü modellerinden biridir.
Süreç, sistem seviyesinde başlar ve ardından analiz, tasarım, kodlama, test ve bakım gibi çeşitli aşamalarla devam eder.

Gereksinim Analizi

Bu aşamada, yazılımın geliştirilmesi için gerekli olan sistem gereksinimleri tanımlanır.
Bu gereksinimler, yazılım ve donanım bileşenlerini kapsayarak yazılım geliştirme süreci için kritik öneme sahiptir.

Analiz (Analysis)

Bu aşamada, geliştirme hedeflerini belirlemek için fizibilite çalışmaları yapılır.
Ayrıca, yazılımın performans ve arayüz gereksinimleri detaylı bir şekilde listelenir.

Tasarım (Design)

Bu aşamada, analiz sürecinde belirlenen gereksinimler, yazılımın yapısal tasarımı açısından tanımlanır. Örneğin, veritabanı tasarımı tamamlanır.

Tasarım aşamasının temel amaçları:

Yazılımın mantıksal akışını belirlemek.
Yazılımın kalitesini değerlendirmek için bir temel oluşturmak.
Geliştiricilere kodlama sürecinde rehberlik edecek teknik spesifikasyonları sağlamak.

Kodlama (Coding)

Bu, tasarımın makine tarafından okunabilir bir forma dönüştürüldüğü programlama aşamasıdır.

Kodlama aşamasında:

Geliştirici, tasarım spesifikasyonlarına uygun olarak yazılımın kaynak kodunu yazar.
Seçilen yazılım dili kullanılarak algoritmalar ve veri yapıları uygulanır.
Kodun okunabilir, sürdürülebilir ve optimize edilmiş olması sağlanır.

Test (Testing)

Bu aşamada, yazılım belirlenen test yöntemlerine göre test edilir.

Test aşamasında:

Olası bug’lar tespit edilir ve gerekli düzeltmeler yapılır.
Yazılımın gereksinimlere uygun çalışıp çalışmadığı doğrulanır.
Fonksiyonel ve fonksiyonel olmayan testler uygulanarak yazılımın güvenilirliği artırılır.

Bakım (Maintenance)

Bakım aşamasında, yazılımın güncellenmesi, hataların giderilmesi ve yeni gereksinimlere uyarlanması sağlanır.

Bakım aşamasında yapılan işlemler:

Yeni gereksinimlere göre yazılım güncellenir.
Canlı sistemde (production) ortaya çıkan hatalar düzeltilir.
Performans iyileştirmeleri ve güvenlik güncellemeleri uygulanır.

Modelin Dezavantajı

Bu modelin en büyük dezavantajı, önceki aşamalarda yapılan hataların sonraki aşamalara taşınmasıdır.
Bu durum, sorunların her aşamada çözülmesini gerektirdiği için daha fazla zaman ve maliyet kaybına yol açabilir.

Spiral Model

Spiral modeli, Waterfall modelinin katı ve esnek olmayan yapısını aşmak için geliştirilmiş bir yazılım geliştirme modelidir.

Temel Farklılıklar:

Dört ana fazdan oluşur: Planlama, Risk Analizi, Mühendislik ve Müşteri Değerlendirmesi.
Her aşama tekrar eden döngülerden (iterasyonlardan) geçer.
Tamamlanmadan önce 2-3 prototip geliştirilerek sistemin eksikleri belirlenir.
Geri bildirim mekanizması sayesinde hatalar erken aşamada tespit edilir.

Avantajları:

Risk odaklıdır – Projenin erken aşamalarında riskler belirlenerek önlem alınır.
Müşteri geri bildirimi sürece dahil edilir – Kullanıcı istekleri iterasyonlar boyunca dikkate alınır.
Esnek bir yapıya sahiptir – Gereksinimler değişebilir, her iterasyonda iyileştirme yapılabilir.

Spiral Modelin Aşamaları

Planlama: Projenin gereksinimleri, hedefleri ve kısıtları belirlenir. Strateji oluşturulur.
Risk Analizi: Alternatif çözümler analiz edilir, proje için kritik riskler belirlenir.
Tasarım ve Geliştirme: Yazılım iteratif olarak geliştirilir ve bir sonraki aşamaya geçilir.
Test ve Müşteri Değerlendirmesi: Kullanıcı geri bildirimi toplanır, hatalar ve eksiklikler düzeltilir.

Spiral Modelin Test Süreci

Her döngüde test yapılır.
Test ekibi ve müşteriler geri bildirim vererek eksiklikleri belirler.
Hata ve kusurlar her iterasyonda düzeltilir, böylece final üründe minimum hata bulunur.

Avantaj:

Erken test süreçleri uygulanır ve hatalar, geliştirme sürecinde düzeltilir.
Müşteri geri bildirimleri doğrultusunda test süreci iyileştirilir.

Dezavantaj:

Her iterasyon zaman ve maliyet gerektirir.
Testlerin müşteriye bağımlı olması, süreci uzatabilir.

Spiral Model vs Waterfall Modeli

Özellik	Waterfall Modeli	Spiral Modeli
Test Süreci	En sonda yapılır.	Her iterasyonda yapılır.
Esneklik	Değişiklik yapmak zordur.	Gereksinimler güncellenebilir.
Risk Yönetimi	Risk analizi yoktur.	Riskler her aşamada analiz edilir.
Müşteri Geri Bildirimi	Proje tamamlandıktan sonra alınır.	Sürekli geri bildirim mekanizması vardır.
Geliştirme Yaklaşımı	Doğrusal (linear).	Döngüsel ve iteratif (iterative).

V-Model

V-Model (Doğrulama ve Geçerleme Modeli), test süreçlerini yazılım geliştirme yaşam döngüsünün (SDLC) her aşamasına entegre eden bir modeldir.

Temel Özellikleri:

Test süreci, proje başlangıcından itibaren başlar ve geliştirme süreciyle paralel ilerler.
Kalite kontrolü her aşamada yapılır, böylece hatalar erken tespit edilir.
Her geliştirme aşamasına karşılık gelen bir test aşaması bulunur.

V-Model: Geliştirme ve Test Aşamaları

Geliştirme Aşaması	Test Aşaması
- İş Gereksinimleri Tanımlama	- Kabul Testleri (Acceptance Testing)
- Fonksiyonel ve Sistem Tasarımı	- Sistem Testleri (System Testing)
- Detaylı Teknik Tasarım	- Entegrasyon Testleri (Integration Testing)
- Modül Tasarımı	- Birim Testleri (Unit Testing)

V-Modelde Test Aşamaları

Birim Testi (Unit Testing):
- Kod seviyesinde yapılan testlerdir.
- Her bir modül veya fonksiyonun doğru çalıştığını doğrulamak için yapılır.
- Test senaryoları, modül tasarım aşamasına göre hazırlanır.
Entegrasyon Testi (Integration Testing):
- Farklı modüllerin birlikte çalışmasının test edilmesini sağlar.
- Modüller arası veri alışverişinin hatasız gerçekleştiği doğrulanır.

V-Modelde Test Aşamaları (Devam)

Sistem Testi (System Testing):
- Yazılımın tüm bileşenleriyle birlikte çalışmasını test eder.
- Performans, güvenlik ve kullanılabilirlik testlerini de içerir.
Kabul Testi (Acceptance Testing):
- Müşteri tarafından yapılan testlerdir.
- Yazılımın iş gereksinimlerini karşılayıp karşılamadığı kontrol edilir.

V-Modelin Avantaj/Dezavantajları

Erken hata tespiti sağlar: Geliştirme aşamalarıyla eşzamanlı test yapıldığı için hatalar erken tespit edilir.
Kaliteyi artırır: Test sürecinin her aşamaya entegre edilmesi, ürünün daha güvenilir olmasını sağlar.
Daha düşük maliyet: Hatalar erken bulunduğunda, düzeltme maliyeti azalır.
Değişiklik yapmak zordur: Gereksinimler belirlendikten sonra değişiklik yapmak maliyetlidir.
Tam belgelenmiş gereksinimler gerektirir: Eksik gereksinimlerde model etkili çalışmaz.

Rapid Application Development Model

Rapid Application Development (RAD), iş gereksinimlerine, proje yönetimi gereksinimlerine ve yazılım gereksinim spesifikasyonlarına (SRS) dayalı olarak oluşturulan bir hızlı yazılım geliştirme modelidir.