TB
← Tüm yazılar

Manuel QA ile otomasyon dengesi

Manuel test ile test otomasyonu arasındaki dengeyi nasıl kurulacağını, her yaklaşımın güçlü ve zayif yönlerini, hibrit stratejiler ile kaynak planlamasını kapsamlı olarak ele alıyoruz.

Test otomasyonu vaadi caziptir: bir kez yaz, sonsuza kadar çalıştır. Pratikte otomasyon her şeyi kapsamaz; kullanılabilirlik, görsel tutarlılık ve keşif testi hâlâ insan zekâsı gerektirir. Tamamen manuel QA ise regresyon maliyetini patlatır. Manuel QA ile otomasyon dengesi, kaynakları doğru yere yönlendiren stratejik bir karardır.

Manuel testin güçlü yönleri

  • Keşif testi: önceden tanımlanmamış senaryoları bulur
  • Kullanılabilirlik: akışın sezgisel olup olmadığını değerlendirir
  • Görsel doğrulama: layout, renk, responsive bozulmaları
  • Bağlamsal yorum: "bu hata kabul edilebilir mi" kararı
  • Edge case sezgisi: deneyimle riskli alanları hedefler

Otomasyonun güçlü yönleri

  • Tekrarlanabilirlik: aynı adımlar her seferinde aynı
  • Hız: binlerce senaryo dakikalar içinde
  • Regresyon güveni: her commit'te kritik akış doğrulanır
  • CI entegrasyonu: merge kapısı olarak çalışır
  • Maliyet ölçekleme: gece koşusu ek insan maliyeti gerektirmez

Quadrant modeli

Brian Marick'in testing quadrant'ları manuel/otomasyon dengesini görselleştirir. Q1 (teknik birim/component) ve Q4 (teknik performans/güvenlik aracı) otomasyona uygun. Q3 (business-facing, keşif) manuele yakın. Q2 (business-facing, otomasyon) E2E ve acceptance test alanıdır.

Quadrant bazlı kaynak dağılımı

Tipik olgun ekip dağılımı: Q1 otomasyon %90, Q2 otomasyon %60 manuel review %40, Q3 manuel %70 otomasyon %30, Q4 tam otomasyon. Oranlar ürün ve risk profiline göre ayarlanır.

Ne otomatize edilmeli?

  1. Kritik business path: kayıt, ödeme, sipariş tamamlama
  2. Regresyon riski yüksek modül: son sprint'te sık değişen alan
  3. Veri kombinasyonu çok: parametrik test otomasyonu ile
  4. API sözleşmesi: contract test ve schema validation
  5. Performans baseline: benchmark otomasyonu

Ne manuel kalmalı?

  1. Yeni özellik keşif testi: ilk sprint'te otomasyon öncesi
  2. UX değerlendirmesi: onboarding akışı, erişilebilirlik
  3. Tek seferlik edge case: maliyet/fayda otomasyona uygun değil
  4. Third-party entegrasyon belirsizliği: sandbox manuel doğrulama
  5. Görsel regresyon sınır durumları: otomasyon false positive üretir

Test piramidi ve kaynak planlaması

Piramidin tabanındaki birim testler geliştirici yazar; QA müdahalesi minimal. Orta katman entegrasyon testleri geliştirici-QA iş birliği. Tepe E2E testleri QA liderliğinde otomatize edilir. Manuel effort exploratory test ve release sign-off'a yoğunlaşır.

Sprint QA kapasitesi (örnek 40 saat):
  Otomasyon bakımı:     12 saat
  Exploratory test:     10 saat
  Release regression:    8 saat
  Test plan/review:      6 saat
  Flaky analiz:          4 saat

Shift-left ile shift-right

Shift-left: test erken yapılır, geliştirici birim test yazar. Shift-right: production'da canary, feature flag, A/B test ile gerçek kullanıcı davranışı izlenir. Manuel QA shift-left'te requirement review'a katılır; shift-right'ta beta feedback analiz eder.

Risk bazlı test matrisi

Her özellik etki × olasılık matrisinde değerlendirilir. Yüksek risk → otomasyon + manuel exploratory. Düşük risk → yalnızca otomasyon smoke. Matris sprint planlamasında test effort tahminini besler.

Örnek matris

  • Ödeme hatası: yüksek etki, orta olasılık → tam otomasyon + manuel sign-off
  • Profil fotoğrafı crop: düşük etki → otomasyon smoke yeterli
  • Veri migration: yüksek etki, düşük olasılık → manuel UAT + rollback test

Otomasyon bakım maliyeti

Kötü yazılmış E2E testleri bakım bataklığıdır. Selector kırılgan, veri bağımlılığı yüksek testler sürekli kırılır. QA ekibinin zamanının yarısı otomasyon onarımına giderse denge bozulmuştur. Page Object Model, stabil selector ve test data factory yatırımı bakım maliyetini düşürür.

Manuel test dokümantasyonu

Manuel test yalnızca kafada kalmamalıdır. Test charter'ları kısa ve hedef odaklı yazılır: "30 dakika ödeme akışı edge case keşfi". Bulgular bug tracking'e session-based test management ile kaydedilir. Tekrarlanabilir manuel senaryolar zamanla otomasyona aday gösterilir.

Release sign-off süreci

Otomasyon kapıları geçildikten sonra manuel sign-off release'in son halkasıdır. Checklist: kritik user journey manuel doğrulama, yeni özellik exploratory, bilinen issue review, rollback planı onayı. Sign-off sorumluluğu QA lead'dedir; geliştirici ve product owner katılır.

Metrikler

Dengeyi ölçmek için: otomasyon regresyon süresi, manuel test saat/sprint, bug escape rate (QA sonrası üretim hatası), otomasyon flaky oranı, automation ROI (otomasyon sayesinde kazanılan manuel saat). Bug escape rate düşerken manuel saat artıyorsa otomasyon yetersizdir.

Anti-pattern'ler

  • 100% otomasyon hedefi: keşif ve UX ihmal edilir
  • 100% manuel regresyon: release döngüsü uzar, burnout oluşur
  • QA silo: geliştirici test sorumluluğu yok
  • Otomasyon without strategy: her şey E2E, piramit ters
  • Manuel test kayıtsız: aynı bug tekrar kaçar

Hibrit strateji örneği

SaaS ürününde sprint sonu: geliştirici birim+entegrasyon test yazar, CI kapıları geçer. QA 4 saat exploratory test yapar. Kritik akış Playwright suite nightly çalışır. Release günü QA 2 saat manuel smoke yapar ve sign-off verir. Toplam manuel effort 6 saat; otomasyon 200+ senaryoyu sürekli doğrular.

Ekip yapısı

Modern QA engineer hem manuel hem otomasyon becerisine sahiptir. SDET rolü otomasyon framework sahipliği yapar. Geliştirici test yazar; QA test stratejisi ve kapsam sahipliği üstlenir. Üç rol tek "test takımı" silosunda değil, feature squad içinde birlikte çalışır.

Regresyon otomasyonu tasarım ilkeleri

Regresyon suite'i büyürken seçici olmak gerekir. Her bug fix'e regresyon testi eklenir ama duplicate senaryo birleştirilir. Test tag'leri (@smoke, @regression, @nightly) koşum profilini belirler. Smoke PR kapısında, full regression release öncesi çalışır. Tag disiplini olmadan suite süresi kontrolden çıkar.

Test otomasyonu ROI hesaplama

Otomasyon yatırımının geri dönüşü ölçülmelidir. Bir E2E senaryosunun yazım süresi 8 saat, manuel koşum 20 dakika ise; sprint başına 10 tekrar varsayımıyla 3 sprint sonra otomasyon kendini amorti eder. Flaky ve bakım maliyeti ROI hesabına dahil edilmelidir. ROI negatif senaryolar otomasyondan çıkarılır veya alt katmana indirilir.

Accessibility ve manuel test

Erişilebilirlik testi otomasyonla kısmen desteklenir (axe-core, Pa11y) ancak ekran okuyucu deneyimi ve klavye navigasyonu manuel doğrulama gerektirir. WCAG uyumluluk sprint'inde QA checklist ile manuel tarama yapılır; bulgular otomatik regresyon testine dönüştürülür.

Crowd testing ve beta program

Shift-right stratejisinin parçası olarak sınırlı beta kullanıcı grubu yeni özelliği gerçek cihaz ve ağ koşullarında dener. Beta feedback manuel QA'nın genişletilmiş halidir; otomasyonun yakalayamadığı kullanıcı davranışı desenlerini ortaya çıkarır. Beta bulguları regresyon testine dönüştürülür.

Olgunluk modeli

Seviye 1: ağırlıklı manuel regresyon. Seviye 2: kritik path otomasyonu. Seviye 3: piramit dengeli, exploratory sürekli. Seviye 4: risk bazlı otomatik test seçimi ve production telemetry ile test önceliklendirme. Ekip mevcut seviyeyi dürüstçe değerlendirir; atlama yapılmaz.

Manuel QA ile otomasyon rakip değil, tamamlayıcıdır. Doğru denge ürün risk profiline, ekip olgunluğuna ve release sıklığına göre evrilir. Risk bazlı matris, test piramidi ve ölçülebilir metrikler ile denge sürdürülebilir hale getirilir.

Sprint içi QA ritmi

Sprint başında test planlama, ortasında exploratory, sonunda regresyon ritmi oturmuş ekiplerde manuel effort öngörülebilir olur. Günlük 30 dakikalık smoke manuel tur, otomasyonun atladığı görsel ve UX sorunlarını yakalar.

Otomasyon borcu

Eski E2E testleri silinmekten korkulmamalıdır. Değer katmayan test otomasyon borcudur. Üç sprint üst üste kırılan test review edilir: düzelt, alt katmana indir veya sil. Borç birikimi manuel QA'yı otomasyon onarımına mahkûm eder.