1.2. Sektördeki Gerçek Senaryo: Gece Yarısı Kilitlenen Sepetler

Yılın en büyük e-ticaret indirim gecesindeyiz. Şirket aylardır bu büyük kampanya dönemine hazırlanıyor: Şehirdeki reklam panoları kiralandı, dev bütçeli anlaşmalar yapıldı, sunucu kapasiteleri olası izdihama karşı üç katına çıkarıldı.

Saatler tam 00:00’ı gösterdiğinde ana sayfada indirim duyurusu parladı ve yüz binlerce kullanıcı aynı anda siteye akın etti.

İlk on dakika her şey kusursuz görünüyordu. Ancak saat 00:14 sularında sistem izleme ekranlarında kırmızı alarmlar yanıp sönmeye başladı. Sosyal medyaya ve müşteri destek hatlarına binlerce öfkeli mesaj yağıyordu. Ortada akılalmaz bir gariplik vardı:

Sepet tutarı 999 TL ve altında olan tüm kullanıcılar ödemelerini saniyeler içinde tereyağından kıl çeker gibi tamamlayabiliyordu. Fakat sepet tutarı tam 1.000 TL ve üzerinde olan hiçbir müşteri “Siparişi Tamamla” butonuna basamıyordu! Butona basıldığı anda sayfa donuyor, kum saati dönüyor ve kullanıcıların karşısına “Beklenmeyen Bir Hata Oluştu (Sunucu Hatası)” uyarısı çıkıyordu.

Şirket genel merkezinde dakikalar içinde acil kriz masası toplandı. Sorunun kaynağı, ödeme adımında son gün yapılan ve herkesin “iki dakikalık masum bir değişiklik” gözüyle baktığı şu iş kuralıydı:

“Sepet tutarı 1.000 TL ve üzerinde olan kullanıcılara kargo ücretsiz tanımlanır ve sistem sepete özel ek indirimi hesaplayarak siparişi onaylar.”

Peki geliştirici bu kuralı koda dönüştürürken ne yapmıştı?

Kendi bilgisayarında sadece “Mutlu Yol” (Happy Path) dediğimiz en rahat, en sorunsuz senaryoları denemişti: Sepete 200 TL’lik bir kulaklık eklemiş, kargonun ücretli olduğunu görmüş; yanına 1.500 TL’lik bir tablet eklemiş, kargonun sıfırlandığını ve indirimin düştüğünü teyit etmişti. İki uçta da işlem başarılı olunca “Kod çalışıyor, bende hiçbir sorun yok” diyerek paketi canlıya göndermişti.

Geliştiricinin gözden kaçırdığı şey, tam sınır çizgisinin kendisiydi:

Sepet tutarı tam 1.000,00 TL olduğunda devreye giren indirim formülü; sistemde gizlenen matematiksel bir mantık hatası yüzünden bir sayıyı sıfıra bölmeye çalışıyordu. İlkokul matematiğinden bildiğimiz gibi: Bir sayıyı sıfıra bölemezsiniz, bu işlem tanımsızdır. Bilgisayarlar da tanımsız bir işlemle karşılaştıklarında ne yapacaklarını bilemez, panikler ve işlemi durdurur.

Sistem 999,99 TL’de başka, 1.500,00 TL’de başka davranırken; tam geçiş noktası olan 1.000,00 TL sınırında kilitlenip çöküyordu.

Sonuç ne mi oldu?

  • Sistem 45 dakika boyunca felç oldu.

  • Doğrudan ciro kaybı 4.2 milyon TL‘yi buldu.

  • Sosyal medyada markanın güvenilirliği ağır bir darbe aldı.

O gece kriz masasında eksik olan tek bir şey vardı: Bir yazılımı yalnızca “çalışıyor mu” diye değil; “hangi sınırlarda zorlanır, kuralların kesiştiği uç noktalarda ne tepki verir” şüpheciliğiyle inceleyen bir Test Mühendisi zihniyeti.

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

💡 Köprüdeki Ağırlık Levhası ve Hata Zinciri

Karayolunda üzerinde “Maksimum Yük: 10 Ton” yazan eski bir taş köprü hayal et.

  • İnsan Hatası (Error): Köprüyü tasarlayan mühendisin, 10 tona kadar olan dayanıklılık hesabını yaparken formülde virgülü yanlış yere koyması bir insan hatasıdır (error/mistake).

  • Kusur / Bug (Defect): Mühendisin bu dikkatsizliği sonucu köprü ayaklarındaki çeliğin projede olması gerekenden 2 milimetre ince üretilmesi projedeki kusurdur (defect/bug). Köprü bomboş dururken kimse bu kusuru fark etmez; sessizce orada bekler.

  • Arıza / Başarısızlık (Failure): Günün birinde köprüden tam 10 tonluk bir kamyon geçerken köprünün çökmesi ise bir arızadır (failure).

Yazılımda da geliştiricinin yorgunluktan yaptığı bir dikkatsizlik (Error), koda bir Kusur (Defect) olarak gizlenir. Kullanıcı o hatalı koda denk gelecek adımı attığında ise sistem çöker (Failure). Test mühendisi, bu arıza canlıdaki gerçek kullanıcıların başına gelmeden önce o gizli kusurları güvenli ortamda yakalayan kişidir.

5. Mini Alıştırma

Senaryo: Bir sinema bileti uygulamasında şu kural geçerlidir:

“65 yaş ve üzeri vatandaşlarımıza biletler %50 indirimlidir.”

Bir geliştirici bu özelliği kodlamış ve sana “Ben 25 yaşında bir genç ile 80 yaşında bir emekli için denedim, sistem ikisinde de doğru çalışıyor; test tamamlandı” demiştir.

Soru: “Sınır Değer” mantığını kavramış bir test uzmanı adayı olarak; geliştiricinin atladığı ve sistemin çökme ya da yanlış indirim uygulama riskinin en yüksek olduğu en kritik 3 yaş değerini seçmen gerekse, hangi yaşları test ederdin?

En kritik 3 sınır değer:

  1. 64 yaş: İndirimin uygulanmaması gereken tam sınırın bir altı (Sistem yanlışlıkla indirim veriyor mu?).

  2. 65 yaş: İndirimin başlaması gereken tam sınır noktası (Sistem kuralı “> 65” mi yoksa “>= 65” mi kodladı?).

  3. 66 yaş: İndirimin kesinlikle uygulanması gereken sınırın hemen bir üstü.