• 1.4. Yeni Mezun Tuzakları (Pitfalls & Anti-Patterns)

    Yazılım sektöründe “Anti-Pattern”; ilk bakışta mantıklı, pratik ya da zararsız görünen ancak zamanla projeyi çıkmaza sokan hatalı çalışma alışkanlıklarını ifade eder. Mesleğe yeni adım atan parlak zihinler, genellikle teknik bilgi eksikliğinden değil, zihinsel reflekslerini doğru kurgulayamadıklarından benzer tuzaklara düşerler.

    İşte sektöre başlarken arkanda bırakman gereken en ölümcül yeni mezun tuzakları:

    Tuzak 1: “Sadece Dokümanda Ne Yazıyorsa Onu Test Ederim” Pasifliği

    • Hatalı Yaklaşım: İş analisti gereksinim dokümanına “Kullanıcı şifresini girer ve giriş butonuna basar” yazmıştır. Yeni mezun testçi, geçerli bir şifre girip ana sayfanın açıldığını görünce arkasına yaslanır ve görevini eksiksiz tamamladığını düşünür.

    • Doğru Mühendislik Yaklaşımı: Dokümanda yazanlar yalnızca Açık Gereksinimlerdir (Explicit Requirements); asıl mühendislik ise dokümanda yazılmaya gerek bile duyulmayan Örtük Gereksinimleri (Implicit Requirements) sorgulamaktır. Bir test mühendisi şu soruları sormakla yükümlüdür:

      • “Kullanıcı şifre kutusuna yanlışlıkla 5.000 karakterlik devasa bir metin yapıştırırsa sistem kilitlenir mi?”

      • “Butona sabırsızca art arda 10 kez tıklarsa arkada 10 farklı oturum mu açılır?”

      • “Kullanıcının klavyesinde ‘Caps Lock’ açıkken sistem onu uyarır mı?”

        Dokümanda yazmayan riskleri gün yüzüne çıkarmak senin temel görevidir.

    Tuzak 2: Pozitif Senaryo Sarhoşluğu (Happy Path Addiction)

    • Hatalı Yaklaşım: Sistemin doğru girdilerle kusursuz çalıştığını görüp testi “Başarılı” (Passed) olarak kapatmak ve işin bittiğini sanmak.

    • Doğru Mühendislik Yaklaşımı: Yazılımcılar kodu inşa ederken zaten pozitif akışın çalıştığını kendi bilgisayarlarında görürler. Test uzmanının asıl katma değeri, sistemin sıra dışı, eksik veya hatalı verilere karşı nasıl ayakta kaldığını denetlemektir. Mühendislikte buna Zarif Dayanıklılık (Graceful Degradation) denir: Sistem beklenmedik bir hatayla karşılaştığında panikleyip beyaz bir hata ekranıyla donmamalı; kullanıcıyı nazikçe uyararak güvenli bir şekilde ayakta kalabilmelidir.

    Tuzak 3: Geliştiriciyle Kişisel Çatışmaya Girmek (Ego Savaşı)

    • Hatalı Yaklaşım: Kusur bulmayı kişisel bir zafer, geliştiricinin hatasını yüzüne vurmayı bir üstünlük gösterisi saymak. Hata takip sistemine (Jira gibi) “Ahmet yine döngüyü kuramamış, kod dökülüyor” minvalinde alaycı veya suçlayıcı notlar düşmek.

    • Doğru Mühendislik Yaklaşımı: Test mühendisi kişileri değil, ürünün kalitesini savunur. Yazılımcı senin rakibin değil; aynı gemide, aynı fırtınaya karşı kürek çektiğin ekip arkadaşındır. ISTQB etik kuralları gereği hatalar asla kişiselleştirilmez. Dil daima nesnel, olgusal ve tarafsız olmalıdır:

      • ❌ “Hatalı kod yazmışsın, buton basmıyor.”

      • “Kullanıcı adı boş bırakılıp ‘Giriş Yap’ tıklandığında, sistem uyarı mesajı vermek yerine kilitlenmektedir (Ekran kaydı ve adımlar ektedir).”

    Tuzak 4: “Yazılımı Bozmak Benim İşimdir” Kibri

    • Hatalı Yaklaşım: Test mühendisini “yazılım kıran, ortalığı dağıtan bir yıkıcı” olarak konumlandırmak.

    • Doğru Mühendislik Yaklaşımı: Sen bir yıkıcı değilsin; sen sistemin henüz keşfedilmemiş çatlaklarını ameliyat titizliğiyle açığa çıkaran bir kalite cerrahısın. Amacın yazılımı kırmak değil; kullanıcıların o yazılımı kıramayacağı kadar sağlam ve dirençli hale getirilmesine rehberlik etmektir.

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

    💡 Bir de Şöyle Düşün: Restoran Müfettişi vs. Gizli Müşteri

    Lüks bir restoranı denetlediğini hayal et:

    • Tuzak Yaklaşım: Masaya oturup garsonun getirdiği nefis yemeği yemek, lezzetine tam puan verip hesabı ödeyerek çıkmaktır. Bu yalnızca “Happy Path”tir.

    • Kalite Mühendisliği Yaklaşımı:

      • “Mutfağın havalandırması aniden durursa yangın söndürme sistemi devreye giriyor mu?”

      • “Aynı anda 50 masa birden sipariş verirse ocaklar siparişleri yetiştirebiliyor mu?”

      • “Yemekten kıl çıkarsa garson müşteriye bağırıyor mu, yoksa özür dileyip tabağı nezaketle yeniliyor mu (Graceful Degradation)?”

    Masadaki tabağın lezzetli olması yetmez; mutfağın kaos anındaki dayanıklılığı o restoranın gerçek kalitesini belirler.

    5. Mini Alıştırma

    Senaryo: Şirketinizdeki genç bir yazılımcı, hazırladığı yeni “Adres Ekleme” ekranını test etmen için sana gönderdi. Sen formu test ederken sokak adı alanına özel karakterler girdiğinde sistemin çöktüğünü (Crash) fark ettin.

    Soru: Ekip içi iletişimi zedelemeden, ISTQB standartlarına uygun nesnel bir hata bildirimi oluşturmak için aşağıdaki iki seçenekten hangisini tercih etmelisin ve neden?

    • A Seçeneği: “Özel karakter kontrollerini yine yapmamışsın, adres satırına ‘@!#’ yazınca tüm sayfa çöküyor, lütfen düzeltip tekrar gönder.”

    • B Seçeneği: “Adres satırına özel karakterler (‘@!#’) girilip ‘Kaydet’ butonuna tıklandığında sayfa yanıt vermeyi durduruyor (HTTP 500). Beklenen sonuç: Geçersiz karakter uyarısı gösterilmesidir. Hata anı ekran kaydı ektedir.”

    Doğru Yanıt: B Seçeneği.

    A seçeneği suçlayıcıdır (“sen yapmamışsın”), kişiyi hedef alır ve geliştiricinin savunma mekanizmasını tetikler. B seçeneği ise tamamen nesneldir; yapılan eylemi, alınan hatalı sonucu, olması gereken beklenen sonucu ve kanıtı (ekran kaydı) sunarak süreci kişilerden bağımsız, saf bir kalite problemine dönüştürür.

ÖncekiSonraki