Yeni bir yazılımı kullanıma almadan önce, günlük işlerinizi baştan sona yapabildiğinizi somut örneklerle kontrol edin. Bu çalışmaya kullanıcı kabul testi denir: yazılımın işletmenin ihtiyaçlarını karşılayıp karşılamadığını değerlendirmeye yardımcı olur. İyi bir başlangıç için hangi işleri deneyeceğinizi, hangi sonucu beklediğinizi ve sonuçları kimin değerlendireceğini önceden belirleyin.

Neden yalnızca tanıtımı izlemek yeterli değildir?

Bir sunumda işlemler genellikle önceden hazırlanmış kayıtlarla gösterilir. İşletmenizin günlük kullanımında ise eksik bilgi, farklı görevler veya değişen işlem sırası olabilir. Bir ekranın açılması, işin bütün adımlarının tamamlanabildiğini göstermeyebilir.

Bu nedenle denemeyi yalnızca yazılımı hazırlayan kişinin gösterisine bırakmayın. Günlük işi bilen kullanıcıların da belirlenen örnekleri uygulaması yararlı olur. Önce neyin kontrol edileceğini konuşmak, daha sonra “beklediğimiz gibi çalışmıyor” denildiğinde hangi beklentinin karşılanmadığını açıklamayı kolaylaştırır.

Kullanıcı kabul testi, bütün teknik denetimlerin yerine geçmez ve yazılımın hatasız olduğunu garanti etmez. Buradaki odak, işletmenin belirlediği işlerin beklenen şekilde yapılabilmesidir.

Denenecek işleri günlük akıştan seçin

Ekran adlarını sıralamak yerine, kullanıcının tamamlamak istediği işleri yazın. “Kayıt ekranını açmak” yerine “yeni bir kayıt oluşturmak, ilgili kişiye aktarmak ve sonucunu tekrar bulmak” daha açıklayıcı bir örnektir.

Önce sık yapılan işleri ve aksaması hâlinde başka işleri durdurabilecek adımları seçin. Her şeyi aynı ayrıntıyla denemek mümkün olmayabilir; bu yüzden önceliği iş üzerindeki etkiye göre konuşun. İlk aşamada hangi özelliklerin beklendiğini netleştirmek için ilk ürün sürümünün kapsamı hakkındaki rehbere bakabilirsiniz.

İşleri kullanıcı görevlerine göre ayırın. Kaydı oluşturan kişi ile onaylayan kişi aynı işlemleri yapmayabilir. Deneme planında bu farklılık görünür olmalı; herkesin tek bir hesapla deneme yapması, günlük iş bölümünü yeterince temsil etmeyebilir.

Her senaryoda başlangıç ve beklenen sonuç belli olsun

Deneme senaryosu, belirli bir işi kontrol etmek için izlenecek adımların kısa açıklamasıdır. Başlangıç koşulunu, yapılacak işlemi ve sonunda ne görülmesi gerektiğini birlikte yazın.

Örneğin “kayıt aktarılabilsin” ifadesi tek başına belirsizdir. Kaydın başlangıçta hangi durumda olduğu, kim tarafından aktarılacağı ve işlemden sonra kimin görebileceği belirtilirse sonuç daha kolay değerlendirilir.

Bir tabloya işin adı, deneyecek kişi, kullanılacak örnek kayıt, işlem adımları, beklenen sonuç ve gözlenen sonuç için sütunlar ekleyebilirsiniz. Tabloyu teknik terimlerle doldurmanız gerekmez. Günlük işinizi doğru anlatan kısa cümleler daha kullanışlı olabilir.

Beklenen sonuç üzerinde anlaşılmadıysa bunu deneme sırasında tahmin etmeyin. Önce ilgili kişilerle açıklığa kavuşturun; aksi hâlde aynı sonuç bir kişi için doğru, başka biri için eksik sayılabilir.

Varsayımsal bir işletmede deneme nasıl ilerler?

Gelen iş taleplerini ortak bir sistemde takip etmek isteyen bir işletme düşünelim. Denenecek iş, talebin kaydedilmesinden kapanmasına kadar ilerleyen bir akış olsun. Bu tamamen varsayımsal bir örnektir.

İlk kullanıcı örnek bir talep oluşturur. Talebi değerlendiren kişi kaydı bulur, bir sorumlu seçer ve işlem durumunu değiştirir. Sorumlu kişi kendisine aktarılan talebi açar, yapılan işi kaydeder ve tamamlandığını belirtir. Son olarak ilk kullanıcı kapanan talebi tekrar bulup sonucu inceler.

Her aşamada yalnızca bir düğmenin çalışmasına bakılmaz. Doğru kayıt mı açıldı, durum değişikliği görünüyor mu, ilgili kişi işi devam ettirebiliyor mu? Bu sorular, birbirine bağlı ekranların birlikte kullanılabilirliğini değerlendirmeye yardımcı olur.

İş kurallarında varsa, eksik zorunlu bilgiyle kayıt oluşturma veya işlemi iptal etme gibi farklı durumları da ayrı senaryolara ekleyin. Bu denemeleri gerçek kayıtları değiştirmeyecek şekilde hazırlanmış bir ortamda, belirlenmiş örnek verilerle yürütmeyi planlayın. Gerçek müşteri bilgilerini deneme amacıyla gelişigüzel paylaşmayın.

Sorunu tekrar edilebilir biçimde kaydedin

“Sistem çalışmadı” demek yerine hangi adımda ne yaptığınızı ve ne gördüğünüzü yazın. Beklenen sonuçla gözlenen sonuç arasındaki farkı açıkça belirtin. Denenen sürümü ve kullanılan örnek kaydı da not edin; böylece aynı durumun yeniden incelenmesi kolaylaşır.

Bulgu, mutlaka yazılım hatası anlamına gelmez. Önceden belirlenen davranışın gerçekleşmemesi, anlaşılmamış bir iş kuralı veya sonradan ortaya çıkan yeni bir istek olabilir. Bunları birlikte değerlendirip birbirinden ayırın. Yeni bir isteği sessizce mevcut kapsama eklemek, teslim beklentilerini belirsizleştirebilir.

Düzeltilen bir sorun için aynı senaryoyu tekrar uygulayın. Gerekirse değişiklikten etkilenebilecek ilişkili işleri de yeniden deneyin. Yalnızca “düzeltildi” bilgisini almakla kontrolü tamamlanmış saymayın.

Deneme öncesi kısa kontrol listesi

  • İşler seçildi mi? Öncelikli günlük işlemler, başlangıç koşulları ve beklenen sonuçlar yazılı olsun.
  • Katılımcılar belli mi? İşi bilen kullanıcıları ve bulguları değerlendirecek kişiyi belirleyin.
  • Ortam hazır mı? Denenecek sürüm, hesaplar ve gerçek kayıtları etkilemeyecek örnek veriler hazır olsun.
  • Bulgular izlenebiliyor mu? Her sorun için gözlenen sonuç, iş üzerindeki etki ve sonraki adım kaydedilsin.
  • Tekrar kontrol planlandı mı? Düzeltmelerin hangi senaryolarla yeniden deneneceği belli olsun.

Bu liste, herkesin aynı beklentiyle çalışmasını sağlamak için bir başlangıçtır. İşletmenizin akışına uymayan maddeleri mekanik biçimde uygulamak yerine, neden gerekli olduklarını birlikte değerlendirin.

Sonuçları kullanıma geçiş kararına bağlayın

Deneme sonunda hangi işler geçti, hangileri tamamlanamadı ve hangileri hiç denenmedi, açıkça yazın. Açık sorunların günlük işi nasıl etkileyebileceğini ve kim tarafından takip edileceğini konuşun. Kullanıma geçiş kararını, bu bilgileri değerlendirecek sorumlu kişi versin.

Başlangıçtaki beklentiler belirsizse proje öncesinde sorulacak sorulara dönmek yararlı olabilir. Kullanıcı kabul testinin değeri, yalnızca bir onay almak değil; yazılımın hangi koşullarda kullanılabildiğini ve hangi konuların hâlâ açıklığa kavuşması gerektiğini görünür hâle getirmektir.