Test senaryoları

Test senaryosu aşamasında yapay zekâ (AI), ürün sahibinin onayladığı story’den yapılandırılmış test senaryosu (test case) taslakları hazırlar; analist her birini inceler ve yalnızca onaylı, değişmemiş case’ler Jira’ya veya Xray’e yayınlanır. Her case kapsadığı kabul kriterlerine bağlıdır ve platform hâlâ kapsanmayan kriterleri gösterir.

Üretim ne zaman başlayabilir (Demoda gösterilir)

Test case üretimi ancak gereksinim ön incelemesi kapısı geçildikten sonra açılır. Somut olarak:

• Story’nin güncel bir ürün sahibi onayı vardır. Metin onaydan sonra değiştiyse, ürün sahibi yeniden onaylayana kadar üretim engellenir.
• Üretimi analist rolü gereksinim detay sayfasından başlatır.

Model; onaylı story metnini, kabul kriterlerini, ürün sahibinin inceleme sorularına verdiği cevapları ve uygulamanın test için sağladığı test verisini alır. Bunların hepsi etiketli bloklarda, güvenilmeyen veri olarak iletilir.

STORY-142 Sipariş iptali için girdi şunlar olur: düzeltilmiş açıklama, AC1–AC4, ürün sahibinin iptal süresinin 12 saat olduğuna dair cevabı ve farklı durumlarda (verildi, ödendi, paketlendi, kargoya verildi) siparişleri olan test hesapları.

Test case üretimi için canlı model değerlendirmesi beklemektedir. Güncel etiket Yetenekler sayfasındadır.

Üretilen bir case neleri içerir

Her case sabit bir JSON şemasına uyar; böylece her taslak aynı yapıdadır.

Alan	İçerik
Başlık	Kısa bir ad
Tür	positive, negative ya da boundary (pozitif, negatif, sınır)
Risk	Case’in ele aldığı risk
Kabul kriterleri	Story’de var olan kriterlere referanslar
Adımlar	En fazla sekiz adım; her birinde eylem, isteğe bağlı veri ve beklenen sonuç
Beklenen sonuç	Genel sonuç
Etiketler	Her zaman AI-generated içerir

Şemaya uymayan çıktı reddedilir. Model doğrulama hatasıyla sınırlı sayıda yeniden istenir; sonrasında sorun bir insana düşer. Bir case story’de olmayan bir kabul kriterine atıf yaparsa doğrulamadan geçemez.

STORY-142 için bir taslak seti şunları içerebilir: “Ödenmiş sipariş süre içinde iptal edilebilir” (pozitif, AC1), “Kargoya verilmiş siparişte İptal yerine İade talep et görünür” (negatif, AC4) ve “Sürenin tam bitiminde iptal” (sınır, AC1). Platform hiçbir case’in kapsamadığı kabul kriterlerini de listeler.

Case’leri incelemek

Analist her taslağı inceler. Her case için üç karar vardır:

• Case’i yazıldığı gibi onaylamak.
• Case’i düzeltip sonra onaylamak. Platform yapay zekâ taslağıyla onaylanan sürüm arasındaki alan bazlı farkı kaydeder.
• Case’i bir gerekçeyle reddetmek.

Her karar, case’in içerik hash’ine bağlı ve kayda geçen bir insan eylemidir. Onaylı bir case sonradan yeniden açılıp düzenlenirse taslağa döner; eski onayına dayanarak yayınlanamaz ya da kod üretiminde kullanılamaz.

Platform incelemeyi yapıldığı anda ölçer: ilk karardaki kabul, ret nedenleri, düzeltme büyüklüğü ve inceleme süresi. Bu değerler kaynak tablolarıyla birlikte Kontrol Kulesi’nde görünür. REPLAY kipinde ölçülecek model süresi olmadığından “yapay zekâ artı inceleme” süresi yalnızca inceleme süresidir; arayüz bunu açıkça yazar.

Jira’ya veya Xray’e yayın

Yayın, onaylı case’leri test yönetim aracınıza yazar. Her zaman bir yayın önizlemesiyle başlar: hiçbir şey yazmadan her case için yapılacak işlemi (örneğin oluşturma) listeleyen bir kuru çalışma.

Bir case ancak üç koşulun üçü de sağlanırsa yayınlanır:

1. Durumu onaylıdır.
2. Güncel içerik hash’i onaylanan hash’e eşittir.
3. Story’nin ürün sahibi onayı hâlâ günceldir.

İki hedef desteklenir:

• Jira Test kayıtları: Her case bir Test kaydı olur; adımlar açıklamada bir tabloda durur.
• Xray Cloud: Her case yapılandırılmış adımları olan manuel bir Xray testi olur.

İki durumda da test, story’ye varsa Test bağlantı türüyle, yoksa Relates ile bağlanır. Story’ye yazılan bir yorum, yayını denetim zinciri hash’iyle birlikte kaydeder.

İdempotentlik ve kısmi hatalar

Yayın, tekrarlanması güvenli olacak biçimde tasarlanmıştır.

• Her case bir dış referans taşır. Aynı case’i iki kez yayınlamak ikinci bir kayıt açmaz, mevcut kaydı bulur.
• Bazı case’ler başarısız olursa (örneğin Jira kısa süre erişilemezse) sonuç hangilerinin başarılı olduğunu, hangilerinin olmadığını raporlar. Seçilenleri yayınla eylemini yeniden çalıştırmak kalanları mükerrer kayıt açmadan tamamlar.
• Jira Cloud arama dizini, bir kayıt açıldıktan sonra birkaç saniye geride kalabilir. Platform kendi önceki yazımlarını tespit etmek için aramaya güvenmez.

Kayıt türü ve bağlantı türleri Jira yapılandırmanıza bağlıdır. Xray kurulu bir projede Test kayıt türü Xray’e aittir. Böyle bir projede iki hedef de kullanılabilir, ama sonuçlar Xray’de farklı görünür. Ayrıntılar için Entegrasyon kurulumu sayfasına bakın.

Case’leri IDE’den hazırlamak (Demoda gösterilir)

Zaten bir yapay zekâ kodlama asistanıyla çalışan ekipler case taslaklarını orada hazırlayıp aynı kapıları kullanmaya devam edebilir. Platform üç araçlı bir MCP uç noktası sunar:

• get_requirement, ürün sahibinin onayladığı metni, kabul kriterlerini ve test verisini onaylanan içerik hash’iyle birlikte döndürür.
• submit_draft_cases, gereksinime taslak ekler. Taslaklar aynı şemaya uymalıdır. Story get_requirement çağrısından sonra değiştiyse gönderim reddedilir. Bir case geçersizse hiçbiri kaydedilmez.
• publish_test_cases, portaldakiyle aynı yayın işini aynı kontrollerle çalıştırır.

Analist bu kanal için portalda kısa ömürlü, tek kapsamlı bir API token’ı oluşturur. Token’larla onay verilemez. IDE’den gönderilen taslaklar portalda diğer taslaklar gibi görünür ve onayı orada bir insan verir. Her araç çağrısı çağıranla birlikte kaydedilir.

Mevcut manuel test case’ler (Yol haritası)

Birçok ekibin Jira’da, Xray’de ya da başka araçlarda zaten büyük manuel test case kütüphaneleri vardır. Bu case’leri içe aktarmak ve üretimde öğrenen bir kütüphane olarak kullanmak yol haritasındadır. Tarih pilot talebiyle belirlenir.

Bugün platform story’lerden yeni case’ler üretir. Mevcut case’ler oldukları yerde kalır ve ekibiniz incelemede onlara başvurabilir. TestRail ya da Zephyr gibi diğer test yönetim araçları için bağlayıcılar bugün mevcut değildir.

Mevcut case’leri içe aktarmak sizin için bir gereksinimse, pilot koşulu olarak kapsamlanabilmesi için bunu pilot görüşmesinde dile getirin.