QA Süreci: Test ve Hata Düzeltmelerini Tek Akışta Topla

QA Süreci: Test ve Hata Düzeltmelerini Tek Akışta Topla

QA test etti, bug buldu, Slack'e yazdı. Geliştirici gördü mü? Belki. Düzeltti mi? Bilinmiyor. QA tekrar test etti mi? Belirsiz. Canlıya çıktı mı? Umarız düzelmiş.

Bu senaryo abartı değil. QA ile geliştirici arasındaki iletişim çoğu startup'ta mesajlaşma üzerinden yürüyor. Slack mesajı, e-posta, hatta ekran görüntüsü WhatsApp'a atılıyor. Hangi bug'ın düzeltildiği, hangisinin beklemede olduğu, hangisinin "sonraki versiyona bırakıldığı" takip edilemiyor.

Sonuç: aynı bug iki kez raporlanıyor, düzeltilen bug tekrar test edilmiyor, canlıya çıkmadan önce neyin hazır olduğu belli değil.

QA-Dev İletişiminde Kopukluk Nereden Geliyor?

QA ve geliştirici arasındaki kopukluğun üç temel kaynağı var.

Test çıktısı yapılandırılmamış. "Şurada bir sorun var" mesajı teknik olarak yetersiz. Hangi ortamda test edildi, hangi adımlarla üretildi, beklenen davranış ne, gerçekleşen ne — bunlar yazılmadan geliştirici ne düzelteceğini tam olarak bilmiyor.

Bug durumu görünmüyor. Bug raporlandı ama sonra ne oldu? Geliştirici aldı mı, önceliğe koydu mu, düzeltti mi, PR açtı mı? Bu bilgi mesajlaşma kanalına gömüldüğünde QA sürekli "bu düzeldi mi?" diye sormak zorunda kalıyor.

Kapanış döngüsü yok. Geliştirici "düzelttim" diyor. QA tekrar test etmesi gerektiğini biliyor mu? Hangi ortamda, hangi versiyonda test edecek? Bu koordinasyon her bug için yeniden kuruluyorsa ciddi zaman kaybı oluyor.

Alios'ta QA Akışı: İki Katmanlı Model

Alios'ta QA süreci test yönetimi iki katmanlı çalışıyor: test checklist ve bug listesi. İkisi ayrı node yapıları ama birbirine bağlı.

Katman 1 — Test Checklist Node'u

Her release veya feature için bir test checklist node'u açılıyor. Bu node QA'nın çalışma belgesi.

📁 TEST — [Feature/Release adı] — [Tarih]
Sorumlu: [QA adı]
Deadline: [Test tamamlanma tarihi]
Ortam: [Staging URL veya versiyon]

📋 TEST SENARYOLARI

Mutlu Yol (Happy Path):
- [ ] [Senaryo 1 — adım adım]
- [ ] [Senaryo 2 — adım adım]
- [ ] [Senaryo 3 — adım adım]

Kenar Durumlar (Edge Cases):
- [ ] [Boş input senaryosu]
- [ ] [Maksimum değer senaryosu]
- [ ] [Eş zamanlı işlem senaryosu]

Hata Durumları:
- [ ] [Hata senaryosu 1 — beklenen mesaj/davranış]
- [ ] [Hata senaryosu 2 — beklenen mesaj/davranış]

Regresyon:
- [ ] [Bu değişiklikten etkilenebilecek mevcut özellik 1]
- [ ] [Bu değişiklikten etkilenebilecek mevcut özellik 2]

Cihaz / Tarayıcı:
- [ ] Chrome — masaüstü
- [ ] Safari — masaüstü
- [ ] Chrome — mobil (Android)
- [ ] Safari — mobil (iOS)

📊 TEST SONUCU
Başlangıç: [Tarih]
Tamamlanma: [Tarih]
Toplam senaryo: [N]
Geçti: [N] | Başarısız: [N] | Bloke: [N]

Genel değerlendirme:
[ ] Canlıya çıkmaya hazır
[ ] Kritik bug var — canlıya çıkılamaz
[ ] Minor bug var — kabul edilebilir / sonraki versiyona

Katman 2 — Bug Node'ları

Test sırasında bulunan her bug ayrı bir node olarak açılıyor. Test checklist node'una bağlanıyor.

📌 BUG — [Kısa tanım]
Durum: Raporlandı
Öncelik: [Kritik / Yüksek / Orta / Düşük]
Sorumlu: [Geliştirici adı]
Deadline: [Fix beklenen tarih]
Bağlantılı test: [Test checklist node adı]

🔍 BUG DETAYI

Ortam: [Staging / Production — URL — versiyon]
Tarayıcı/Cihaz: [Chrome 122 / iPhone 14 vb.]
Hesap tipi: [Admin / Normal kullanıcı / vb.]

Üretme adımları:
1. [Adım 1]
2. [Adım 2]
3. [Adım 3]

Beklenen davranış:
[Ne olması gerekiyordu]

Gerçekleşen davranış:
[Ne oldu]

Ekran görüntüsü / Video: [Link veya ek]
Console hatası: [Varsa kopyala]

🔧 GELİŞTİRİCİ NOTU
[Geliştirici ne buldu, nasıl düzeltti, PR linki]
PR: [Link]
Fix versiyonu: [Branch veya tag]

✅ QA DOĞRULAMA
[ ] Fix staging'de test edildi
[ ] Senaryo tekrar üretilemedi
[ ] Regresyon kontrolü yapıldı
[ ] Node kapatıldı: [Tarih]

Bug Durumları: Beş Aşama

Bug node'u beş aşamadan birinde yaşıyor:

🔴 Raporlandı → QA buldu, geliştirici henüz almadı
🟡 İnceleniyor → Geliştirici aldı, analiz ediyor
🔵 Düzeltiliyor → Aktif geliştirme
🟣 Fix Hazır → PR merge edildi, QA testi bekliyor
✅ Doğrulandı → QA onayladı, node kapandı
⏸ Ertelendi → Bu versiyonda fix yok, sonraya bırakıldı

Her durum değişikliğinde açıklamaya kısa not: "PR #67 açıldı", "staging'de deploy edildi, test edilebilir", "bu versiyonda düzeltilmeyecek — sebep: kapsam dışı."

Bu notlar QA'nın "bu düzeldi mi?" sorusunu sormadan cevabı bulmasını sağlıyor.

Kapanış Kriterleri

Bug Kapanışı İçin

Bir bug node'u şu koşullar sağlandığında kapanıyor:

✅ Fix staging'de deploy edildi
✅ QA aynı adımlarla bug'ı tekrar üretemedi
✅ İlgili regresyon senaryoları geçti
✅ Geliştirici PR linkini node'a ekledi
✅ QA doğrulama bölümünü doldurdu ve node'u kapattı

Önemli: bug'ı geliştirici kapatmıyor. QA kapatıyor. Bu ayrım "düzelttim" ile "doğrulandı" arasındaki farkı netleştiriyor.

Release Kapanışı İçin

Test checklist node'u şu koşullar sağlandığında kapanıyor:

✅ Tüm test senaryoları çalıştırıldı
✅ Kritik ve yüksek öncelikli bug'ların tamamı "Doğrulandı"
✅ Ertelenen bug'ların listesi ve gerekçesi yazıldı
✅ "Canlıya çıkmaya hazır" onayı verildi
✅ Test özeti node açıklamasına işlendi

"Kritik bug yoksa çıkılabilir" kararı ekibin vereceği bir kriter. Ama bu kriterin önceden yazılı olması gerekiyor — canlıya çıkış günü tartışılmamalı.

Haftalık QA Rutini

QA sürecini sürdürülebilir kılmak için haftalık rutin:

⏱️ PAZARTESİ — Sprint başı (15 dakika)
→ Bu sprint'te test edilecek feature'lar belirlendi
→ Her feature için test checklist node'u açıldı
→ Test senaryoları taslak olarak yazıldı

⏱️ HAFTA İÇİ — Test süreci
→ Her bulunan bug ayrı node olarak açıldı
→ Düzeltilen bug'lar "Fix Hazır" durumuna geçince test edildi
→ Node durumları güncel tutuldu

⏱️ CUMA — Sprint kapanışı (20 dakika)
→ Açık bug'ların durumu gözden geçirildi
→ Ertelenen bug'lar belgelendi
→ Test checklist node'u kapatıldı veya sonraki sprint'e taşındı
→ Release kararı verildi

Son Düşünce

QA süreci test yönetimi mesajlaşmadan çıktığında hem QA hem geliştirici kazanıyor. QA "bu düzeldi mi?" diye sormak zorunda kalmıyor — bug node'una bakıyor. Geliştirici hangi bug'ın öncelikli olduğunu biliyor — node'da yazıyor. Release kararı tartışma değil, checklist kontrolü oluyor.

Alios'ta test checklist ve bug node'larını birlikte kullanmak bu görünürlüğü kuruyor. Slack'teki "şurada bir sorun var" mesajı yapılandırılmış bir node'a dönüşüyor. Kapanış kriterleri belirsizliği ortadan kaldırıyor.

Daha az "bu düzeldi mi?", daha az tekrar test, daha güvenli release.