Kavramlar

AI Testing Probe, bu dokümantasyonun her sayfasında karşınıza çıkan birkaç fikir üzerine kuruludur. Onay Kapıları her yapay zekâ (AI) adımından sonra bir insan kararı koyar, kanıtlı bulgular yapay zekânın iddialarını denetlenebilir kılar, denetim kaydı da kimin neye karar verdiğini tutar. Bu sayfa her terimi bir kez tanımlar.

Onay Kapıları

Onay Kapısı (Approval Gate), akışta bir yapay zekâ taslağının insan kararını beklediği noktadır. Kapı geçilmeden hiçbir şey sonraki aşamaya geçmez; Jira’ya, Xray’e ya da ana dala hiçbir şey yazılmaz.

Akıştaki Onay Kapıları (Approval Gates) şunlardır:

• Bulgu kararları: Analist her ön inceleme bulgusu için dokümanın mı, kodun mu yanlış olduğuna karar verir.
• Ürün sahibi onayı: Ürün sahibi (PO) düzeltilmiş story’yi Jira’da onaylar.
• Test case incelemesi: Analist yayından önce yapay zekânın hazırladığı her test senaryosunu (test case) onaylar, düzeltir ya da reddeder.
• PR incelemesi ve merge: Mühendis üretilen kodu inceler ve korumalı dal üzerinden merge eder.
• Zayıf test kabulü: Kırarak Doğrula, testin bir hatayı yakaladığını gösteremezse merge açık ve kayda geçen bir kabul ister.
• Bug taslağı kararı: Testçi yeni kayıt açar, mevcut kayda bağlar, taslağı düzeltir ya da reddeder.
• Onarım PR’ı merge’ü: Her locator onarımını bir insan merge eder.

Onaylar bir içerik hash’ine bağlıdır. Onaydan sonra içerik değişirse onay geçersizleşir ve öğe yeniden incelenmelidir. API token’larıyla taslak gönderilebilir, ama onay verilemez.

Yapay zekâ, insan ve sistem adımları

Akıştaki her adımı üç aktörden biri yapar. Arayüz her adımı yalnızca renkle değil, ikon ve metinle etiketler.

• Yapay zekâ adımları taslak üretir: ön inceleme bulguları, tutarlılık bulguları, test case’ler, adım–page object eşlemeleri, kuralların karar veremediği hata sınıflamaları, bug taslakları ve mükerrer aday sıralamaları.
• İnsan adımları karardır: onaylamak, düzeltmek, reddetmek, merge etmek ve kayıt açmak.
• Sistem adımları deterministiktir: Jira’yı okumak, kanıtı yeniden doğrulamak, derleyici ve linter’ları çalıştırmak, AST koruması, test koşuları, Kırarak Doğrula, kural tabanlı triage ve locator onarım önerileri.

Herhangi bir ekranı okumanın iyi yolu, her öğeyi bu üçünden hangisinin ürettiğini sormaktır. Yapay zekâ çıktısı, bir insan adımı durumunu değiştirene kadar her zaman taslak olarak işaretlidir. Deterministik bir kural karar verebiliyorsa, karar modele bırakılmaz. Örneğin triage önce kuralları uygular; model yalnızca hiçbir kural eşleşmezse çağrılır.

Kullanıcı rolleri

Platformda rol tabanlı erişim denetimiyle uygulanan beş portal rolü vardır.

Rol	Başlıca sorumluluklar
Analist	Gereksinimleri çeker, bulgulara karar verir, test case üretir ve inceler, yayınlar; MCP kanalı için API token’ı oluşturur
Ürün sahibi	Düzeltilmiş gereksinimi onaylar. Jira story’lerinde onay Jira’da, serbest metin gereksinimlerde portalda verilir
Mühendis	Kod üretir, Kırarak Doğrula’yı çalıştırır, PR’ları inceler ve merge eder, onarım PR’larını açar ve merge eder
Testçi	Bug taslaklarına karar verir: yeni kayıt, mevcut kayda bağlama, düzeltme ya da ret
Yönetici	Deploy ve gece koşularını tetikler, Kontrol Kulesi’ni ve raporları izler

Her rol yalnızca yapmaya yetkili olduğu eylemleri görür. Bir kişi birden fazla role sahip olabilir, ama her karar onu veren kişi ve rol adına kaydedilir.

Kanıtlı bulgu

Kanıtlı bulgu (evidence-backed finding), platformun model kullanmadan denetleyebileceği bir kanıtla gelen yapay zekâ iddiasıdır. Örneğin tutarlılık denetiminde “kod story ile uyuşmuyor” diyen bir bulgu, repodaki bir dosya ve satırı ya da salt okunur bir veritabanı sorgusunun sonucunu göstermek zorundadır.

Bulgu gösterilmeden önce platform kanıtı deterministik olarak yeniden doğrular. Gösterilen satır bulgunun söylediğini içermiyorsa ya da sorgu belirtilen değeri döndürmüyorsa, bulgu düşürülür ve analiste hiç ulaşmaz.

Bu, yapay zekâ çıktısının inceleniş biçimini değiştirir. Analist “model haklı mı?” diye sormak yerine kanıta bakar ve ne anlama geldiğine karar verir: doküman mı yanlış, kod mu? Aynı ilke bug taslaklarında da geçerlidir; beklenen ve gerçekleşen değerler koşunun kendi artefaktlarında bulunmalıdır. Mükerrer aday sıralamaları da yalnızca Jira aramasının gerçekten döndürdüğü kayıtları adlandırabilir.

REPLAY ve canlı kip

Model geçidi farklı kiplerde çalışabilir. Canlı kipte yapay zekâ adımları yapılandırılmış model sağlayıcısını çağırır. REPLAY kipinde her yapay zekâ adımının çıktısı, girdisi bir beyana karşı doğrulanmış ve önceden hazırlanmış bir kayıttan gelir.

REPLAY, güvenilir demolar ve testler için vardır. Canlı kiple aynı kod yolunu izler: kayıt, şema doğrulaması, kanıtın yeniden doğrulanması ve insan kapıları birebir aynıdır. Tek fark, model çıktısının nereden geldiğidir.

Platform REPLAY’i hiçbir zaman canlıymış gibi sunmaz. Her REPLAY çıktısı REPLAY rozeti taşır. Girdi kayıtla eşleşmezse çıktı REPLAY-MISS olarak işaretlenir ve yerine hiçbir şey uydurulmaz. Kod üretimi ajanında, REPLAY’de bile tarayıcı adımları uygulamada gerçekten koşar; yalnızca modelin kararları kayıttan gelir.

Bir prompt paketi canlı kullanılmadan önce canlı modele karşı değerlendirme setinden geçmelidir. Bu değerlendirmeden geçmek REPLAY çıktısını canlı çıktıya dönüştürmez.

Olgunluk etiketleri

Bu sitedeki her yetenek üç olgunluk etiketinden birini taşır; anlam renge ya da ikona bağlı kalmasın diye etiket metin olarak da yazılır.

• Canlı doğrulandı: Canlı modelle değerlendirildi ve gerçek sistemlerde (Jira Cloud ya da Xray, GitHub, GitHub Actions) koştu. Kanıt ve tarihi Yetenekler sayfasında listelenir.
• Demoda gösterilir: Uçtan uca çalışır; REPLAY çıktılarıyla ya da canlı bir platformda gösterilir. Canlı model değerlendirmesi tamamlanmamıştır.
• Yol haritası: Henüz yok ya da yalnızca tasarımda. Her madde bir çeyrek ya da pilot koşulu belirtir veya tarihin pilot talebiyle belirleneceğini söyler.

Bu dokümantasyonda etiket, önemli olduğu başlıklarda yer alır; örneğin “Selenium göçü (Yol haritası)”. Yol haritasındaki özellikler planlandığını bilmeniz için tanıtılır, ama hiçbir zaman talimat olarak yazılmaz. Her yeteneğin güncel etiketinin tek kaynağı Yetenekler sayfasıdır.

Denetim kaydı

Denetim kaydı, her yapay zekâ çağrısını, araç çağrısını, onayı ve reddi tutar. Kayıtlar yalnızca eklemelidir: uygulamanın veritabanı rolü denetim olaylarını güncelleyemez ya da silemez.

Her denetim olayı bir öncekine, önceki hash ile olayın kanonik JSON’unun SHA-256 hash’i üzerinden zincirlenir. Eski bir olayı değiştirmek ya da silmek zinciri kırar; zincir portaldan her an doğrulanabilir.

Zincirin başı platformun dışına da sabitlenir. Onaylı case’ler yayınlandığında Jira yorumu zincir hash’ini içerir; üretilen PR’lar ve onarım PR’ları bunu açıklamalarında taşır. Böylece bir inceleyici bir Jira kaydını ya da PR’ı kaydın belirli bir durumuyla eşleştirebilir.

Kayıt, SHA-256 sağlama dosyasıyla birlikte JSON Lines olarak dışa aktarılabilir. Ortamın tam sıfırlanması önce kaydı dışa aktarır; dışa aktarım başarısız olursa hiçbir şey silmeden durur.

CI’da Sıfır AI ve Onarım PR’ları

İki imza terim daha merge sonrasını anlatır.

CI’da Sıfır AI (Zero-AI CI), CI akışınızda koşan testlerin onaylı, deterministik Playwright kodu olduğu anlamına gelir. CI ve test imajlarında model anahtarı, ajan ya da model SDK’sı yoktur; otomatik bir güvenlik kontrolü bunu doğrular. Kararsız bir model build’i kırmızıya çeviremez, çünkü orada model çalışmaz.

Onarım PR’ları (Repair PRs) bakımın nasıl yapıldığını anlatır. Bir test, elemanın rolü ve erişilebilir adı aynı kalırken testId’si değiştiği için kırılırsa, deterministik bir kural bunu test bakımı olarak sınıflar. Platform, page object locator’larındaki yalnızca testId değerini değiştiren bir PR önerir; değişiklik AST korumasıyla ve tam bir yerel koşuyla denetlenir. Bir insan inceler ve merge eder. Sessiz self-healing yoktur: test kodundaki her değişiklik incelenmiş bir PR’dır.

Beklenen sonucun gerçekleşenden farklı olduğu bir hata asla onarılmaz. Defect adayı olur ve bir insana gider.