Bir ekip bir kez her teknik testi geçen bir gider sistemi sunar. İlk gün finans ekibi, işlerinin büyük bir kısmını oluşturan birden fazla para birimindeki alacak taleplerini karşılayamayacaklarını keşfeder. Hiçbir şey “kırılmadı” ama kullanılabilir değildi. Kullanıcı kabul testleri lansmandan önce tam olarak bu tür bir boşluğu yakalamak için mevcuttur.

Bu kılavuz, UAT’nin diğer testlerden nasıl farklı olduğunu, adım adım nasıl çalıştırılacağını ve ne zaman yayınlamaya hazır olduğunuza nasıl karar vereceğinizi kapsar. Yukarıdaki senaryo ve aşağıdaki örnekler açıklayıcıdır ve süreç, projenize uyacak şekilde ölçeklendirilmelidir.

UAT nedir?

UAT genellikle piyasaya sürülmeden önceki son test aşamasıdır; burada amaçlanan kullanıcılar, yazılımın işini gerçekçi koşullarda yapabileceğini doğrular. Buna son kullanıcı testi veya kabul testi de denir. Ürünün kararlı olmasının beklendiği geliştirme ve sistem testinden sonra gelir.

Amacı her hatayı bulmak değildir. Bu aşamada bunların çoğunun çoktan gitmiş olması gerekir. Amaç doğrulamadır: Doğru şeyi mi geliştirdik? Test uzmanları, ürünün spesifikasyona uygun olduğunu doğrular. UAT, spesifikasyonun ve ürünün gerçekten ihtiyacı karşıladığını doğrular.

UAT ve QA testi

UAT diğer testlerin yerini almaz. Kullanıcılar temel hatalarla karşılaşmaya devam ederse derleme hazır değildir ve onların sınırlı zamanını boşa harcıyorsunuz demektir. Bu sorunlar önceki test seviyelerine ve regresyon testlerine aittir.

UAT’yi kim yönetiyor?

Bugün işi gerçekten yapan test uzmanlarını seçin. Deneyimli bir talep yöneticisi, bir yöneticinin veya vekilin asla tespit edemeyeceği sorunları tespit edecektir. Bir dizi deneyimi dahil edin, çünkü yeni bir çalışan genellikle bir uzmanın fark etmeden üzerinde çalıştığı kafa karıştırıcı adımları ortaya çıkarır. UAT tam bir iş yükünün üstünde başarılı olamayacağından, yöneticilerinin bunun için zaman ayırmasını sağlayın.

UAT Türleri

Yedi adımlı UAT süreci

1. Kapsamı ve hedefleri tanımlayın

Neyin kabul edildiğine, neyin kapsam dışı olduğuna ve hangi iş sonuçlarının önemli olduğuna karar verin. Örneğin: “Finans personeli, desteklenen herhangi bir para biriminde bir gider talebini gönderebilir, onaylayabilir ve ödeyebilir.”

2. Kabul kriterleri üzerinde anlaşın

Başarının neye benzediğini sade bir dille yazın; ideal olarak lansmandan bir hafta önce değil, projenin başlangıcında. Belirsiz kriterler daha sonra tartışmalara yol açar.

3. Test uzmanlarını seçin ve bilgilendirin

Gerçek kullanıcıları seçin, amacı açıklayın, onlara geri bildirimin nasıl kaydedileceğini gösterin ve kendilerinin test edilmek yerine yazılımı test ettiklerini açıkça belirtin. Birçok insan bir şeyin yanlış olmasından endişeleniyor.

4. Ortamı ve verileri hazırlayın

UAT ortamı, pratik olduğu kadar üretime benzemelidir. Gerçekçi veriler kullanın, doğru kullanıcı rollerini ayarlayın ve e-posta gibi entegrasyonları kontrol edin. Üretim verilerini kopyalarsanız önce kişisel bilgileri maskeleyin. Hızlı bir duman testi gerçekleştirin; böylece test uzmanları gelip bozuk bir yapı bulmaz.

5. Senaryolar yazın

Bunları tek tek düğmeler yerine gerçek iş akışlarına dayandırın. Yazılım gibi değil, iş gibi okumalılar. Test senaryosu ve test senaryosu hakkındaki kılavuzumuz, ne kadar ayrıntıya ihtiyacınız olduğunu açıklıyor.

6. Testleri çalıştırın ve geri bildirim toplayın

Yardıma hazır biriyle oturumlar düzenleyin. Sorunları ekran görüntüleriyle tek bir yerde toplayın. İnsanlar senaryoların asla öngörmediği şeyleri denedikleri için, ücretsiz keşif için de biraz zaman ayırın. Keşif testleri bunun için yararlı teknikler sunar.

7. Düzeltin, yeniden test edin ve imzalayın

Geri bildirimi önceliklendirin, önemli olanı düzeltin ve aynı kullanıcıların düzeltmeleri onaylamasını sağlayın. Daha sonra resmi bir kararı kaydedin.

Bir UAT test senaryosu

Bir UAT test senaryosunun teknik bilgisi olmayan birinin takip etmesi kolay olmalıdır. İşte bir gider sistemi örneği:

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

Teknik ayrıntıları değil, gerçek bir görevi tanımladığını ve yorumlara yer bıraktığını unutmayın. Bu yorumların çoğu zaman en değerli kısım olduğu ortaya çıkıyor, örneğin “bu işe yarıyor ama o düğmeyi asla bulamayacağım”.

Giriş ve çıkış kriterleri

Bunlar daha geniş yazılım testi yaşam döngüsüne uyar. Rakamları paydaşlarınızla önceden belirleyin. “Doğru hissettiğinde karar vereceğiz” ifadesi, son teslim tarihinin etkisiyle aceleyle verilen bir evet’e yol açma eğilimindedir.

Geri bildirimi işleme

UAT geri bildirimi birçok şeyin karışımıdır ve hepsi bir hata değildir. Kategorilere göre sıralayın:

Bir izni neyin engellediğine ilişkin, önem derecesi ve öncelik bölümünde açıklandığı gibi net kurallar kullanın. Reddettikleriniz de dahil olmak üzere her öğeye yanıt verin. İnsanlar geri bildirimin kaybolduğu görülüyorsa geri bildirim vermeyi bırakırlar. Hata raporunun nasıl yazılacağına ilişkin kılavuzumuz, test uzmanlarının sorunları net bir şekilde tanımlamasına yardımcı olabilir.

UAT kontrol listesi

UAT’den önce

• Kapsam ve kabul kriterleri yazılı olarak kararlaştırılır
• Sistem ve regresyon testi tamamlandı
• Test uzmanları seçilir, bilgilendirilir ve süre verilir
• Ortam, hesaplar ve gerçekçi veriler hazır
• Kopyalardaki kişisel veriler maskelendi
• Senaryolar işletme tarafından inceleniyor
• Sorunların kaydedileceği tek bir yer oluşturuldu
• İmza sahibinin adı belli oldu

UAT sırasında

• Bir destek iletişim kişisi mevcut
• Sorunlar her gün önceliklendiriliyor
• İlerleme paydaşlarla paylaşılıyor
• Düzeltmeler kontrollü bir şekilde dağıtılır ve yeniden test edilir

UAT’den sonra

• Çıkış kriterleri kontrol edildi
• Bilinen sorunlar sahiplerle birlikte belgelenir
• Resmi imzalar kaydedildi
• Eğitim ve sürüm notları güncellendi
• Kısa bir retrospektif düzenlendi

Çevik ekiplerde UAT

Geleneksel UAT, sürprizin pahalı olduğu, sonunda büyük bir aşama olarak gelir. Çevik ekipler bu döngüyü kısaltır. Ürün sahipleri, sprint sırasında her hikayeyi kabul kriterlerine göre inceler ve kullanıcılar, sprint incelemelerinde çalışan yazılımı görür. Pek çok ekip, özellikle çeşitli özelliklerin tek bir iş akışında birleştirildiği durumlarda, büyük bir sürümden önce hâlâ odaklanmış bir UAT çalıştırıyor.

Sık sık yayınlanan sürümlerle, özellik işaretleri ve canary dağıtımları gibi teknikler, gerçek kullanıcıların yeni çalışmaları kademeli olarak denemesine olanak tanır. Bunların kabul testlerini tamamladığını ancak özellikle resmi bir kayda ihtiyaç duyan düzenlenmiş endüstrilerde otomatik olarak onun yerine geçmediğini unutmayın.

Yaygın hatalar

• Bunu bir formalite olarak ele almak. Gerçek bir faydası olmayan bir imza, hiç kimseyi korumaz.
• Yanlış test kullanıcılarının kullanılması. Geliştiriciler ve QA, sistem hakkında kullanıcıları temsil edemeyecek kadar fazla bilgiye sahiptir.
• Kararsız bir yapıyla başlamak. Test uzmanları güvenini ve ilgisini hızla kaybeder.
• Son dakikaya bırakıyoruz. O zaman öğrendiklerinizi düzeltmeye zaman kalmıyor.
• Gerçekçi olmayan veriler kullanmak. Test verileri nadiren gerçek işlerdeki gibi karmaşık durumlara sahiptir.
• Kapsamın büyümesine izin vermek. Yeni fikirleri, gerçek anlamda engelleyici olmadıkları sürece, değişiklik istekleri olarak değerlendirin.

Son sözler

UAT, yazılımın onu kullanacak kişilere gerçekten yardımcı olup olmadığını, yayınlanmadan önce öğrenmek için son şansınızdır. Bunu bir projenin başlangıcından itibaren planlayın, gerçek kullanıcıları işe alın ve başarının neye benzediği konusunda anlaşın. Bir sonraki sürümünüz için basit bir değişiklik deneyin: Gerçek bir senaryo sırasında bir kullanıcıyla birlikte oturun ve onlar çalışırken hiçbir şey söylemeyin.

Sık sorulan sorular

Öğrenmeye devam et