Playwright ile test otomasyonu

Giriş, ödeme ve sipariş gibi akışları her sürümde gerçek bir tarayıcıda kendiliğinden deneyen uçtan uca testler.

Playwright ile web uygulamanızın kritik akışlarını her sürümde gerçek tarayıcıda kendiliğinden deneyen uçtan uca test otomasyonu kuruyoruz.

Son güncelleme:

Ekibimizin deneyimi

Bunlar Pepechura’nın müşteri projeleri değil; ekibimiz bu şirketlerin kendi ekipleri içinde görev aldı.

Subtraid

İnşaat sektörüne yönelik SaaS platformu

Ekibimiz, Subtraid’in geliştirme ekibi içinde Playwright ve TypeScript ile yazılan, yapay zekâ destekli uçtan uca test otomasyonu üzerinde çalıştı. Testler page object yapısıyla yazılıyor ve CI hattında koşuyor.

Playwright ne işe yarar

Playwright, Microsoft’un geliştirdiği açık kaynaklı bir tarayıcı otomasyon aracı. Bir test gerçek bir tarayıcı açar, kullanıcı gibi giriş yapar, form doldurur, düğmelere tıklar ve ekranda beklenen sonucun çıkıp çıkmadığına bakar. Aynı testi Chromium, Firefox ve Safari’nin motoru WebKit üzerinde koşabilir; bir öğenin görünür ve tıklanabilir olmasını kendisi beklediği için “bazen geçen, bazen kalan” testlerin önemli bir kaynağını baştan ortadan kaldırır.

Test otomasyonunun karşılığını verdiği durumlar

  • Sık sürüm çıkıyorsunuz ve aynı akışları her seferinde elle denemek ekibin zamanını yiyor
  • Giriş, ödeme, başvuru ya da sipariş gibi bozulduğunda doğrudan müşteri kaybettiren akışlarınız var
  • Yönetici, müşteri ya da bayi gibi farklı rollerle giren kullanıcılar aynı uygulamada farklı ekranlar görüyor
  • Bir değişikliğin başka bir ekranı bozup bozmadığını yayından önce bilmek istiyorsunuz

Playwright’ın tek başına yetmeyeceği durumlar

  • Mağazadan indirilen native mobil uygulamalar: Playwright tarayıcıyı sürer, telefondaki uygulamayı değil
  • Arayüzü her hafta baştan değişen çok erken bir prototip; testler yazıldıkları hızla eskir
  • Yük ve performans testi: çok sayıda eşzamanlı kullanıcıyı taklit etmek için başka araçlar gerekir
  • Tasarımın iyi görünüp görünmediği ya da akışın anlaşılır olup olmadığı gibi insan gözü isteyen yargılar

Neyi otomatikleştirmeli, neyi elle test etmeli

Her şeyi otomatikleştirmeye çalışmak, bakımı yazılmasından pahalı bir test paketi üretir. Otomasyonu, her sürümde tekrar eden ve kırıldığında pahalıya patlayan akışlara ayırıyoruz. Yeni bir özelliğin ilk denemesi, senaryo dışına çıkan keşif testi ve kullanılabilirlik kontrolü insan işi olarak kalıyor. Projelerimizde her sürümü yayından önce senior QA test ediyor; otomasyon bu kontrolün yerini almıyor, QA’nın her hafta aynı adımları tekrar etmesini önlüyor.

Otomasyona uygunElle test daha doğru
AkışGiriş, kayıt, ödeme, sipariş, form gönderimi gibi her sürümde aynı kalan akışlarYeni çıkmış ve henüz oturmamış özellikler
Kontrol edilenKaydın oluştuğu, doğru rolün doğru ekranı gördüğü, hata mesajının çıktığıMetnin anlaşılır, yerleşimin rahat olup olmadığı
Ne zamanHer sürümde ve kod birleştirildiğinde, kendiliğindenDeğişen ekranlarda, sürüm başına
YöntemÖnceden yazılmış senaryo, her seferinde aynı adımlarBeklenmedik kullanımı deneyen keşif testi

Kararsız (flaky) testlerle nasıl başa çıkıyoruz

Bir test bazen geçip bazen kalıyorsa ekip bir süre sonra kırmızı sonuçlara bakmayı bırakır ve otomasyon değerini yitirir. Bunu önlemek için testleri baştan şu kurallarla yazıyoruz:

  • Sabit süre beklemek yerine ekranda belirli bir durumun oluşmasını bekliyoruz
  • Öğeleri değişebilen CSS sınıflarıyla değil, erişilebilir adlarla ya da ön yüze eklenen sabit test kimlikleriyle (data-testid) buluyoruz
  • Her test kendi verisini hazırlıyor; bir testin sonucu önceki testin bıraktığı veriye bağlı olmuyor
  • Kalan testin izi (trace), ekran görüntüsü ve hata bağlamı saklanıyor; neden kaldığı rapordan anlaşılıyor
  • Yeniden denemede geçen test ayrıca “flaky” olarak raporlanıyor ve kök nedeni ayrı bir iş olarak ele alınıyor

Ekibimiz, Subtraid’in geliştirme ekibi içinde Playwright tabanlı test otomasyonu üzerinde çalışırken bu kuralları uyguladı: TypeScript ile yazılan testler, ekranları page object’lere ayıran bir yapı, her kullanıcı rolü için bir kez giriş yapıp oturumu testlere paylaştıran bir kurulum ve CI hattında kısa bir kritik setle tam paketin ayrı ayrı koşması. Testlerin yazımında, mimari kuralları yazılı olarak verilmiş yapay zekâ kodlama ajanlarından yararlanıldı.

Playwright’ın yanında kullandığımız araçlar

TypeScript

Testleri uygulamanın kendisiyle aynı dilde yazıyoruz; yanlış yazılmış bir seçici ya da eksik parametre test koşmadan yakalanır.

Page object

Her ekranın alanları ve düğmeleri tek bir sınıfta durur. Arayüz değişince yalnızca o sınıf güncellenir, senaryolar aynı kalır.

CI hattı

Testler GitHub Actions ya da Bitbucket Pipelines gibi bir CI hattında, Playwright’ın resmi Docker imajında koşar; kritik set hızlı geri bildirim verir, tam paket paralel adımlarda çalışır.

Trace Viewer

Kalan testin her adımını, ağ isteklerini ve o andaki ekranı kayıttan izlemeyi sağlar; hatanın yerini tartışmadan bulmaya yarar.

Faker

Her koşuda yeni ve gerçekçi test verisi üretmek için; testler birbirinin verisine çarpmaz.

Yapay zekâ kodlama ajanları

Yeni senaryo yazmak ve ön yüze test kimliği eklemek gibi tekrar eden işlerde, yazılı mimari kurallarla çalışan ajanlardan yararlanıyoruz.

Bir test otomasyonu projesi nasıl ilerliyor

  1. 01

    Ücretsiz keşif görüşmesi

    30 dk

    Uygulamanızı, sürüm sıklığınızı ve bugün elle test ettiğiniz akışları konuşuyoruz.

  2. 02

    Kritik akışlar ve teklif

    Bozulduğunda en çok zarar veren akışları sıraya koyuyor; hangi rollerle, hangi ortamda (test ya da ön yayın) koşulacaklarını yazıya döküyoruz.

  3. 03

    Haftalık sürümler

    Her hafta yeni testler CI hattına ekleniyor. Raporu siz de görüyorsunuz ve sonraki haftanın akışlarını birlikte seçiyoruz.

  4. 04

    Kontrol ve teslim

    Senior QA sürümü yayından önce test ediyor. Testlerin nasıl çalıştırıldığını, raporun nasıl okunduğunu ve yeni test eklemenin kurallarını dokümante ediyoruz.

  5. 05

    Yayından sonraki 30 gün

    30 gün

    Bu sürede çıkan hataları ücretsiz düzeltiyoruz. Sonrasında, arayüz değiştikçe testleri güncel tutmak aylık bakımın parçası olabilir.

Süre ve bütçe aralıkları web uygulaması geliştirme ve fiyatlar sayfalarımızda yayında; bu sayfadaki her şey aynı rakamlara bağlı.

Playwright test otomasyonu hakkında sık sorulanlar

Var olan bir uygulamaya sonradan Playwright testleri eklenebilir mi?

Evet. Playwright uygulamanın hangi teknolojiyle yazıldığına bakmaz; tarayıcıda açılan her web uygulamasında çalışır. Ön yüzde sabit test kimlikleri yoksa testlerle birlikte onları da ekliyoruz; bunun için kaynak koda erişim gerekir.

Neden Selenium ya da Cypress değil de Playwright?

Öğeleri kendiliğinden beklemesi, birden fazla tarayıcı motorunu tek bir arayüzle sürmesi, testleri paralel koşturması ve kalan testin izini kaydetmesi hazır geliyor. Yine de ekibinizin oturmuş bir Cypress ya da Selenium paketi varsa, yalnızca araç değiştirmek için baştan yazmayı önermeyiz.

Mobil uygulamaları da test edebilir misiniz?

Playwright web içindir: mobil tarayıcıların ekran boyutunu ve dokunma davranışını taklit edebilir, ama mağazadan indirilen native bir uygulamayı süremez. Mobil uygulamanız varsa hangi yolun uygun olduğunu keşif görüşmesinde ayrıca konuşuruz.

Otomasyon varsa ayrıca QA’ya gerek kalır mı?

Evet. Otomasyon bildiğimiz akışların bozulmadığını kontrol eder; yeni bir özelliğin doğru kurgulanıp kurgulanmadığını ya da beklenmedik bir kullanımda ne olduğunu bulmak insan işidir. Projelerimizde her sürümü yayından önce senior QA test ediyor.

Proje bitince elimde ne kalır?

Yazılımı süresiz kullanma lisansı ve dokümantasyon. Kaynak kodun size devredilmesini isterseniz bu ek ücretle mümkündür ve teklifte ayrıca belirtilir.

İlgili hizmetler

Web uygulamasıÖzel yazılımMVP
İletişim

Test otomasyonunu konuşalım

Bugün elle test ettiğiniz akışları anlatın; 30 dakikalık ücretsiz keşif görüşmesinde hangilerinin otomasyona değeceğini birlikte belirleyelim.