🐞 E5 · Network'ten Defect Yakalama

E5 · Network'ten Defect Yakalama: E1-E4'te öğrendiğin her şey (sütunlar, filtre, sekmeler, Timing) tek bir amaç için var: **Network paneli, UI'nın SÖYLEDİĞİ ile sunucunun GERÇEKT

E1-E4'te öğrendiğin her şey (sütunlar, filtre, sekmeler, Timing) tek bir amaç için var: **Network paneli, UI'nın SÖYLEDİĞİ ile sunucunun GERÇEKTEN YAPTIĞI arasındaki farkı ortaya çıkaran bir yalan makinesidir.** UI her zaman geliştiricinin YAZDIĞI metni gösterir ("Başarılı!"), Network paneli ise sunucunun GERÇEKTEN döndürdüğünü gösterir (500, boş body, sızan bir alan) — ikisi arasındaki uyumsuzluk tam olarak bir defect'in doğduğu yerdir. Peki neden bu kadar sık UI ile gerçeklik arasında fark olur — geliştirici bilerek mi yalan söylüyor? Hayır — çoğu zaman geliştirici sadece "mutlu yol"u (happy path) test eder, hata durumunu (`catch` bloğunu) ya hiç yazmaz ya da orada da yanlışlıkla "başarılı" mesajı gösterir; bu bir kasıt değil, bir GÖZDEN KAÇMADIR. Java'da bunun karşılığı, bir `try` bloğunun `catch (Exception e) { }` ile SESSİZCE yutulmasıdır — hata gerçekten olur ama hiçbir yere loglanmaz/bildirilmez, tıpkı UI'nın 500'ü "başarılı" göstermesi gibi. QA açısından bu sekme, sayfanın tüm GRUP E'sinin doruk noktasıdır: artık sadece paneli OKUMUYORSUN, panelde SAKLI olan gerçek bug'ları AVLIYORSUN.

5 Gerçek Defect Senaryosu ve Hangi Katmanda Yakalanır

Aşağıdaki 5 senaryo, Network panelinden yakalanan gerçek defect kategorileridir. Her biri farklı bir "UI ile gerçeklik arasındaki fark" türünü temsil eder.

UI "Başarılı" Diyor, Network "500" Diyor

**1. Sessiz 500 (Silent 500)** — UI hiçbir hata göstermeden "İşlem tamamlandı" der, ama Network panelinde ilgili request `500 Internal Server Error` döner. **Kök neden:** frontend kodu response'un status kodunu HİÇ kontrol etmeden `.then()` bloğunu çalıştırır. **Tester nerede yakalar:** Network panelinde Status sütununu UI mesajından BAĞIMSIZ olarak her zaman kontrol ederek.

**2. Çift POST (Double POST)** — Kullanıcı "Kaydet" butonuna sabırsızca iki kez tıklar; buton devre dışı bırakılmadığı için Network panelinde AYNI `POST /api/v1/bugs` request'i İKİ KEZ görünür, iki ayrı bug kaydı oluşur. **Kök neden:** buton, request devam ederken `disabled` yapılmamış. **Tester nerede yakalar:** hızlı çift tıklama sonrası Network panelinde aynı request'in tekrarını sayarak.

**3. N+1 Request** — Bug listesi sayfası ÖNCE `GET /api/v1/bugs` ile 10 kayıt çeker, sonra HER kayıt için ayrı ayrı `GET /api/v1/bugs/{id}/details` çağırır — 1 yerine 11 request. **Kök neden:** liste endpoint'i zaten ihtiyaç duyulan detayı döndürmüyor, frontend her satır için ayrı request atmak ZORUNDA kalıyor. **Tester nerede yakalar:** Network panelinde AYNI URL kalıbının kayıt sayısı kadar tekrarlandığını görerek.

**4. Response'ta Sızan `passwordHash`** — Bir kullanıcı listesi request'inin `Response`/`Preview` sekmesinde, UI hiç göstermese bile, JSON gövdesinde `passwordHash` gibi ASLA dönmemesi gereken bir alan görülür. **Kök neden:** backend, veritabanı entity'sini (tüm alanlarıyla) doğrudan JSON'a çeviriyor, bir DTO/response modeliyle alan filtrelemiyor. **Tester nerede yakalar:** Response/Preview sekmesinde JSON'u UI'da GÖRÜNMEYEN alanlar için de tarayarak — bu bir güvenlik açığıdır, sadece bir "kozmetik" fazlalık değil.

**5. Cache-Control Eksikliği** — Bir kullanıcı hassas bir bug detayını görüntüler, çıkış yapar; tarayıcının GERİ tuşuna basınca aynı sayfa, YENİ bir request atmadan, ÖNBELLEKTEN eski (ve artık yetkisiz olması gereken) veriyi gösterir. **Kök neden:** response header'larında `Cache-Control: no-store` YOK, tarayıcı hassas response'u serbestçe önbelleğe alıyor. **Tester nerede yakalar:** Headers sekmesinde `Cache-Control` alanının varlığını/değerini kontrol ederek, sonra geri tuşu senaryosunu deneyerek.

🎬 Network Panelinde Bir Bug

Kullanıcı: "Kaydet"e basar

UI: "Başarıyla oluşturuldu"

Network: 500 Internal Error

Tester Network'ü açar