🔄 Workflow ve Durumlar

Workflow ve Durumlar: Bir workflow, havalimanındaki kapılar dizisine benzer: check-in, güvenlik, pasaport, kapı.

Bir workflow, havalimanındaki kapılar dizisine benzer: check-in, güvenlik, pasaport, kapı. Her kapıdan geçmek bir izin gerektirir ve sıra atlanamaz — pasaport kontrolünden geçmeden uçağa binemezsin. Jira'da her durum (status) bir bekleme salonu, her geçiş (transition) bir kapıdır; kapının kimin için açıldığı ise izinlerle belirlenir. Düşündürücü soru: bir bug'ı "Done" yapmak neden tek bir tuş değil? Çünkü "bitti" cümlesi tek başına anlamsızdır: kod yazıldı mı, gözden geçirildi mi, staging'e çıktı mı, DOĞRULANDI mı? Workflow bu soruların cevabını kayıt altına alan bir sözleşmedir. Karşılaştır: bir enum ile durum makinesi yazdığında geçersiz geçişleri kodla engellersin. Jira'da bu engel derleme zamanında değil, workflow tanımında yaşar — geçiş koşulu (condition) koymadıysan yanlış geçiş serbesttir ve kimse uyarmaz. QA açısından kritik nokta resolution alanıdır: bir kayıt "Done" durumuna geçtiğinde resolution yanlış (ya da boş) bırakılırsa, o bug raporlarda ya hiç görünmez ya da hâlâ açık sayılır. Yani yanlış tek bir alan, bütün kalite panonu sessizce yanıltır.

🧭 Bu Sekmede Ne Öğreneceksin

Status, transition ve resolution üçlüsünün farkını; tipik bir bug workflow'unu ve QA'in bu akıştaki yerini (Ready for QA → In QA → Done ya da Reopened); "Done" tanımının takımca yazılı olması gerektiğini; geçişlere konan koşulların (condition) neden bazen senin butonunu görünmez yaptığını; ve belirli geçişlerde çalışan otomasyon kurallarının hangi işleri devraldığını işleyeceğiz.

🎬 Bir Bug'ın Reopened'a Düşüşü

SHOP-142 "In Progress" durumunda — Mert kupon hesaplama fonksiyonunu düzeltiyor. Bu filmde kaydın kapıdan kapıya nasıl ilerlediğini ve bir kapının nasıl geri döndürdüğünü izleyeceksin.

Adım 1 — Mert kodu bitirir ve "Ready for QA" geçişini tetikler. Bu geçişte bir koşul (condition) vardır: kod review onayı olmadan bu buton hiç görünmez. Onay var, geçiş açılır.

Adım 2 — Ayşe kaydı "In QA"ya alır ve staging'de kupon senaryosunu koşar. Yüzde bazlı tekli kupon doğru çalışıyor — ama Ayşe ikinci bir senaryo daha dener: kupon + üye indirimi aynı anda.

Adım 3 — İkinci senaryoda hata hâlâ var: iki indirim üst üste bindiğinde tutar yine yanlış hesaplanıyor. Ayşe kaydı "Reopened"a taşır ve YENİ bir tekrar üretim adımı ekler — orijinal rapor eksik değildi, kapsam genişledi.

Final (kontrast) — Mert ikinci düzeltmeyi yazar, bu sefer resolution alanını yalnızca Ayşe DOĞRULADIKTAN sonra "Fixed" olarak set eder — kendi geçişinde BOŞ bırakır. Eğer Mert resolution'ı erkenden "Fixed" yazsaydı, kayıt Reopened'a düşse bile bazı raporlar onu hâlâ "çözülmüş" sayardı — resolution'ın NE ZAMAN set edildiği, DONE kadar önemlidir.

1️⃣ E1. Status, Transition ve Resolution Üçlüsü

Bu üçlüyü bir trafik ışığı sistemine benzet: status IŞIĞIN RENGİDİR (şu anki durum — kırmızı/sarı/yeşil), transition IŞIĞIN DEĞİŞMESİDİR (kırmızıdan yeşile geçiş, bir olay), resolution ise KAVŞAĞIN KAMERA KAYDIDIR (bu geçiş neden oldu, hangi sebeple — arıza mı, planlı bakım mı). Üçü de farklı bir soruya cevap verir. Düşündürücü soru: neden "Done" tek başına yeterli değil de ayrıca bir resolution alanına ihtiyaç var? Çünkü aynı "Done" durumuna FARKLI SEBEPLERLE ulaşılabilir — gerçekten düzeltildi mi (Fixed), aslında bir kopya mıydı (Duplicate), yoksa hiç tekrar üretilemedi mi (Cannot Reproduce)? Status "nerede olduğunu", resolution "NEDEN orada olduğunu" anlatır. Karşılaştır: Java'da bir metodun dönüş DEĞERİ (status'e benzer — hangi sonuca ulaşıldı) ile fırlattığı EXCEPTION TİPİ (resolution'a benzer — bu sonuca hangi sebeple ulaşıldı) farklı bilgiler taşır; ikisini tek bir alana sıkıştırmak bilgi kaybettirir. QA açısından pratik sonuç: bir raporlama sorgusu yalnızca status'e ("= Done") bakarsa, gerçekten düzeltilmiş bug'larla "cannot reproduce" ile kapatılmış bug'ları AYIRT EDEMEZ — resolution'a bakması gerekir.

Bir kalite raporu "bu ay kaç bug DÜZELTİLDİ" sorusunu `status = Done` sorgusuyla cevaplıyor. Bu sorgunun hatası nedir?

Hiçbir hatası yok, status = Done yeterlidir

Done durumuna Duplicate veya Cannot Reproduce sebebiyle de ulaşılabilir; resolution'a bakılmadan gerçekten düzeltilenler AYIRT EDİLEMEZ