Kurumsal Bir Yazılım İçin Kullanılabilirlik Testi Nasıl Satın Alınır?

Kurumsal bir yazılım için kullanılabilirlik testi satın almak, birkaç kullanıcıya ekranları gösterip fikirlerini sormaktan ibaret değildir. Doğru hizmet; gerçek kullanıcıların sipariş verme, teklif onaylama, stok sorgulama, iş emri kapatma veya rapor hazırlama gibi kritik görevleri tamamlayıp tamamlayamadığını sistemli biçimde inceler. Bulguları önem derecesine göre sıralar ve tasarım ile yazılım ekiplerinin uygulayabileceği iyileştirmelere dönüştürür.

Bu nedenle satın alma sürecinin başlangıç sorusu “Kaç ekran test edilecek?” değil, “Hangi kullanıcı, hangi iş sonucuna ulaşmaya çalışırken hangi riskleri ölçmek istiyoruz?” olmalıdır. Bu rehber; dijital dönüşüm, ürün, BT, operasyon, pazarlama ve satın alma ekiplerinin kapsamı açık bir kullanılabilirlik testi teklifi istemesine yardımcı olur.

Kullanılabilirlik testi tam olarak neyi ölçer?

ISO 9241-11, kullanılabilirliği belirli kullanıcıların belirli hedeflere, belirli bir kullanım bağlamında etkililik, verimlilik ve memnuniyetle ulaşabilmesi üzerinden ele alır. Dolayısıyla test yalnızca arayüzün beğenilip beğenilmediğini ölçmez. Görevin tamamlanması, hata ve geri dönüşler, ihtiyaç duyulan yardım, harcanan süre ve kullanıcının deneyime ilişkin algısı birlikte değerlendirilir.

Örneğin bir B2B müşterisinin geçmiş siparişi yeniden oluşturabilmesi, depo çalışanının yanlış seri numarasını fark etmesi veya yöneticinin yetki sınırını aşan talebi doğru kişiye göndermesi gerçek birer test konusudur. “Ekran modern görünüyor mu?” sorusu tek başına bu operasyonel sonuçları açıklamaz.

Nitel testler sorunları ve bunların nedenlerini keşfetmeye; nicel testler ise görev başarısı ya da görev süresi gibi ölçülerle karşılaştırma yapmaya yönelir. Nielsen Norman Group’un kullanılabilirlik testi rehberi de bu iki amacın farklı örneklem ve araştırma düzenleri gerektirdiğini belirtir. Teklifte yöntemin adı kadar, hangi kararı destekleyeceği de yazmalıdır.

Satın alma öncesinde ürün aşamasını ve karar ihtiyacını belirleyin

Test, ürün yaşam döngüsünün farklı noktalarında satın alınabilir. Fikir veya prototip aşamasında amaç, geliştirme başlamadan önce bilgi mimarisini ve ana akışları doğrulamaktır. Geliştirme sürecindeki test, çalışan işlevlerdeki sorunları sürüm öncesinde yakalar. Canlı üründeki test ise destek talepleri, düşük tamamlama oranları veya operasyonel hatalar gibi gözlenen problemlerin nedenlerini araştırır.

Mevcut aşamayı teklif talebinde açıkça belirtin: taslak akış, tıklanabilir prototip, test ortamı ya da canlı ürün. Ekranların ne kadar tamamlandığı, test verisinin bulunup bulunmadığı, entegrasyonların çalışıp çalışmadığı ve araştırma sonucunda hangi kararın verileceği de paylaşılmalıdır. Yeni ürünlerde kapsam kararını yapılandırmak için web yazılım projesinde MVP kapsamı yaklaşımından yararlanılabilir.

Kullanılabilirlik testi satın alma süreci nasıl ilerlemeli?

Karşılaştırılabilir ve uygulanabilir teklifler elde etmek için satın alma sürecini aşağıdaki sırayla yürütün. Her adım, bir sonraki adımın girdisini oluşturmalı; katılımcı sayısı veya oturum süresi kapsam netleşmeden kesinleştirilmemelidir.

1. İş hedefini ve test sorularını tanımlayın

“Portalın kullanılabilirliğini test etmek” çok geniştir. Bunun yerine sipariş oluşturma süresini uzatan noktaları bulmak, yeni bayi kaydındaki terk nedenlerini anlamak veya saha ekibinin çevrimdışı iş emri kapatabilmesini doğrulamak gibi karar odaklı sorular yazın. Başarı göstergeleri de görev tamamlama, kritik hata, yardım ihtiyacı veya yanlış veri girişi gibi gözlenebilir davranışlara bağlanmalıdır.

2. Kullanıcı rolleri ile kullanım bağlamını çıkarın

Kurumsal yazılımlarda tek bir “kullanıcı” yoktur. Bayi çalışanı, satın alma sorumlusu, depo operatörü, satış yöneticisi, finans uzmanı ve sistem yöneticisi aynı üründe farklı yetki ve hedeflere sahip olabilir. Her rol için deneyim düzeyi, cihaz, çalışma ortamı, kullanım sıklığı ve erişilebilirlik ihtiyacı belirtilmelidir.

3. Kritik görevleri ve riskleri önceliklendirin

Tüm ekranları aynı ağırlıkta test etmeye çalışmak bütçeyi dağıtır. Finansal kayıp, veri hatası, müşteri kaybı, mevzuat riski veya yüksek destek yükü doğurabilecek iş akışlarına öncelik verin. ERP bağlantılı bir portalda fiyat görüntüleme, stok doğrulama, sipariş onayı ve entegrasyon hatasından kurtulma; kurumsal mobil uygulamada çevrimdışı kayıt, kamera veya barkod kullanımı ve senkronizasyon öncelikli olabilir.

4. Yöntem ve katılımcı planını eşleştirin

Moderatörlü görüşme, karmaşık iş akışlarında kullanıcının davranışını ve gerekçesini derinlemesine anlamaya uygundur. Moderatörsüz uzaktan test, görevlerin açık ve ürünün erişilebilir olduğu durumlarda daha geniş dağılım sağlayabilir. Yerinde bağlamsal çalışma ise depo, üretim veya saha koşullarının davranışı etkilediği projelerde değerlidir. Katılımcılar gerçek rolleri temsil etmeli; yalnızca şirket içinden kolay ulaşılan kişiler seçilmemelidir.

5. Çıktıları ve iyileştirme sorumluluğunu sözleşmeye yazın

Teslimat; sorun listesi, kanıt, önem derecesi, etkilenen rol ve görev, önerilen çözüm yönü ile sunum oturumunu içermelidir. Tasarım revizyonu, prototip güncellemesi, geliştirme backlog’una aktarım ve yeniden test ayrı kalemlerse açıkça gösterilmelidir. Böylece test raporu arşivde kalan bir belge değil, ürün kararlarına bağlanan çalışma aracına dönüşür.

Görev senaryoları nasıl hazırlanmalıdır?

Görev senaryosu kullanıcıya hangi düğmeye basacağını söylememeli; gerçekçi bir amaç ve yeterli bağlam vermelidir. “Siparişler menüsüne girip tekrar sipariş ver düğmesine basın” yönlendirici bir talimattır. “Geçen ay aldığınız ürünleri aynı teslimat adresiyle yeniden sipariş etmek istiyorsunuz” ifadesi ise kullanıcının yolu kendisinin bulmasını sağlar.

Senaryolar rol, başlangıç koşulu, hedef, gerekli test verisi ve başarı ölçütüyle tanımlanmalıdır. Ayrıca mutlu yolun yanında stok bulunmaması, yetki yetersizliği, bağlantı kesintisi, geçersiz barkod veya ERP yanıt vermemesi gibi istisnalar bulunmalıdır. Entegrasyon davranışlarının netleştirilmesi için API, ERP, CRM ve ödeme entegrasyonlarını planlama çerçevesi kullanılabilir.

Katılımcı profili ve sayısı nasıl değerlendirilir?

Katılımcı sayısı için her projeye uygulanacak tek bir rakam yoktur. Rol sayısı, roller arasındaki davranış farkı, araştırmanın nitel veya nicel amacı ve risk düzeyi birlikte değerlendirilmelidir. Nitel araştırmada az sayıda doğru profille tekrarlanan turlar, tek seferde geniş fakat karışık bir örneklemden daha yararlı olabilir. Nicel kıyaslama için ise istatistiksel hedefe uygun daha büyük örneklem gerekir.

Tarama formunda unvanın ötesine geçin. Kullanılan ERP veya portal, işlem sıklığı, onay limiti, cihaz, sektör deneyimi ve yardımcı teknoloji kullanımı gibi ölçütler aranmalıdır. Gizli kurumsal veriye erişecek katılımcılar için aydınlatma, onay, kayıt saklama ve gizlilik kuralları da teklif kapsamında tanımlanmalıdır.

Teklifte hangi yöntem ve test ortamı ayrıntıları bulunmalı?

İyi bir teklif; oturumların uzaktan mı yerinde mi yürütüleceğini, moderasyon dilini, süreyi, kayıt biçimini, gözlemci katılımını ve pilot testi açıklar. Kullanılacak cihazlar, tarayıcılar, işletim sistemleri, ekran boyutları ve ağ koşulları da ürünün gerçek kullanımına uygun olmalıdır.

React Native ile geliştirilen kurumsal mobil uygulamalarda fiziksel cihaz, işletim sistemi sürümü, izinler, bildirim, kamera ve çevrimdışı davranış dikkate alınmalıdır. Kumsal Ajans’ın projeye özel web yazılım yaklaşımında olduğu gibi kullanıcı rolleri, veri ve entegrasyon gereksinimleri birlikte ele alındığında, test ortamı da yalnızca ekranlardan değil sistem davranışından hareketle kurulabilir.

Erişilebilirlik kullanılabilirlik testine nasıl dahil edilir?

Otomatik erişilebilirlik taraması ile gerçek kullanıcı testi birbirinin alternatifi değildir. W3C, uygunluk kontrollerinin otomatik test ve insan değerlendirmesini birlikte gerektirebildiğini; standart ölçütleri karşılayan içeriğin her kullanıcı için mutlaka kullanılabilir olmayabileceğini açıklar. WCAG 2.2 uygunluk açıklaması, kullanılabilirlik test gruplarına engelli kullanıcıların dahil edilmesini de önerir.

Teklifte klavye kullanımı, ekran okuyucu, odak sırası, büyütme, kontrast, hata mesajları ve zaman sınırlı işlemler için hangi kontrollerin yapılacağı sorulmalıdır. Kullanıcı profiline göre yardımcı teknoloji kullanan katılımcılar araştırmaya dahil edilmeli; erişilebilirlik bulguları genel kullanılabilirlik sorunlarından ayrıştırılarak fakat aynı önceliklendirme sisteminde raporlanmalıdır.

Rapor ve bulgular hangi formatta teslim alınmalı?

Tek başına uzun bir sunum yeterli değildir. Her bulgu en azından etkilenen rolü, görevi, gözlenen davranışı, kanıtı, etkisini, tekrar sıklığını, önem derecesini ve önerilen çözüm yönünü içermelidir. Video kesitleri yararlı olabilir; ancak katılımcı izni, erişim yetkisi ve saklama süresi tanımlanmalıdır.

Önem derecesi yalnızca kaç kişinin sorun yaşadığına göre verilmemelidir. Görevin kritikliği, hatanın geri alınabilirliği, finansal veya operasyonel etkisi ve çözümün önündeki bağımlılıklar da hesaba katılmalıdır. Örneğin tek katılımcının ortaya çıkardığı yanlış fiyatla sipariş verme riski, sık görülen fakat kolay aşılan bir menü tereddüdünden daha öncelikli olabilir.

Kurumsal projelerde en uygulanabilir teslim biçimi, yönetici özeti ile ürün backlog’unu birlikte sunar. Her öneri tasarım, içerik, yazılım, entegrasyon veya operasyon sorumlusuna bağlanır. Kritik değişikliklerden sonra aynı görevlerin yeniden test edilmesi de kabul ölçütlerine eklenir.

Kullanılabilirlik testi teklifleri nasıl karşılaştırılır?

Teklifleri yalnızca toplam fiyat ve katılımcı sayısıyla karşılaştırmayın. Kapsamın aynı kullanıcı rolleri, görevler ve teslimatlar üzerinden verildiğinden emin olun. Katılımcı bulma maliyeti, teşvikler, seyahat, test ortamı hazırlığı, transkripsiyon, prototip revizyonu ve yeniden test gibi kalemlerin dahil olup olmadığını kontrol edin.

Ajansın karmaşık iş süreçlerini anlayabilmesi de önemlidir. B2B e-ticaret, ERP bağlantıları, çok seviyeli yetkiler ve mobil saha kullanımı hakkında deneyim; senaryoların yalnızca arayüz davranışını değil, gerçek iş sonucunu sınamasını sağlar. Kurumsal kaynak planlaması kapsamındaki finans, satış, stok ve operasyon bağlarını görmek için kurumsal kaynak planlaması hizmeti gibi süreç odaklı yaklaşımlar değerlendirme ölçütü olabilir.

Teklif talebinde sorulacak temel sorular

• Hangi kullanıcı rolleri ve kritik görevler kapsama dahildir?
• Katılımcılar hangi eleme ölçütleriyle ve kim tarafından bulunacaktır?
• Test nitel mi, nicel mi; moderatörlü mü, moderatörsüz mü yürütülecektir?
• Pilot oturum ve senaryo revizyonu fiyata dahil midir?
• Test verisi, kullanıcı hesapları ve entegrasyon ortamından kim sorumludur?
• Ham kayıtlar, bulgu raporu, önemlendirme ve yönetici sunumu teslim edilecek midir?
• Tasarım iyileştirmesi, geliştirme desteği ve yeniden test kapsamda mıdır?
• Gizlilik, kişisel veri, kayıt saklama ve silme kuralları nasıl yönetilecektir?

Kumsal Ajans ile test kapsamı nasıl oluşturulur?

Kumsal Ajans, kurumsal ürünleri iş hedefleri, gerçek kullanıcı ihtiyaçları ve teknik gereksinimlerle birlikte ele alır. Projeye özel web yazılımı, B2B e-ticaret, React Native mobil uygulama, ERP süreçleri, kullanıcı deneyimi ve arayüz tasarımı aynı bağlamda değerlendirilebilir. Böylece bulgular yalnızca görsel önerilere değil; rol, iş akışı, entegrasyon, mobil uyumluluk ve sürdürülebilir geliştirme kararlarına bağlanır.

Test edilecek kullanıcı rollerini, kritik iş akışlarını ve ürünün mevcut aşamasını paylaşın. Senaryosu, katılımcı profili, yöntemi, çıktıları ve iyileştirme kapsamı açıkça tanımlanmış bir kullanılabilirlik testi planı ve proje teklifi isteyin. Bu çerçeve, tekliflerin karşılaştırılmasını kolaylaştırırken test yatırımının ölçülebilir ürün kararlarına dönüşmesini sağlar.