Otomatik Test Altyapısı Kurma: CI/CD Entegrasyonu ve Örnek Pipeline

Neden CI/CD içinde otomatik test altyapısı kurmalısınız?

Otomatik test altyapısı, kod değişikliklerinin beklenmedik hatalar üretmesini erken yakalamayı amaçlar. Bunu CI/CD pipeline’ına bağladığınızda, her commit veya merge request/pull request sırasında tekrarlanabilir bir kalite kontrol zinciri çalışır. Sonuç: daha hızlı geri bildirim, daha tutarlı sürümleme ve daha az “son dakikada sürpriz”.

Bu yazıda, yazılım test ve kalite güvencesi yaklaşımını CI/CD ile birleştirerek pratik bir kurulum planı çıkaracağız. Odak noktamız; test otomasyonu türleri, raporlama/coverage, E2E (end-to-end) testleri ve örnek bir pipeline tasarımı olacak.

Kimin için / Ön koşullar

• CI runner/agent erişimi (GitLab Runner vb.) ve pipeline çalıştırma yetkisi
• En azından temel bir unit test seti (ideal olarak entegrasyon ve E2E için başlangıç senaryoları)
• Pipeline çıktıları için artifact saklama imkânı (test raporları, coverage, E2E çıktıları)
• Ortam/bağımlılıkların (DB, queue, harici API) nasıl ayağa kalkacağına dair temel kararlar

Temel strateji: Test piramidi ve hızlı geri bildirim

Sağlam bir otomasyon stratejisi genellikle “test piramidi” mantığına dayanır: tabanda çok sayıda hızlı birim testi, orta katmanda daha az sayıda entegrasyon testi, tepede ise az ama kritik senaryoları kapsayan E2E testleri. Bu denge, pipeline süresini makul tutarken güveni artırmaya yardımcı olabilir. Bu yaklaşım, pratik CI/CD rehberlerinde ve endüstri perspektiflerinde sıkça vurgulanır (bkz. Atlassian Continuous Delivery Pipeline 101, ThoughtWorks Technology Radar).

Pipeline tasarımında hedef: “önce hızlı sinyaller”

• İlk dakikalarda lint/format, statik analiz ve birim testleriyle hızlı sinyal alın.
• Gerekli olduğunda entegrasyon testleri (DB, queue, API) devreye girsin.
• E2E testleri, az sayıda kritik akışa odaklansın; paralelleştirme ve seçici çalıştırma ile yönetilsin.

Kurulum planı: Otomatik test altyapısını 8 adımda inşa edin

1) Kalite kapılarını (quality gates) netleştirin

“Pipeline geçerse neye güveniyoruz?” sorusu net olmalı. Örnek kalite kapıları:

• Birim testleri: başarı (pass/fail) ve test raporu üretimi
• Coverage: takip edilmesi ve raporlanması (tek başına kalite ölçütü değildir)
• E2E: kritik kullanıcı akışlarının (login, checkout, onboarding vb.) stabil çalışması
• Opsiyonel: güvenlik taramaları ve bağımlılık kontrolleri (kurum politikanıza göre)

Not: Coverage için sabit bir “tek doğru yüzde” yoktur; ürün riskine, kodun olgunluğuna ve test türlerine göre hedefler değişir. Bu nedenle coverage’ı “trend ve görünürlük” için kullanıp, tek karar kriteri yapmamak çoğu ekipte daha sağlıklı sonuçlar verebilir.

2) Test katmanlarını ve sahipliğini belirleyin

• Birim testleri: geliştiriciler tarafından, hızlı, izole, her commit’te
• Entegrasyon: servis sınırlarında, daha pahalı, genellikle her merge request’te
• E2E: ürünün en kritik akışları, daha az sayıda, daha uzun sürebilir

3) Araç seçiminde gereksinimlerinizi önceleyin (Playwright örneği)

E2E tarafında Playwright gibi modern araçlar; çoklu tarayıcı desteği ve CI entegrasyonu gibi konularda resmi rehberler sunar (bkz. Playwright CI docs ve genel dokümantasyon giriş sayfası: Playwright Python). Eğer tarayıcı matrisinizde WebKit/Safari benzeri gereksinimler varsa veya paralel koşu ile süreyi yönetmek istiyorsanız Playwright güçlü bir aday olabilir. Ancak seçim, ekibin dil/ekosistem tercihi ve mevcut test birikimiyle birlikte değerlendirilmelidir (endüstri perspektifi için: ThoughtWorks Radar).

4) Depo (repo) yapısını ve test verisini standardize edin

Yapı, ölçeklenebilirlik için belirleyicidir. Basit bir şablon:

• /src: uygulama kodu
• /tests/unit: birim testleri
• /tests/integration: entegrasyon testleri
• /tests/e2e: Playwright/Cypress gibi E2E testleri
• /test-data: sabit fixture’lar (PII içermemeli)

Test verisi yönetiminde iki uçtan kaçının: (1) canlı üretim verisini kopyalamak (gizlilik/uyum riskleri), (2) gerçek dışı verilerle hatalı güven üretmek. Pratik yaklaşım: anonimleştirilmiş/sentetik fixture + ihtiyaç oldukça test ortamında kısa ömürlü veri oluşturma.

5) Lokal çalıştırmayı “tek komut” yapın

CI’deki testlerin yerelde benzer şekilde çalışması, kırılmaları azaltmaya yardımcı olur. Örnek hedefler:

• make test veya npm test gibi tek giriş noktası
• Bağımlılıkların sabitlenmesi (lock dosyaları)
• Başarısız test çıktılarının anlaşılır olması

6) CI/CD’de aşamaları (stages) tasarlayın

Atlassian’ın pipeline ilkeleri, akışı “koddan üretime” mantıksal adımlara bölmeyi ve geri bildirim döngüsünü iyileştirmeyi önerir (bkz. Pipeline 101). Tipik bir akış:

1. Lint/Static checks
2. Unit tests + rapor/coverage
3. Integration tests
4. E2E tests (paralel/segmentli)
5. Build (ekibin stratejisine göre testlerden önce/sonra konumlandırılabilir)

Pratik not: Gerçek pipeline’larda genellikle ayrıca bir çalışma ortamı (image veya runner etiketi), cache (bağımlılıklar), ve entegrasyon testleri için opsiyonel servisler (ör. DB) tanımlanır. Bunlar projeden projeye değiştiği için YAML örneğini minimal tutup, ihtiyaca göre genişletmek daha güvenlidir.

7) Test raporlarını ve coverage çıktısını pipeline’a ekleyin

Raporlamayı pipeline çıktısına eklemek, kod inceleme/merge kararları için somut sinyal üretir. GitLab CI’nin test rehberi, test raporları ve coverage gibi çıktıların CI arayüzüne taşınmasına yönelik örnek ve kavramlar sunar (bkz. Test with GitLab CI/CD).

Uygulamada şunları hedefleyin:

• JUnit/XML gibi standart formatlarda test sonucu üretimi
• Coverage raporunun artifact olarak saklanması
• Başarısızlıkta log gibi hata ayıklama artifact’ları; E2E’de buna ek olarak ekran görüntüsü/trace/video gibi çıktılar üretilmesi mümkünse (bkz. Playwright Trace Viewer)

8) Süreyi kontrol edin: paralelleştirme ve fail-fast

Uzun süren suite’lerde iki yaklaşım sık kullanılır:

• Paralelleştirme: E2E testlerini birden çok worker ile paralel çalıştırma veya shard’lara bölerek koşturma, toplam süreyi bazı senaryolarda düşürebilir. İlgili rehber: Playwright parallelism.
• Fail-fast: Kritik bir grup test başarısız olursa geri kalan uzun testleri koşturmayı durdurma ya da önceliklendirme. GitLab yaklaşımı: Fail fast testing.

Sınırlılık notu: Paralelleştirmenin maliyet/performans etkisi runner kapasitesi, eşzamanlılık sınırları ve test ortamı darboğazlarına göre değişir. Bu nedenle küçük bir pilot (PoC) ile kendi verinizi toplamak çoğu ekip için daha sağlıklı olur.

Örnek pipeline: GitLab CI ile çok katmanlı test akışı

Aşağıdaki örnek, kavramsal bir pipeline örneği sunar. Projenize göre komutları, rapor yollarını ve çalışma ortamını uyarlamanız gerekir. GitLab CI’nin test rehberi: GitLab Docs.

Örnek .gitlab-ci.yml iskeleti (sadeleştirilmiş)

stages:
  - lint
  - unit
  - integration
  - e2e

lint:
  stage: lint
  script:
    - ./ci/run-lint.sh

unit_tests:
  stage: unit
  script:
    - ./ci/run-unit-tests.sh
  artifacts:
    when: always
    reports:
      junit: test-results/unit/junit.xml
    paths:
      - coverage/

integration_tests:
  stage: integration
  script:
    - ./ci/run-integration-tests.sh
  artifacts:
    when: always
    reports:
      junit: test-results/integration/junit.xml

e2e_playwright:
  stage: e2e
  script:
    - ./ci/run-e2e-playwright.sh
  artifacts:
    when: always
    paths:
      - test-results/e2e/

E2E için pratik öneriler (Playwright)

• Tarayıcı matrisini bilinçli seçin: Her commit’te tüm tarayıcılar yerine, merge aşamasında daha geniş matris koşturmak daha dengeli olabilir.
• Hata ayıklama çıktıları üretin: Başarısız testte trace/screenshot gibi çıktılar, sorunu yeniden üretmeyi kolaylaştırabilir (bkz. Trace Viewer ve CI kılavuzu: CI docs).
• Paralelleştirmeyi ölçün: Süre düşerken ortam darboğazları (test DB, rate limit, 3rd party API) artabilir. Bu nedenle önce küçük ölçekte deneyin.

Fail-fast ve seçici çalıştırma: ne zaman mantıklı?

Özellikle büyük monorepo’larda veya uzun E2E suite’lerinde, değişikliğin etkilediği alanlara göre “subset test çalıştırma” ya da fail-fast yaklaşımı bekleme süresini bazı durumlarda azaltabilir. GitLab CI tarafında ilgili rehber: Fail fast testing.

Ancak seçici test çalıştırma, yanlış kurgulanırsa risk yaratır (değişiklik etkisi doğru hesaplanmadığında ilgili testler atlanabilir). Güven seviyesini artırmak için:

• Seçici koşuyu “hızlı sinyal” olarak kullanın, kritik branch’lerde tam koşuyu koruyun.
• Değişiklik etki analizi kuralları basit başlayıp zamanla olgunlaşsın.

Kalite sinyalleri: test raporu, coverage ve trend takibi

CI/CD’de sadece “yeşil/kırmızı” değil, zaman içinde trend de önemlidir:

• Pipeline süresi: ortalama ve p95 gibi dağılımlar (takım içi ölçümle)
• Flaky test oranı: yeniden koşunca geçen testler (birikirse güveni azaltabilir)
• Coverage trendi: artıyor mu, kritik modüller görünür mü?

GitLab CI, test sonuçlarını rapor olarak toplama ve CI çıktılarında gösterme yaklaşımıyla bu görünürlüğü destekler (bkz. GitLab testing docs).

Playwright mı, başka bir E2E aracı mı? Kararı nasıl verirsiniz?

Tek bir “en iyi” araç yoktur. Kararı somut gereksinimlerle verin:

• Tarayıcı kapsamı: WebKit/Safari benzeri kapsam kritik mi?
• Paralelleştirme ve CI modeli: suite’iniz büyüdükçe paralel koşuya ihtiyaç olacak mı?
• Ekip becerileri: JS/TS ağırlıklı mısınız, yoksa Python/.NET/Java gibi farklı dillerle test yazmak istiyor musunuz?
• Debug edilebilirlik: trace, screenshot, video, rapor kalitesi

Playwright’ın resmi dokümantasyonu; çoklu dil ve CI kullanım senaryolarına dair rehber sağlar (bkz. Playwright Python ve CI docs). Endüstri perspektifinde ise araçların hızla evrildiği, bu nedenle seçimlerin proje bağlamına göre değiştiği vurgulanır (bkz. ThoughtWorks Radar).

Sık karşılaşılan sorunlar ve pratik çözümler

1) Flaky (kararsız) testler

Flaky testler, “pipeline yeşil ama güven yok” problemine yol açabilir. Pratik yaklaşım:

• Önce nedenleri sınıflandırın: zamanlama, ağ bağımlılığı, paylaşılan state, test verisi çakışması.
• Retry mekanizmasını geçici bir tampon olarak kullanın; kalıcı çözüm yerine “alarm” gibi konumlandırın.
• E2E’de test izolasyonu ve deterministik test verisi üretimine yatırım yapın.

2) Çok uzun pipeline süreleri

• Birim testlerini paralelleştirin (framework desteği varsa).
• E2E’yi shard/worker yaklaşımıyla paralelleştirmeyi değerlendirin (Playwright: test-parallel).
• Fail-fast uygulayın; ancak kritik branch’lerde tam koşuyu koruyun (GitLab: fail-fast testing).

3) Rapor var ama kimse bakmıyor

• Merge/MR ekranında görünür olacak şekilde raporu entegre edin (GitLab test raporları yaklaşımı: GitLab CI testing).
• Kalite kapılarını az ama net tutun: “Bu sinyal kırmızıysa merge yok.”
• Coverage’ı tek başına hedef değil, tartışma başlatan bir metrik olarak kullanın.

Uygulanabilir kontrol listesi

• Test piramidi kurgulandı (unit > integration > E2E).
• Her test katmanı yerelde tek komutla çalışıyor.
• CI’da test raporları ve gerekiyorsa coverage artifact’ı üretiliyor (GitLab: CI testing).
• E2E testleri kritik akışlara odaklı ve mümkünse hata ayıklama çıktıları var (Playwright CI: docs).
• Pipeline süresi için paralelleştirme ve uygun yerde fail-fast planlandı (GitLab: rehber).
• Yeni araç/özellikler önce küçük pilot ile deneniyor; maliyet ve süre ölçülüyor (endüstri perspektifi: ThoughtWorks Radar).

Sonuç: Sağlam bir otomatik test altyapısı, “hız” ve “güven”i birlikte destekler

CI/CD entegrasyonlu test otomasyonu, tek seferlik bir kurulum değil; ölçerek iyileştirilen bir sistemdir. Test piramidiyle denge kurup raporlamayı görünür kıldığınızda, E2E testlerini hedefli (ve uygun olduğunda paralel) çalıştırdığınızda ve fail-fast gibi yaklaşımları kontrollü kullandığınızda pipeline’ınız ekip için daha güvenilir bir kalite sinyaline dönüşebilir.

Bir sonraki adım olarak, önce küçük bir “kritik akış” E2E seti + birim test raporlama/coverage çıktısı ile başlayıp, pipeline sürelerini ve hata türlerini izleyerek kademeli genişletme yaklaşımını benimseyin.