1.3. Adım Adım Metodoloji: Test Temelleri ve ISTQB Prensipleri

Bir test mühendisinin mesleki omurgasını, uluslararası geçerliliğe sahip olan ISTQB (International Software Testing Qualifications Board – Uluslararası Yazılım Test Nitelikleri Kurulu) standartları oluşturur. Bu disiplin; sisteme rastgele tıklamalar yapma devrini kapatır, kaliteyi matematiksel kuralları olan ölçülebilir bir bilime dönüştürür.

1.3.1. Temel Terminoloji: Error vs. Defect vs. Failure

Teknik mülakatlarda en sık sorulan ve sektörde birbirinin yerine yanlışlıkla kullanılan üç temel kavramı netleştirelim:

Aşama Standart Terim Günlük Dildeki Karşılığı Ne Demektir? Nerede Ortaya Çıkar?
1. Kök Neden Error (Mistake) İnsan Hatası / Yanılgı İnsanın yorgunluk, bilgi eksikliği veya dikkatsizlik sonucu yaptığı zihinsel yanılgıdır. İnsanın Zihninde
2. Statik Kusur Defect (Bug / Fault) Kusur / Gizli Hata Zihinsel hatanın koda, tasarıma veya analiz dokümanına yansıyan somut halidir. Yazılı Belgede, Kaynak Kodda
3. Dinamik Belirti Failure Arıza / Sistem Çökmesi Kusurlu kod çalıştığında sistemin yapması gereken işi yapamaması veya çökmesidir. Canlı Ortamda, Kullanıcı Ekranında

Bu üç adımı birbirine bağlayan mekanizma şöyledir:

  • Error (İnsan Hatası): Hata yalnızca insana aittir. Bir geliştiricinin gece geç saatte yorgunluktan dolayı matematik formülündeki büyüktür (>) işaretini küçük eşittir (<=) yapması ya da iş analistinin indirim kuralını gereksinim belgesine yazarken eksik bırakması birer Error‘dur.

  • Defect (Kusur / Bug): İnsan hatasının dokümana veya koda dökülmüş, henüz çalıştırılmamış somut halidir. Yazılımcının bilgisayarında ya da kod deposunda (repository) sessizce bekleyen hatalı formül bir Defect‘tir. O kod satırı henüz kimse tarafından tetiklenmemiş olabilir; orada uyur.

  • Failure (Arıza / Başarısızlık): Kusur barındıran kod parçasının çalışma zamanında (runtime) gerçek bir veriyle karşılaşması sonucu sistemin bekleneni verememesidir. Kullanıcının butona bastığında siparişin tamamlanamaması veya sistemin çökmesi bir Failure‘dır.

Kritik Kural: Yapılan bir insan hatası (Error), dokümana veya koda bir kusur (Defect) olarak yerleşir. Ancak her kusur mutlaka bir arızaya (Failure) dönüşmek zorunda değildir. Kusurlu kod parçası hiçbir zaman çalıştırılmazsa (örneğin sadece 4 yılda bir gelen 29 Şubat gününe özel yazılmış hatalı bir indirim kuralı gibi), o kusur sistemde yıllarca fark edilmeden sessizce bekleyebilir. Test mühendisinin görevi, bu kusurları birer canlı sistem felaketine (Failure) dönüşmeden önce saklandıkları yerlerde ortaya çıkarmaktır.

1.3.2. ISTQB’nin 7 Temel Test İlkesi

Aşağıdaki 7 ilke, kariyerin boyunca alacağın her stratejik kararın, hazırlayacağın her test planının ve yöneteceğin her krizin temel anayasasıdır:

İlke 1: Test Etmek Kusurların Varlığını Gösterir, Yokluğunu Değil

Test koşarak bir yazılımda hataların var olduğunu kanıtlayabilirsin; fakat sistemde “kesinlikle hiçbir kusur kalmadığını” asla kanıtlayamazsın. Binlerce senaryo çalıştırıp hepsinden yeşil “Başarılı” sonucu alsan dahi “Bu yazılımda sıfır hata vardır” diyemezsin. Testin amacı, bulunamayan gizli kusurların olasılığını azaltmak ve canlıya çıkış riskini şirketin kabul edebileceği güvenli bir eşiğe çekmektir.

İlke 2: Tükenmez (Eksiksiz) Test İmkânsızdır (Exhaustive Testing is Impossible)

Bir mobil bankacılık uygulamasındaki sadece 6 haneli şifre alanını düşün. Rakamlar, özel karakterler, boşluklar, kopyala-yapıştır denemeleri, farklı alfabeler ve cihaz türleri hesaba katıldığında sonsuz sayıda deneme kombinasyonu ortaya çıkar. Bütün olasılıkları tek tek denemeye ne zaman ne de şirketlerin bütçesi yeter. Test mühendisliği bir “rastgele tıklama” işi değil; risk analizi ve özel test teknikleri (BVA, ECP) kullanarak bu sonsuz ihtimaller denizini en riskli, en kritik senaryolara indirgeme bilimidir.

İlke 3: Erken Test Hayat Kurtarır (Shift-Left Yaklaşımı)

Bir hatayı ne kadar erken yakalarsan, çözümü o kadar ucuz ve zahmetsiz olur:

Aşama Hatanın Yakalandığı An Çözüm Maliyeti Somut Karşılığı
Gereksinim / Analiz Proje Başlangıcı (Tasarım) 1x (Taban) Dokümandaki mantık hatası bir cümle değiştirilerek 5 dakikada düzeltilir (Maliyet: ~100 TL).
Geliştirme (Kodlama) Kod Yazılırken 5x – 10x Geliştirici fonksiyonu baştan yazar, kodunu yeniden derler (Maliyet: ~1.000 TL).
Test Ortamı (QA) Test Mühendisinin Elinde 20x – 50x Kusur raporlanır, toplantı yapılır, geliştirici düzeltir, test tekrar koşulur (Maliyet: ~5.000 TL).
Canlı Ortam (Prod) Gerçek Müşterinin Elinde 100x – 500x+ Kriz masası toplanır, ciro kaybedilir, prestij zedelenir, acil yama çıkılır (Maliyet: 50.000 TL+).

Test faaliyetlerini yazılım geliştirme sürecinin sonundan alıp en başına (yani gereksinimlerin ve mimarinin yazıldığı sol tarafa) çekme yaklaşımına sektörde Shift-Left (Sola Kaydırma) denir.

İlke 4: Hatalar Belirli Alanlarda Kümelenir (Pareto Prensibi)

Genel kural yazılımda da değişmez: Bir sistemdeki canlı ortam hatalarının yaklaşık %80’i, sistemin en karmaşık ve en çok veri alışverişi yapan %20’lik çekirdek modülünden (örneğin ödeme adımı veya yetkilendirme servisleri) kaynaklanır. Test stratejini kurarken eforunu sistemin her ekranına körü körüne eşit dağıtmazsın; riskin kümelendiği bu kritik alanlara odaklanırsın.

İlke 5: Böcek İlacı (Pestisit) Paradoksu (Pesticide Paradox)

Bir tarlaya aynı tarım ilacını aralıksız sıkarsan, böcekler o kimyasala zamanla bağışıklık kazanır ve ilaç artık etkisini kaybeder. Test senaryoları da böyledir: Aynı test adımlarını ve aynı otomatik testleri aylarca hiçbir veri değişikliği yapmadan çalıştırırsan, sistemin sadece o testlerin geçtiği yolları sağlamlaşır; fakat arka sokaklarda gizlenen yeni hataları yakalayamazsın. Bu yüzden test senaryoları sürekli güncellenmeli ve sisteme farklı açılardan yeni keşifçi testler uygulanmalıdır.

İlke 6: Test Bağlama Bağlıdır (Testing is Context-Dependent)

Evrensel, tek tip bir test reçetesi yoktur. Basit bir bulmaca oyununu test ederken eğlence faktörü, ekran tepki hızı ve renk geçişleri ön plandayken; bir hastanenin yoğun bakım solunum cihazı yazılımını ya da bir bankanın EFT motorunu test ederken sıfır veri kaybı, yasal uyumluluk ve milisaniyelik güvenlik önceliklidir. Testi, içinde bulunduğu sektörün ve riskin bağlamına göre şekillendirirsin.

İlke 7: Hatasızlık Yanılgısı (Absence-of-Errors Fallacy)

Sistemdeki tüm teknik hataları bulmuş, koddaki tüm kusurları sıfırlamış ve testleri %100 “Başarılı” tamamlamış olabilirsin. Ancak ortaya çıkan yazılım kullanıcının gerçek ihtiyacını çözmüyorsa, karmaşık yapısı yüzünden kimse tarafından tercih edilmiyorsa o proje ticari olarak başarısızlıktır. Bu yüzden mühendislikte şu iki soru asla birbirinden ayrılamaz:

  • Doğrulama (Verification): “Ürünü şartnameye ve plana uygun şekilde doğru yaptık mı?”

  • Geçerleme (Validation): “Kullanıcının gerçek problemini çözen doğru ürünü mü yaptık?”

4. “Bir de Şöyle Düşün” (Kutu İçeriği)

💡 Bir de Şöyle Düşün: Terzi ve Düğün Takım Elbisesi

Özel bir düğün için terziye takım elbise diktirdiğini hayal et:

  • Doğrulama (Verification): Terzi eline cetveli alır; ceketin kol boyunu, pantolonun paça genişliğini ve dikiş aralıklarını sipariş fişindeki ölçülerle tek tek karşılaştırır. Ölçüler milimi milimine tutmaktadır. Terzi işini teknik olarak doğru yapmıştır.

  • Geçerleme (Validation): Takım elbiseyi giyersin. Aynaya baktığında ceket üzerine oturmamıştır, kollarını yukarı kaldıramıyorsundur ve kumaş seni terletmektedir. Ölçüler doğru olmasına rağmen ürün ihtiyacını karşılamaz.

Hatasızlık Yanılgısı (İlke 7) tam olarak budur: Kod teknik şartnameye harfiyen uyabilir (Doğrulama başarılı); ancak son kullanıcı o uygulamayı kullanamıyorsa ya da ürün işe yaramıyorsa (Geçerleme başarısız), o sistem kusursuz olsa bile başarısızdır.

5. Mini Alıştırma

Senaryo: Bir sağlık teknolojisi şirketinde çalışıyorsun. Yazılım ekibi şeker hastalarının kan şekerini takip eden bir mobil uygulama geliştirdi. Ekip lideri sana gururla gelip şunu söylüyor:

“6 aydır aynı 50 adet otomatik test senaryosunu her gün sabah akşam çalıştırıyoruz ve son 2 aydır tek bir hata bile bulamadık. Sistemimiz artık kusursuz, canlıya güvenle çıkabiliriz.”

Soru: ISTQB ilkelerini özümsemiş bir Test Mühendisi olarak, ekip liderinin bu iddiasında yer alan iki temel mantık hatasını hangi ISTQB ilkeleriyle çürütürsün?

  1. İlke 5 (Böcek İlacı / Pestisit Paradoksu): Sürekli aynı 50 test senaryosu koşulduğu için sistem o senaryolara bağışıklık kazanmıştır; kodun diğer yollarındaki yeni kusurları yakalayamaz hale gelmiştir. Test senaryolarının çeşitlendirilmesi ve güncellenmesi gerekir.

  2. İlke 1 (Test Kusurların Varlığını Gösterir, Yokluğunu Değil): 2 aydır hata bulunamamış olması sistemde hiç hata kalmadığını kanıtlamaz. Yalnızca mevcut testlerin artık yeni bir hata yakalayamadığını gösterir.

ÖncekiSonraki