🐞 Manuel Test Lab

Manuel Test Lab: Bir bug report, bir polis tutanağı gibi — "bir şey ters gitti" demek YETMEZ, BAŞKA BİRİNİN (geliştiricinin) senin görmediğin ekrandan, sadece yazdıklarınla aynı

Bir bug report, bir polis tutanağı gibi — "bir şey ters gitti" demek YETMEZ, BAŞKA BİRİNİN (geliştiricinin) senin görmediğin ekrandan, sadece yazdıklarınla aynı hatayı YENİDEN ÜRETEBİLMESİ gerekir. Şimdi gerçek soru: neden "Giriş çalışmıyor" gibi bir başlık YETERSİZ ama "Boş şifreyle giriş denendiğinde 'Geçersiz email' hatası gösteriliyor" yeterli? Çünkü ilki bir HİS, ikincisi bir TEKRAR ÜRETME TARİFİDİR — adımlar, beklenen sonuç, gerçek sonuç içerir. Bu, kod yazmaktan tamamen farklı bir beceri ister: BELİRSİZLİĞİ ortadan kaldırma disiplini. Bir geliştirici senin raporunu okuyup ekranını AÇMADAN bile "ah, anladım, sorun şu" diyebiliyorsa, o rapor işini yapmıştır.

Manual Testing Lab — Bug Avı

Aşağıdaki giriş formunda kasıtlı olarak en az 5 farklı bug var. Formu farklı girdilerle dene (boş şifre, geçersiz email, "Şifremi Unuttum" linki, Giriş Yap butonuna art arda tıklama gibi), bulduğun her sorun için sağdaki forma yapılandırılmış bir bug report yaz. Sistem raporunu başlık, yeniden üretme adımları, beklenen/gerçek sonuç ve severity seçimine göre otomatik puanlar ve XP verir.

🎬 "Giriş Çalışmıyor" Neden Yetersiz? Bir Bug Report'un Zinciri

Ekranımda Sorun Yok!

Adımlar + Beklenen + Gerçek

Anında Anlaşıldı, Düzeltildi

Bir bug bulduğunda, "bir şey ters gitti" demek YETER mi? Bu filmde bir bug report'un neden bir polis tutanağı GİBİ olması gerektiğini — adım adım, kanıtla — izleyeceğiz.

Adım 1 — tester login formunda bir sorun BULUR ve raporu yazar: "Giriş çalışmıyor." Bu cümle tester'ın kendi ekranında GÖRDÜĞÜ bir HİSSİ anlatır — ama geliştiriciye hiçbir SOMUT bilgi TAŞIMAZ.

Adım 2 (kontrast) — geliştirici raporu okur, KENDİ ekranında login sayfasını açar, normal şifreyle giriş yapar — HER ŞEY ÇALIŞIR. "Ekranımda sorun yok!" der ve raporu "reproduce edilemedi" diye KAPATIR — bug hâlâ oradadır ama GÖRÜNMEZ kalmıştır.

Adım 3 (düzeltme) — tester raporu YENİDEN yazar: "ADIMLAR: 1) Login sayfasını aç, 2) Şifre alanını BOŞ bırak, 3) Giriş Yap'a tıkla. BEKLENEN: 'Şifre gerekli' uyarısı. GERÇEK: sayfa sessizce yeniden yükleniyor, hiçbir uyarı yok."

Adım 4 — geliştirici bu raporu okur ve EKRANI HİÇ AÇMADAN "ah, boş şifre kontrolü eksik" der — çünkü rapor artık bir HİS değil, bir TEKRAR ÜRETME TARİFİ: kesin adımlar, kesin beklenti, kesin gözlem.

Ders — bir bug report yazmak, kod yazmaktan TAMAMEN farklı bir beceridir: BELİRSİZLİĞİ ortadan kaldırma disiplini. Aşağıdaki Manual Testing Lab'da kendi bug report'unu yaz ve sistemin onu nasıl DEĞERLENDİRDİĞİNİ gör.

İyi Bir Bug Report'un Anatomisi