Bir projeyi yayına almadan önce hangi testleri yapıyoruz? İşlevsel testler, tarayıcı uyumluluğu, performans, erişilebilirlik ve güvenlik kontrollerini açıklıyoruz.
Test, projenin sonunda yapılan tek seferlik bir kontrol değil. Geliştirme başladığı andan itibaren her tamamlanan ekran kendi içinde deneniyor; haftalık staging sürümleri de sizin erken geri bildirim vermenizi sağlıyor. Yayın öncesi yapılan kapsamlı test turu, bu sürekli kontrolün son adımı oluyor.
Testi baştan almanın nedeni maliyet. Geliştirme sırasında bulunan bir hatanın düzeltilmesi dakikalar sürüyor; yayına çıkmış bir hatanın düzeltilmesi ise hem geliştirme hem doğrulama hem de yeniden dağıtım gerektiriyor. Aynı hata, bulunduğu aşama geciktikçe pahalılaşıyor.
İşlevsel testlerde kullanıcının yapabileceği her işlemi elle deniyoruz. Kontrol ettiğimiz tipik maddeler:
Kritik akışlar için otomatik test yazıyoruz. Bir e-ticaret sitesinde ödeme akışı, bir panelde yetki kontrolü gibi bozulduğunda ağır sonuç doğuran yerlerde otomatik test, sonraki güncellemelerde emniyet ağı görevi görüyor.
Güncel Chrome, Safari, Firefox ve Edge sürümlerinde masaüstü testi yapıyoruz. Mobil tarafta iOS Safari ve Android Chrome üzerinde gerçek cihaz testi yapıyoruz; tarayıcı geliştirici araçlarındaki cihaz benzetimi ön kontrol için yeterli, ama son kontrol için değil. Dokunmatik hedef boyutları, sabit başlıkların klavye açıldığında davranışı ve yatay kaydırma sorunları ancak gerçek cihazda görülüyor.
Ekran genişliklerini üç kırılım yerine sürekli olarak deniyoruz: pencereyi yavaşça daraltıp genişleterek bozulan noktaları yakalıyoruz. Kırılım noktaları arasında kalan genişliklerde bozulan tasarımlar, sadece belirlenen üç boyutta test edildiği için gözden kaçıyor.
Performans ölçümünü hem laboratuvar hem saha verisiyle yapıyoruz. Laboratuvar tarafında Lighthouse ile kısıtlı ağ ve orta seviye cihaz benzetimi altında ölçüm alıyoruz; masaüstü hızlı bağlantıda alınan skorlar gerçeği yansıtmıyor.
Takip ettiğimiz üç ana metrik: LCP, sayfanın en büyük görsel ögesinin ne kadar sürede göründüğünü; INP, kullanıcının etkileşimine yanıt süresini; CLS ise yükleme sırasındaki görsel kaymayı ölçüyor. Bu üçünün de "iyi" aralığında olması hedefimiz. Ayrıca sunucu yanıt süresi, toplam sayfa ağırlığı ve istek sayısını ayrıca kaydediyoruz.
Yayından sonra saha verisini de izliyoruz. Laboratuvar skoru iyi olan bir sayfanın saha verisinde kötü çıkması mümkün; genellikle nedeni gerçek kullanıcıların daha yavaş bağlantıları veya sonradan eklenen üçüncü taraf betikleri oluyor.
Erişilebilirliği WCAG 2.2 AA seviyesini hedefleyerek çalışıyoruz. Otomatik araçlar sorunların ancak bir bölümünü yakaladığı için elle kontroller de yapıyoruz:
Bu maddelerin çoğu ek maliyet yaratmıyor; baştan doğru kurulduğunda sonradan düzeltmekten çok daha ucuz oluyor. Erişilebilirlik ayrıca arama motoru görünürlüğünü ve genel kullanılabilirliği de olumlu etkiliyor.
Teknik SEO kontrol listemiz yayın öncesi mutlaka işletiliyor. Her sayfanın benzersiz başlık ve açıklama etiketi olması, canonical adreslerin doğru kurulması, site haritasının üretilmesi ve arama konsoluna bildirilmesi, robots.txt dosyasının istenmeyen dizinleri kapatması ve staging ortamının dizine alınmaya kapalı olması listenin ilk maddeleri.
Mevcut bir sitenin yerine geçen projelerde eski adreslerin listesini çıkarıp 301 yönlendirmelerini kuruyoruz. Yayın sonrası ilk hafta arama konsolundaki tarama hatalarını günlük izliyoruz; bu dönemde çıkan 404 hataları hızlıca kapatıldığında görünürlük kaybı en aza iniyor.
Kapsamlı bir sızma testi ayrı bir uzmanlık alanı ve bunu bir güvenlik firmasının yapmasını öneriyoruz. Bizim yaptığımız, yaygın hataların kontrolü: giriş doğrulaması, parametreli sorgu kullanımı, oturum ve yetki kontrolleri, dosya yükleme kısıtları, hata mesajlarının sistem bilgisi sızdırmaması ve HTTP güvenlik başlıklarının kurulması.
Bağımlılıkları da tarıyoruz. Kullanılan kütüphanelerin bilinen açıkları için otomatik tarama çalıştırıyor, kritik seviyedeki bulguları yayın öncesi kapatıyoruz. Bakım anlaşması olan projelerde bu tarama düzenli olarak tekrarlanıyor.
Son kabul testini siz yapıyorsunuz. Staging ortamına erişim veriyor, yanına da kontrol listesi ekliyoruz. Listenin amacı sizi yormak değil, gözden kaçabilecek başlıkları hatırlatmak: kendi telefonunuzdan formu doldurmak, kendi tarayıcınızda menüyü denemek, bir ürünü baştan sona satın almak gibi.
Kabul testinde bulunan maddeler önceliklendiriliyor. Yüksek öncelikli maddeler yayın öncesi kapatılıyor; düşük öncelikli maddeler yayın sonrası listeye devredilebiliyor. Bu ayrımı birlikte yapıyoruz, çünkü hangi eksikliğin sizin işinizi gerçekten aksatacağını en iyi siz biliyorsunuz.
Yayından sonraki ilk otuz gün garanti kapsamındadır; bu sürede çıkan hataları ücretsiz gideriyoruz. Hata bildirimini aldığımızda önce yeniden üretmeye çalışıyoruz: hangi ekranda, hangi tarayıcıda, hangi adımlarla oluştuğunu netleştirmeden düzeltmeye başlamıyoruz. Yeniden üretilemeyen bir hata için yapılan düzeltme, çoğu zaman başka bir yeri bozuyor.
Düzeltme önce staging ortamında uygulanıyor, doğrulandıktan sonra canlıya alınıyor. Kritik bir sorun söz konusuysa hızlı müdahale ediyor, ancak sonrasında aynı hatanın tekrar oluşmaması için otomatik test yazıyoruz.
Her hatanın nedenini kısaca kayda alıyoruz. Aynı türden hatalar tekrar ediyorsa bu, tek tek düzeltilmesi gereken sorunlar değil, süreçte düzeltilmesi gereken bir eksiklik anlamına geliyor. Kontrol listelerimizdeki maddelerin çoğu bu şekilde ortaya çıktı.
Test aşamasında yalnızca işlevlerin çalışmasına değil, hata durumunda ne olduğuna da bakıyoruz. Bir kayıt kaydedilirken bağlantı koparsa, iki kullanıcı aynı kaydı aynı anda değiştirirse veya bir aktarım yarıda kalırsa sistemin ne yaptığını ayrıca test ediyoruz.
Kritik işlemleri, ya tamamı ya hiçbiri çalışacak şekilde kuruyoruz. Yarım kalan bir işlem, hatalı bir işlemden daha tehlikeli olabiliyor; çünkü sistem kendini tutarlı sanmaya devam ediyor. Aynı isteğin iki kez gönderilmesi durumunda mükerrer kayıt oluşmasını da engelliyoruz.
Yayın öncesi mutlaka geri dönüş planı hazırlıyoruz. Bir sürüm beklenmedik bir sorun çıkarırsa önceki sürüme dönmenin adımları ve süresi önceden belli oluyor. Yedeğin alınmış olması yeterli değil; geri yüklemenin denenmiş olması gerekiyor.
