30 saniyelik özet

User Acceptance Testing, kısaca UAT, çözümün tanımlanmış iş ihtiyaçlarını ve kullanım senaryolarını karşılayıp karşılamadığının iş kullanıcılarıyla değerlendirilmesidir. Türkçede kullanıcı kabul testi olarak adlandırılır. Ekranın açılması veya işlemin hata vermeden tamamlanması yeterli değildir. Kullanıcının beklediği iş sonucu, roller, veri ve süreç koşullarıyla birlikte sınanmalıdır. UAT sonunda hangi kapsamın kabul edildiği, hangi kusurların açık kaldığı ve hangi sınırlamaların bulunduğu görülmelidir. Onay, bu kanıtların değerlendirilmesine dayanır; çözümün bütün koşullarda sorunsuz çalışacağına dair sınırsız bir güvence değildir.

Neden önemli?

Bir iade modülünde müşteri hizmetleri görevlisi talep açabiliyor, depo ürünü kabul edebiliyor ve finans ekibi ödeme iadesini başlatabiliyor olsun. Bu adımlar ayrı ayrı çalışsa da süreç tamamlanmış olmayabilir. Ürün stoğa yanlış durumda dönebilir, müşteri bildirimi gönderilmeyebilir veya başarısız ödeme iadesi kaydı kapanmış görünebilir.

UAT, gerçek iş akışında bu tür sonuçları araştırır. Kullanıcı yalnızca bir düğmeyi denemez; tanımlanmış bir görevi tamamlar ve sonucun iş açısından doğru olup olmadığını değerlendirir. Ekip böylece çalışan parçalarla kullanılabilir süreç arasındaki farkı görebilir.

Yönetici açısından kabul kararı, canlıya geçiş riskinin hangi kanıtla değerlendirildiğini gösterir. Ancak UAT ile canlıya geçiş kararı aynı şey değildir. Eğitim, destek, veri aktarımı ve işletim hazırlığı da değerlendirilmelidir. Kullanıcı testleri olumlu sonuçlansa bile bu hazırlıklar eksik olabilir. Tersine, çözüm hazır görünse de yetkili iş kullanıcılarının değerlendirmediği kritik süreçler bulunabilir.

Terim nedir?

UAT, belirlenmiş kabul koşullarına göre iş kullanımını değerlendirir. Kabul koşulu, çözümün kabul edilebilir sayılması için gözlenebilir biçimde karşılaması gereken beklentidir. “İade düzgün çalışmalı” yerine hangi olayın hangi stok, ödeme ve bildirim sonucunu üretmesi gerektiği yazılmalıdır.

UAT, geliştirici ve test uzmanlarının yürüttüğü teknik kontrollerin yerine geçmez. Birim testi küçük yazılım parçalarını, sistem testi ise bütünleşmiş sistemin belirli davranışlarını inceleyebilir. UAT’de odak, iş kullanıcılarının görevleri ve sonuçlarıdır. Aynı işlem farklı testlerde ele alınabilir; fakat değerlendirme amacı ve karar sahibi farklı olabilir.

Başlamadan önce kapsam, katılımcılar, veri, ortam ve beklenen sonuçlar belirlenir. Test ortamı, değerlendirme için kullanılan ürün ve bağlı hizmetlerin çalışma düzenidir. Bu düzenin gerçek kullanımdan önemli farkları varsa sonuç yorumlanırken görünür tutulmalıdır. Çalışmayan entegrasyonun yerine elle veri girmek, o entegrasyonun gerçek davranışını doğrulamaz.

Temsilci kullanıcıların süreci bilmesi önemlidir; ancak en deneyimli kişinin her engeli aşabilmesi bütün kullanıcıların aynı görevi yapabileceğini göstermez. Farklı roller ve iş durumları değerlendirilmeli, test sırasında verilen yardım da kaydedilmelidir. Kullanıcının kendi başına tamamladığı işlemlerle yoğun yönlendirmeyle tamamladıkları ayrılmalıdır.

Kabul kararı için kusur, gereksinim eksikliği ve yeni tercih de ayırt edilmelidir. Onaylı davranışın karşılanmaması kusur olabilir. Test sırasında ortaya çıkan yeni ihtiyaç ise ayrıca değerlendirilmelidir. Her yorumu hata saymak kapsamı belirsizleştirir; her yorumu yeni talep saymak da gerçek eksikleri gizleyebilir.

Gerçek vaka: Dynamics 365 uygulamasında eksik çalışma koşulları

Microsoft Learn, adı açıklanmayan bir eğlence araçları üreticisinin Dynamics 365 uygulamasını gerçek vaka olarak anlatıyor. Şirketin başlangıç test stratejisinde UAT dahil dört test çevrimi bulunuyordu; ancak ilk uygulama için performans testi gerekli görülmemişti.

Daha kapsamlı testlerde gerçekçi veri hacmi, kullanıcılar ve entegrasyonlar bir araya geldiğinde ciddi yavaşlama ortaya çıktı. Ekip, üretim ortamının daha güçlü olacağı varsayımıyla UAT’ye devam etti ve iş onayı alındı. Canlı kullanımda servis entegrasyonları açılınca işlemler ve sevkiyatlar aksadı. İnceleme, entegrasyon çağrılarının darboğaz oluşturduğunu gösterdi; tasarım değişikliği gerekti.

Sonraki aşamalarda ayrı ortamda performans testleri daha erken yürütüldü. UAT sırasında kullanıcı işlemleriyle entegrasyonlar paralel çalıştırıldı. Kaynak, aksesuar üretim bölümünü kapsayan sonraki canlıya geçişin daha kolay gerçekleştiğini belirtiyor.

Bu vaka, UAT’nin bütün performans testlerini üstlenmesi gerektiğini söylemez. Çıkarılabilecek ders, kabulün dayandığı koşulları ve çözülmemiş teknik bulguları birlikte değerlendirmektir. Daha güçlü ortam varsayımı, gözlenen sorunun giderildiğine dair kanıt değildir.

Kaynak: Microsoft Learn, Case study in testing strategy; sayfa güncellemesi 1 Şubat 2024.

Varsayımsal örnek: E-ticaret iade sürecinin kabulü

Bir e-ticaret işletmesi yeni iade modülünü kullanıma açacak. İş analisti, müşteri hizmetleri, depo ve finans temsilcileriyle kapsamı belirliyor. Temel görev, uygun bir iadenin talebinden ödeme sonucuna kadar izlenebilir biçimde tamamlanması. Ürünün fiziksel kabulü ile paranın müşteriye dönmesi ayrı olaylar olarak ele alınıyor.

Senaryolar standart iadenin yanında kısmi iade, indirimli sipariş, uygunluk süresi dışındaki talep ve başarısız ödeme iadesini kapsıyor. Her senaryo için geçerli iş kuralı ve beklenen sonuç yazılıyor. İndirim dağılımı henüz kararlaştırılmadıysa kullanıcıların test sırasında tahmin yürütmesi beklenmiyor; konu ilgili karar sahibine yönlendiriliyor.

Gerçek süreci temsil eden, kişisel bilgileri korunmuş test kayıtları hazırlanıyor. Depoya dönen ürünün satışa uygunluğu ayrı değerlendiriliyor. Ödeme hizmeti işlemi reddettiğinde iade kaydının nasıl görünmesi ve finans ekibinin ne yapması gerektiği sınanıyor. Başarısız ödeme, tamamlanmış iade olarak kapatılmıyor.

Bir kullanıcı stok hareketini doğrularken başka bir kullanıcı müşteri bildiriminin durumunu inceliyor. Gözlemler aynı senaryo kaydında birleştiriliyor. Böylece bir bölümün işlemi tamamlaması, bütün sürecin kabul edildiği şeklinde yorumlanmıyor.

Değerlendirmede yanlış ödeme tutarı üreten bir kusur bulunursa ilgili kapsamın kabulü durduruluyor. İş sonucunu etkilemeyen görsel bir sorun ise etkisi incelenerek ertelenebilir. Bu varsayımsal kararda sorumlu kişi, düzeltme hedefi ve geçici koşullar yazılıyor. Erteleme, sorunun kayıttan silinmesi anlamına gelmiyor.

Yaygın üç hata

  1. Kullanıcıya ürünü serbestçe denetip kabul istemek

Serbest keşif yararlı gözlemler üretebilir; ancak hangi gereksinimlerin değerlendirildiğini tek başına göstermez. Tanımlı görevler ve beklenen sonuçlar hazırlayın. Kullanıcının yeni keşiflerini de kaydedin, fakat planlı kapsamın tamamlandığıyla karıştırmayın.

  1. Gerçek kullanımdan uzak koşulları açıklamamak

Az veri, tek kullanıcı veya kapalı entegrasyonlarla olumlu sonuç alınabilir. Ortam farklarını ve sınanamayan koşulları raporlayın. Bu boşlukların başka testlerle değerlendirildiğini kontrol edin. Test koşulunu genişletemiyorsanız kabul kararındaki sınırlamayı görünür tutun.

  1. İmzayı açık sorunların çözümü saymak

Onay, kusuru ortadan kaldırmaz. Açık sorunların etkisi, geçici çözümü ve risk sahibi belirtilmelidir. Hangi rolün kabul kararı vermeye yetkili olduğunu baştan belirleyin. Katılımcının senaryoyu çalıştırması, bütün teslimatı onaylama yetkisi olduğu anlamına gelmez.

Mini uygulama / şablon

Kritik bir iş süreci seçin. Aşağıdaki alanlarla bir UAT senaryosu hazırlayın; yalnızca işlem adımlarını değil, süreç sonunda kontrol edilecek sonuçları da yazın.

Senaryo kimliği ve iş amacı
—
İlgili gereksinimler ve kabul koşulları
—
Katılımcı roller ve kabul yetkilisi
—
Önkoşullar ve test verisi
—
Ürün sürümü ve test ortamı
—
Gerçek kullanımdan önemli farklar
—
Kullanıcının gerçekleştireceği görev
—
Beklenen veri, süreç ve bildirim sonuçları
—
Gözlenen sonuç ve kanıt
—
Geçti, kaldı veya çalıştırılamadı durumu
—
Kusur veya açık karar bağlantısı
—
Düzeltme sonrası yeniden değerlendirme
—
Kalan risk ve sorumlu kişi
—
Kabul kararı ve kapsam sınırları
—

Kapanışta yalnızca başarılı senaryoları saymayın. Çalıştırılamayan işleri, açık kusurları ve temsil edilmeyen kullanım koşullarını da gösterin. Kritik bir senaryonun eksikliği, çok sayıda basit senaryonun geçmesiyle telafi edilmiş sayılmaz. Karar sahibinin değerlendirmesi, sonuçların sayısından önce iş etkisine dayanmalıdır.

İlgili terimler

Acceptance Criteria, Business Requirement, Business Rule, Functional Requirement, Non-Functional Requirement, Use Case, Requirements Traceability Matrix, Change Request ve Impact Analysis, Scope ve Out of Scope