Göndermeden Önce Duyarlı Kırılma Noktalarında Görüntü Kalitesi Nasıl Test Edilir

Deterministik bir görsel kalite test paketi oluşturma

Güvenle yayınlamak için görsel kaliteyi diğer test edilebilir özellikler gibi ele alın. Hedef: tanımlı kırılım noktalarında her görsel varyantının kalite eşiklerini karşıladığını programatik olarak doğrulamak.

Adım 1: test matrisinizi tanımlayın

Önemli olan görünüm alanları ve piksel oranlarıyla başlayın. Gerçek cihazlar ortak genişlikler etrafında kümelenir: 390, 428, 810, 1280, 1440, 1920; ancak DPR ölçeklemesini de göz önünde bulundurun. Yararlı bir yaklaşım, tarayıcının sizes özniteliğinize ve srcset tanımlayıcılarınıza dayanarak isteyeceği etkili görsel genişliklerini numaralandırmaktır.

Örneğin, şöyle tanımlarsanız:

<img src="hero-640.jpg"
     srcset="hero-640.jpg 640w,
             hero-1280.jpg 1280w,
             hero-1920.jpg 1920w"
     sizes="(max-width: 800px) 100vw, 50vw"
     alt="hero">

İstenen etkili görsel genişlikleri 800px'e kadar yaklaşık 100vw, sonrasında 50vw olacaktır. Yaygın görünüm alanlarında (390, 428, 810, 1280, 1440, 1920) ve DPR 1, 2, 3'te tarayıcı en yakın adayı seçer. Bu kombinasyonların her birini manuel test etmek imkânsızdır; betikler bunları saniyeler içinde çalıştırabilir.

Adım 2: referans ekran görüntüleri yakalayın

Playwright, Puppeteer veya Selenium gibi araçlar her kırılım noktasında ekran görüntüsü yakalamayı otomatikleştirebilir. Sabit görünüm alanı ve DPR ile başsız (headless) bir tarayıcı kullanın (Playwright deviceScaleFactor sağlar). Tarayıcı önbelleğini kapatın ve piksel kararlı yakalamalar elde etmek için yumuşak animasyonları kapatmayı düşünün. Referans ekran görüntülerini sürüm kontrollü bir dizinde saklayın (ör. /tests/visual-baseline).

Asgari bir Playwright betiği şuna benzeyebilir:

const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch();
const context = await browser.newContext({
viewport: { width: 390, height: 844 },
deviceScaleFactor: 3,
});
const page = await context.newPage();
await page.goto('http://localhos:3000/produc/123');
await page.screensot({ path: 'baseline/produc-390-dpr3.png', fullPage: true });
await browser.close();
})();

Görsel ağırlıklı sayfalar için her zaman tam sayfa ekran görüntüleri alın; böylece hem hero görselleri hem de farklı koşullarda düzeni kaydırabilen satır içi ürün görselleri tespit edilebilir.

Adım 3: görsel regresyon aracıyla karşılaştırın

Resemble-js, pixelmatch veya BackstopJS gibi kütüphaneler iki görüntüyü piksel piksel karşılaştırır. Tipik bir iş akışı:

1. Bir değişiklikten sonra (ör. dağıtım önizlemesi) yeni bir ekran görüntüsü yakalayın.
2. Bunu temel görüntüyle (baseline) üst üste bindirin ve uyuşmazlık yüzdesini hesaplayın.
3. Uyuşmazlıklar bir eşiği aşarsa (örneğin %2) derlemeyi başarısız kılın.
4. Hangi piksellerin değiştiğini tam olarak gösteren bir görsel fark (visual diff) oluşturun.

Ancak piksel mükemmeliyetçi karşılaştırma kırılgandır; tek bir dolgu (padding) ayarı, görsel kalite bozulmamış olsa bile binlerce görsel pikselini "değişmiş" olarak işaretleyebilir. Percy veya Chromatic gibi akıllı araçlar, düzen kaymalarını yok sayan ve görsel içeriğe odaklanan yapay zeka destekli farklılaştırma sunar. Ancak bunlar abonelik maliyetleriyle gelir ve görsel kalitesine özgü kontroller için daha az özelleştirilebilir.

Piksel karşılaştırmasının ötesine geçmek: görsel kalite metrikleri

Bir ekran görüntüsü "değişti mi?" sorusunu yanıtlayabilir, ancak "hâlâ keskin mi?" sorusunu yanıtlayamaz. Bunun için SSIM, PSNR veya VMAF gibi yapısal benzerlik endekslerine ihtiyacımız var. Bunlar, insan kalite algısına yaklaşan sayısal bir puan hesaplar; yeni bir sıkıştırma ayarının görsel keskinliğini bozup bozmadığını test etmek için idealdir.

Bir senaryo düşünün: dosya boyutunu daha da azaltmak için AVIF sıkıştırma kaydırıcısını kalite 30'dan kalite 35'e güncelliyorsunuz. Görsel bir fark dramatik bir değişim göstermeyebilir, ancak SSIM, 2x ekranda fark edilebilecek kumaş veya cilt tonlarındaki ince doku kaybını ortaya çıkarabilir.

Kalite kontrolünü şöyle bir betikle yapabilirsiniz:

const sharp = require('sharp');
const ssim = require('image-ssim'); // hypothetical package
const reference = await sharp('baseline/produc-1280.jpg').raw().toBuffer();const candidate = await sharp('build/produc-1280.jpg').raw().toBuffer();const score = await ssim.compare(reference, candidate);assert(score > 0.95, 'Image quality dropped below acceptable threshold');

SSIM, 0 ile 1 arasında bir değer üretir. Duyarlı (responsive) görseller için 0,95–0,98 eşik değeri, önemsiz değişikliklere tolerans gösterirken algılanabilir bozulmayı yakalar. Bunu, her pull request'te çalışan ve oluşturulan her görsel varyantını üretim sürümüyle karşılaştıran bir CI pipeline'ına entegre edebilirsiniz.

Gerçek cihazlar olmadan duyarlı davranışı test etme

Cihaz laboratuvarları pahalı ve yavaştır. Modern başsız (headless) tarayıcılar çoğu mobil özelliği taklit edebilir, ancak yalnızca DPR ve viewport ile renk profilleri, OLED derin siyahları veya ortam aydınlatması kopyalanamaz. Yine de, güvenle dağıtım için DPR duyarlı testler, duyarlı görsellerdeki sorunların çoğunu kapsar.

Bir ipucu: tarayıcının beklenen görsel dosyasını gerçekten indirdiğini (sadece görüntülemediğini) doğrulamak için Playwright'ın istek yakalama (request interception) özelliğini kullanın. Her görsel isteğini ve HTTP başlıklarını kaydedin, ardından dosya boyutu ve boyutlarının beklentilerle eşleştiğini kontrol edin:

bpage.on('request', request => \{
  if (request.resourceType() === 'image') \{
    console.log(request.url(), request.headers()['accepet']);
  \}
\});

Tam otomatik kontroller için, page.$$eval ile işlenmiş görsellerin img.currentSrc veya NaturalWidth/NaturalHeight değerlerini alın ve beklenen breakpoint değerleriyle karşılaştırın. Bu, srcset çözünürlük mantığının beklendiği gibi çalışmasını sağlar.

Otomatik görsel istek kaydı, bir CDN'nin beklenmeyen bir varyant teslim ettiğini ortaya çıkarır; bu, CMS geçişleri veya CDN yapılandırma değişikliklerinden sonra sık görülen bir sorundur. Bunu prodüksiyonda değil, staging ortamında yakalayın.

WebP/AVIF yedeklerini ve format hazırlığını doğrulama

Modern görseller, birden çok <source> etiketi içeren <picture> öğesine dayanır. Sık karşılaşılan bir hata: ilk <source> tarayıcının desteklediği bir tür belirtirken, içindeki srcset geçersiz genişlikler içerir ve tarayıcı düşük çözünürlüklü bir JPEG'e düşer. Veya yedek <img> öğesi, retina ekranda kötü görünen eski bir yeniden boyutlandırılmış küçük resme işaret eder.

Bunu test etmek için, format desteği açılıp kapatılarak ekran görüntüleri alın. Örneğin, Playwright'ın browser.newContext(\{ ignoreHTTPSErrors: true \}) formatı etkilemez, ancak içeriği başlıklara göre koşullu olarak sunabilirsiniz. Daha iyi bir yaklaşım: aynı test paketini, WebP/AVIF desteğini ?no-webp=1 gibi bir sorgu parametresiyle devre dışı bırakan bir staging ortamında çalıştırın ve ekran görüntülerini modern format taban çizgisiyle karşılaştırın. Fark kabul edilebilir kalite sınırları içinde olmalıdır; bu, yedek görsellerinizin yeterli olduğunu doğrular.

CI entegrasyonu: görsel kalitesini bir derleme adımı haline getirme

Tüm paketi birkaç npm betiğine sarın. Tipik bir CI işi şunları yapabilir:

1. Bir staging ortamı başlat (Vercel preview, Netlify deploy preview).
2. Tüm breakpoint'ler arasında gezen, ekran görüntüleri alan ve istenen görsel URL'lerini kaydeden bir Playwright betiği çalıştır.
3. Hero ve önemli ürün görselleri için SSIM puanlarını hesaplayan bir karşılaştırma betiği çalıştır.
4. Yan yana farkları ve kalite puanlarını gösteren bir HTML raporu oluştur ve CI artifact'i olarak yükle.
5. Herhangi bir görsel kalite eşiğinin altına düşerse veya beklenen dosya boyutundan %20'den fazla saparsa derlemeyi başarısız say.

Bu, duyarlı görsel kalite güvencesini rastgele bir manuel kontrolden deterministik, tekrarlanabilir bir adıma dönüştürür. Geliştiriciler pull request'leri hakkında anında geri bildirim alır; artık "benim makinemde iyi görünüyor" yok.

"Programatik görsel kalite kontrollerini CI'ımıza eklemek, bize her sürüm döngüsünde 15+ saat kazandırdı ve her iki sprintte bir prodüksiyona sızan regresyonları ortadan kaldırdı."

Geliştirici araçlarıyla boşluğu kapatma

Otomasyona rağmen, geliştiricilerin UI üzerinde hızlıca yineleme yapması gerekir. Bir hero bölümünü yeniden yazdığınızda, kodlamadan önce yeni kompozisyonun her breakpoint'te keskin göründüğünden emin olmak istersiniz. İşte bu noktada tarayıcı uzantıları devreye girerek, iyi test edilmiş bir UI bloğunu, duyarlı görsel işaretlemesi ve kalite ayarlarıyla birlikte doğrudan yerel ortamınıza kopyalamanıza olanak tanır.

srcset genişliklerini elle yazıp sıkıştırma oranlarının orijinalla eşleşeceğini ummak yerine, tam hesaplanmış stilleri ve görsel kaynaklarını yakalayan araçlar, geliştiricilerin kaliteye saygı göstererek daha hızlı dağıtım yapmasını sağlar. Blok içe aktarıldıktan sonra, otomatik test paketi nihai sonucu doğrular: her iki dünyanın en iyisi.

Başarı için anahtarlar: bir kontrol listesi

• Analitiklerinizdeki en iyi cihazları kapsayan gerçekçi bir viewport ve DPR matrisi tanımlayın.
• Başsız tarayıcılarla ekran görüntüsü almayı otomatikleştirin ve temel çizgileri (baselines) sürüm kontrolünde saklayın.
• Regresyon tespiti için görsel farklılaştırma (visual diffing) kullanın, ancak kaliteye özel iddialar için SSIM/PSNR ekleyin.
• Hem modern hem de yedek formatları test ederek kademeli bozulmanın (graceful degradation) düzgün olduğundan emin olun.
• Her şeyi CI'ya entegre edin; derlemeleri erken başarısız kılın ve uygulanabilir fark raporları sağlayın.

Duyarlılık ve kalitenin buluştuğu yer: yaygın kör noktalar

Güçlü otomasyona rağmen, bazı alanlar hâlâ insan muhakemesi gerektirir. Sanat yönetimi (art direction) – bir görselin odağının mobil için farklı kırpıldığında ortalanmış kalmasını sağlamak – otomatikleştirmesi zordur. Görsel farklılaştırma bir değişikliği işaretleyebilir, ancak yeni kırpmanın ürünü doğru şekilde vurgulayıp vurgulamadığını yalnızca bir insan söyleyebilir.

Hız ve kalite ödünleşimleri de gri alanda yaşar. Kaliteyi 80'den 75'e düşürmek 6 inçlik bir ekranda görünmez olabilir, ancak 27 inçlik bir monitörde bantlaşmaya (banding) neden olabilir. Otomatik SSIM eşikleri ayarlanabilir, ancak çıtayı çok yüksek tutarsanız makul optimizasyonları reddedersiniz; çok düşük tutarsanız gerçek bozulmayı kaçırırsınız. Sürekli izleme ve ara sıra yapılan manuel nokta kontrolleri önemini korur.

Son düşünceler

Duyarlı görsel testi bir endişe kaynağı olmak zorunda değil. Bunu bir kod kalite metriği olarak, birim testleriyle aynı titizlikle ele alarak ekipler, bulanık hero'yu, yanlış kırpmayı ve çok megabaytlık mobil görseli kullanıcı görmeden önce yakalayabilir. Otomatik ekran görüntüsü alımını yapısal benzerlik puanlamasıyla birleştirin, CI pipeline'ınıza bağlayın ve daha fazla güvenle daha hızlı dağıtın.

Her milisaniyelik yükleme süresinin ve her piksel kalitesinin kullanıcı güvenini tanımladığı bir çağda, otomatik duyarlı görsel testi, tasarım sisteminizin güvenlik ağıdır. Bir kez kurun ve sonraki her sürüm size teşekkür edecek.