Neden otomatik test pipeline’ı?

Otomatik test pipeline’ı; bir değişiklik yapıldığında (ör. pull request açıldığında) testlerin belirli bir sırayla çalışması, sonuçların raporlanması ve gerekirse dağıtımın (CD) durdurulması için kurgulanan CI/CD akışıdır. Amaç sadece “testleri koşturmak” değil; hızlı geri bildirim, tekrarlanabilirlik ve ekipçe güven üretmektir.

Genel bir kural olarak, bir pipeline iki soruya cevap vermelidir:

  • Bu değişiklik ana dala güvenle birleşebilir mi? (PR doğrulaması)
  • Ürünün tamamı belirli aralıklarla sağlıklı mı? (gecelik/planlı tam test koşusu)

Test Piramidi: hâlâ iyi bir başlangıç noktası

Test Piramidi, testlerin katmanlı dağılımını önerir: tabanda çok sayıda hızlı unit testi, ortada daha az sayıda servis/integration testi, en üstte ise az sayıda fakat daha pahalı UI/E2E testi. Bu çerçeve, Martin Fowler’ın “Test Pyramid” yazısında da pratik bir dengeleme yaklaşımı olarak anlatılır: hızlı geri bildirim için alt katmanları güçlü tutarken, üst katmanı (E2E) amaç odaklı sınırlamak (kaynak).

Ancak piramit “evrensel oranlar” demek değildir. Mimari (monolit/mikroservis), ürün riski ve ekip olgunluğu; PR kapısına hangi testlerin gireceğini ve planlı koşulda neyin genişletileceğini belirler. 2025 tarihli akademik inceleme de piramidin, güvenlik kontrolleri ve AI destekli yaklaşımlarla genişletilmesini tartışırken aynı noktaya işaret eder: uyarlama gereklidir (kaynak).

Piramidi CI/CD’ye nasıl çevirirsiniz?

Piramidi bir “test sayısı hedefi” olarak değil, pipeline maliyeti ve güven olarak düşünmek daha işlevseldir:

  • PR (hızlı kapı): Unit + seçilmiş kritik entegrasyon kontrolleri + küçük bir E2E smoke set.
  • Merge sonrası / ana dal: Daha geniş entegrasyon seti ve daha geniş E2E.
  • Zamanlanmış (tam güven): Tam E2E regresyonu + raporların/çıktıların arşivlenmesi.

Test katmanlarını netleştiren kısa tablo

Katman Amaç CI’de tipik kullanım Başarısızlıkta ipucu
Unit Fonksiyon/sınıf düzeyi doğruluk, hızlı geri bildirim Her PR’da zorunlu Genellikle kod değişikliğine doğrudan işaret eder
Integration/Servis Bileşenlerin birlikte çalışması, API sözleşmeleri PR’da kritik subset, ana dal/planlı koşuda geniş set Konfigürasyon, bağımlılık, veri akışı sorunlarını açığa çıkarabilir
UI/E2E Kullanıcı akışlarının uçtan uca doğrulanması PR’da smoke; planlı koşuda regresyon Ortam/veri/perf dalgalanması etkileyebilir; teşhis için iyi çıktı gerekir

CI/CD’de pratik tasarım: “Hızlı kapı” + “derin doğrulama”

Birçok ekip için sürdürülebilir desen şudur: PR’da hızlı bir kapı koşusu, ana dala birleşince daha kapsamlı doğrulama ve belirli aralıklarla tam tarama. GitHub Actions belgeleri; bu tür akışlarda tetikleyiciler, runner seçenekleri, paralelleştirme ve temel CI kavramlarını özetler (kaynak).

1) PR iş akışı: hızlı ve mümkün olduğunca deterministik

  • Tetikleyici: Pull request açma/güncelleme.
  • Hedef süre: Ekibin akışını bölmeyecek kadar kısa (eşik, ürün ve ekip ritmine göre değişir).
  • İçerik: Lint + unit + kritik entegrasyon + E2E smoke.

Burada amaç “her şeyi” test etmek değil; yüksek sinyal üretmektir. Smoke seti genellikle en kritik 3–10 kullanıcı akışını kapsayan küçük bir gruptur.

2) Ana dal / planlı iş akışı: geniş kapsama ve raporlama

  • Tetikleyici: Ana dala push ve/veya zamanlanmış çalışma (cron).
  • İçerik: Daha geniş entegrasyon seti, E2E regresyonu, raporların saklanması.
  • Çıktı: Raporlar, loglar ve (E2E’de) iz/trace benzeri teşhis çıktıları.

Bu koşu daha uzun sürebilir; amaç, PR kapısına sığmayan riskli alanları düzenli ve izlenebilir şekilde doğrulamaktır.

Araç seçimi: Playwright, Selenium ve test stratejiniz

UI/E2E tarafında modern ekiplerin değerlendirdiği araçlardan biri Playwright’tır. Playwright’ın resmi CI rehberi; CI entegrasyonu, raporlama ve trace alma gibi pratiklere odaklanır (kaynak). Bu tür çıktılar, özellikle CI koşullarında (kısıtlı yeniden üretim, headless çalıştırma, farklı runner performansı) sorunun nerede ve hangi adımda oluştuğunu görmeyi kolaylaştırabilir; yine de ortam/veri dalgalanması varsa tek başına “garanti” değildir.

Selenium ise ekosistemi geniş ve uzun süredir kullanılan bir seçenektir. Kurumsal ortamlarda mevcut altyapı ve ekip deneyimi Selenium’u mantıklı kılabilir. Seçim yaparken şu kriterleri değerlendirin:

  • Mevcut teknoloji yığını: Dil/runner uyumu, ekip deneyimi.
  • CI’de teşhis kolaylığı: Rapor, iz/trace, ekran görüntüsü, log toplama.
  • Paralelleştirme: Testleri parçalayıp koşma (toplam süreyi düşürmek için).
  • Bakım maliyeti: Flaky testlerle mücadele pratikleri.

GitHub Actions ile örnek pipeline iskeleti (okunabilir parçalar)

GitHub Actions’ta bir CI tasarımını anlamanın en kolay yolu, akışı “tetikleyiciler” ve “job’lar” olarak bölmektir (resmi CI özeti: GitHub Docs).

Not: Aşağıdaki yapı kopyala-yapıştır amaçlı tam bir YAML değildir; pseudocode gibi, proje komutlarınıza göre uyarlamanız gereken bir iskelet olarak düşünün.

A) Tetikleyici kurgusu (ne zaman çalışacak?)

Akış Tetikleyici Hedef
PR doğrulama pull_request Hızlı kapı: unit + kritik integration + E2E smoke
Ana dal doğrulama push (main) Daha geniş doğrulama ve raporlama
Planlı tam koşu schedule (cron) Tam E2E regresyonu + arşivleme

B) Job ayrımı (neyi ayrı koşturacaksınız?)

Job Koşu İçerik
unit PR + main Hızlı, güvenilir temel testler
integration PR (subset) + main/schedule (geniş) Servis bağımlılıkları / sözleşme kontrolleri
e2e_smoke PR Kritik kullanıcı akışları (küçük set)
e2e_full main + schedule Geniş regresyon + rapor/trace arşivi

C) Job adımları (her job’da ortak “iskelet”)

Adım Örnek amaç Not
Checkout Kodu al Repo state’i sabitlenir
Dependencies Bağımlılıkları kur Cache, süreyi düşürmeye yardımcı olabilir (uygun tasarlanırsa)
Run tests Testleri koştur PR’da kısa; schedule’da geniş
Collect artifacts Rapor/log sakla CI’da teşhis için kritik

Secrets yönetimi: “loglara düşmesin” prensibi

CI’de E2E testleri bazen kimlik bilgileri veya API anahtarları gerektirebilir. Bu noktada iki temel ilke önemlidir (GitHub Actions ve Playwright CI dokümanları, secrets kullanımına özellikle dikkat çeker: GitHub Docs, Playwright CI):

  • Secrets değerlerini repoya yazmayın; CI’nin secrets mekanizmasını kullanın.
  • Log ve artifact kapsamını düşünün; hata anında toplanan çıktılarda hassas veri bulunmadığından emin olun.

Ölçeklenebilirlik: test seti büyüdükçe ne değişir?

Test sayısı arttıkça sık görülen iki problem: sürelerin uzaması ve güvenin azalması (özellikle flaky testler). Ölçeklenebilir bir tasarım için aşağıdaki yapı taşlarını birlikte düşünün.

1) Paralelleştirme ve parçalama (shard)

CI sistemleri birden fazla job’ı paralel çalıştırabilir; bu, geri bildirim döngüsünü kısaltmanın en doğrudan yollarından biridir. GitHub Actions belgeleri, paralel iş yürütme ve runner seçenekleri için temel çerçeveyi sunar (kaynak). E2E tarafında ise testleri parçalara ayırmak toplam süreyi azaltabilir; ancak parçalama stratejisi (tarayıcı/özellik/dosya bazlı) testlerin dağılımına göre belirlenmelidir.

  • İş ayrımı: tarayıcı bazında, özellik bazında veya test dosyası bazında.
  • Kaynak planlama: runner kapasitesi ve kuyruk süreleri; yoğun saatlerde PR kapısının yavaşlamaması için kritik olabilir.

2) Cache ve artifact stratejisi

Cache ile bağımlılık indirmeyi hızlandırabilir; artifact ile rapor/trace/log gibi çıktıları saklayabilirsiniz. İyi bir pratik, şu iki soruya net cevap vermektir:

  • Cache’lediğim şey deterministik mi? Yanlış cache, “tesadüfen geçen” koşulara yol açabilir.
  • Artifact’ler teşhis için yeterli mi? Özellikle E2E’de rapor + iz/trace, yeniden üretimin zor olduğu CI koşullarında değerli olabilir (Playwright CI rehberi: kaynak).

3) Flaky test yönetimi: görünürlük + disiplin + uygulanabilir kurallar

Flaky test, kod değişmeden bazen geçen bazen kalan testtir. Tamamen sıfırlamak her zaman kısa vadede mümkün olmayabilir; bu yüzden hedef, önce ölçmek ve etkisini sınırlamak olmalıdır.

  • Karantina (quarantine) için etiketleme: Flaky olduğu şüpheli testleri @quarantine gibi bir etiketle ayırın. PR kapısında bu grubu çalıştırmayın; ayrı bir job’da (ana dal/planlı koşu) çalıştırıp sonuçları görünür kılın. Böylece ekip, “kapı”yı bozmadan flaky borcunu takip eder.
  • Retry’ı sınırlayın ve şeffaf tutun: Retry kullanacaksanız üst sınır koyun (örn. en fazla 1–2 tekrar) ve raporlamada “ilk koşuda mı geçti, retry ile mi geçti?” bilgisini ayrı görün. Aksi halde gerçek hatalar gizlenebilir.
  • Başarısızlık başına minimum artifact paketi tanımlayın: En azından test raporu, ilgili loglar ve E2E için mümkünse iz/trace gibi teşhis çıktıları saklayın. Bu, CI’da tekrar çalıştırma ihtiyacını azaltabilir (Playwright CI’da rapor/trace odakları: kaynak).

Flaky testlerin kök nedenleri sıklıkla test izolasyonu, paylaşılan test verisi, zaman aşımı ve çevresel bağımlılıklardır. Hangi aracı kullandığınızdan bağımsız olarak, izole test verisi ve deterministik kurulum iyileştirmenin temelidir.

“Test Piramidi 2.0”: güvenlik ve AI destekli yaklaşımlar (temkinli çerçeve)

2025 tarihli akademik çalışma, test piramidi yaklaşımının modernleştirilerek güvenlik kontrollerinin ve AI destekli tekniklerin katmanlara entegre edilebileceğini tartışır (The Test Pyramid 2.0). Bunu pratikte şöyle ele almak daha güvenlidir:

  • Güvenliği pipeline’a gömme: PR’da hızlı sinyal veren kontroller; daha ağır taramalar ise planlı koşularda.
  • AI destekli verimlilik (pilot yaklaşımı): Test taslağı üretimi, test verisi önerileri veya anomali tespiti gibi alanlarda küçük pilotlar ve ölçülebilir hedeflerle ilerlemek; “tam otomasyon” beklentisine göre daha kontrollü bir yaklaşımdır.

Adım adım uygulama planı

Adım 1: Test envanteri çıkarın

  • Hangi testler unit, hangileri integration, hangileri E2E?
  • PR’da koşması şart olan “kritik akışlar” hangileri?

Adım 2: PR kapısını tanımlayın

  • Unit testler: zorunlu.
  • Integration: kritik subset.
  • E2E: smoke set (etiketleme/filtreleme ile).

Adım 3: Ana dal ve planlı koşuyu kurgulayın

  • Ana dal: geniş suite + raporlama.
  • Planlı: tam E2E regresyonu + artifact arşivi.

Adım 4: Süre hedefleri koyun ve darboğazı ölçün

  • Hangi job en çok zaman alıyor?
  • Paralelleştirme mi gerekir, yoksa testlerin kendisi mi optimize edilmeli?

Adım 5: Flaky test politikasını yazılı hale getirin

  • Retry ne zaman ve kaç kez kullanılacak?
  • Karantina etiketi hangi kriterle verilecek, nasıl kaldırılacak?
  • Her flaky test için “sahiplik” (owner) ve hedef çözüm süresi olacak mı?

Sık yapılan hatalar ve daha sağlam alternatifler

  • Her şeyi E2E ile test etmeye çalışmak: E2E pahalıdır; çoğu mantık unit/integration’da daha hızlı ve stabil yakalanır (Test Piramidi mantığı; Fowler).
  • PR’da tam regresyonu zorunlu kılmak: Geliştirme hızını düşürebilir; PR kapısı + planlı tam koşu daha sürdürülebilir olabilir.
  • Rapor/iz toplamamak: “Kaldı ama neden?” sorusu yanıtsızsa CI ekibe yük olur; E2E’de rapor/trace bu noktada fayda sağlayabilir (Playwright CI).
  • Secrets’leri yanlış ele almak: Hassas verilerin loglara/artifact’lere sızmaması için CI secrets mekanizmalarını doğru kullanın (GitHub Docs).

Kısa kontrol listesi

  • PR kapısı: Unit + kritik integration + E2E smoke hazır.
  • Ana dal / planlı koşu: Geniş regresyon ve rapor/çıktı arşivi var.
  • Artifact standardı: En az rapor + log; E2E’de mümkünse iz/trace.
  • Ölçek planı: Paralelleştirme stratejisi ve runner kapasitesi net.
  • Flaky politikası: Karantina etiketi + sınırlı retry + sahiplik kuralı yazılı.

Kaynaklar

Not: Bu yazı genel bilgilendirme amaçlıdır; pipeline tasarımını takım yapısı, mimari ve risk profiline göre uyarlamak gerekir.