Kullanıcı Kabul Testi

Kullanıcı Kabul Testi (User Acceptance Testing - UAT), bir yazılım geliştirme sürecinin son aşamasını temsil eder ve yeni geliştirilen ya da güncellenen bir yazılımın gerçek kullanıcılar veya iş temsilcileri tarafından gerçek senaryolara uygun olarak test edilmesini ifade eder. Bu testin temel amacı, yazılımın teknik testlerde sorunsuz çalışmasının ötesinde, kullanıcı beklentilerini, iş gereksinimlerini ve sözleşme şartlarını eksiksiz yerine getirip getirmediğini doğrulamaktır.

QA (Quality Assurance) testlerinden farklı olarak UAT, teknik hatalardan ziyade kullanılabilirlik, işlevsellik, mevzuata uygunluk ve gerçek dünyada uygulanabilirlik gibi açılardan yazılımın doğruluğunu sınar. Bu sayede UAT, geliştirme ile üretime geçiş arasında köprü görevi görerek, ürünün değerini her kullanıcı için garanti altına alır.

Kullanıcı Kabul Testi (UAT) yazılım geliştirme sürecinde sadece teknik doğruluğu değil, ürünün işlevsel, kullanıcı dostu ve uygulanabilir olup olmadığını garanti altına alan tek aşamadır.

• Hataları erken bulur: Teknik testlerde gözden kaçan işlevsel uyumsuzlukları ve kullanıcı deneyimi sorunlarını açığa çıkarır.
• Müşteri memnuniyetini korur: Gerçek kullanıcı geri bildirimiyle yazılımın kullanım kolaylığı, erişilebilirliği ve beklenti uyumu test edilir.
• Marka değerini artırır: Lansman sonrası müşteri şikâyetlerini azaltarak şirketin güvenilirliğine katkıda bulunur.
• Maliyet tasarrufu sağlar: Lansmandan sonra bulunacak hataları düzeltmek, geliştirme aşamasındakinden çok daha maliyetlidir.
• Yasal uyumu sağlar: Bazı sektörlerde (finans, sağlık vb.) mevzuata uyum zorunludur. UAT, bu gerekliliklerin sahada sağlandığını ispat eder.
• Sözleşme şartlarını yerine getirir: Müşteriyle imzalanan SLA ya da proje sözleşmelerine uygunluk ancak UAT ile garantilenebilir.

Bir uygulamanın “çalışıyor olması”, “kullanıcı tarafından benimsenebilir olduğu” anlamına gelmez. Bu boşluğu kapatan kritik köprü UAT’tir.

Yazılım geliştirme tarihinde kabul testinin ortaya çıkışı, iş dünyasının yazılıma bağımlılığının artmasıyla başlar.

• 1950’lerde–70’lerde, testler daha çok donanım-işlev odaklıydı. Kullanıcı senaryosu test planlarında yer almıyordu.
• 80’lerden itibaren, bankacılık, sağlık, kamu sektörü gibi kritik alanlarda iş gereksinimlerinin doğrudan teknik ekibe bırakılması yetersiz kaldı. Saha çalışanlarının ve kullanıcıların görüşü önem kazandı.
• Agile ve kullanıcı merkezli tasarım anlayışının yaygınlaşması (1990–2000) ile “Iteratif Geliştirme ve Sürekli Geri Bildirim” prensibi benimsendi. Artık yazılım, sadece QA uzmanları değil, gerçek kullanıcılarca da test edilmek zorundaydı.

Bugün, kullanıcı kabul testi, proje kapanış şartıdır. UAT'siz teslimat nadiren kabul edilir çünkü müşteri memnuniyeti, düzenleyici uyumluluk ve sözleşme şartları bu aşamaya bağlıdır.

• Erken aşamada, şirket içi uzmanlar (ürün sahipleri, iş analistleri) tarafından yapılır.
• Gerçek kullanım senaryoları simüle edilir.
• Beta testine hazırlık niteliğindedir.

• Ürün gerçek kullanıcılarla sahada test edilir.
• Geri bildirim doğrudan geliştirme ekibine döner.
• Gerçek dünyada cihaz uyumluluğu, ağ hızları gibi faktörler gözlemlenir.

• Test eden, kod yapısını bilmez. Yalnızca işlevlere odaklanır.
• Kullanıcının sisteme ne girdiği ve ne sonuç aldığı test edilir.

• Ürünün, sözleşmedeki teslim kriterlerine uygunluğu değerlendirilir.
• Müşteri ödemesi çoğunlukla bu aşamada yapılır.

• Yazılımın kararlılık, güvenlik, yedekleme, kurtarma planları gibi operasyonel unsurları test edilir.
• Operasyon ekibi ve teknik destek ekiplerinin sorumlulukları netleştirilir.

• Yazılımın yerel mevzuat, sektör regülasyonları veya uluslararası standartlara uygunluğu incelenir.

• Organizasyon içinde, geliştirme ekibi ve iş sahipleri arasında yapılır.
• Daha az resmi, daha hızlı geri bildirim odaklıdır.

• Ürünün gerçek müşterilere veya beta kullanıcılarına sunulmasıdır.
• Genelde lansman öncesi nihai kullanıcı testi olarak bilinir.

Adım 1 - İş Gereksinimlerinin Toplanması: Proje dökümanları (BRD, SRS, süreç diyagramları) analiz edilir. Fonksiyonel & iş gereksinimleri ayrıştırılır.

Adım 2 - Kabul Kriterlerinin Belirlenmesi: Hangi özellik hangi koşullarda “başarılı” sayılır? Giriş/çıkış ölçütleri yazılır.

Adım 3 - UAT Planı Hazırlanması: Test kapsamı, sorumlu kişiler, zaman çizelgesi, test ortamı ve kullanılacak araçlar planlanır.

Adım 4 - Senaryolar ve Vaka Adımları Oluşturulur: Gerçek kullanım akışlarını taklit eden, adım adım yönergeler hazırlanır.

Adım 5 - Test Ortamının ve Verinin Hazırlanması: Üretim ortamına benzer koşullar sağlanır. Gerçekçi ama anonimleştirilmiş veri kullanılır.

Adım 6 - UAT Ekibinin Eğitilmesi: Teknik olmayan kullanıcılar için eğitim verilir. Geri bildirim formatları açıklanır.

Adım 7 - Testlerin Çalıştırılması: Test senaryoları uygulanır, tüm bulgular detaylı kaydedilir.

Adım 8 - Hataların Raporlanması ve Yeniden Test Edilmesi: Bulunan hatalar geliştirme ekibine bildirilir, düzeltildikten sonra tekrar test yapılır.

Adım 9 - Sign-Off (Onay): Kabul kriterleri sağlandığında, paydaşlar resmî olarak ürünü onaylar.

Profesyonel bir UAT sürecinin temel belgeleri şunlardır:

• Proje Adı & Sürüm: Testin hangi versiyona ait olduğu belirtilir.
• Test Amaçları: Testin hangi iş hedeflerine hizmet ettiği yazılır.
• Değişiklik Kayıtları (Change Log): "Kim ne zaman hangi güncellemeyi yaptı?" sorusunun cevabı aranır.
• Test Maddeleri: "Hangi modüller/fonksiyonlar test edilecek? Hangileri hariç?" sorusunun cevabı aranır.
• Eylem Planı: Test sonrası bug yönetimi, yeniden test prosedürü.
• Giriş/Çıkış Kriterleri: Başarılı testin ölçütleri.
• Test Ortamı Tanımı: Donanım, yazılım, veri gereksinimleri.
• Test Vakaları: Adım adım yönergeler. Her vaka net, ölçülebilir olmalı.
• UAT Ekibi Listesi: "Kim sorumlu? Kimin yetkisi var?" sorusunun cevabı aranır.
• Son Rapor: Test tamamlandığında paydaşlara sunulur.

• Yanlış Kullanıcı Seçimi: Teknik ekibe yakın kişiler yerine gerçek kullanıcı profilini yansıtan kişiler seçilmelidir.
• Net Olmayan Kabul Kriterleri: Belirsiz hedefler, gereksiz tartışmalara ve tekrar testlere yol açar.
• Zaman Baskısı: Geliştirme sürecindeki gecikmeler, UAT süresini sıkıştırır. Test kalitesi düşebilir.
• Gerçekçi Olmayan Test Ortamı: Üretim ortamından farklı bir test ortamı, hataların gözden kaçmasına yol açar.
• İletişim Kopukluğu: Geri bildirimlerin doğru raporlanmaması veya eksik izlenmesi hatalı teslimata neden olabilir.
• Hataların Önceliklendirilmemesi: Tüm hataların aynı anda çözülmeye çalışılması kaynak israfına sebep olur. Kritik hatalara odaklanmak gerekir.

Bir bitki tanıma uygulamasında yazılımcılar, makine öğrenmesi algoritmalarıyla bitki türlerini tanımlayan kodlar geliştirir. Ancak bir botanik uzmanı olmadan geliştirilen yazılım, sahada gerçek bir botanik uzmanı tarafından test edilmediği sürece gerçekte çalışıp çalışmadığı garanti edilemez. UAT burada devreye girmektedir; gerçek kullanıcı, yazılımın vaat ettiği değeri sunup sunmadığını gerçek ortamda doğrular.