Bug ve Issue Takibi: Alios'ta Pratik Model ve Şablon

Bug ve Issue Takibi: Alios'ta Pratik Model ve Şablon

Müşteri bir bug raporluyor. Slack'e yazıyor. Geliştirici görüyor, emoji koyuyor. Bir sonraki sprint planlamasında kimse o mesajı hatırlamıyor. Müşteri iki hafta sonra tekrar yazıyor: "Bu hâlâ düzelmedi."

Ya da içeriden: QA bir sorun buluyor, ekran görüntüsü atıyor. Geliştirici "bakacağım" diyor. Başka bir şey çıkıyor, bug unutuluyor. Canlıda durmaya devam ediyor.

Bug takibinin çalışmaması teknik ekibin dikkatsizliğinden gelmiyor. Bug'ların yaşadığı yerin iş takip sisteminden ayrı olmasından geliyor.

Bug'lar Neden Chat'te Kayboluyor?

Bug raporlama için standart bir yer olmadığında her kişi en kolay erişebildiği kanalı kullanıyor: Slack mesajı, e-posta, WhatsApp, hatta sözlü. Bu kanalların ortak sorunu: bilgi gömülüyor, takip edilemiyor, önceliklendirilemiyor.

Öncelik belli değil. "Şurada bir sorun var" mesajı kritik bir güvenlik açığı da olabilir, küçük bir UI hatası da. Öncelik yazılmadan her bug aynı aciliyette görünüyor ya da tam tersi, hiçbiri acil görünmüyor.

Repro adımları yok. Geliştirici bug'ı teslim almadan önce nasıl üreteceğini bilmesi gerekiyor. "Ödeme yaparken hata çıktı" bir repro değil. Hangi adımlar, hangi ortam, hangi hesap türü — bunlar olmadan geliştirici zaman harcıyor ama bug'ı bulamıyor.

Durum görünmüyor. Bug raporlandı, sonra ne oldu? Alındı mı, inceleniyor mu, düzeldi mi, ertelendi mi? Bu bilgi mesajlaşma kanalına gömüldüğünde hem raporlayan hem de takip eden karanlıkta kalıyor.

Tekrar raporlanıyor. Aynı bug farklı kişiler tarafından birden fazla kez raporlanıyor. Her seferinde yeni Slack mesajı, yeni "bakacağım," yeni unutma.

Alios'ta Bug Takip Akışı

Alios'ta bug ve issue takibi şu yapıyla kuruluyor: her bug ayrı bir node, standart şablon, net durum akışı.

Bug Node Şablonu

Her bug node'u açılırken şu şablon doldruluyor. Şablon ne kadar eksiksiz doldurulursa geliştirici o kadar hızlı çözüme ulaşıyor.

📌 BUG — [Kısa, net başlık]
Durum: Raporlandı
Öncelik: [Kritik / Yüksek / Orta / Düşük]
Sorumlu: [Geliştirici adı — atanmamışsa boş]
Deadline: [Fix beklenen tarih — varsa]
Raporlayan: [İsim] — Tarih: [Tarih]

🔍 BUG DETAYI

Ortam:
- Platform: [Web / iOS / Android]
- Tarayıcı/Versiyon: [Chrome 122 / Safari 17 vb.]
- Cihaz: [MacBook / iPhone 14 / vb.]
- Hesap türü: [Admin / Normal kullanıcı / Trial vb.]
- URL: [Bug'ın görüldüğü sayfa]

Repro adımları:
1. [İlk adım — mümkün olduğunca spesifik]
2. [İkinci adım]
3. [Üçüncü adım]
4. [Bug'ın tetiklendiği adım]

Beklenen davranış:
[Ne olması gerekiyordu]

Gerçekleşen davranış:
[Ne oldu — ekran görüntüsü veya video varsa ek]

Üretme sıklığı:
[ ] Her zaman üretiliyor
[ ] Ara sıra üretiliyor — yaklaşık: [%N]
[ ] Bir kez gözlemlendi, tekrarlanamadı

Ekler:
- Ekran görüntüsü: [Link veya dosya]
- Video: [Link]
- Console hatası: [Kopyalanmış hata mesajı]
- Log: [Varsa ilgili log satırları]

✅ KABUL KRİTERİ

Fix tamamlandı sayılmak için:
- [ ] [Repro adımları takip edildiğinde bug artık üretilemiyor]
- [ ] [Beklenen davranış gerçekleşiyor — spesifik]
- [ ] [Edge case: X durumunda da düzgün çalışıyor]
- [ ] [Regresyon: Etkilenebilecek Y özelliği hâlâ çalışıyor]

🔧 GELİŞTİRİCİ NOTU
[Geliştirici ne buldu, root cause ne, nasıl düzeltti]
PR: [Link]
Fix versiyonu: [Branch / Tag / Commit]

🧪 QA DOĞRULAMA
[ ] Fix staging'de test edildi
[ ] Repro adımları tekrar denendi — bug üretilemiyor
[ ] Kabul kriterleri karşılandı
[ ] Regresyon kontrolü yapıldı
Doğrulayan: [İsim] — Tarih: [Tarih]

Bug Durum Akışı

Her bug node'u altı durumdan birinde yaşıyor:

🔴 Raporlandı
→ Bug kayıt altına alındı, henüz kimse almadı

🟡 İnceleniyor
→ Geliştirici aldı, repro deniyor veya root cause araştırılıyor

🔵 Düzeltiliyor
→ Root cause bulundu, fix aktif geliştiriliyor

🟣 Fix Hazır
→ PR açıldı veya merge edildi, QA testi bekleniyor

✅ Doğrulandı
→ QA onayladı, kabul kriterleri karşılandı, kapatıldı

⏸ Ertelendi
→ Bu versiyonda düzeltilmeyecek, sebep açıklamada yazıyor

Her durum değişikliğinde açıklamaya tek satır not:

[Tarih] Raporlandı → İnceleniyor: Ali aldı, repro deneniyor
[Tarih] İnceleniyor → Düzeltiliyor: Root cause bulundu —
auth token yenilenmeden önce race condition var
[Tarih] Düzeltiliyor → Fix Hazır: PR #53 açıldı,
staging'e deploy edildi
[Tarih] Fix Hazır → Doğrulandı: Zeynep onayladı,
canlıya alındı

Bu notlar "bu düzeldi mi?" sorusunu sormadan cevaplayabiliyor.

Önceliklendirme: Hangi Bug Ne Zaman?

Her bug aynı aciliyette değil. Dört öncelik seviyesi:

Kritik — Aynı gün

Tanım: Sistemin çalışmasını durduruyor veya
veri kaybına yol açıyor. Geçici çözüm yok.

Örnekler:
- Ödeme işlemi tamamlanamıyor
- Kullanıcılar sisteme giremiyor
- Veri kaybı veya bozulması
- Güvenlik açığı

Beklenti: Bulunduğu gün sprint'e alınır,
aynı gün veya ertesi gün fix hazır.

Yüksek — Bu sprint

Tanım: Temel özellik çalışmıyor ama geçici
çözüm var. Kullanıcı deneyimini ciddi etkiliyor.

Örnekler:
- Önemli bir form submit olmuyor
- Bildirimler gitmiyor
- Export özelliği hata veriyor

Beklenti: Mevcut sprint'te fix.

Orta — Önümüzdeki sprint

Tanım: Özellik çalışıyor ama yanlış veya
eksik. Kullanıcı ilerleyebiliyor.

Örnekler:
- Yanlış hesaplama gösteriliyor
- Filtre beklendiği gibi çalışmıyor
- Yükleme süresi beklenmedik yavaş

Beklenti: Backlog'a alındı, önümüzdeki
sprint planlamasında değerlendirilir.

Düşük — Backlog

Tanım: Kozmetik sorun veya edge case.
Kullanıcıyı engellemez.

Örnekler:
- Hizalama bozukluğu
- Yazım hatası
- Nadiren tetiklenen UI sorunu

Beklenti: Backlog'da bekler, sprint
dolduğunda alınır.

Tekrar Raporlanan Bug'lar

Aynı bug birden fazla kez raporlandığında yeni node açılmıyor. Mevcut node'a kaynak ekleniyor:

📋 TEKRAR RAPORLAMA

[Tarih] — [İsim] — [Kanal]: [Kısa not]
[Tarih] — Müşteri A — Destek talebi: Aynı hata
[Tarih] — Müşteri B — Chat: Onayladı
Toplam raporlama: 3

Bu birikim önceliklendirmeyi veriyle destekliyor. "Bu bug kaç kişiyi etkiliyor?" sorusu node'a bakılarak cevaplanıyor.

Haftalık Bug Review Rutini

⏱️ PAZARTESİ — 15 DAKİKA

1. "Raporlandı" durumundaki node'ları gözden geçir
   → Öncelik doğru mu?
   → Atanacak geliştirici var mı?

2. "İnceleniyor" veya "Düzeltiliyor" node'larını kontrol et
   → 3 günden uzun süredir hareket yok mu?
   → Bloke olan var mı?

3. "Fix Hazır" node'larını kontrol et
   → QA testi yapıldı mı?
   → Bekleyen doğrulama varsa bugün tamamlanabilir mi?

4. Ertelenen bug'ları gözden geçir
   → Koşullar değişti mi, şimdi önceliği yükselmeli mi?

Bu rutin 15 dakika alıyor ama bug listesinin kontrolden çıkmasını önlüyor.

Son Düşünce

Bug ve issue takibi mesajlaşma kanallarından çıkıp iş takip sistemine girdiğinde iki şey oluyor: bug kaybolmuyor ve önceliklendirme mümkün hale geliyor.

Alios'ta her bug için node açmak, repro adımlarını ve kabul kriterlerini doldurmak, durum akışını güncel tutmak — bu üç alışkanlık "bu düzeldi mi?" sorusunu ortadan kaldırıyor.

Müşteri ikinci kez aynı bug'ı raporlamıyor. Çünkü ilk raporlandığında kayıt altına alındı, önceliklendirildi, takip edildi ve kapandı.