Kullanılabilirlik Hatalarını QA Sürecinde Ölçülebilir Kılmak
Kullanılabilirlik sorunları hata kaydına girmediği sürece düzelmez. Fonksiyonel bir hatanın beklenen sonucu bellidir; kullanıcının üç adımda bitirmesi gereken işi yedi adımda bitirmesi ise çoğu takımda "tasarım tercihi" etiketiyle kapanır. QA'nın deneyim tarafındaki asıl işi test koşmak değil, bu tür bulguları ölçülebilir kabul kriterine çevirip kaydı açık tutmaktır.
Kabul kriteri yoksa hata da yok
Bir kullanılabilirlik bulgusunu "kullanıcı alışır" gerekçesiyle kapatmam. Kapatılacaksa ölçüyle kapatılır. Bulguyu kayda geçirirken beklenen sonucu sayıya bağlamak gerekir, aksi halde tartışma zevk meselesine döner ve kaydı açan kişi kaybeder.
Kullanılabilirlik için işe yarayan ölçüler kısa bir liste: görevin tamamlanma oranı, tamamlanma süresi, hedefe ulaşmak için gereken tıklama veya ekran sayısı, görev başına düşen hata sayısı, yardım isteme oranı. "Sipariş iptali üç ekranda tamamlanır ve on kullanıcının en az sekizi yardım almadan bitirir" cümlesi test edilebilir. "İptal akışı kullanıcı dostu olmalı" cümlesi test edilemez, dolayısıyla hata kaydı da değildir.
Bu çeviriyi yapmanın yan faydası, tasarım kararının uygulamaya maliyetini görünür kılması. Adım sayısını yediden üçe indirmek çoğu zaman arayüz değil veri modeli işidir; iptal nedenini toplayan üç ayrı ekran, arka uçta üç ayrı zorunlu alan olduğu için oradadır. Kriteri sayıyla yazdığınızda tartışma "daha sade olsun" düzeyinden çıkar, hangi alanın gerçekten zorunlu olduğuna gelir.
Erken test ucuzdur, ama her hata erken bulunmaz
Prototip üzerinde test yapmanın maliyeti düşürdüğü doğru. Bunun genelleştirilmesi yanlış: bazı hata sınıfları tasarım aşamasında yapısal olarak görünmez.
- Veri hacmi. Prototipteki listede on iki kayıt vardır, üründe dört bin. Sıralama, filtreleme ve arama kararları prototipte doğru görünür, gerçek veride çöker.
- Gecikme. Tıklamayla sonucun arası prototipte sıfırdır. Kullanıcının kararsız kaldığı, ikinci kez tıkladığı, sekmeyi kapattığı anlar ancak gerçek yanıt süreleriyle ortaya çıkar.
- Hata ve boş durumlar. Wireframe'lerde her şey mutlu yoldan ilerler. Oysa kullanıcıyı asıl zorlayan ekranlar, oturumun düştüğü, ödemenin reddedildiği, listenin boş geldiği ekranlardır.
- Eşzamanlılık. İki sekmede açık aynı form, arka planda değişen stok, süresi dolan sepet. Bunların hiçbiri tekil kullanıcı testinde görünmez.
Sonuç şu: erken testi hata sınıflarının tamamı için değil, akış ve anlaşılabilirlik için kullanın. Gecikme ve durum yönetimi hatalarını yakalayacak olan, gerçek veriyle çalışan bir ortamda koşan testlerdir. Bu iki katmanı ayırmayan ekipler, prototipte onaylanmış bir akışın canlıda neden şikâyet ürettiğini anlamakta zorlanır.
Hız bir his değil, bir eşik
"Site yavaş" bir hata kaydı değil, bir izlenimdir. Ölçülebilir hale getirmenin yolu, kritik akışlara eşik koymak: arama sonucu p95'te 800 ms altında dönecek, ürün sayfası ilk anlamlı içeriği 2 saniyede gösterecek. Ortalamayı değil yüzdelik dilimi almak önemli, çünkü ortalama en kötü deneyimi yaşayan kullanıcıyı gizler. On isteğin dokuzu 200 ms, biri 4 saniye ise ortalama iyi görünür, o bir kullanıcı gider.
Eşik bir kez yazıldığında test otomatikleşir ve tartışma biter. Eşiği aşan istek bir hatadır, kimsenin fikrini sormaya gerek kalmaz.
Düzelen deneyim geri bozulur
Kullanılabilirlik düzeltmeleri regresyona fonksiyonel hatalardan daha açıktır, çünkü çoğu kod içinde iz bırakmaz. Adım sayısını azaltmak için kaldırılan bir onay ekranı, altı ay sonra başka bir gereksinim için geri gelir; kimse bunun daha önce ölçülmüş bir kararı iptal ettiğini bilmez.
Çözüm, kararı kodun yanında tutmak. Akışın adım sayısını doğrulayan bir uçtan uca test, kaldırılan ekran geri geldiğinde kırılır ve tartışmayı yeniden başlatır. Aynı şekilde klavye ile gezinme, odak sırası ve etiket eşleşmeleri gibi erişilebilirlik koşulları otomatik denetime bağlanabilir. Buradaki ilke basit: elle tekrarlanması gereken her kontrol, yeterince zaman geçince yapılmaz.
Pratikte nereden başlanır
En kısa yol, mevcut hata takip sisteminde "kullanılabilirlik" etiketiyle kapatılmış kayıtları geri açmak ve her birine ölçülebilir bir kabul kriteri yazmak. Bu iş bir öğleden sonra sürer ve genellikle iki şeyi ortaya çıkarır: kayıtların bir kısmı gerçekten kriter yazılamayacak kadar belirsizdir, kalanı ise aylardır bekleyen somut sorunlardır. İkinci grup, yeni kullanıcı testi planlamadan önce yapılacak işi zaten verir.