> tpl_qav_005
Test Otomasyon Stratejisi ve Kapsam Matrisi
Test piramidi katman dağılımını (birim, sözleşme, entegrasyon, uçtan uca), yürütme süre bütçelerini, CI/CD tetikleyicilerini, kararsız (flaky) test karantina politikalarını ve YG (ROI) metriklerini belirleyen kurumsal test otomasyon mimarisi ve kapsam yönetişim modeli.
Piramit dağılımlarını, CI/CD yürütme bütçelerini, kararsız test karantinasını ve kapsam metriklerini kurallara bağlayan kurumsal test otomasyon stratejisi.
Önemli Teknik Doküman Şablonu ve Hukuki Uyarı
TinyCTO.tv Teknik Doküman Şablon Bildirimi: Bu şablon genel eğitim ve operasyon amaçlı bir başlangıç materyalidir. Hukuki, vergisel, muhasebesel, yatırım, satın alma, mevzuat, güvenlik veya sertifikasyon danışmanlığı değildir. Gereklilikler ülkeye, kuruma, sözleşmeye ve riske göre değişir. Kullanmadan önce yetkin uzmanlarla gözden geçirip uyarlayın.
Çözülen Üretim Problemi
Mühendislik ekipleri saatlerce çalışan, küçük bir CSS değişikliğinde kırılan, pull request'leri tıkayan ve geliştirici güvenini yok eden kırılgan uçtan uca UI testlerini otomatikleştirirken, kritik API sınır durumları ve birim mantığı tamamen testsiz kalır.
Ne Zaman Kullanılmalı?
- •Frontend, backend ve dağıtık servisler genelinde otomatik test mimarisini sıfırdan kurarken veya yeniden yapılandırırken
- •CI/CD dağıtım hattı test kapılarını (PR birleştirme, gecelik regresyon, sürüm öncesi onay) tanımlarken
- •Test paketlerinin yavaşlamasını gidermek ve titiz karantina protokolleriyle kararsız (flaky) testleri yok etmek için
Ne Zaman Kullanılmamalı?
- •Manuel iş birimi kullanıcı kabul testlerini (UAT) ve onay sertifikasyonunu planlarken (TPL-QAV-004 kullanın)
- •Yapılandırılmış keşif testi şartnameleri ve sınır analizi senaryoları tasarlarken (TPL-QAV-003 kullanın)
5 Şablon Bölümü ve Yapısal İskelet
İdeal test paketi dağılımı: Birim Testleri (%70), Servis/Sözleşme/Entegrasyon Testleri (%20) ve Uçtan Uca UI Testleri (%10). Katman başına çalışma hızı kriterleri.
Diller genelinde standartlaştırma: Web UI için Playwright/Cypress, birim testleri için Vitest/Jest, sözleşme testleri için Pact, API için k6. Test verisi yükleme ve konteynerize geçici ortamlar.
Kesin süre bütçeleri: Pull Request hızlı geri bildirim kapısı (birim/sözleşme için < 5 dakika), Birleştirme Öncesi entegrasyon (< 15 dakika) ve Gecelik kapsamlı E2E regresyonu (< 45 dakika).
Otomatik yeniden deneme kuralları (en fazla 1 yeniden deneme), anında otomatik karantina etiketleme, karantinadaki testleri düzeltme SLA'sı (72 saat) ve kalıcı silme kriterleri.
Otomasyon etkinliğinin takibi: Hata Tespit Yüzdesi (DDP), Kararsızlık Oranı (< %1), Test Çalışma Süresi Eğilimi ve Canlıya Sızan Hata Oranı.
Doldurma ve Uygulama Yönergeleri
Bağımsız İnceleme ve Onay Kontrol Listesi
- Tüm zorunlu bölümler dolduruldu
- Gizli anahtar veya parola içermiyor
- Yönetici sponsor onayı alındı
Test Otomasyon Stratejisi ve Kapsam Matrisi - Örnek Vaka Analizi
Örnek Organizasyon: FinTech Yüksek Frekanslı Ödeme İşleme Platformu
FinTech Yüksek Frekanslı Ödeme İşleme Platformu için eksiksiz operasyonel uygulamayı gösteren gerçek dünya vaka analizi.
- •2.400 otomatik testi %70/20/10 piramidine göre yeniden yapılandırarak CI test süresini 54 dakikadan 8 dakikaya düşürdü
- •Otomatik Playwright kararsızlık karantinası hattı ile hatalı pozitif derleme kesintilerini %94 oranında ortadan kaldırdı
- •İki sürüm çeyreği içinde canlı ortama sızan kritik hata oranını %68 azalttı
Sıkça Sorulan Sorular
Uçtan uca (E2E) UI testleri neden tüm test paketinin yalnızca %10'unu oluşturmalıdır?
E2E testleri tüm dağıtık sistemlerle etkileşime girer; bu da onları kat kat daha yavaş, maliyetli ve ağ gecikmelerine veya ufak arayüz değişikliklerine karşı aşırı hassas yapar. %70 birim ve %20 sözleşme/entegrasyon temeli hızlı ve kararlı geri bildirim sağlarken, E2E yalnızca kritik kullanıcı yolculuklarını doğrulamalıdır.
Mühendislik ekipleri rastgele başarısız olan "kararsız" (flaky) testleri nasıl yönetmelidir?
Kararsız testler geliştirici güvenini yıkar. Bu stratejiye göre, kod değişikliği olmadan rastgele başarısız olan bir test anında dağıtımı engellemeyen karantina grubuna alınır. Bir SDET görevlendirilir ve kök nedeni (yarış durumu, taklit edilmemiş zamanlayıcılar) çözmek veya testi silmek için 72 saat süre verilir.
Tüketici Odaklı Sözleşme Testinin (Pact) modern test otomasyonundaki rolü nedir?
Mikroservis mimarilerinde uçtan uca entegrasyon ortamlarını ayakta tutmak çok zordur. Sözleşme testi, istemcilerin API beklentilerini sözleşme olarak yayınlamasını sağlar; sağlayıcı servis tüm sistemi ayağa kaldırmadan bu sözleşmeyi izole bir şekilde doğrular.
Teknik Doküman Şablon Paketi
Giriş GerekliTüm boş şablonları, işlenmiş senaryoları ve doğrulama manifestolarını tek bir arşivde indirin.
Yetkili Standartlar ve Kaynaklar
- Martin Fowler: The Practical Test PyramidMartin Fowler • OFFICIAL REQUIREMENT
- Google Testing Blog: Just Say No to More End-to-End TestsGoogle Testing Blog • OFFICIAL REQUIREMENT
- ISO/IEC/IEEE 29119-4 Software Testing Standards: Test TechniquesISO/IEC/IEEE • OFFICIAL REQUIREMENT