Test Otomasyonu Başlangıç Rehberi: Neyi, Ne Zaman, Nasıl Test Etmeli

Bu rehber, test otomasyonuna başlamak isteyen ekipler için hazırlandı: neyin otomatikleştirileceğine nasıl karar verilir, hangi test katmanı hangi işe yarar, ilk ay nasıl planlanır ve kalite nasıl ölçülür.

1. Otomasyon Neyi Çözer, Neyi Çözmez?

Otomasyon, tekrarlayan doğrulamayı hızlı ve tutarlı yapar: her sürümde aynı yüz senaryoyu dakikalar içinde koşar. Keşif testi, kullanılabilirlik değerlendirmesi ve yeni özelliğin ilk incelemesi insan işidir. Hedef, insan zamanını tekrardan kurtarıp yargı gerektiren işe ayırmaktır.

2. Test Piramidi

Tabanda çok sayıda hızlı birim testi (iş kuralları), ortada servis ve API testleri (entegrasyon noktaları), tepede az sayıda uçtan uca arayüz testi (kritik kullanıcı yolculukları). Ters piramit (her şey arayüzden) yavaş, kırılgan ve pahalıdır.

Çıktı: Katman başına hedef kapsam ve araçlar.

3. Neyle Başlamalı?

İlk aday, en sık kırılan ve iş etkisi en yüksek akışlardır: giriş, sipariş, ödeme, fatura, rapor. Hata kayıtları ve destek talepleri listeyi verir. İlk ay için beş ila on kritik senaryo yeterlidir; her sürümde otomatik koşan küçük bir "duman testi" paketi büyük bir kapsamdan değerlidir.

4. Test Verisi ve Ortam

Otomasyonun en büyük düşmanı değişken veridir. Her koşu bilinen bir veri setiyle başlar (fabrika/tohum veri), üretim verisi maskelenmeden kullanılmaz, testler birbirine bağımlı yazılmaz. Hazırlık ortamı CI hattından otomatik kurulur.

Çıktı: Test veri stratejisi ve ortam tanımı.

5. Araçlar

Birim ve özellik testlerinde dilin kendi çatısı (PHPUnit, Pest, Jest, pytest); API testlerinde Postman koleksiyonları ya da kod tabanlı istemciler; uçtan uca testte Playwright ya da Cypress; yük testinde k6; erişilebilirlik kontrollerinde axe; mobilde Appium ve platform araçları. Araç seçimi ekibin dili ve mevcut hatla uyumuna göre yapılır.

6. Kırılgan Testlerle Mücadele

Zamanlamaya bağlı beklemeler yerine koşul bekleme, kararlı seçiciler (test kimlikleri), ağ çağrılarını sahteleme, testleri bağımsız ve tekrar çalıştırılabilir yazma. Rastgele kırılan test ya düzeltilir ya da karantinaya alınır; yeşil-kırmızı yanıp sönen hat güveni yok eder.

7. CI Hattına Bağlama

Birim ve API testleri her birleştirme isteğinde; uçtan uca testler birleştirme sonrası ve gece; yük testleri sürüm öncesi. Hat kırmızıysa birleştirme engellenir; test raporu ve kapsam değişimi her istekte görünür.

8. Ölçüler

Üretime kaçan hata sayısı, sürüm başına bulunan hata, test koşum süresi, kırılgan test oranı ve kritik akışların kapsamı. Kapsam yüzdesi tek başına hedef değildir; kritik akışların yüzde yüz güvence altında olması asıl ölçüdür.

Kontrol Listesi

• Otomasyonun kapsamı ve insan testi alanları ayrıldı.
• Katman başına hedefler ve araçlar belirlendi.
• İlk ay için beş ila on kritik senaryo seçildi; duman paketi her sürümde koşuyor.
• Test verisi stratejisi ve hazırlık ortamı tanımlı.
• Kırılgan test politikası (düzelt ya da karantina) var.
• Testler CI hattında; kırmızı hat birleştirmeyi engelliyor.
• Kalite ölçüleri aylık raporlanıyor.