Entegrasyon kurulumu

AI Testing Probe mevcut araçlarınıza adaptörler üzerinden bağlanır: gereksinimler için Jira Cloud, test senaryoları (test case) için Jira ya da Xray Cloud, kod ve CI için GitHub ile GitHub Actions, bulut tarayıcılar için Sauce Labs (Yol haritası), model için de model geçidi üzerinden bir sağlayıcı. Bu sayfa her entegrasyonun neye ihtiyaç duyduğunu ve verilmesi gereken en az izinleri listeler.

Her entegrasyonda geçerli ilkeler

Hangi araç olursa olsun her bağlantıya aynı kurallar uygulanır.

• Okuma ve yazma kimlikleri ayrıdır. Okuma ve yazma farklı hesaplar ya da belirteçlerle yapılır. Yazma kimliği, platformun çalıştığı proje ya da repoyla sınırlıdır.
• Kimlik bilgileri tek yerde durur. Model anahtarları ve yazma kimlikleri yalnızca core worker servisine verilir. Toolchain, test koşucusu ve CI (sürekli entegrasyon) bunları hiç almaz; her değişiklikten sonra otomatik bir güvenlik kontrolü bunu doğrular.
• Sırlar Git’e girmez. Kimlik bilgileri platform sunucusundaki, asla commit edilmeyen ortam dosyasında ya da CI secret’ı olarak tutulur. Bağlantıyı doğrulayan komutlar sır değerlerini ekrana basmaz.
• Simülatör ya da gerçek, kod aynıdır. Her dış sistem bir portun arkasındadır. Değerlendirme ve geliştirme sırasında Jira, Git ve CI yerine yerel bir simülatör kullanılabilir; gerçek adaptör aynı istemci kodunu kullanır. Geçiş bir yapılandırma değişikliğidir.
• Dürüst etiketler. Canlı modelden gelmeyen yapay zekâ (AI) çıktısı her zaman REPLAY olarak gösterilir.

Pilot bittiğinde, pilot için verilmiş tüm belirteç ve anahtarları yenileyin ya da iptal edin.

Jira Cloud

Jira Cloud gereksinimleri tutar; doküman düzeltmelerini, PO sorularını ve bug kayıtlarını alır.

Proje. Story ve Bug iş türlerine sahip bir proje kullanın. Bir Test iş türü ve Test bağlantı türü önerilir; yoksa platform başka bir iş türüne ve Relates bağlantısına geri döner. İş akışında “Done” kategorisinde bir durum bulunmalıdır. Kabul kriterleri açıklamada “Acceptance Criteria” başlığı altında, AC1: ... gibi numaralı satırlar olarak durmalıdır. Kabul kriterleri özel bir alandaysa kısa bir uyarlama planlayın.

Hesaplar.

Hesap	İzinler
Okuma	Yalnızca hedef projede projeye göz atma. Hiçbir projede yorum ekleme, kayıt oluşturma ya da düzenleme izni taşımamalıdır.
Yazma (bot)	Yalnızca hedef projede: göz atma, oluşturma, düzenleme, yorum ekleme, kayıt bağlama ve durum geçişi
PO (bir kişi)	Story’lere (Jira’daki kullanıcı hikâyeleri) yorum yazma ve etiket ekleme

Her hesap API token’ını kendi Atlassian hesap ayarlarından üretir. PO, okuma ve yazma hesaplarından farklı bir Atlassian hesabı olmalıdır. Onaylar görünen adla değil, her zaman hesap kimliği ya da e-postayla eşlenir.

PO onayı ayarları

PO onayı Jira’da verilen bir insan kapısıdır; bu yüzden biraz yapılandırma ister.

• İzinli onaylayanlar. Onay verebilecek kişilerin Atlassian hesap kimliklerini listeleyin. Liste boşsa gerçek Jira’da hiçbir onay kabul edilmez.
• Bot hesap kimliği. Yazma hesabının kimliğini kaydedin; böylece bu hesabın eklediği etiket hiçbir zaman onay sayılmaz.
• Rol bahsetmeleri (isteğe bağlı). Analist, PO, mühendis ve testçi rolleri için hesap kimlikleri verilirse platform yorumları doğru kişileri bahseder. Bahsetme yalnızca bildirimdir; hiçbir yetki vermez.

Onayın kendisi story üzerindeki bir etikettir. Platform, etiketi kimin eklediğini kaydın değişiklik geçmişinden doğrular. Bu etiketi hiçbir zaman kendisi eklemez; bot hesabı eklediyse etiketi kaldırır.

Platformun yazdığı her yorum AI Testing Probe: imiyle başlar. Böylece yazma hesabı adı bilinen bir kişiye ait olsa bile platform yorumları insan yorumlarından kolayca ayırt edilir.

Xray Cloud

Xray Cloud isteğe bağlıdır. Xray yoksa onaylı case’ler, adımları açıklamada bulunan Jira Test kayıtları olarak yayınlanır.

Adımlı, yapılandırılmış manuel testler yayınlamak için:

1. Yukarıdaki Jira Cloud kurulumunun tamamlandığından emin olun. Xray, testi story’ye Jira üzerinden bağlar.
2. Xray Cloud’u siteye kurun ve hedef projede etkinleştirin.
3. Xray genel ayarlarında, platformun yazma hesabına bağlı bir API anahtarı (client ID ve secret) oluşturun.
4. Anahtarı platform sunucusundaki ortam dosyasına ekleyin ve servisleri yeniden başlatın.

Bundan sonra portaldaki yayın önizlemesi hedef olarak Xray’i gösterir. İlk yayından sonra her case, story’ye bağlı ve adımları dolu bir manuel test olarak görünür.

Xray kurulu bir projede Test iş türü Xray’e aittir. Böyle bir projede Jira Test kayıtlarına yayın yine çalışır, ancak bu testlerde Xray adımı olmaz. Proje başına tek bir hedef seçin ve onu koruyun.

GitHub ve GitHub Actions

GitHub üretilen testleri tutar ve CI’ı koşturur. Platform, her biri en dar kapsamla tanımlanmış dört kimlik kullanır.

Kimlik	Ne yapar
GitHub App (bot)	Üretilen testler ve onarımlar için dal ve PR (pull request) açar, yorum yazar, yerini yenisine bırakan PR’ları kapatır, dalları günceller, workflow tetikler ve artefaktları okur. Asla merge etmez.
İnsan merge kimliği	Portaldan bir mühendis adına merge eder. Ruleset’i atlayabilen bir takımın üyesidir.
Salt okuma token’ı	Tutarlılık denetiminin uygulama kodunu okumasını sağlar.
Salt okuma ayna token’ı	Toolchain’in kontroller ve Kırarak Doğrula için commit’leri çekmesini sağlar.

App’i yalnızca test reposuna kurun; izinler: Contents ve Pull requests yazma, Actions okuma ve yazma, Checks okuma.

main için ruleset: değişiklik yalnızca PR ile; en az bir onay, code owner review’u ve son push’un onayı; testler, AST koruması ve statik analiz için zorunlu kontroller; force-push ve silme yok. Kuralı yalnızca insan takımı atlayabilir. İlk içeriği ruleset’i uygulamadan önce gönderin.

CI tetikleri ve Sauce Labs

Aynı onaylı paket dört tetikte koşar ve hiçbirinde yapay zekâ yoktur.

Tetik	Kaynak
PR	Bir PR’ın açılması ya da güncellenmesi
Push	main’e bir merge
Deploy	Deploy akışınızın ya da portalın gönderdiği bir repository_dispatch olayı
Gece	Zamanlanmış bir koşu ya da portaldan elle başlatma

Platform her koşuyu bulur, artefaktlarını indirir ve PR sonucunu PR’a tek bir yorum olarak yazar. Sonuçlar standart JUnit XML, Allure ve Playwright HTML raporlarıdır.

Sauce Labs (Yol haritası) aynı testleri ayrı bir GitHub Actions job’unda bulut tarayıcılarda koşturmak için tasarlandı. Sauce kullanıcı adını ve erişim anahtarını yalnızca GitHub Actions secret’ı olarak saklayın, asla platform sunucusunda değil; veri merkezi bölgesini de repo değişkeni olarak tanımlayın. Sauce job’u merge’ü engellemez ve aynı anda tek oturum koşturur. Sauce Labs en yeni Playwright sürümünün gerisinde kalabilir; bu yüzden bu job reponun geri kalanından daha eski, desteklenen bir Playwright sürümüne sabitlenebilir. Sauce Labs adaptörü GitHub Actions job’u olarak hazırdır ama henüz bir demoda gösterilmedi (Yol haritası).

Model sağlayıcısı

Model geçidi, model sağlayıcısıyla konuşur. Bugün desteklenen sağlayıcı Anthropic Claude’dur.

• Sağlayıcı konsolunda platform için ayrı bir çalışma alanı ve API anahtarı oluşturun. Anahtar bir çalışma alanına bağlıysa çalışma alanı kimliğini de yapılandırın.
• Anahtar yalnızca core worker servisine verilir. Güvenlik kontrolü başka hiçbir servisin onu göremediğini doğrular.
• Model kipini seçin: replay küratörlü kayıtları kullanır ve anahtarı yok sayar; live sağlayıcıyı çağırır, anahtar yoksa açık bir hata verir; auto anahtar varsa live, yoksa replay kullanır.
• Bir prompt paketi canlı kullanılmadan önce değerlendirme setinin canlı modelle geçmesi gerekir. Değerlendirme koşusunun katı bir bütçe tavanı vardır.
• Model geçidinde kişisel veri maskelemesi (TCKN, IBAN, telefon, e-posta) mevcuttur ve müşteri verisi işlendiğinde açık olmalıdır; pilotlar sentetik ya da üretim dışı veriyle yapılabilir.

Azure OpenAI ve diğer model sağlayıcıları (Yol haritası). Geçit sağlayıcıdan bağımsızdır ve sağlayıcıya özgü kod yalnızca adaptörlerde bulunur. Diğer sağlayıcılar bugün desteklenmez; tarih pilot talebiyle belirlenir.

Bugün olmayanlar

Aşağıdaki entegrasyonlar bugün ürünün parçası değildir. Pilot görüşmesinde erkenden gündeme getirebilmeniz için listelenmiştir.

• Azure DevOps (Boards, Repos, Pipelines, Test Plans) (Yol haritası). Tarih pilot talebiyle belirlenir.
• Diğer test yönetim araçları, örneğin TestRail ya da Zephyr. Test yönetimi bir port olduğu için yeni adaptörler aynı arayüzü izler, ancak bugün böyle bir adaptör yoktur.
• Portal için tek oturum açma (OIDC ya da SAML). Portal kullanıcıları platform hesaplarıyla ve rol tabanlı erişim denetimiyle giriş yapar.
• Jira Data Center ya da Server. Jira adaptörü, API token’larıyla Jira Cloud REST API’sini hedefler.

Kullandığınız bir araç listede yoksa adaptör kapsamı pilotunuz için konuşulabilir. Her entegrasyonun güncel etiketi Entegrasyonlar sayfasındadır.