Uçtan Uca İş Akışı, CI/CD Entegrasyonu, Etik ve Güvenlik: YZ'yi Sorumlu Kullanmak

Kazanimlar:

• Fikirden yayına uzanan uçtan uca QA akışında yapay zekanın rolünü ve insan onay noktalarını CI/CD bağlamında tasarlayabilme
• CI/CD'de yapay zekaya testi otomatik 'geçirme' yetkisi vermeme, gizli veri ve anahtarları koruma sınırlarını uygulayabilme
• Güvenlik testini yetki dâhilinde ve savunma amaçlı yapma, sorumlu ifşa ve etik şeffaflık ilkelerini benimseyebilme

Önceki on ünitede YZ'yi tek tek görevlerde kullandık: senaryo üretimi, otomasyon kodu, hata raporu, kapsam analizi, mutasyon testi. Bu son ünite, hepsini tek bir sorumlu iş akışında birleştirir. Modern QA, bir kişinin masasında biten bir iş değildir; CI/CD (Continuous Integration / Continuous Delivery — kodun sürekli birleştirilip otomatik test edilerek sık ve güvenli biçimde yayına hazırlandığı boru hattı) içinde yaşayan bir süreçtir. YZ bu sürecin her aşamasına dokunabilir. Ama YZ'nin gücü arttıkça, onu sorumlu kullanmanın önemi de artar: gizlilik, güvenlik testinde yetki, etik ve en önemlisi kalite kararının insanda kalması. Bu ünitede uçtan uca akışı ve sınırları öğreneceksiniz.

Uçtan uca YZ destekli QA akışı

Bir özelliğin fikirden yayına kadar yolculuğunda YZ'nin rolü:

1. Gereksinim analizi. YZ, gereksinimdeki belirsizlikleri ve eksik kabul kriterlerini işaretler ("bu kural, şifre en az kaç karakter demiyor").

2. Test tasarımı. Kabul kriterlerinden senaryo ve vaka taslakları (2. ünite), kenar durumlar (3. ünite).

3. Otomasyon. Birim (6), API (5) ve UI (4) test kodu taslakları; her biri mutasyonla doğrulanır (10).

4. CI/CD entegrasyonu. Testler her kod birleştirmede otomatik çalışır. YZ, boru hattı yapılandırmasını (YAML) taslaklar, başarısız testlerin loglarını özetler, olası kök nedeni önerir.

5. Sürüm kararı. Risk analizi (8) ve regresyon (9) sonuçları toplanır — ama "çıkabilir mi" kararını uzman verir.

6. Üretim izleme ve geri besleme. Canlıdaki hatalar, gelecekteki testlere dönüşür; YZ, bir üretim hatasından regresyon vakası önerir.

İpucu: YZ'yi CI/CD'de "test yazan ve karar veren" değil, "insanın gözden geçirdiği taslakları hızlandıran" bir katman olarak kurun. Otomatik üretilen hiçbir test, bir insan gözden geçirip onaylamadan boru hattına girmemeli.

CI/CD'de YZ: nerede evet, nerede hayır

Aşama

YZ uygun

İnsan şart

Test kodu taslağı

Evet

Gözden geçirme + mutasyon

Boru hattı YAML taslağı

Evet

Doğrulama + gizli anahtar denetimi

Başarısız log özeti

Evet

Kök neden onayı

Kırılgan test teşhisi

Evet

Kalıcı çözüm kararı

"Sürüm çıkabilir mi"

Hayır

Uzman kararı ve sorumluluk

Testi otomatik "geçir"

Asla

—

Dikkat: YZ'ye CI/CD'de "başarısız testi geçecek şekilde düzelt" gibi bir yetki asla vermeyin. Bu, testin amacını yok eder ve hataları otomatik olarak örter. YZ hatayı açıklayabilir, düzeltme önerebilir; ama testi "yeşile boyamak" bir insanın bilinçli, gerekçeli kararı olmalıdır.

Gizlilik, veri ve güvenlik: değişmez sınırlar

Gizlilik. Test ortamında gerçek müşteri verisi, üretim veritabanı kopyaları, API anahtarları ve iç sistem bilgileri hassastır. Halka açık YZ araçlarına bunları vermeyin. Kişisel veri KVKK ve benzeri düzenlemelere tabidir; logları ve ekran görüntülerini maskeleyin. Mümkün olan her yerde sentetik (kurgusal) test verisi kullanın.

Güvenlik testi — savunma amaçlı ve yetki dâhilinde. Bu modülde öğrenilen güvenlik testleri (yetkilendirme/IDOR testleri, dosya yükleme sınırları, girdi doğrulama) yalnızca kendi ürününüzü, yazılı yetki ve tanımlı kapsam dâhilinde sınamak içindir. YZ'yi başkasının sistemine izinsiz erişmek, gerçek açıkları silah hâline getirmek veya kapsam dışı test yapmak için kullanmak hem etik dışıdır hem yasa dışıdır. Bir güvenlik açığı bulduğunuzda sorumlu ifşa (responsible disclosure — açığı gizli tutup ilgili tarafa bildirerek düzeltilmesini sağlama) ilkesine uyun.

Etik ve şeffaflık. YZ'nin ürettiği testleri kendi emeğinizmiş gibi sunmayın; ekip içinde YZ kullandığınızı belirtmek şeffaflıktır. YZ'nin ürettiği bir çıktının yanlışlığından siz sorumlusunuz — "YZ yazdı" bir mazeret değildir.

Zayıf prompt / Güçlü prompt

Zayıf: "CI için test pipeline'ı kur."

Güçlü: "GitHub Actions için bir CI iş akışı YAML'ı taslakla: her PR'da birim + API testlerini çalıştır, kapsam raporu üret, mutasyon testini (Stryker) haftalık koştur. Gizli anahtarları koda gömme; yalnızca secrets referansı kullan. Testler kırmızıysa birleştirmeyi engelle. Bu bir TASLAK; ben gizli anahtar yönetimini ve onay adımlarını gözden geçirip düzenleyeceğim. Otomatik test 'düzeltme' veya 'geçirme' adımı EKLEME."

Güçlü prompt; gizlilik (secrets), insan gözden geçirmesi ve "testi otomatik geçirme yasağı" sınırlarını baştan koyar.

Dört kopyalanabilir şablon

1) Uçtan uca test planı:

Rolün: kıdemli QA lideri. Şu özellik için fikirden yayınauçtan uca test planı taslakla: [özellik + kabul kriterleri].Aşamalar: gereksinim analizi (belirsizlikler), test tasarımı,otomasyon katmanları (birim/API/UI), CI/CD entegrasyonu,sürüm kararı kriterleri, üretim izleme. Her aşamada YZ'ninrolünü ve İNSAN onay noktalarını ayrı belirt.

2) CI/CD boru hattı taslağı:

[GitHub Actions/GitLab CI/Azure Pipelines] için CI YAML taslağı:- PR'da birim + API test + kapsam- Kırmızı testte birleştirmeyi engelle- Gizli değerler yalnızca secrets ile; koda gömmeBu bir taslak; anahtar yönetimi ve onay adımlarını bengözden geçireceğim. Testi otomatik düzeltme/geçirme adımı ekleme.

3) Başarısız test log analizi:

Şu CI çıktısında testler kırmızı. Logu incele; başarısızlıklarıgrupla, olası kök nedeni ve HANGİSİNİN gerçek hata, hangisininkırılgan test/ortam sorunu olabileceğini ayırt et. Kişisel verivarsa maskele. Karar ve düzeltme bana ait olacak. Log: [yapıştır]

4) Güvenlik/gizlilik ön denetimi:

Bu test verisi/log YZ aracına gönderilmeden önce denetle:kişisel veri, API anahtarı, iç sistem adresi, üretim verisiiçeriyor mu? İçeriyorsa hangi alanların maskelenmesi/çıkarılmasıgerektiğini listele. Bu haliyle işleme. İçerik: [yapıştır]

Üç mini vaka

Vaka 1 — Uçtan uca akışın hızı. Bir ekip, yeni bir "abonelik yenileme" özelliğini YZ destekli uçtan uca akışla ele aldı: gereksinim belirsizlikleri baştan işaretlendi, üç katmanlı testler taslaklandı ve mutasyonla doğrulandı, CI'a bağlandı. Özellik geleneksel süreçte 5 gün süren test döngüsünü 2 güne indirdi; ama her aşamada insan onayı korundu ve bir gereksinim belirsizliği (yenileme başarısızsa ne olacağı) canlı öncesi kapatıldı.

Vaka 2 — Anahtar sızıntısından dönüş. Bir geliştirici, YZ'ye CI YAML'ı ürettirdi ve YZ örnek olarak gerçek görünen bir API anahtarını YAML içine gömdü. "Güvenlik/gizlilik ön denetimi" adımı bunu yakaladı; anahtar secrets referansına çevrildi. Denetim adımı olmasaydı anahtar sürüm kontrolüne (git geçmişine) sızacaktı.

Vaka 3 — Yetki sınırı. Bir ekip üyesi, öğrendiği IDOR testini bir iş ortağının canlı sistemine "merak ettim" diye uygulamak istedi. QA lideri durdurdu: yazılı yetki ve tanımlı kapsam olmadan başka bir sisteme güvenlik testi yapmak yasa dışıdır. Test yalnızca kendi ürünlerinin test ortamında, yetkiyle yapıldı; bulunan açık sorumlu ifşa ile ilgili ekibe bildirildi.

Sık yapılan hatalar

• YZ'ye sürüm kararı verdirmek. "Çıkabilir mi" sorusunu YZ'ye sordurup cevabı imza yerine koymak.
• Otomatik testi "geçirmek". CI'da YZ'ye testi yeşile boyatmak; hataları örtmek.
• Gizli veriyi/anahtarı araca vermek. Üretim verisi, kişisel veri veya API anahtarını denetimsiz paylaşmak.
• Yetkisiz güvenlik testi. Kapsam ve izin belgesi olmadan başka sisteme saldırgan test.
• Gözden geçirmeden boru hattına test sokmak. YZ taslağını insan onayı olmadan otomatik çalıştırmak.
• Sorumluluğu YZ'ye atmak. Hatalı çıktıyı "YZ yazdı" diye savunmak.

Özetle

Uçtan uca QA, gereksinimden üretim izlemeye uzanan ve CI/CD içinde yaşayan bir süreçtir; YZ her aşamada taslak üretir, log özetler, kök neden önerir. Ama sınırlar değişmezdir: test kararlarını ve sürüm onayını insan verir; YZ'ye testi otomatik "geçirme" yetkisi asla verilmez; gizli veri ve anahtarlar araca girmez; güvenlik testi yalnızca kendi ürününüzde, yazılı yetki ve tanımlı kapsam dâhilinde, savunma amaçlı yapılır ve bulgular sorumlu ifşa ile bildirilir. YZ kullandığınızda şeffaf olun; çıktının doğruluğundan siz sorumlusunuz. YZ hızlandırır; kaliteye ve etiğe siz kefil olursunuz.

Uygulama görevi

Kendi projenizden bir özellik için "uçtan uca test planı" şablonuyla fikirden yayına bir plan taslaklayın; her aşamada YZ'nin rolünü ve insan onay noktalarını ayrı işaretleyin. Ardından "CI/CD boru hattı taslağı" ile bir YAML üretin ve "güvenlik/gizlilik ön denetimi"ni bu YAML'a uygulayarak gömülü anahtar/gizli veri olup olmadığını kontrol edin. Son olarak planınızdaki tüm "insan kararı" noktalarını listeleyin ve neden bu kararların YZ'ye devredilemeyeceğini bir cümleyle gerekçelendirin.

Kontrol listesi

• [ ] Sürüm ve test kararlarını insan onayına bağladım; YZ'ye devretmedim.
• [ ] CI/CD'de YZ'ye testi otomatik "geçirme/düzeltme" yetkisi vermedim.
• [ ] Araca göndermeden önce gizli veri, kişisel veri ve anahtarları denetleyip maskeledim.
• [ ] Güvenlik testini yalnızca kendi ürünümde, yazılı yetki ve kapsam dâhilinde düşündüm.
• [ ] Bulunan açıkları sorumlu ifşa ilkesiyle ele aldım.
• [ ] YZ kullandığımı şeffaf belirttim ve çıktının doğruluğundan kendimi sorumlu tuttum.

Modul Sinavi

1. QA bağlamında 'sahte-geçiş' (false pass) en doğru şekilde nasıl tanımlanır?

• A) Testin yeşil yanmasına rağmen gerçekte hiçbir davranışı doğrulamaması; kod bozuk olsa bile kırmızıya dönmemesi ✔
• B) Testin çok yavaş çalışıp zaman aşımına uğraması
• C) Testin gerçek bir hatayı bulup kırmızıya dönmesi
• D) Testin yalnızca üretim ortamında çalışması

Aciklama: Sahte-geçiş, bir testin 'geçti' demesine rağmen aslında hiçbir anlamlı şeyi doğrulamamasıdır; test yeşildir ama yazılım hatalı olsa bile bunu yakalamaz. Bu, QA'da yapay zekanın bir numaralı riskidir çünkü YZ düzgün görünen ama içi boş testler üretmeye eğilimlidir.

2. Test ve QA sürecinde yapay zekanın en doğru konumlandırması hangisidir?

• A) Yapay zeka insan onayı olmadan sürümün yayına çıkıp çıkamayacağına karar verebilir
• B) Yapay zeka taslak ve fikir üreten bir asistandır; 'yayına hazır mı' kararı ve sorumluluğu uzmanındır ✔
• C) Yapay zeka yalnızca metin yazar, test koduyla hiç ilgilenemez
• D) Yapay zeka her zaman insandan doğru test yazar, bu yüzden gözden geçirme gereksizdir

Aciklama: Yapay zeka bir test asistanı, taslak üreticisi ve fikir çoğaltıcısıdır; test senaryosu, otomasyon kodu ve rapor taslakları üretir. Ancak 'bu yazılım yayına hazır mı', 'bu test geçti mi' gibi kalite kararlarının sorumluluğu ve son onayı yetkin uzmana aittir.

3. Hataların en çok eşik değerlerde oluştuğu gerçeğinden yola çıkarak 18 yaş sınırı için 17, 18 ve 19'u ayrı ayrı test etmek hangi test tasarım tekniğidir?

• A) Durum geçişi testi
• B) Karar tablosu
• C) Sınır değer analizi ✔
• D) Keşif testi

Aciklama: Sınır değer analizi (boundary value analysis), hataların en sık sınırlarda ortaya çıktığı gözlemine dayanır ve eşik değerlerini (sınırın hemen altı, tam üstü ve hemen üstü) ayrı ayrı test eder. Denklik sınıflarını tamamlayan güçlü bir tekniktir.

4. Yapay zeka ile üretilen UI test otomasyon kodunda kırılganlığı azaltmak için element seçiminde tercih edilmesi gereken yaklaşım hangisidir?

• A) Mümkün olan en uzun XPath yolunu kullanmak
• B) Elementin ekrandaki piksel konumuna göre seçmek
• C) CSS sınıf adlarına dayalı seçiciler kullanmak
• D) Test için eklenen kararlı öznitelikleri (data-testid) kullanmak ✔

Aciklama: Uzun XPath yolları ve CSS sınıf adları sayfa yapısına ve tasarıma aşırı bağımlıdır; en küçük arayüz değişikliğinde kırılır. Test için özel eklenen kararlı öznitelikler (örneğin data-testid) hem tasarım değişikliklerinden etkilenmez hem de testleri sağlam kılar.

5. Bir API testinin yalnızca HTTP durum kodunu (örneğin 200) kontrol etmesi neden yetersizdir?

• A) Çünkü doğru durum koduyla birlikte gövde verisi bozuk olabilir ve yalnızca durum kontrolü bunu yakalayamaz (sahte-güven) ✔
• B) Çünkü durum kodları API testlerinde hiç güvenilir değildir
• C) Çünkü durum kodu kontrolü testi çok yavaşlatır
• D) Çünkü API testlerinde durum kodu hiç dönmez

Aciklama: Sunucu doğru durum kodunu döndürürken gövdedeki veriyi bozuk (yanlış tip, eksik alan, yanlış hesaplanmış değer) döndürebilir. Sadece duruma bakan test bunu göremez ve sahte-güven verir. Bu yüzden şema/sözleşme ve iş kuralı doğrulaması da eklenmelidir.

6. Yapay zekaya birim test yazdırırken 'beklenen değeri kabul kuralına göre elle hesapla, fonksiyonun mevcut çıktısını referans alma' demek neden kritiktir?

• A) Çünkü elle hesaplama testleri daha hızlı çalıştırır
• B) Çünkü aksi halde test, kodun mevcut (belki hatalı) davranışını 'doğru' kabul eder ve hatayı onaylar ✔
• C) Çünkü yapay zeka ondalık sayıları hiç hesaplayamaz
• D) Çünkü kabul kuralları testlerde hiç kullanılmaz

Aciklama: Yapay zeka, beklenen değeri test edilen fonksiyonun çıktısından türetirse, fonksiyon hatalı olsa bile testi 'geçer' hale getirir; yani kod ne üretirse test onu doğru sayar. Beklenen değeri kabul kuralından bağımsız hesaplamak, testin kodun aynası değil, kuralın bekçisi olmasını sağlar.

7. İyi bir hata raporunun en ayırt edici özelliği aşağıdakilerden hangisidir?

• A) Mümkün olduğunca uzun ve teknik olması
• B) Yapay zeka tarafından yazılmış olması
• C) Geliştiricinin bağımsız izleyip hatayı üretebileceği deterministik tekrar üretim adımları içermesi ✔
• D) Yalnızca bir ekran görüntüsünden ibaret olması

Aciklama: Bir hata raporunun asıl değeri, geliştiricinin sizin yardımınız olmadan hatayı yeniden üretebilmesindedir. Deterministik, sıfırdan izlenebilir tekrar üretim adımları bunu sağlar; bu adımlar eksikse rapor çoğu zaman 'üretemedim' diye kapanır.

8. Ana sayfadaki şirket adının yanlış yazılması hatasında şiddet (severity) ve öncelik (priority) ilişkisi için en doğru ifade hangisidir?

• A) Şiddet ve öncelik daima aynı değerde olmalıdır
• B) Bu hatanın hem şiddeti hem önceliği kesinlikle düşüktür
• C) Şiddet ve öncelik aynı kavramdır, tek etiket yeterlidir
• D) Teknik şiddeti düşük olabilir ama iş önceliği (itibar) yüksek olabilir; ikisi farklı değerlendirilir ✔

Aciklama: Şiddet hatanın teknik etkisidir (yazım hatası teknik olarak düşük), öncelik ise ne kadar acil düzeltilmesi gerektiğidir (her ziyaretçinin gördüğü itibar unsuru olduğu için yüksek). İkisi her zaman aynı yönde gitmez; bu örnek düşük şiddet-yüksek öncelik durumudur.

9. %90 satır kapsamına sahip bir test paketi için en doğru yorum hangisidir?

• A) Satırların çalıştırıldığını gösterir ama doğru davrandığını kanıtlamaz; yüksek kapsam sahte-güven verebilir ✔
• B) Yazılımın %90'ının hatasız olduğunu kesin olarak kanıtlar
• C) Test kalitesinin mükemmel olduğunun kesin ölçüsüdür
• D) Artık hiç ek test yazmaya gerek olmadığını gösterir

Aciklama: Satır kapsamı yalnızca satırların çalıştırıldığını gösterir; doğru sonuç ürettiğini kanıtlamaz. Assert'siz testlerle bile %90 kapsam elde edilebilir. Kapsam bir 'nereye hiç bakmadım' haritasıdır, 'her şey test edildi' güvencesi değildir; gerçek koruma mutasyon testiyle ölçülür.

10. Risk bazlı testte, sınırlı test emeğini yönlendirmek için bir özelliğin riski nasıl hesaplanır?

• A) Yalnızca kod satır sayısına göre
• B) Bozulma olasılığı ile bozulunca oluşacak etkinin çarpımıyla ✔
• C) Yalnızca özelliğin geliştirilme sırasına göre
• D) Yalnızca test yazması en kolay olan özelliğe öncelik vererek

Aciklama: Risk bazlı testte risk = olasılık (bozulma ihtimali) × etki (bozulursa zarar) olarak değerlendirilir. Yüksek olasılık ve yüksek etki taşıyan alanlar (ödeme, kimlik doğrulama) en yoğun testi hak ederken, düşük × düşük alanlar hafif test alır.

11. Kodu değişmediği halde bazen geçip bazen kalan (kırılgan/flaky) bir teste retry (birkaç kez tekrar deneme) eklemenin temel riski nedir?

• A) Testin çalışma süresini kısaltması
• B) Kapsam yüzdesini düşürmesi
• C) Gerçek bir eşzamanlılık hatasını veya kök nedeni örtüp semptomu bastırması ✔
• D) Testin adını değiştirmesi

Aciklama: Retry bir teşhis aracıdır, tedavi değildir. Kararsızlık çoğu zaman gerçek bir yarış koşulundan (race condition) veya bağımlılıktan gelir; retry ile testi 'geçer' hale getirmek bu gerçek hatayı örter ve canlıda ciddi sorunlara yol açabilir. Önce kök neden bulunmalıdır.

12. Bir test paketinin gerçekten koruyup korumadığını ölçmenin en dürüst yöntemi olan mutasyon testi nasıl çalışır?

• A) Testlerin çalışma hızını ölçerek
• B) Kaç satır kod yazıldığını sayarak
• C) Testleri farklı sırayla çalıştırarak
• D) Kodda kasıtlı küçük bozmalar üretip testlerin bunları yakalayıp yakalamadığını ölçerek ✔

Aciklama: Mutasyon testi, kaynak kodda kasıtlı küçük bozmalar (mutasyonlar) üretir; iyi bir test paketi bu bozmaları yakalayıp kırmızıya dönmelidir. Yakalanmayan (hayatta kalan) mutasyonlar, testlerin o davranışı korumadığını gösterir. Mutasyon skoru, kapsam yüzdesinden çok daha dürüst bir kalite ölçüsüdür.

13. Güvenlik testi (örneğin yetkilendirme/IDOR testleri) yaparken uyulması gereken temel sınır hangisidir?

• A) Yalnızca kendi ürününde, yazılı yetki ve tanımlı kapsam dâhilinde, savunma amaçlı yapılmalı ✔
• B) Merak edilen her sisteme serbestçe uygulanabilir
• C) İş ortaklarının canlı sistemlerinde izin almadan denenebilir
• D) Bulunan açıklar herkese açık şekilde hemen yayımlanmalıdır

Aciklama: Bu modülde öğrenilen güvenlik testleri yalnızca kendi ürününüzü, yazılı yetki ve tanımlı kapsam dâhilinde, savunma amaçlı sınamak içindir. Başkasının sistemine izinsiz erişmek veya kapsam dışı test yapmak hem etik dışıdır hem yasa dışıdır; bulunan açıklar sorumlu ifşa ile bildirilir.

14. CI/CD boru hattında yapay zekaya asla verilmemesi gereken yetki hangisidir?

• A) Başarısız test loglarını özetleme
• B) Başarısız (kırmızı) testi otomatik olarak 'geçirme' veya yeşile boyama yetkisi ✔
• C) Test kodu taslağı önerme
• D) Boru hattı YAML dosyası taslaklama

Aciklama: Yapay zeka CI/CD'de test kodu taslağı, boru hattı YAML'ı ve log özeti üretebilir; ancak başarısız bir testi otomatik olarak 'geçirme/düzeltme' yetkisi asla verilmemelidir. Bu, testin amacını yok eder ve hataları otomatik olarak örter. Testi yeşile boyamak, bir insanın bilinçli ve gerekçeli kararı olmalıdır.