Kullanılabilirlik Testinde Gerçek Kullanıcı Verisi Kullanmak

Gerçek veriyle yapılan test, sahte veriyle hiç görünmeyecek bir hata sınıfını ortaya çıkarır: doğrulama kuralları, alan sınırları, karakter setleri. Karşılığında ölçüm gücünü zayıflatır ve elinize hukuki bir sorumluluk bırakır. Hangi görevde hangisini kullanacağınız bu takasa göre belirlenir.

Gerçek veri neyi bulur

Sahte veri her zaman temizdir. Altı harflik bir ad, İstanbul, düzgün bir e-posta. Gerçek katılımcı kendi bilgisini yazdığında forma apostroflu soyadlar, büyük İ ile küçük ı, kırk karakteri geçen adresler, boşluklu girilmiş IBAN'lar, iki parçalı soyadlar girer. Doğrulama regex'inin varsaydığı dünya ile kullanıcının yaşadığı dünya arasındaki fark tam burada çıkar.

Bir kayıt formunda apostrof içeren soyadın gönderimi sessizce düşürdüğünü, ancak katılımcı kendi soyadını yazdığında fark etmiştik.

İkinci kazanç davranışsal. Kendi kart bilgisini giren kullanıcı ödeme adımında gerçekten duraklar, adres onayını gerçekten okur. Sahte veriyle o duraklama hiç oluşmaz, dolayısıyla güven sorunlarını ölçemezsiniz.

Nicel ölçümde ters çalıştığı yer

Görev süresi ya da hata sayısı karşılaştırıyorsanız gerçek veri ölçüme kontrol edemediğiniz bir değişken sokar. Katılımcının adresi uzun olduğu için yazması on iki saniye fazla sürdüyse, o on iki saniye arayüzle ilgili değildir. Kullanılabilirlik testlerinde katılımcı sayısı genelde beş ile sekiz arasında olduğundan, bu tür bir sapma ölçmeye çalıştığınız etkiden büyük çıkabilir. İki tasarımı karşılaştırdığınız durumda sonucu tamamen ters çevirmesi de mümkün.

Çözüm testi ikiye bölmek değil, görevi bölmek. Süre ölçtüğünüz görevlerde veriyi sabitleyin, herkese aynı kartı ve aynı adresi verin. Keşif amaçlı görevlerde kullanıcı kendi verisini kullansın. Aynı oturumda ikisi rahatlıkla yaşar, yeter ki hangi görevden hangi tür sonuç beklediğinizi test planında önceden yazmış olun.

İzin, saklama, silme

Gerçek veri topladığınız anda bunu KVKK kapsamında işliyorsunuz demektir. Aydınlatma metni ve açık rıza gerekli, ekran kaydı da kişisel veri sayılır.

"Test bitince sileriz" cümlesi tek başına bir şey ifade etmiyor, çünkü verinin nereye yayıldığını kimse baştan saymıyor. En az şu beş yere bakın:

• Test ortamının veritabanı ve orada açılan geçici hesaplar.
• Uygulama logları. Form gönderimini debug seviyesinde loglayan bir servis varsa katılımcının adresi düz metin olarak orada duruyor.
• Hata izleme aracı. İstisna yakalandığında request payload'ı da gönderiliyorsa veri artık üçüncü bir sağlayıcıda.
• Analitik ve oturum kaydı araçları.
• Video dosyaları ve moderatörün not defteri.

Log ve hata izleme tarafı en çok atlanan ikilidir, çünkü verinin oraya yazıldığını genelde yalnızca kodu yazan bilir. Test planını hazırlarken bu iki kaynağı geliştiriciyle birlikte kontrol edin.

Kaydı en baştan maskeli alın

Ekran kaydını çektikten sonra hassas alanları bulanıklaştırmak yavaş ve hataya açık bir iş. Bir saatlik kayıtta bir kareyi atlamanız yeterli. Bunun yerine maskelemeyi kayıt anına taşıyın: test yapılandırmasında ilgili alanların değerini gizleyin, ya da kaydı o bölgeyi dışarıda bırakacak şekilde kırpın.

Ödeme adımında ise gerçek kart hiç istenmemeli. Ödeme sağlayıcısının test kartı numaraları ya da önceden yüklenmiş bir hediye kartı, akışın tamamını gerçek kart kadar iyi test eder ve sizi kayıt tarafındaki bütün riskten kurtarır.

Verisini paylaşmak istemeyen katılımcı

Bu talebi tartışmayın, hazır alternatifle karşılayın. Alternatif setini teste girmeden önce hazırlayın; oturum sırasında doğaçlama üretilen sahte bilgi genelde sistemin kabul etmeyeceği bir şey oluyor ve on dakikanızı yiyor.

Herkese aynı sahte e-postayı vermek kayıt akışını tıkar, çünkü sistem ikinci katılımcıda "bu adres zaten kayıtlı" diyecektir. Katılımcı başına ayrı adres planlayın. Artı takısı (ornek+p03@alanadi.com) çoğu yerde çalışır, ama bazı formlar artı karakterini reddediyor; testten önce bir kez denemeniz gereken şey bu. Doğrulama e-postasının açılması gereken bir akış varsa, katılımcının önünde açabileceğiniz gerçek bir kutu bulundurun.