Geliştirici ekibe mail atıyorsunuz: “Form çalışmıyor.”
Gelen cevap: “Bizde çalışıyor. Hangi form? Nerede? Ne hatası veriyor?”
Ve başlıyor sonsuz mail trafiği…
Bug bulmak kolay, ama onu düzeltilebilir şekilde raporlamak başka bir iş. Kötü yazılmış bir bug report saatlerce zaman kaybettirir, iyi yazılmış olanı ise sorunu 10 dakikada anlaşılabilir hale getirir.
Peki iyi bir bug report nasıl yazılır?
İyi Bir Bug Report’un Anatomisi
Her bug report’ta mutlaka bulunması gereken 6 temel öğe var:
1. Başlık (Title)
Kötü Örnek: “Form çalışmıyor”
İyi Örnek: “İletişim formu – Safari’de ‘Gönder’ butonu tıklanamıyor”
Fark ne?
– Hangi özellik? → İletişim formu
– Ne sorunu? → Buton tıklanamıyor
– Nerede? → Safari’de
Başlık, geliştiricinin 3 saniyede “Bu benim sorunum mu?” anlayabileceği kadar net olmalı.
2. Öncelik (Priority)
Critical: Sistem çöküyor, para kaybı var
High: Ana özellik çalışmıyor
Medium: Özellik çalışıyor ama hatalı
Low: Görsel hatalar, yazım yanlışları
Örnek: E-ticaret sitesinde “Ödeme alınamıyor” Critical, “Ürün görseli kaymış” ise High.
3. Adımlar (Steps to Reproduce)
Bu kısım en kritik bölüm. Geliştirici, hatayı görmeden düzeltemez.
Kötü Örnek: “Kayıt olurken hata veriyor.”
İyi Örnek:
1. Ana sayfadan ‘Kayıt Ol’ butonuna tıkla
2. Email: test@test.com
3. Şifre: 123456
4. ‘Kayıt Ol’ butonuna tıkla
5. Hata mesajı görünüyor: “Geçersiz email formatı”
4. Beklenen Sonuç vs Gerçekleşen Sonuç
Beklenen: “Kullanıcı kayıt olmalı ve dashboard sayfasına yönlendirilmeli.”
Gerçekleşen: “Hata mesajı gösteriliyor: ‘Geçersiz email formatı’ ancak email formatı doğru.”
Bu karşılaştırma, geliştiriciye “ne yanlış gidiyor?” sorusunun cevabını verir.
5. Ortam Bilgisi (Environment)
– Tarayıcı: Safari 17.2
– İşletim Sistemi: macOS Sonoma 14.2
– Cihaz: MacBook Pro M2
– Tarih: 13.01.2026
Mobil için: Cihaz modeli, iOS/Android versiyonu ve bağlantı tipi (WiFi/4G) ekleyin.
6. Görsel Kanıt (Screenshot/Video)
Ekran görüntüsü: Hata mesajları, görsel hatalar, tek bir anı göstermek için
Video: Adım adım süreç, animasyon hataları, zamanlama sorunları için
İpucu: Ekran görüntüsüne ok işareti ekleyin, neye bakılması gerektiğini gösterin.
Geliştiricilerin Anlamadığı 4 Klasik Hata
❌ “Bazen çalışıyor, bazen çalışmıyor”
✅ Düzeltme: “5 denemeden 3’ünde çalışıyor. Genellikle 3. tıklamada hata veriyor.”
❌ “Bu korkunç bir hata!”
✅ Düzeltme: “Kullanıcı akışını engelleyen kritik bir hata.”
❌ “Bunun için setTimeout kullanmalısınız”
✅ Düzeltme: Sadece hatayı bildirin, çözüm önerisi geliştiriciye kalsın.
❌ Tek raporda birden fazla hata
✅ Düzeltme: Her hata için ayrı rapor açın.
Gerçek Hayattan Karşılaştırma
🔴 Kötü Bug Report:
Başlık: Hata var
Açıklama: Tıklayınca bir şey olmuyor.
Sonuç: Geliştirici 2 saat harcayıp neyi, nerede, nasıl tıkladığınızı anlamaya çalışır.
🟢 İyi Bug Report:
Başlık: Checkout – “Siparişi Tamamla” butonu tıklanamıyor
Öncelik: Critical
Açıklama: Sepet sayfasından checkout’a geçtikten sonra, ödeme bilgileri girildikten sonra “Siparişi Tamamla” butonu tıklanamıyor.
Adımlar:
1. Sepete 2 ürün ekle
2. “Sepete Git” butonuna tıkla
3. “Ödemeye Geç” butonuna tıkla
4. Kart bilgilerini doldur (4111 1111 1111 1111)
5. “Siparişi Tamamla” butonuna tıkla
6. Hiçbir şey olmuyor, loading göstermiyor
Beklenen: Sipariş tamamlanmalı, onay sayfasına yönlendirilmeli
Gerçekleşen: Butona basılıyor ama hiçbir işlem olmuyor
Ortam:
– Cihaz: iPhone 14 Pro
– iOS: 17.2
– Tarayıcı: Safari Mobile
– Tarih: 13.01.2026 14:30
Konsol Hatası:
“Uncaught TypeError: Cannot read property ‘amount’ of undefined”
Ekler: + [console screenshot]
Sonuç: Geliştirici 15 dakikada sorunu anlar.
Son Söz
İyi bir bug report yazmak bir iletişim sanatıdır. Amacınız suçlamak değil, çözmektir.
Net, tekrarlanabilir, tarafsız ve görsellerle desteklenmiş bir rapor hem size hem de geliştirici ekibe zaman kazandırır.
Bir sonraki bug bulduğunuzda, bu rehberi hatırlayın.
Vidius Project olarak yazılım projelerinizi yayına çıkmadan önce detaylı test ediyor ve en kapsamlı raporları hazırlıyoruz.