🧪 Test Yönetimi: Xray & Zephyr

Test Yönetimi: Xray & Zephyr: Bir uçağın iki ayrı defteri vardır: arıza kayıtları (ne bozuldu, ne zaman, nasıl giderildi) ve bakım kontrol listeleri (hangi kontrol, hangi uçuştan

Bir uçağın iki ayrı defteri vardır: arıza kayıtları (ne bozuldu, ne zaman, nasıl giderildi) ve bakım kontrol listeleri (hangi kontrol, hangi uçuştan önce, kim tarafından yapıldı). İkisi de zorunludur ve birbirinin yerine geçmez. Jira tek başına birinci defteri tutar; Xray veya Zephyr gibi eklentiler ikincisini ekler. Düşündürücü soru: bug'ları zaten Jira'da tutuyorsun; test senaryolarını da aynı yere issue olarak yazsan ne kaybedersin? Kaybettiğin şey ilişkidir: bir test senaryosunun defalarca KOŞULDUĞUNU, her koşumun ayrı bir sonucu olduğunu ve bu sonucun bir sürüme ait olduğunu düz bir issue listesi ifade edemez. Test tanımı ile test koşumu farklı şeylerdir. Karşılaştır: bir test sınıfı yazarsın ve o sınıf her gece çalışır. Sınıfın kendisi bir kez vardır, koşum kayıtları yüzlercedir. JUnit raporu ile test kaynak kodu arasındaki ayrım neyse, Test issue'su ile Test Execution issue'su arasındaki ayrım da odur. QA açısından asıl kazanç izlenebilirlik matrisidir: bir gereksinimden ona bağlı testlere, testlerden son koşum sonuçlarına, başarısız koşumlardan açılan bug'lara uzanan zincir kurulunca "bu sürümde ne test edildi ve hangi gereksinim hiç doğrulanmadı" sorusu tahminle değil tek bir ekranla cevaplanır.

🧭 Bu Sekmede Ne Öğreneceksin

Jira'nın tek başına niçin test yönetimi yapmadığını; Xray/Zephyr'ın getirdiği yeni issue tiplerini (Test, Test Set, Test Plan, Test Execution, Precondition) ve aralarındaki ilişkiyi; izlenebilirlik matrisini; otomasyon koşum sonuçlarının Jira'ya nasıl aktığını; ve iki aracın karşılaştırmasıyla "hangisi" kararının kriterlerini işleyeceğiz.

🎬 Bir Test Senaryosunun 50 Koşumu: Tanım ile Sonuç Arasındaki Fark

"Bir kupon sipariş başına bir kez uygulanır" senaryosu bir KEZ tanımlanır: TC-42. Ama bu tanım gelecekte ONLARCA kez koşulacak — her sürüm çıkışında, her regresyon paketinde. Bu filmde tanımın koşumlardan nasıl AYRIŞTIĞINI izleyeceksin.

Adım 1 — Build 2026.8.1'de koşulur: PASS. Bu sonuç TC-42'nin KENDİSİNE değil, TC-42'nin build .1'deki bu ÖZEL koşumuna aittir — tanım değişmeden kalır.

Adım 2 — Build 2026.8.2'de AYNI test tanımı tekrar koşulur: FAIL. Tanım hiç değişmedi, sadece koşulduğu ÜRÜN değişti — ve bu koşum SHOP-142 bug'ını doğurur.

Adım 3 — Düzeltme sonrası, AYNI tanım build 2026.8.3'e karşı üçüncü kez koşulur: PASS. Şimdi TC-42'nin geçmişinde ÜÇ ayrı koşum kaydı var: PASS, FAIL, PASS — hepsi aynı tanımın farklı zamanlardaki sonuçları.

Final (kontrast) — Eğer bu bilgi düz bir issue listesinde tutulsaydı, TC-42 için TEK bir kayıt olurdu — son durumu "PASS" gösterirdi ve build .2'deki FAIL tamamen kaybolurdu. Test Execution kayıtları sayesinde "bu senaryo hangi build'lerde kaç kez başarısız oldu" sorusu asla kaybolmaz — bu, izlenebilirlik matrisinin ham malzemesidir.

1️⃣ H1. Bug Takibi ≠ Test Yönetimi

TC-42 üç farklı build'e karşı üç kez koşuldu (PASS, FAIL, PASS) ama bu bilgi düz bir issue listesinde tek bir kayıt olarak tutuluyor. Kaybolan bilgi nedir?

Hiçbir şey kaybolmaz, son durum yeterlidir

Hangi build'de başarısız olduğu ve o başarısızlığın hangi bug'ı doğurduğu bilgisi kaybolur

Test tanımının kendisi kaybolur