“Test otomasyonu kuralım mı?” sorusu, küçük ekiplerin ve ürün sahiplerinin en sık sorduğu sorulardan biri. Cevap ne “kesinlikle evet” ne de “gerek yok”. Otomasyon doğru yere kurulduğunda her sürümde saatler kazandırır; yanlış yere kurulduğunda ise bakımı yapılmayan, sürekli kırmızı yanan ve sonunda kimsenin bakmadığı bir test yığınına dönüşür. Bu yazıda manuel ve otomatik testin neyi kapsadığını, otomasyonun ne zaman kendini amorti ettiğini, Selenium, Playwright ve Appium arasında nasıl seçim yapacağınızı ve işe nereden başlayacağınızı pratik bir dille anlatıyorum.
Manuel test ve otomatik test neyi kapsar?
Manuel test, bir insanın uygulamayı gerçekten kullanarak kontrol etmesidir. İnsan gözü; tasarımdaki tuhaflıkları, kafa karıştıran metinleri, “çalışıyor ama mantıksız” akışları yakalar. Keşif amaçlı test, kullanılabilirlik değerlendirmesi ve yeni özelliklerin ilk kontrolü için manuel test vazgeçilmezdir.
Otomatik test ise önceden tanımlanmış adımları bir kodun tekrar tekrar, aynı şekilde çalıştırmasıdır. Yorulmaz, adım atlamaz ve dakikalar içinde onlarca senaryoyu birden koşturabilir. Ama yalnızca kendisine söylenen şeyi kontrol eder; yeni bir hatayı “fark etmez”, bildiği bir davranışın bozulup bozulmadığını doğrular.
Kısacası ikisi birbirinin rakibi değil, tamamlayıcısıdır: otomasyon tekrarlayan kontrolleri üstlenir, insan da zamanını gerçekten düşünmesi gereken yerlere ayırır.
Otomasyon ne zaman kendini amorti eder?
Her test yazımı bir yatırımdır: yazmak zaman alır, uygulama değiştikçe güncellemek de zaman alır. Bu yatırım genellikle şu durumlarda geri döner:
- Aynı akışı sık sık test ediyorsanız. Her sürümde giriş, kayıt, sepet ve ödeme adımlarını elle tıklıyorsanız, bu adımlar otomasyonun ilk adayıdır.
- Bozulması pahalı olan akışlar varsa. Ödeme almayan bir sepet ya da çalışmayan bir şifre sıfırlama, doğrudan para ve müşteri kaybı demektir.
- Sık sürüm çıkıyorsanız. Haftada birkaç kez canlıya çıkan bir ekip, her seferinde uzun bir manuel kontrol listesine zaman ayıramaz.
- Birden fazla tarayıcı veya cihaz destekliyorsanız. Aynı senaryoyu Chrome, Firefox ve Safari'de elle denemek hızla yorucu hale gelir.
- Ürün belli bir olgunluğa ulaştıysa. Arayüzü her hafta baştan değişen erken bir prototipte testler sürekli kırılır; temel akışlar oturduğunda otomasyon çok daha verimli olur.
Tersine, bir kez yapılacak bir kampanya sayfası, çok erken aşamadaki bir MVP veya görsel tasarım değerlendirmesi gibi işlerde manuel test genellikle daha mantıklıdır.
Araç seçimi: Selenium, Playwright, Appium
Selenium
Selenium, tarayıcı otomasyonunun en köklü aracıdır ve W3C WebDriver standardının temelini oluşturur. Java, Python, C#, JavaScript ve Ruby gibi birçok dili destekler; Selenium Grid ile testleri birden çok makinede paralel çalıştırabilirsiniz. Ekibiniz zaten Java veya C# ile çalışıyorsa ya da kurumsal bir test altyapınız varsa Selenium hâlâ güçlü bir seçimdir. Dezavantajı, bekleme mantığını ve raporlamayı çoğu zaman kendiniz kurmanız gerekmesidir.
Playwright
Playwright, Microsoft tarafından geliştirilen daha yeni bir araçtır. Chromium, Firefox ve WebKit motorlarını tek bir API ile yönetir; TypeScript/JavaScript, Python, Java ve .NET desteği vardır. En büyük artısı otomatik bekleme: bir öğe tıklanabilir hale gelene kadar kendisi bekler, bu da kararsız (flaky) testleri ciddi ölçüde azaltır. Hazır test çalıştırıcısı, paralel çalışma, ekran görüntüsü, video ve adım adım inceleme yapabildiğiniz trace viewer kutudan çıkar. Sıfırdan başlayan bir web projesi için çoğu durumda önerim Playwright'tır.
Appium
Web değil de yerel bir Android veya iOS uygulamanız varsa Appium devreye girer. Appium da WebDriver protokolünü kullanır; Android için UiAutomator2, iOS için XCUITest gibi sürücülerle gerçek cihazlarda ve emülatörlerde test çalıştırır. Kurulumu web araçlarına göre daha zahmetlidir ve mobil testler doğası gereği daha yavaştır, bu yüzden mobilde senaryo sayısını özellikle dikkatli seçmek gerekir.
Küçük bir Playwright örneği
Aşağıdaki test, bir kullanıcının giriş yapıp panel sayfasını görebildiğini doğrular. Gerçek projelerde de ilk yazdığım testler genellikle bu kadar sadedir:
// tests/login.spec.ts
import { test, expect } from '@playwright/test';
test('user can log in and see the dashboard', async ({ page }) => {
await page.goto('https://example.com/login');
await page.getByLabel('Email').fill('demo@example.com');
await page.getByLabel('Password').fill('correct-password');
await page.getByRole('button', { name: 'Sign in' }).click();
// Playwright waits automatically until these become true (or times out)
await expect(page).toHaveURL(/dashboard/);
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});
// Run: npx playwright testDikkat ederseniz CSS sınıfları yerine getByRole ve getByLabel gibi kullanıcının gördüğü şeylere dayalı seçiciler kullanıldı. Bu sayede tasarım değiştiğinde testler daha az kırılır.
CI entegrasyonu
Testlerin asıl değeri, birinin hatırlamasına gerek kalmadan otomatik çalıştıklarında ortaya çıkar. GitHub Actions, GitLab CI gibi bir CI sistemine her pull request'te veya ana dala her gönderimde testleri çalıştıran bir adım eklersiniz; testlerden biri başarısız olursa birleştirme durdurulur ve rapor, ekran görüntüsü ya da trace dosyası çıktı olarak saklanır. Playwright bunun için hazır CI rehberi ve örnek yapılandırmalar sunar; ilk kurulum çoğu projede bir saatten kısa sürer.
Sık yapılan hatalar
- Her şeyi test etmeye çalışmak. Yüzlerce uçtan uca test yazmak, yavaş ve bakımı zor bir paket demektir. Kritik akışları uçtan uca, detayları ise birim ve API testleriyle kapsamak daha sağlıklıdır.
- Kararsız testleri görmezden gelmek. Bazen geçip bazen kalan bir test, ekibin test sonuçlarına olan güvenini yok eder. Sabit
sleepbeklemeleri yerine koşul bazlı beklemeler kullanın, kararsız testi hemen düzeltin ya da geçici olarak devre dışı bırakıp kayda geçirin. - Kırılgan seçiciler. Uzun XPath'ler veya otomatik üretilmiş CSS sınıfları en küçük tasarım değişikliğinde kırılır. Erişilebilir roller, etiketler ya da özel
data-testidöznitelikleri tercih edin. - Testlerin birbirine bağımlı olması. Her test kendi verisini hazırlamalı ve tek başına çalışabilmelidir; aksi halde sıralama değiştiğinde her şey çöker.
- Bakım maliyetini hesaba katmamak. Test kodu da koddur; okunabilir tutulmalı ve uygulama değiştikçe güncellenmelidir.
Nereden başlamalı?
- Kaybı en pahalı olan üç ila beş kritik akışı listeleyin: genellikle giriş, kayıt, ödeme ve ana özellik.
- Bu akışları önce düz bir metin olarak adım adım yazın; bu, aynı zamanda manuel test listeniz olur.
- Web için Playwright, mobil için Appium ile bu senaryoları otomatikleştirin.
- Testleri CI'a bağlayın ve her değişiklikte çalıştırın.
- Gerçek bir hata yakalandıkça veya yeni kritik bir özellik eklendikçe paketi yavaş yavaş büyütün.
Küçük ama güvenilir bir test paketi, büyük ama kimsenin güvenmediği bir paketten her zaman daha değerlidir.
Sonuç
Test otomasyonu bir hedef değil, sürüm çıkarırken içinizin rahat olması için bir araçtır. Doğru akışlar seçildiğinde ve doğru araçla kurulduğunda küçük ekipler için bile kısa sürede kendini amorti eder. Projeniz için hangi senaryoların otomatikleştirilmesi gerektiğini birlikte belirlemek ya da mevcut testlerinizi daha güvenilir hale getirmek isterseniz benimle iletişime geçmekten çekinmeyin.
