Kod hatası büyük gürültü yapar. Sayfa açılmaz, hata gösterir, test kırılır, log dolar. Hata ayıklamak yorucudur ama en azından fark edilir.
UI hatası sessizdir. Sayfa açılır. Kullanıcı bir şeyin yanlış olduğunu hisseder ama adını koyamaz. Geliştirici "iyi görünüyor" der ve geçer.
Bu yazı, sessiz UI hatalarının nasıl oluştuğunu ve neden bu kadar zor yakalandığını anlatıyor.
"Sessiz" ne demek?
Bir hata sessizdir, eğer üç koşul birden sağlanıyorsa:
- Fonksiyonel değil. Düğmeye tıklayınca çalışıyor, form gönderiliyor, sayfa yükleniyor.
- Görsel ve düzeltilmiş. Birisi fark edip düzeltirse bir daha olmaz.
- Mevcut testler geçiyor. Çünkü testler DOM'a bakar, görünüme değil.
Bu üçü bir araya geldiğinde hata, geliştiricinin ekranına hiç girmez. Kimse "buraya baktım, burada iyi" demez, çünkü kimse o ekrana bakmaz.
Nereden geliyor?
Tailwind ve CSS sıfırlama güncellemeleri. Bir sıfırlama kütüphanesinin yeni sürümü, tarayıcı başına özelliği farklı yorumlayabilir. Sizin CSS'iniz aynıdır, ama sonuç değişmiştir. Hata, sizin kodunuzda değil, tarayıcının davranışında.
Bileşen kütüphanesi güncellemeleri. Bir <button> bileşeninin dolgu
değişikliği, tüm uygulamadaki butonları etkiler. Kırılan şey tek bir bileşendir,
etkilenen yüzlerce yerdir.
Tipografi değişiklikleri. Yeni bir yazı tipi ailesi, farklı satır aralığı. Metin aynı, yükseklik değişikliği. Dikey taşma, beklenmedik satır kaydırması.
Karanlık mod eklenmesi. Yeni bir renk paleti, açık zeminde okunmayan metin. Bu, özellikle sessizdir: metin var, ekranda, sadece okunmuyor.
Tarayıcı sürüm davranışı. Safari'de düzgün görünen bir şey Chrome'da taşabilir. Hangi tarayıcıda test edeceğiniz, hatanın görünürlüğünü belirler.
İçerik değişikliği. "Kısa açıklama" alanına 300 karakterlik metin girilir ve buton sığmaz. Metin değişikliği taraması bunu yakalar, ama kimse içerik giriyor olarak "görseli de kontrol et" demiyor.
Neden testler yakalamıyor?
Bir test şunu yapar:
expect(page.getByRole('button', { name: 'Gönder' })).toBeVisible()
Bu test geçer. Buton görünür — yani display değil none, boyutu sıfırdan büyük.
Ama butonun metni kesilmiş olabilir, arka planı metinle aynı renkte olabilir, üstüne
başka bir katman binmiş olabilir.
Testin kontrol ettiği şey, kullanıcının gördüğü şey değil. Bu, testin kötü yazıldığı anlamına gelmez — sadece testin kapsamının dışında olduğu anlamına gelir.
Erken yakalamak için ne yapmalı?
1. Eşiği sıkı, kapsamı dar tutun
Geniş kapsamlı sıkı eşik, her gün yüzlerce yanlış alarm üretir. Dar kapsamlı gevşek eşik, gerçek hataları kaçırır. İkisi arasında seçim yapmanız gerekiyor.
Pratik denge: en kritik sayfaları sıkı, gerisini hiç izlemeyin. Yüz sayfayı zayıf izlemek, on sayfayı güçlü izlemekten kötüdür.
2. Karşılaştırmayı gözle kontrol edin
Otomatik karşılaştırma, gerçek görünümün yaklaşık bir temsilidir. Piksel farkı, "bu tasarım bozuldu" demek değildir.
Ayda bir, sistemin işaretlediği farklardan birkaçını açın ve gerçekten bozulma olup olmadıklarına bakın. Bu iki dakika, sistemin güvenilirliğini belirler.
3. Erişilebilirlik taramasını ayrı çalıştırın
Renk kontrastı, odak halkası, dokunma hedefi boyutu — bunlar görsel testin kapsamı dışında ve otomatik taranabilir.
Karanlık mod eklediyseniz, kontrast taraması en değerli yatırımdır. Çünkü "okunmayan metin" hatasını gözle yakalamak neredeyse imkânsızdır.
4. Değişiklik kaydını bağlayın
Hata "bir gün fark edildi" değil, "değişiklikten iki hafta sonra fark edildi" ise, hangi değişikliğin yaptığını bulamazsınız. Bu yüzden değişiklik geçmişi, görsel kayıtla aynı yerde durmalıdır.
Bu konu ajans için neden farklı?
Ajans, bu hataları kendi sitesinde değil müşterisinin sitesinde arar. Ve müşterinin sitesinde güncelleme yapan kişi ajans değildir.
Bu, durumu hem kolaylaştırır hem zorlaştırır:
Kolaylaştırır: Müşterinin sitesinde sizin kontrolünüz yoksa, en azından kendi ekibinizin neden yaptığını bilirsiniz. Bir CSS güncellemesi yaptıysanız, aradaki bağı kurabilirsiniz.
Zorlaştırır: Üçüncü taraf eklentiler, tema güncellemeleri, host firmanın kendi değişiklikleri. Bunların hiçbiri sizin ekibinizden gelmiyor.
Bu yüzden ajansın izleme değeri, teknik bilgiden çok tarih bilgisidir. Ne zaman değişti? Ne değişti? Öncesi nasıldı? Bu üç sorunun cevabı, hatayı bulmakla eşdeğerdir.
Özet
- UI hataları, işlevsel olmadıkları ve testler geçtiği için sessizdir.
- En sık kaynakları: sıfırlama ve bileşen güncellemeleri, tipografi, karanlık mod, tarayıcı farkları, uzun içerik.
- Testler DOM'a baktığı için yakalamaz; yakalayacak olan görsel karşılaştırmadır.
- Kapsamı daraltmak, kapsamı genişletmekten daha iyidir.
- Değişiklik geçmişi olmadan bir UI hatasını teşhis etmek, bir fotoğrafın kimliğini bilmeden kayıp ilan etmek gibidir.
Karşılaştırmanın nasıl çalıştığını görsel regresyon testi yazısında ele alıyoruz. Dinamik sayfalarda bu yöntemin neden kırıldığını maskeleme yazısında anlatıyoruz.