🧩 Issue Türleri ve Hiyerarşi

Issue Türleri ve Hiyerarşi: Bir inşaat projesini düşün: kat planı (Epic) bütün bir hedefi tarif eder, her daire (Story) teslim edilebilir bir parçadır, dairenin içindeki tek tek

Bir inşaat projesini düşün: kat planı (Epic) bütün bir hedefi tarif eder, her daire (Story) teslim edilebilir bir parçadır, dairenin içindeki tek tek işler (Sub-task) o parçayı bitiren adımlardır. Bug ise bu hiyerarşinin dışından gelir: teslim edilmiş bir dairede bulunan hasar tespitidir — kendi başına bir iş kalemidir ama daima bir daireye işaret eder. Düşündürücü soru: sonuçta hepsi panoda birer karta dönüşüyorsa, bir işi Story mi Task mı Bug mı açtığın gerçekten önemli mi? Önemi kartta değil, o karttan üretilen sayıda: "bu sprintte 20 bug çıktı" cümlesi, o 20 kartın 12'si aslında unutulmuş bir iş kalemiyse yalan söylüyordur. Karşılaştır: Java'da yanlış tip kullanırsan derleyici seni durdurur. Jira'da yanlış issue tipi seçersen hiçbir uyarı almazsın — bedel derleme anında değil, üç ay sonra kalite raporunda ortaya çıkar. Tip güvenliği burada makinede değil, disiplindedir. QA açısından bunun anlamı şudur: bug ile task arasındaki sınırı takımca yazılı olarak tanımlamak, ölçtüğün her kalite metriğinin ön koşuludur. Tanım yoksa metrik yoktur; metrik yoksa "kalite iyileşiyor mu" sorusunun cevabı da sezgiden ibarettir.

🧭 Bu Sekmede Ne Öğreneceksin

Epic → Story → Task → Sub-task hiyerarşisini ve Bug'ın bu ağaçtaki yerini, bir issue'nun hangi alanlardan (field) oluştuğunu ve bu alanların hangi ekranda (screen) göründüğünü, "bu alan neden bu projede yok" sorusunun cevabını, ve issue link tiplerinin (blocks / is blocked by / duplicates / relates to) sprint planlamasını nasıl etkilediğini işleyeceğiz.

🎬 Bir Epic'in Altında Bug Nasıl Doğar

Epic SHOP-100 — "Ödeme Akışı Yenileme" — büyük bir hedefi tarif ediyor, tek başına teslim edilemez. Bu filmde bu hedefin nasıl küçük parçalara bölündüğünü ve sonunda bir bug'ın nereden doğduğunu izleyeceksin.

Adım 1 — Epic bir Story'ye bölünür: SHOP-118 "Kupon Kodu Uygulama" teslim edilebilir tek bir parçadır. Bir Epic altında onlarca Story olabilir; her biri bağımsız teslim edilir.

Adım 2 — Story, Sub-task'lara bölünür: "kupon alanı UI'ı", "backend indirim hesaplama", "e2e test". Her Sub-task tek bir kişinin bir günde bitirebileceği somut bir iştir.

Adım 3 — Tüm Sub-task'lar biter, Story Done olur, özellik canlıya çıkar. Hiyerarşi burada tamamlanmıştır — Epic → Story → Sub-task zinciri kapanmıştır.

Final (kontrast) — İki hafta sonra Ayşe canlı ortamda kupon indiriminin iki kez düştüğünü fark eder. SHOP-142 açılır — ama bu bug, hiyerarşinin İÇİNDE bir çocuk DEĞİLDİR; hiyerarşinin DIŞINDAN gelip Story'ye bir LINK ile bağlanır ("caused by SHOP-118"). Epic → Story → Sub-task planlanan işi anlatır; Bug ise planlanmamış, keşfedilen bir gerçeği anlatır — ikisi aynı ağaçta yaşamaz.

1️⃣ C1. Hiyerarşi: Epic → Story → Sub-task

Bu hiyerarşiyi Java paket yapısına benzet: Epic bir PAKET gibidir (`com.shopqa.checkout`) — geniş bir hedefi bir arada tutar. Story bir SINIF gibidir (`CouponService`) — tek bir sorumluluğu, tek bir amacı vardır. Sub-task bir METOT gibidir (`applyDiscount()`) — tek bir somut işi yapar. Düşündürücü soru: bu analoji nerede kırılır? Bir Java paketi, birbiriyle hiç ilgisi olmayan sınıfları da barındırabilir (zorunlu bir ilişki yoktur) — ama bir Epic'in altındaki tüm Story'ler AYNI hedefe hizmet etmek ZORUNDADIR. Yani Jira hiyerarşisi paketten daha SIKI bir kısıtlama taşır: gruplama değil, ortak bir amaca bölünmedir. Karşılaştır: bir metodun içinde başka bir metot (iç içe fonksiyon) olabilir ama Java'da sınıfın içinde sınıf sık kullanılmaz; Jira'da da Sub-task'ın altında başka bir Sub-task AÇILAMAZ — hiyerarşi üç seviyeyle sınırlıdır, sonsuz derinlik yoktur. QA açısından bunun anlamı: bir işi yanlış seviyeye koymak (örneğin bir Sub-task'ı Story gibi açmak) yalnızca görsel bir düzensizlik değildir — raporlama araçları seviyeye göre toplam alır, yanlış seviye o toplamı bozar.

Adım Adım: Bir Hedef Nasıl Teslim Edilebilir Parçalara Bölünür?

"Ödeme Akışı Yenileme" — tek başına test edilemeyecek, haftalarca sürecek bir hedef. Bir sprint'e sığmaz.

Story: teslim edilebilir dilim