UAT rehberi: kabul kriterlerinden yayın onayına

UAT nedir, diğer test türlerinden farkı ne?

Kullanıcı kabul testi (User Acceptance Testing, UAT), geliştirilen yazılımın gerçek kullanıcılar tarafından kendi iş süreçleri içinde denendiği ve iş ihtiyacını karşılayıp karşılamadığına karar verildiği son test aşamasıdır. Birim, entegrasyon ve sistem testleri "yazılım doğru çalışıyor mu" sorusuna cevap arar; UAT ise "doğru yazılımı mı yaptık" sorusunu sorar.

Bu fark pratikte önemlidir. Bir sistem, teknik olarak şartnameye tam uygun olabilir ama iş birimi onu kullanırken ihtiyaç duyduğu bir adımın eksik olduğunu, ekranların işin akışına uymadığını ya da bir kuralın yanlış anlaşıldığını fark edebilir. Bu tür sorunları ancak işi bilen kişiler yakalayabilir. Test ekibi bunları çoğu zaman göremez, çünkü işin gerçek bağlamını bilmez.

UAT'nin sonunda verilen karar da farklıdır: bu bir hata raporu değil, bir kabul kararıdır. İş birimi yazılımı canlıya almak için hazır olup olmadığını söyler. Bu yüzden UAT, teknik bir faaliyet olduğu kadar bir yönetişim ve sorumluluk meselesidir.

Kabul kriterleri kavramının kendisi için sözlük sayfasına, genel test planlaması için test stratejisi sayfasına bakabilirsiniz; bu rehber UAT'nin planlanması ve yürütülmesine odaklanır.

Kabul kriterlerini yazmak

UAT, kabul kriterleri iyi yazıldığında kolaydır. Kriter belirsizse, test sonunda herkes farklı bir şey beklediğini fark eder. İyi bir kabul kriteri ölçülebilir, tek bir davranışı anlatır ve iş birimi tarafından da anlaşılacak sadelikte yazılır.

Yaygın bir kalıp Given/When/Then biçimidir: bir durum verildiğinde, kullanıcı belirli bir eylemi yaptığında, beklenen sonuç ne olmalıdır? Örneğin: • Given: Müşteri sepetinde ürün var ve geçerli bir indirim kodu var. • When: Müşteri kodu girip uygular. • Then: Sepet toplamı indirimi yansıtır ve kod bir daha kullanılamaz görünür.

Bu kalıp, iş analisti, geliştirici ve test uzmanının aynı cümleyi aynı şekilde okumasını sağlar. Kriterler geliştirme başlamadan, en geç ilgili iş geliştirmeye alınmadan önce yazılmalı ve iş birimi tarafından onaylanmalıdır. Sonradan değişen kriter, UAT sırasında tartışmaya yol açar.

Kriterler yalnız mutlu senaryoyu değil, geçersiz giriş, yetkisiz erişim, eksik veri ve sınır durumlarını da kapsamalıdır. Aksi halde canlıya geçildiğinde kullanıcı beklenmedik bir durumla karşılaşır.

UAT planı: kapsam, ekip, ortam ve veri

UAT planı, testin hangi iş sürecini, kimlerle, hangi ortamda, hangi veriyle ve hangi takvimle yapılacağını yazar. Plan kısa olabilir, ama şu unsurlar mutlaka bulunmalıdır: • Kapsam: Hangi özellikler ve iş süreçleri test edilecek, hangileri kapsam dışı? • Katılımcılar: Hangi iş birimi temsilcileri senaryoları yürütecek, kim koordinatör, kim hata sınıflandırmasında karar verici? • Ortam: Canlıya olabildiğince benzeyen, sürümü sabitlenmiş bir test ortamı. • Veri: Gerçek işe benzeyen, ancak kişisel verileri maskelenmiş ya da üretilmiş test verisi. • Takvim: Hazırlık, koşum, hata düzeltme ve yeniden test için ayrılmış süre. • Giriş ve çıkış kriterleri: UAT'nin başlayabilmesi ve bitebilmesi için gereken koşullar.

Giriş kriteri çoğu zaman ihmal edilir. Sistem testi tamamlanmadan, ciddi hatalarla dolu bir sürüm iş birimine verilirse, kullanıcılar zamanlarını teknik hataları raporlamakla harcar ve sürece güvenleri azalır. Giriş kriterini baştan koymak bu duruma engel olur.

Katılımcı seçiminde işi gerçekten yapan kişileri bulmak önemlidir. Yönetici düzeyindeki bir temsilcinin onayı yetmez; günlük işi yapan kullanıcının zamanı ayrılmalı ve yöneticisi tarafından desteklenmelidir. Aksi halde UAT, iş yoğunluğu arasında yarım yamalak yapılan bir işe dönüşür.

Test senaryoları ve iş birimi katılımı

UAT senaryoları, teknik fonksiyonları değil gerçek iş süreçlerini izler. "Kayıt formu alanını doldur" bir sistem testi adımıdır; "Yeni bir müşteri kaydı oluştur, sipariş gir, faturayı kes ve raporda görüldüğünü doğrula" ise bir UAT senaryosudur. Senaryo, bir kullanıcının işe başlayıp bitirdiği uçtan uca akışı kapsar.

İyi bir senaryo şunları içerir: hedef, ön koşul, adımlar, beklenen sonuç ve sonucun nerede doğrulanacağı. Adımlar iş diliyle yazılır; ekran adlarını ve teknik terimleri kullanıcı bilmiyorsa onun diliyle ifade etmek gerekir. Beklenen sonuç kabul kriterine bağlanır, böylece her sonuç bir kritere karşılık gelir.

İş birimi katılımını sağlamak için kullanıcılara testten önce kısa bir bilgilendirme yapılır: ne test edilecek, nasıl hata bildirilecek, kimden destek alınacak? Test sırasında bir koordinatör kullanıcılara yardım eder ama onların yerine kararı vermez. Kullanıcı "bu böyle çalışmıyor" diyorsa bunun hata mı, talep değişikliği mi yoksa yanlış anlama mı olduğunu sonradan sınıflandırmak gerekir; ancak bildirimi bastırmamak önemlidir.

Koşumu yönetmek: hata kaydı ve sınıflandırma

Koşum sırasında her bildirim tek bir yere, tutarlı bir formatta kaydedilir: hangi senaryo, hangi adım, ne beklendi, ne oldu, ekran görüntüsü ya da veri. Dağınık e-postalarla ve sohbetlerle toplanan hatalar izlenemez; bazıları kaybolur, bazıları iki kere kaydedilir.

Her bildirim ayrılır: gerçek bir hata mı, eksik bir gereksinim mi, kabul kriterinin yeniden yorumu mu, yoksa kullanım yanlışı mı? Gerçek hatalar ciddiyet ve önceliğe göre sınıflandırılır; ciddiyet sistemin etkisini, öncelik ise düzeltme sırasını gösterir. Bu iki kavramın farkı için ilgili sözlük sayfasına bakabilirsiniz.

Koşum boyunca düzenli bir durum toplantısı yapmak yararlıdır: kaç senaryo tamamlandı, hangi engeller var, hangi hatalar kritik? Düzeltilen hatalar yeni bir sürümle ortama alınır ve ilgili senaryolar yeniden koşulur; yalnız düzeltilen hatayı değil, çevresindeki akışı da tekrar denemek gerekir, çünkü düzeltmeler başka yerleri bozabilir.

Çıkış kriteri, onay ve sık yapılan hatalar

UAT'nin sonunda verilen kararın ölçüsü, baştan yazılmış çıkış kriteridir. Genel yaklaşımda şu koşullar aranır: planlanan kritik senaryoların tamamlanmış olması, yayını engelleyen ciddiyetteki hataların kapanmış olması ve açık kalan düşük etkili hataların bilinçli bir kararla kabul edilip kayda geçirilmesi. Kesin eşikleri her proje kendi riskine göre belirler.

Onay, iş birimi sorumlusu tarafından yazılı olarak verilir. Açık kalan hatalar, planlanan düzeltme tarihi ve kabul edilen riskler onay belgesine eklenir. Böylece canlıya geçişten sonra bir sorun çıktığında, bunun bilinçli bir karar mı yoksa gözden kaçan bir durum mu olduğu bellidir.

Sık yapılan hatalar şunlardır: • Kabul kriterleri olmadan UAT'ye başlamak. • Testi yalnız teknik ekibe yaptırmak ya da iş birimini son anda sürece katmak. • Gerçek işe benzemeyen veriyle test etmek. • Yayın tarihi baskısıyla çıkış kriterini esnetmek. • Açık hataları kayıt altına almadan onay vermek.

Mindset'in Yazılım Sürüm Doğrulama ve Kabul Testleri (UAT) programı; kabul kriterlerinin yazımı, UAT planlaması ve koşum yönetimi ile yayın onayı ve sürüm doğrulama başlıklarını işler. İş analistleri, test uzmanları, proje yöneticileri ve yazılım projelerinde iş birimi adına kabul sorumluluğu taşıyanlar için uygulamaya dönük bir yol sunar.