[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-otomatik-test-pipelinelari-kurma-cicd-test-piramidi-ve-olceklenebilirlik":3},{"dataItem":4,"heading":36,"metaData":38,"schema":81},["Reactive",5],{"id":6,"title":7,"summary":8,"content":9,"seo_title":10,"seo_description":11,"seo_keywords":12,"slug":13,"createdAt":14,"updatedAt":14,"blog_categories":15,"authors":19,"image":24,"thumb":25,"image_webp":26,"thumb_webp":27,"rating":28,"heading_title":7,"heading_sub_title":17,"readingTime":29,"url":34,"comments":35,"meta_cover":24},21602,"Otomatik Test Pipeline’ları Kurma: CI/CD, Test Piramidi ve Ölçeklenebilirlik","Bu rehber, CI/CD içinde otomatik test pipeline’ı kurmanın pratik adımlarını açıklar. Test Piramidi yaklaşımıyla PR doğrulaması ve zamanlanmış tam koşuları kurgulamayı, GitHub Actions tetikleyicileri/iş ayrımını, Playwright ile E2E rapor/trace toplamayı ve ölçek büyüdükçe paralelleştirme ile flaky test yönetimini ele alır.","\u003Ch2>Neden otomatik test pipeline’ı?\u003C/h2>\n\u003Cp>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; \u003Cstrong>hızlı geri bildirim\u003C/strong>, \u003Cstrong>tekrarlanabilirlik\u003C/strong> ve \u003Cstrong>ekipçe güven\u003C/strong> üretmektir.\u003C/p>\n\u003Cp>Genel bir kural olarak, bir pipeline iki soruya cevap vermelidir:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Bu değişiklik ana dala güvenle birleşebilir mi?\u003C/strong> (PR doğrulaması)\u003C/li>\n\u003Cli>\u003Cstrong>Ürünün tamamı belirli aralıklarla sağlıklı mı?\u003C/strong> (gecelik/planlı tam test koşusu)\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>Test Piramidi: hâlâ iyi bir başlangıç noktası\u003C/h2>\n\u003Cp>\u003Cstrong>Test Piramidi\u003C/strong>, testlerin katmanlı dağılımını önerir: tabanda çok sayıda hızlı \u003Cem>unit\u003C/em> testi, ortada daha az sayıda \u003Cem>servis/integration\u003C/em> testi, en üstte ise az sayıda fakat daha pahalı \u003Cem>UI/E2E\u003C/em> 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 (\u003Ca href=\"https://martinfowler.com/bliki/TestPyramid.html\">kaynak\u003C/a>).\u003C/p>\n\u003Cp>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 (\u003Ca href=\"https://pmc.ncbi.nlm.nih.gov/articles/PMC12713685/\">kaynak\u003C/a>).\u003C/p>\n\n\u003Ch3>Piramidi CI/CD’ye nasıl çevirirsiniz?\u003C/h3>\n\u003Cp>Piramidi bir “test sayısı hedefi” olarak değil, \u003Cstrong>pipeline maliyeti ve güven\u003C/strong> olarak düşünmek daha işlevseldir:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>PR (hızlı kapı):\u003C/strong> Unit + seçilmiş kritik entegrasyon kontrolleri + küçük bir E2E smoke set.\u003C/li>\n\u003Cli>\u003Cstrong>Merge sonrası / ana dal:\u003C/strong> Daha geniş entegrasyon seti ve daha geniş E2E.\u003C/li>\n\u003Cli>\u003Cstrong>Zamanlanmış (tam güven):\u003C/strong> Tam E2E regresyonu + raporların/çıktıların arşivlenmesi.\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Test katmanlarını netleştiren kısa tablo\u003C/h3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Katman\u003C/th>\n\u003Cth>Amaç\u003C/th>\n\u003Cth>CI’de tipik kullanım\u003C/th>\n\u003Cth>Başarısızlıkta ipucu\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Unit\u003C/td>\n\u003Ctd>Fonksiyon/sınıf düzeyi doğruluk, hızlı geri bildirim\u003C/td>\n\u003Ctd>Her PR’da zorunlu\u003C/td>\n\u003Ctd>Genellikle kod değişikliğine doğrudan işaret eder\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Integration/Servis\u003C/td>\n\u003Ctd>Bileşenlerin birlikte çalışması, API sözleşmeleri\u003C/td>\n\u003Ctd>PR’da kritik subset, ana dal/planlı koşuda geniş set\u003C/td>\n\u003Ctd>Konfigürasyon, bağımlılık, veri akışı sorunlarını açığa çıkarabilir\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>UI/E2E\u003C/td>\n\u003Ctd>Kullanıcı akışlarının uçtan uca doğrulanması\u003C/td>\n\u003Ctd>PR’da smoke; planlı koşuda regresyon\u003C/td>\n\u003Ctd>Ortam/veri/perf dalgalanması etkileyebilir; teşhis için iyi çıktı gerekir\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\n\u003Chr>\n\n\u003Ch2>CI/CD’de pratik tasarım: “Hızlı kapı” + “derin doğrulama”\u003C/h2>\n\u003Cp>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 (\u003Ca href=\"https://docs.github.com/en/actions/get-started/continuous-integration\">kaynak\u003C/a>).\u003C/p>\n\n\u003Ch3>1) PR iş akışı: hızlı ve mümkün olduğunca deterministik\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>Tetikleyici:\u003C/strong> Pull request açma/güncelleme.\u003C/li>\n\u003Cli>\u003Cstrong>Hedef süre:\u003C/strong> Ekibin akışını bölmeyecek kadar kısa (eşik, ürün ve ekip ritmine göre değişir).\u003C/li>\n\u003Cli>\u003Cstrong>İçerik:\u003C/strong> Lint + unit + kritik entegrasyon + E2E smoke.\u003C/li>\n\u003C/ul>\n\u003Cp>Burada amaç “her şeyi” test etmek değil; \u003Cstrong>yüksek sinyal\u003C/strong> üretmektir. Smoke seti genellikle en kritik 3–10 kullanıcı akışını kapsayan küçük bir gruptur.\u003C/p>\n\n\u003Ch3>2) Ana dal / planlı iş akışı: geniş kapsama ve raporlama\u003C/h3>\n\u003Cul>\n\u003Cli>\u003Cstrong>Tetikleyici:\u003C/strong> Ana dala push ve/veya zamanlanmış çalışma (cron).\u003C/li>\n\u003Cli>\u003Cstrong>İçerik:\u003C/strong> Daha geniş entegrasyon seti, E2E regresyonu, raporların saklanması.\u003C/li>\n\u003Cli>\u003Cstrong>Çıktı:\u003C/strong> Raporlar, loglar ve (E2E’de) iz/trace benzeri teşhis çıktıları.\u003C/li>\n\u003C/ul>\n\u003Cp>Bu koşu daha uzun sürebilir; amaç, PR kapısına sığmayan riskli alanları düzenli ve izlenebilir şekilde doğrulamaktır.\u003C/p>\n\n\u003Chr>\n\n\u003Ch2>Araç seçimi: Playwright, Selenium ve test stratejiniz\u003C/h2>\n\u003Cp>UI/E2E tarafında modern ekiplerin değerlendirdiği araçlardan biri \u003Cstrong>Playwright\u003C/strong>’tır. Playwright’ın resmi CI rehberi; CI entegrasyonu, raporlama ve trace alma gibi pratiklere odaklanır (\u003Ca href=\"https://playwright.dev/docs/next/ci-intro\">kaynak\u003C/a>). Bu tür çıktılar, özellikle CI koşullarında (kısıtlı yeniden üretim, headless çalıştırma, farklı runner performansı) sorunun \u003Cem>nerede\u003C/em> ve \u003Cem>hangi adımda\u003C/em> oluştuğunu görmeyi \u003Cem>kolaylaştırabilir\u003C/em>; yine de ortam/veri dalgalanması varsa tek başına “garanti” değildir.\u003C/p>\n\u003Cp>\u003Cstrong>Selenium\u003C/strong> 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:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Mevcut teknoloji yığını:\u003C/strong> Dil/runner uyumu, ekip deneyimi.\u003C/li>\n\u003Cli>\u003Cstrong>CI’de teşhis kolaylığı:\u003C/strong> Rapor, iz/trace, ekran görüntüsü, log toplama.\u003C/li>\n\u003Cli>\u003Cstrong>Paralelleştirme:\u003C/strong> Testleri parçalayıp koşma (toplam süreyi düşürmek için).\u003C/li>\n\u003Cli>\u003Cstrong>Bakım maliyeti:\u003C/strong> Flaky testlerle mücadele pratikleri.\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>GitHub Actions ile örnek pipeline iskeleti (okunabilir parçalar)\u003C/h2>\n\u003Cp>GitHub Actions’ta bir CI tasarımını anlamanın en kolay yolu, akışı “tetikleyiciler” ve “job’lar” olarak bölmektir (resmi CI özeti: \u003Ca href=\"https://docs.github.com/en/actions/get-started/continuous-integration\">GitHub Docs\u003C/a>).\u003C/p>\n\u003Cp>\u003Cstrong>Not:\u003C/strong> Aşağıdaki yapı \u003Cem>kopyala-yapıştır\u003C/em> amaçlı tam bir YAML değildir; \u003Cstrong>pseudocode\u003C/strong> gibi, proje komutlarınıza göre uyarlamanız gereken bir iskelet olarak düşünün.\u003C/p>\n\n\u003Ch3>A) Tetikleyici kurgusu (ne zaman çalışacak?)\u003C/h3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Akış\u003C/th>\n\u003Cth>Tetikleyici\u003C/th>\n\u003Cth>Hedef\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>PR doğrulama\u003C/td>\n\u003Ctd>pull_request\u003C/td>\n\u003Ctd>Hızlı kapı: unit + kritik integration + E2E smoke\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Ana dal doğrulama\u003C/td>\n\u003Ctd>push (main)\u003C/td>\n\u003Ctd>Daha geniş doğrulama ve raporlama\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Planlı tam koşu\u003C/td>\n\u003Ctd>schedule (cron)\u003C/td>\n\u003Ctd>Tam E2E regresyonu + arşivleme\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\n\u003Ch3>B) Job ayrımı (neyi ayrı koşturacaksınız?)\u003C/h3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Job\u003C/th>\n\u003Cth>Koşu\u003C/th>\n\u003Cth>İçerik\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>unit\u003C/td>\n\u003Ctd>PR + main\u003C/td>\n\u003Ctd>Hızlı, güvenilir temel testler\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>integration\u003C/td>\n\u003Ctd>PR (subset) + main/schedule (geniş)\u003C/td>\n\u003Ctd>Servis bağımlılıkları / sözleşme kontrolleri\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>e2e_smoke\u003C/td>\n\u003Ctd>PR\u003C/td>\n\u003Ctd>Kritik kullanıcı akışları (küçük set)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>e2e_full\u003C/td>\n\u003Ctd>main + schedule\u003C/td>\n\u003Ctd>Geniş regresyon + rapor/trace arşivi\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\n\u003Ch3>C) Job adımları (her job’da ortak “iskelet”)\u003C/h3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Adım\u003C/th>\n\u003Cth>Örnek amaç\u003C/th>\n\u003Cth>Not\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Checkout\u003C/td>\n\u003Ctd>Kodu al\u003C/td>\n\u003Ctd>Repo state’i sabitlenir\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Dependencies\u003C/td>\n\u003Ctd>Bağımlılıkları kur\u003C/td>\n\u003Ctd>Cache, süreyi düşürmeye yardımcı olabilir (uygun tasarlanırsa)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Run tests\u003C/td>\n\u003Ctd>Testleri koştur\u003C/td>\n\u003Ctd>PR’da kısa; schedule’da geniş\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Collect artifacts\u003C/td>\n\u003Ctd>Rapor/log sakla\u003C/td>\n\u003Ctd>CI’da teşhis için kritik\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\n\u003Ch3>Secrets yönetimi: “loglara düşmesin” prensibi\u003C/h3>\n\u003Cp>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: \u003Ca href=\"https://docs.github.com/en/actions/get-started/continuous-integration\">GitHub Docs\u003C/a>, \u003Ca href=\"https://playwright.dev/docs/next/ci-intro\">Playwright CI\u003C/a>):\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Secrets değerlerini repoya yazmayın\u003C/strong>; CI’nin secrets mekanizmasını kullanın.\u003C/li>\n\u003Cli>\u003Cstrong>Log ve artifact kapsamını düşünün\u003C/strong>; hata anında toplanan çıktılarda hassas veri bulunmadığından emin olun.\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>Ölçeklenebilirlik: test seti büyüdükçe ne değişir?\u003C/h2>\n\u003Cp>Test sayısı arttıkça sık görülen iki problem: \u003Cstrong>sürelerin uzaması\u003C/strong> ve \u003Cstrong>güvenin azalması\u003C/strong> (özellikle flaky testler). Ölçeklenebilir bir tasarım için aşağıdaki yapı taşlarını birlikte düşünün.\u003C/p>\n\n\u003Ch3>1) Paralelleştirme ve parçalama (shard)\u003C/h3>\n\u003Cp>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 (\u003Ca href=\"https://docs.github.com/en/actions/get-started/continuous-integration\">kaynak\u003C/a>). 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.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>İş ayrımı:\u003C/strong> tarayıcı bazında, özellik bazında veya test dosyası bazında.\u003C/li>\n\u003Cli>\u003Cstrong>Kaynak planlama:\u003C/strong> runner kapasitesi ve kuyruk süreleri; yoğun saatlerde PR kapısının yavaşlamaması için kritik olabilir.\u003C/li>\n\u003C/ul>\n\n\u003Ch3>2) Cache ve artifact stratejisi\u003C/h3>\n\u003Cp>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:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Cache’lediğim şey deterministik mi?\u003C/strong> Yanlış cache, “tesadüfen geçen” koşulara yol açabilir.\u003C/li>\n\u003Cli>\u003Cstrong>Artifact’ler teşhis için yeterli mi?\u003C/strong> Özellikle E2E’de rapor + iz/trace, yeniden üretimin zor olduğu CI koşullarında değerli olabilir (Playwright CI rehberi: \u003Ca href=\"https://playwright.dev/docs/next/ci-intro\">kaynak\u003C/a>).\u003C/li>\n\u003C/ul>\n\n\u003Ch3>3) Flaky test yönetimi: görünürlük + disiplin + uygulanabilir kurallar\u003C/h3>\n\u003Cp>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 \u003Cstrong>ölçmek\u003C/strong> ve \u003Cstrong>etkisini sınırlamak\u003C/strong> olmalıdır.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Karantina (quarantine) için etiketleme:\u003C/strong> Flaky olduğu şüpheli testleri \u003Cem>@quarantine\u003C/em> 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.\u003C/li>\n\u003Cli>\u003Cstrong>Retry’ı sınırlayın ve şeffaf tutun:\u003C/strong> Retry kullanacaksanız üst sınır koyun (örn. \u003Cstrong>en fazla 1–2\u003C/strong> 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.\u003C/li>\n\u003Cli>\u003Cstrong>Başarısızlık başına minimum artifact paketi tanımlayın:\u003C/strong> En azından \u003Cstrong>test raporu\u003C/strong>, ilgili \u003Cstrong>loglar\u003C/strong> ve E2E için mümkünse \u003Cstrong>iz/trace\u003C/strong> gibi teşhis çıktıları saklayın. Bu, CI’da tekrar çalıştırma ihtiyacını azaltabilir (Playwright CI’da rapor/trace odakları: \u003Ca href=\"https://playwright.dev/docs/next/ci-intro\">kaynak\u003C/a>).\u003C/li>\n\u003C/ul>\n\u003Cp>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, \u003Cstrong>izole test verisi\u003C/strong> ve \u003Cstrong>deterministik kurulum\u003C/strong> iyileştirmenin temelidir.\u003C/p>\n\n\u003Chr>\n\n\u003Ch2>“Test Piramidi 2.0”: güvenlik ve AI destekli yaklaşımlar (temkinli çerçeve)\u003C/h2>\n\u003Cp>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 (\u003Ca href=\"https://pmc.ncbi.nlm.nih.gov/articles/PMC12713685/\">The Test Pyramid 2.0\u003C/a>). Bunu pratikte şöyle ele almak daha güvenlidir:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Güvenliği pipeline’a gömme:\u003C/strong> PR’da hızlı sinyal veren kontroller; daha ağır taramalar ise planlı koşularda.\u003C/li>\n\u003Cli>\u003Cstrong>AI destekli verimlilik (pilot yaklaşımı):\u003C/strong> 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.\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>Adım adım uygulama planı\u003C/h2>\n\u003Ch3>Adım 1: Test envanteri çıkarın\u003C/h3>\n\u003Cul>\n\u003Cli>Hangi testler unit, hangileri integration, hangileri E2E?\u003C/li>\n\u003Cli>PR’da koşması şart olan “kritik akışlar” hangileri?\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Adım 2: PR kapısını tanımlayın\u003C/h3>\n\u003Cul>\n\u003Cli>Unit testler: zorunlu.\u003C/li>\n\u003Cli>Integration: kritik subset.\u003C/li>\n\u003Cli>E2E: smoke set (etiketleme/filtreleme ile).\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Adım 3: Ana dal ve planlı koşuyu kurgulayın\u003C/h3>\n\u003Cul>\n\u003Cli>Ana dal: geniş suite + raporlama.\u003C/li>\n\u003Cli>Planlı: tam E2E regresyonu + artifact arşivi.\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Adım 4: Süre hedefleri koyun ve darboğazı ölçün\u003C/h3>\n\u003Cul>\n\u003Cli>Hangi job en çok zaman alıyor?\u003C/li>\n\u003Cli>Paralelleştirme mi gerekir, yoksa testlerin kendisi mi optimize edilmeli?\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Adım 5: Flaky test politikasını yazılı hale getirin\u003C/h3>\n\u003Cul>\n\u003Cli>Retry ne zaman ve kaç kez kullanılacak?\u003C/li>\n\u003Cli>Karantina etiketi hangi kriterle verilecek, nasıl kaldırılacak?\u003C/li>\n\u003Cli>Her flaky test için “sahiplik” (owner) ve hedef çözüm süresi olacak mı?\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>Sık yapılan hatalar ve daha sağlam alternatifler\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Her şeyi E2E ile test etmeye çalışmak:\u003C/strong> E2E pahalıdır; çoğu mantık unit/integration’da daha hızlı ve stabil yakalanır (Test Piramidi mantığı; \u003Ca href=\"https://martinfowler.com/bliki/TestPyramid.html\">Fowler\u003C/a>).\u003C/li>\n\u003Cli>\u003Cstrong>PR’da tam regresyonu zorunlu kılmak:\u003C/strong> Geliştirme hızını düşürebilir; PR kapısı + planlı tam koşu daha sürdürülebilir olabilir.\u003C/li>\n\u003Cli>\u003Cstrong>Rapor/iz toplamamak:\u003C/strong> “Kaldı ama neden?” sorusu yanıtsızsa CI ekibe yük olur; E2E’de rapor/trace bu noktada fayda sağlayabilir (\u003Ca href=\"https://playwright.dev/docs/next/ci-intro\">Playwright CI\u003C/a>).\u003C/li>\n\u003Cli>\u003Cstrong>Secrets’leri yanlış ele almak:\u003C/strong> Hassas verilerin loglara/artifact’lere sızmaması için CI secrets mekanizmalarını doğru kullanın (\u003Ca href=\"https://docs.github.com/en/actions/get-started/continuous-integration\">GitHub Docs\u003C/a>).\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>Kısa kontrol listesi\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Cstrong>PR kapısı:\u003C/strong> Unit + kritik integration + E2E smoke hazır.\u003C/li>\n\u003Cli>\u003Cstrong>Ana dal / planlı koşu:\u003C/strong> Geniş regresyon ve rapor/çıktı arşivi var.\u003C/li>\n\u003Cli>\u003Cstrong>Artifact standardı:\u003C/strong> En az rapor + log; E2E’de mümkünse iz/trace.\u003C/li>\n\u003Cli>\u003Cstrong>Ölçek planı:\u003C/strong> Paralelleştirme stratejisi ve runner kapasitesi net.\u003C/li>\n\u003Cli>\u003Cstrong>Flaky politikası:\u003C/strong> Karantina etiketi + sınırlı retry + sahiplik kuralı yazılı.\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>Kaynaklar\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"https://playwright.dev/docs/next/ci-intro\">Playwright Docs: Setting up CI\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://docs.github.com/en/actions/get-started/continuous-integration\">GitHub Docs: Continuous integration (GitHub Actions)\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://martinfowler.com/bliki/TestPyramid.html\">Martin Fowler: Test Pyramid\u003C/a>\u003C/li>\n\u003Cli>\u003Ca href=\"https://pmc.ncbi.nlm.nih.gov/articles/PMC12713685/\">The Test Pyramid 2.0: AI-assisted testing across the pyramid (2025)\u003C/a>\u003C/li>\n\u003C/ul>\n\u003Cp>\u003Cstrong>Not:\u003C/strong> Bu yazı genel bilgilendirme amaçlıdır; pipeline tasarımını takım yapısı, mimari ve risk profiline göre uyarlamak gerekir.\u003C/p>","Otomatik Test Pipeline’ı: CI/CD, Test Piramidi, Ölçekleme","CI/CD’de otomatik test pipeline kurmak için pratik rehber: test piramidiyle PR kapısı, GitHub Actions akışları, E2E rapor/trace ve ölçekleme adımları.","otomatik test pipeline, CI/CD, test piramidi, GitHub Actions, Playwright, E2E test, unit test, integration test, test otomasyonu, flaky test","otomatik-test-pipelinelari-kurma-cicd-test-piramidi-ve-olceklenebilirlik","2026-03-11T14:30:42.000Z",{"id":16,"title":17,"slug":18},603,"Yazılım Test ve Kalite Güvencesi","yazilim-test-ve-kalite-guvencesi",{"id":20,"name":21,"nickname":22,"slug":23},151,"Ayben Akpınar","AybenA","ayben-akpinar","/media/blog/37f1d6b8e43b0e1f9e04ca3fed702dbc.jpg","/media/blog/37f1d6b8e43b0e1f9e04ca3fed702dbc_thumb.jpg","/media/blog/37f1d6b8e43b0e1f9e04ca3fed702dbc.webp","/media/blog/37f1d6b8e43b0e1f9e04ca3fed702dbc_thumb.webp",null,{"minutes":30,"wordCount":31,"imageCount":32,"formatted":33},8,1578,0,"8 dk okuma süresi","/blog/yazilim-test-ve-kalite-guvencesi/otomatik-test-pipelinelari-kurma-cicd-test-piramidi-ve-olceklenebilirlik",[],["Reactive",37],{"title":7,"subTitle":17,"image":24},["Reactive",39],{"title":10,"meta":40,"link":75},[41,43,45,48,51,54,57,60,63,66,69,71,73],{"hid":42,"name":42,"content":11},"description",{"hid":44,"name":44,"content":12},"keywords",{"hid":46,"name":46,"content":47},"author","Yazılım Rehberi",{"hid":49,"name":49,"content":50},"robots","index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1",{"hid":52,"property":52,"content":53},"og:type","website",{"hid":55,"property":55,"content":56},"og:title","Yazılım Rehberi: Blog ve Sosyal Medya İçin Yeni Yazılımlar",{"hid":58,"property":58,"content":59},"og:description","Blog yazarları ve sosyal medya içerik üreticileri için yeni yazılımlar, kullanım önerileri ve pratik rehberler sunan güncel bilgi blogu.",{"hid":61,"property":61,"content":62},"og:image","https://yeniyazilimlar.com/media/blog/37f1d6b8e43b0e1f9e04ca3fed702dbc.jpg",{"hid":64,"property":64,"content":65},"og:url","https://yeniyazilimlar.com/blog/yazilim-test-ve-kalite-guvencesi/otomatik-test-pipelinelari-kurma-cicd-test-piramidi-ve-olceklenebilirlik",{"hid":67,"name":67,"content":68},"twitter:card","summary_large_image",{"hid":70,"name":70,"content":56},"twitter:title",{"hid":72,"name":72,"content":59},"twitter:description",{"hid":74,"name":74,"content":62},"twitter:image",[76,78],{"rel":77,"href":65},"canonical",{"rel":79,"href":80},"amphtml","https://amp.yeniyazilimlar.com/blog/yazilim-test-ve-kalite-guvencesi/otomatik-test-pipelinelari-kurma-cicd-test-piramidi-ve-olceklenebilirlik",["Reactive",82],{"@context":83,"@graph":84},"https://schema.org",[85,98],{"@type":86,"headline":10,"image":62,"author":87,"publisher":90,"datePublished":14,"dateModified":14,"mainEntityOfPage":96,"description":11},"BlogPosting",{"@type":88,"name":21,"url":89},"Person","https://yeniyazilimlar.com/yazarlar/ayben-akpinar",{"@type":91,"name":47,"logo":92},"Organization",{"@type":93,"url":94,"width":95,"height":95},"ImageObject","https://yeniyazilimlar.com/img/icons/favicon.png",32,{"@type":97,"@id":65},"WebPage",{"@type":99,"itemListElement":100},"BreadcrumbList",[101,106,110,113],{"@type":102,"position":103,"name":104,"item":105},"ListItem",1,"Ana Sayfa","https://yeniyazilimlar.com",{"@type":102,"position":107,"name":108,"item":109},2,"Blog","https://yeniyazilimlar.com/blog",{"@type":102,"position":111,"name":17,"item":112},3,"https://yeniyazilimlar.com/blog/yazilim-test-ve-kalite-guvencesi",{"@type":102,"position":114,"name":7,"item":65},4]