Yani, Bir ürün ekibiyle sabah toplantısına girdiniz diyelim. Herkes yeni özelliklerden konuşuyor, roadmap havada uçuşuyor, “şunu da ekleyelim” cümlesi masanın üstünde dolaşıyor… ama kimse şu basit soruyu sormuyor: Ekranda bir şey bozulursa ne olacak?
İşin aslı şu: çoğu şirket test bütçesini hep işlevlere gömüyor. Form çalışıyor mu, ödeme akıyor mu, API cevap veriyor mu? Tamam. Güzel. Ama kullanıcı sayfası kaymışsa, buton görünmüyorsa ya da mobilde yazılar birbirine girmişse — teknik olarak site çalışsa bile — işin ticari tarafı can yakıyor. Ben bunu ilk kez 2022’de İstanbul Levent’te bir e-ticaret projesinde bizzat gördüm; checkout ekranı tek bir banner yüzünden yarım santim kaydı ve satış ekibi “trafik var ama dönüşüm niye düşüyor?” diye panikledi. Kimsenin aklına görsel uyumsuzluk gelmemişti ilk başta, tabii.
Bu yazıda görsel testin neden “lüks” değil de bayağı sağlam bir yatırım olduğunu konuşalım. Yönetimi ikna etmek istiyorsanız sadece kalite dilini değil, para dilini de konuşmanız gerekiyor. Hani bazen teknik doğruluk yetmez ya (evet, doğru duydunuz). burada tam öyle.
Neden Görünüm Meselesi Sandığınızdan Daha Pahalı?
Size bir şey söyleyeyim, Bakın şimdi, kötü görünen bir arayüz çoğu zaman “küçük bug” diye geçiştiriliyor. Halbuki küçük dediğiniz şey bazen ciddi paraya dönüşüyor. Bir ödeme butonu gizlenirse satış kaçar. Okunamayan fiyat etiketi olursa güven azalır. Yanlış hizalanmış bir ürün fotoğrafı olursa kullanıcı sayfayı terk eder — hem de bunu raporlamadan, direkt çıkarak.
2023’te Kadıköy’de çalışan küçük bir SaaS ekibinin demo ortamında buna benzer bir şey yaşadım. Masaüstünde her şey düzgündü ama bazı dar ekranlarda kart düzeni büyük ölçüde dağılıyordu (kendi tecrübem). Ürün yöneticisi önce pek önemsemedi. Sonra satış görüşmelerinden gelen geri bildirimler birikiyor, mesele büyüyor… ve aslında sorun kodda falan değildi; sorun gözden kaçan görsel uyumsuzluktu. Hepsi bu.
Çok konuştum, örnekle göstereyim.
Yani, Rakamlar da bu hissi destekliyor. Yazılım hatalarının maliyeti uzun süredir tartışılıyor. Bağımsız araştırmalar kullanıcı bir düşüneyim… tarafındaki kaybın hiç de hafif olmadığını gösteriyor — kullanıcıların önemli bir kısmı hata gördüğünde uygulamayı kapatıyor, hatta ikinci şansı vermiyor. E tabi bu noktada “ama işlev çalışıyor” demek pek kurtarmıyor.
Kullanıcı güveni kırılınca geri toplamak zorlaşıyor
Mağaza vitrini gibi düşünün. İçeride kasa düzgün çalışsa bile vitrin dökülmüşse müşteri içeri girerken iki kere düşünüyor. Web’de de aynı refleks var — sayfa yamuk yumuk görünüyorsa kullanıcı bilinçli olmasa bile “burada işler biraz karışık galiba” hissine kapılıyor ve çıkıyor.
Çok konuştum, örnekle göstereyim.
Açık konuşayım: kurumsal tarafta insanlar bazen hata toleransını düşük tutuyor. Ürün ekipleri bu etkiyi hafife alabiliyor. Halbuki özellikle finans, sağlık ve e-ticaret tarafında ilk izlenim doğrudan gelirle bağlantılı. Ciddi fark var.
Manuel Kontrol Nereye Kadar Yetiyor?
Lafı gevelemeden söyleyeyim: tek başına sürdürülebilir değil. İlk günlerde ekipten biri birkaç tarayıcı açar, birkaç cihaz emülatörü dener ve “tamam” deriz… ama deploy sayısı arttıkça bu yöntem çuvallıyor. Kaçınılmaz.
Geçen yıl Şişli’de görüştüğüm orta ölçekli bir ekipte her sürüm sonrası iki kişi sırayla ekranları kontrol ediyordu. Başta iyi gidiyordu çünkü ürün küçüktü. Sonra yeni tema geldi, ardından dark mode geldi, akabinde kampanya landing page’leri çıktı ve bir noktadan sonra kimse aynı checklist’i aynı dikkatle yapamaz oldu — insan dikkatinin sınırı var, bunu değiştiremezsiniz. Nokta.
| Kriter | Manuel Kontrol | Otomatik Görsel Test |
|---|---|---|
| Kapsam | Sınırlı | Geniş |
| Tutarlılık | Kişiye bağlı | Aynı standartta |
| Maliyet | Sürüm arttıkça yükselir | Zamanla düşer |
| Hata yakalama oranı | Düşebilir | Daha yüksek olur |
Şöyle söyleyeyim, Evet, manuel inceleme tamamen çöpe atılmaz; hayati alanlarda hâlâ gerekir. Ama tek savunma hattınız buysa iş zorlaşır… özellikle enterprise ölçekte onlarca ekran ve yüzlerce varyasyon söz konusuysa. Daha fazla bilgi için Tesla’nın Yeni Güncellemesi: Otomatik Kurulum Neyi Değiştiriyor? yazımıza bakabilirsiniz.
İşte tam da bu noktada devreye giriyor. Laravel API’de Lead Toplama: DTO, Action ve JSON:API yazımızda bu konuya da değinmiştik. Türkiye’de Yenilenmiş TV Dönemi: Alırken Neye Bakmalı? yazımızda bu konuya da değinmiştik.
Görsel testin en büyük gücü şurada yatıyor: Kodun doğru olmasıyla arayüzün doğru görünmesi aynı şey değil.
Bütçe Masasında ROI Nasıl Konuşulur?
Yönetim kurulunda kimse “pixel-perfect” lafıyla heyecanlanmıyor; açık konuşalım, onların ilgilendiği şey risk ve getiri dengesi. O yüzden görsel testi anlatırken şu soruya dönmek lazım: Bugün harcadığımız para bize hangi kaybı engelliyor?
Neyse, uzatmayalım — örnek üzerinden gidelim. Diyelim ki günlük cirosu 10 bin dolar olan bir e-ticaret sitesi var. Ödeme akışında çıkan tek bir görsel bug yüzünden saatlik gelir düşüyorsa bunun faturası hızla büyüyor. Profesyonel bir araç lisansı veya otomasyon yatırımı ise çoğu durumda bundan çok daha düşük kalıyor. Hesabı basit aslında.
Bana kalırsa yönetimi ikna etmenin en temiz yolu üç katmanlı anlatmak:
- Müşteri etkisi: kötü görüntü güveni azaltır. (bence en önemlisi)
- Ekip etkisi: manuel kontrol süresi uzar.
- Mali etki: geciken bug düzeltmeleri daha pahalı olur.
Küçük startup ile büyük kurum arasında fark ne?
Küçük startup için mesele genelde hızdır. Az kişi vardır, her deploy altın değerindedir ve biri gece yarısı hotfix atmak zorunda kalabilir. Böyle yapılarda temel görsel regresyon seti kurmak bile rahatlama sağlıyor; hele pazarlama sayfaları sık değişiyorsa ciddi fark yaratıyor.
Enterprise tarafta ise konu başka yere gidiyor. Orada marka standardı devreye giriyor — aynı butonun farklı ülkelerde farklı görünmesi bile problem olabiliyor. Bir bankada ya da büyük perakendecide küçük hizalama hatası bile onay zincirine takılıyor çünkü orada sadece ekran yoktur, hukuk, marka ve operasyon da vardır. Çok katmanlı bir dünya.
Araç Seçerken Nelere Bakmalı?
Piyasadaki araçlara bakınca hepsi kendini güzel anlatıyor, tabi. Ama pratikte işleyen seçim kriterleri daha sade: hangi tarayıcıları kapsıyor, snapshot karşılaştırması ne kadar net, false positive oranı nasıl, CI/CD’ye oturuyor mu? Bunlar önemli. Geri kalan pazarlama lafı. RCI Hospitality Sızıntısı: IDOR Açığı Neyi Gösteriyor? yazımızda da bu konuya değinmiştik. OneCoin Mağdurları İçin 40 Milyon Dolar: Şimdi Ne Olacak? yazımızda da bu konuya değinmiştik.
Bu konuyu editör masasında incelerken özellikle entegrasyon kolaylığına baktım. Çünkü araç güzel olsa bile pipeline’a girmiyorsa pek anlam taşımıyor. Mantıklı değil mi? Benim gözümde iyi araç, geliştiriciye ekstra yük bindirmeyen araçtır; kendi halinde akar gider, kimse farkında bile olmaz.
// Basit bir visual testing akışı örneği
1) Sayfayı aç
2) Kritik bölgelerin snapshot'ını al
3) Önceki sürümle karşılaştır
4) Fark varsa rapor üret
5) Onay gerekiyorsa build'i durdur
Neleri hemen otomasyona almalısınız?
Tüm siteyi ilk günden kapsamak şart değil. Hatta gereksiz bile olabilir. Ben olsam önce para kazandıran akışlardan başlarım: anasayfa, ürün detay, checkout, login, kampanya landing page… Bu dört beş alan size zaten sinyal verir, geri kalanı zamanla eklersiniz.
Daha sonra komponent seviyesine inerim. Kartlar, modal pencereler, form alanları, navbar gibi tekrar eden parçalar burada öne çıkıyor. Çünkü asıl kırılma çoğu zaman orada oluyor — bir stil dosyası değişiyor ve domino taşı gibi yayılıyor. Bunu yaşamayana anlatması zor, yaşayana anlatmaya gerek yok.
Neden Bu İş Sadece QA’nın Derdi Değil?
Bazen garip biçimde görsel test sanki sadece test ekibinin göreviymiş gibi konuşuluyor. Değil. Tasarımcı için de faydalı, frontend geliştirici için de, ürün yöneticisi için de. Hatta pazarlama ekibi bile bundan besleniyor çünkü kampanya sayfasının bozulması direkt performans metriğine vuruyor.
Bir arkadaşım İzmir’deki ajansında şöyle demişti: “Biz tasarımı Figma’da tamamlıyoruz. Prod’a çıkınca renkler bambaşka oluyor.” İşte tam burada görsel regresyon devreye giriyor. Tasarım niyetini canlı sistemde korumak için kullanıyorsunuz onu. “Kağıt üstünde süper, pratikte göreceğiz” demek yerine gerçekten görüyorsunuz — fark bu.
Bir de şu var: görsel test ekip içinde iletişimi düzene sokuyor. Tartışma artık “bence bozuk” bir düşüneyim… seviyesinden çıkıp somut karşılaştırmaya geliyor. Ekranın eski hali ile yeni hali yan yana durunca laf azalıyor, kanıt çoğalıyor. Herkes aynı şeye bakıyor.
Sizi Kurtaracak Küçük Bir Uygulama Planı
Laf kalabalığı yapmadan uygulanabilir bir yol çizeyim:
- Kritik kullanıcı akışlarını belirleyin.
- Tasarım sistemi olan ekranları önce kapsayın.
- Eşik değerlerini netleştirin; her piksele takılmayın.
- CI/CD içine bağlayın ki insan unutunca sistem unutmasın.
- False positive çıkan yerleri temizleyip kural setini rafine edin.
Sıkça Sorulan Sorular
Görsel test ile fonksiyonel test arasındaki fark nedir?
Fonksiyonel test sitenin doğru çalışıp çalışmadığına bakar; görsel test ise doğru görünüme odaklanır. Yani düğme tıklanıyorsa fonksiyonel test geçebilir ama düğme gizlenmişse görsel test bunu yakalar.
Küçük ekipler için görsel test gerekli mi?
Evet, çünkü küçük ekiplerde hata kaçarsa toparlamak daha zor olur.. En çok da sık yayın yapan startup’larda temel sayfalarda otomasyon ciddi zaman kazandırır.””Ne kadar kapsam yeterlidir?”}”
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
