Kurumsal yazılım projelerinde teknik olarak çalışan bir ürünün, iş açısından da hazır olması gerekir. Tam bu noktada uat testi, yani kullanıcı kabul testi devreye girer. Buradaki amaç yalnızca hata bulmak değildir; ekranların, iş akışlarının, onay adımlarının ve raporların gerçek kullanıcı beklentilerini karşılayıp karşılamadığını doğrulamaktır. Bir ERP modülü, saha satış uygulaması ya da B2B sipariş portalı geliştirilmiş olabilir. Ancak canlıya alınmadan önce, bu çözümün günlük operasyon altında nasıl davrandığı kontrollü biçimde test edilmelidir.
Birçok kurumda sorun test eksikliği değil, testin yanlış seviyede yapılmasıdır. Geliştirici ekip fonksiyon testini tamamlar, QA ekibi regresyon koşar, ardından proje canlıya yaklaşır. Buna rağmen depo sorumlusu, finans uzmanı, bölge satış yöneticisi ya da çağrı merkezi temsilcisi sistemi ilk kez son hafta görür. Risk tam da burada büyür. Kullanıcı kabul testleri geç başlarsa yalnızca hata sayısı artmaz; eğitim yükü, değişim direnci ve canlı sonrası destek talepleri de yükselir.
Sağlıklı bir UAT yaklaşımı için test sürecinin bir kontrol listesi olmaktan çıkması gerekir. Senaryo bazlı, rol bazlı ve ölçülebilir bir yapı kurulmalıdır. Kabul kriterleri yazılı olmalı, test verisi gerçek hayata yakın hazırlanmalı, bulgular önceliklendirilmeli ve canlıya geçiş kararı subjektif yorumlarla değil, net eşiklerle verilmelidir.
UAT testi nedir, neyi doğrular?
UAT testi, son kullanıcıların veya iş birimi temsilcilerinin, yazılımın tanımlanan iş ihtiyaçlarını karşıladığını onaylamak için yürüttüğü doğrulama aşamasıdır. Burada odak kod kalitesi değil, işe uygunluktur. Örneğin bir satın alma sürecinde sistem teknik olarak form kaydediyor olabilir. Fakat 4 adımlı onay zincirinde bütçe limiti aşıldığında doğru yöneticiye yönlenmiyorsa, ürün canlıya hazır sayılmaz.
Kurumsal projelerde UAT genellikle canlıya geçişten 2 ila 4 hafta önce planlanır. Süre, modül sayısına ve ekip büyüklüğüne göre değişir. Tek bir akış için 3 günlük kısa bir UAT yeterli olabilir. Birden fazla departmanı etkileyen ERP dönüşümlerinde ise bu pencere daha geniş tutulur. Kritik nokta, UAT'nin yalnızca “bakıldı, sorun yok” notuyla kapatılmamasıdır.
Bu aşamada doğrulanan başlıklar şunlardır:
- İş kurallarının beklendiği gibi çalışması
- Rol ve yetki matrisinin gerçek organizasyon yapısına uyması
- Rapor, çıktı ve dashboard'ların operasyonel kullanım için yeterli olması
- Uçtan uca süreçlerin kesintisiz tamamlanabilmesi
- Kullanılabilirlik kaynaklı hata risklerinin görülmesi
Basit bir örnek düşünelim. Bir servis operasyon uygulamasında teknisyen sahada arıza kaydı açıyor, fotoğraf yüklüyor, parça talebi oluşturuyor ve işi kapatıyor. QA testinde tüm butonlar çalışıyor olabilir. UAT sırasında ise mobil bağlantı zayıfken fotoğraf yükleme akışının yarım kaldığı, iş emrinin tekrar açılmadığı ve saha ekibinin aynı kaydı ikinci kez girdiği fark edilebilir. Bu tür bulgular çoğu zaman laboratuvar testlerinde değil, kullanıcı kabul aşamasında ortaya çıkar.
Canlı öncesi UAT planı nasıl hazırlanır?
Etkili bir plan, test başlangıcından en az 7-10 gün önce hazır olmalıdır. Kurum içinde “kim test edecek, neyi test edecek, ne zaman karar verilecek” sorularının yanıtı yazılı hale gelmeden UAT başlatmak, süreci gereksiz yere uzatır.
1. Kapsamı modül değil süreç bazında tanımlayın
“Sipariş modülü test edilecek” ifadesi zayıftır. Daha net bir çerçeve gerekir: müşteri oluşturma, fiyat listesi atama, kampanyalı sipariş girme, kredi limit kontrolü, sevk emri üretme ve fatura entegrasyonu. Böyle bir tanım, testçiye hangi sonucun beklendiğini açıkça gösterir.
2. UAT katılımcılarını gerçek rollere göre seçin
Her departmandan en az 1 ana kullanıcı belirlemek çoğu projede işe yarar. Ancak sadece yöneticilerle UAT yapmak eksik kalır. Sistemi günde 30-50 işlem ile kullanacak operasyon personeli de sürece dahil edilmelidir. Çünkü sürtünme noktaları genellikle en yoğun kullanıcı grubunda ortaya çıkar.
3. Kabul kriterlerini baştan yazın
“Kullanıcı beğenirse geçer” yaklaşımı yerine ölçülebilir kriterler belirlenmelidir. Örneğin:
- P1 seviyesinde açık hata kalmamalı
- P2 hatalar için geçici çözüm tanımlanmış olmalı
- Kritik 12 iş senaryosunun tamamı başarıyla tamamlanmalı
- Yetki testlerinde uygunsuz erişim bulunmamalı
4. Test ortamını canlıya yakın kurun
UAT ortamında sahte kullanıcılar, boş veri tabanı ve devre dışı entegrasyonlar varsa sonuç yanıltıcı olur. En azından maskeleştirilmiş örnek müşteri verileri, güncel ürün listeleri ve aktif entegrasyon simülasyonları kullanılmalıdır. Özellikle e-fatura, ödeme, kargo, LDAP/SSO veya SAP gibi sistemlerle konuşan projelerde bu detay kritik hale gelir.
UAT senaryoları nasıl yazılır?
İyi bir UAT senaryosu tek bir ekranı değil, iş sonucunu hedefler. 1 senaryo çoğu zaman 5 ila 15 adım içerir. Senaryo metni kısa, net ve doğrulanabilir olmalıdır.
Örnek bir B2B sipariş senaryosu:
- Bayi kullanıcısı sisteme giriş yapar.
- Stokta bulunan 2 ürün ve kampanyalı 1 ürün sepete eklenir.
- Toplam tutar kredi limitini aşacak şekilde sipariş oluşturulur.
- Sistem siparişi beklemeye alır ve bölge yöneticisine onaya gönderir.
- Yönetici onay verdikten sonra sevk emri oluşur.
- ERP entegrasyonunda sipariş numarası geri yazılır.
Beklenen sonuçlar da ayrıca yazılmalıdır. Örnek: “Kredi limiti uyarısı görünmeli”, “onaysız sipariş ERP'ye düşmemeli”, “entegrasyon yanıt süresi 10 saniyeyi aşarsa hata mesajı kullanıcı dilinde gösterilmeli”. Bu yapı, “çalıştı/çalışmadı” düzeyinin ötesine geçer.
Senaryo yazarken şu dört tip akışı dengede tutmak faydalıdır:
- Normal akış
- İstisna akışı
- Yetki sınırı
- Entegrasyon bağımlılığı
Kurumsal projelerde kritik hataların büyük bölümü istisna akışlarında yakalanır. İade, iptal, eksik veri, zaman aşımı, çift kayıt ve eşzamanlı kullanım bunların başında gelir.
Hata yönetimi ve önceliklendirme nasıl yapılmalı?
UAT sırasında çıkan her bulgu aynı ağırlıkta değildir. “Buton hizası bozuk” ile “yanlış müşteriye sipariş geçiliyor” aynı listede yer alabilir; ancak aynı öncelikte ele alınmaları doğru değildir. Pratikte P1, P2, P3 gibi seviyeler kullanılır.
- P1: Canlıya geçişi durduracak kritik hata. Veri kaybı, güvenlik açığı, süreç tamamlanamaması.
- P2: Temel iş akışını zorlayan ama geçici çözümü olan hata. Yanlış hesaplama riski, entegrasyon gecikmesi, rapor eksikliği.
- P3: Kullanılabilirlik veya görsel iyileştirme. Metin hatası, hizalama, ikincil filtre eksikliği.
Burada önemli bir disiplin vardır: UAT, yeni özellik toplama seansına dönüşmemelidir. “Madem test ediyoruz, şuraya yeni alan ekleyelim” yaklaşımı takvimi bozar. Talep mevcut kapsamın dışındaysa change request olarak ayrılmalı, canlı öncesinde risk yaratmıyorsa sonraki sürüme alınmalıdır.
Hata takibi için Jira, Azure DevOps ya da benzeri araçlar kullanılabilir. Kaydın içinde en az şu alanlar bulunmalıdır: ortam bilgisi, rol, ön koşul, tekrar adımları, beklenen sonuç, gerçekleşen sonuç, ekran görüntüsü veya kısa video. İyi tanımlanmamış bir bug kaydı, çözüm süresini çoğu zaman birkaç saat değil, birkaç gün uzatır.
Kullanıcı direnci UAT aşamasında nasıl azaltılır?
UAT'nin değeri yalnızca kalite kontrolle sınırlı değildir. Aynı zamanda değişim yönetiminin en pratik araçlarından biridir. Kullanıcılar sisteme katkı verdiğini hissettiğinde direnç azalır. Projeye dışarıdan dayatılan bir araç yerine, birlikte şekillendirilen bir çalışma ortamı algısı oluşur.
Burada işe yarayan yaklaşım, ana kullanıcı modelidir. Her departmandan seçilen temsilci, test sırasında bulgu toplar, kararları netleştirir ve ekip içinde köprü görevi görür. Orta ölçekli projelerde 5-8 kişilik bir UAT çekirdek grubu çoğu zaman yeterli olur.
Direnci azaltmak için uygulanabilecek bazı pratikler:
- Test oturumlarını 60-90 dakikalık bloklara bölmek
- Her senaryonun iş hedefini başta açıklamak
- “Hata bulma” yerine “süreci doğrulama” dili kullanmak
- Bulgu kapanışlarını aynı gün görünür kılmak
- Eğitim materyallerini UAT ekran görüntüleriyle güncellemek
Özellikle yeni ERP, CRM veya saha uygulamalarında kullanıcıların ilk tepkisi çoğu zaman teknik değil, alışkanlık temellidir. Eski sistemde 2 tıklamayla yapılan işlem yeni sistemde 4 adıma çıktıysa, bunun nedeni denetim veya veri doğrulama gereksinimi olabilir. Bu fark UAT sırasında anlatılmazsa canlı sonrasında “sistem yavaş” yorumu artar.
UAT tamamlandıktan sonra canlıya geçiş kararı nasıl verilir?
UAT bitişi, takvimdeki son günün gelmesiyle değil, kabul toplantısıyla netleşmelidir. Bu toplantıda açık bulgular, kalan riskler ve geçiş ön koşulları gözden geçirilir. İyi bir kapanış raporu genellikle 1-2 sayfa olur ve yöneticinin hızlı karar almasını sağlar.
Karar öncesinde kontrol edilmesi gereken başlıklar:
- Kritik senaryoların başarı oranı
- Açık P1/P2 hata durumu
- Geçici çözüm gerektiren süreçler
- Eğitim ve kullanım dokümantasyonunun güncelliği
- Cutover planı, veri aktarımı ve rollback hazırlığı
Örneğin cuma akşamı canlıya alınacak bir sipariş yönetim sistemi için cutover listesi saat bazlı hazırlanmalıdır: 18:00 son veri yedeği, 19:30 veri taşıma doğrulaması, 21:00 entegrasyon sağlık kontrolü, 22:00 ana kullanıcı onayı. Bu netlik sağlanmadığında, UAT'de başarıyla geçen sistem bile geçiş gecesinde sorun çıkarabilir.
En sağlıklı yaklaşım şudur: UAT sonucunu yalnızca bir test raporu olarak değil, operasyonel hazır oluş göstergesi olarak ele almak. Teknik ekip, iş birimi ve yönetim aynı tabloya baktığında sürprizler azalır.
Özetle, uat testi kurumsal yazılım projelerinde canlıya geçiş öncesindeki son savunma hattıdır. Doğru planlandığında kritik hataları erken görünür kılar, kullanıcı alışkanlıklarını dikkate alır ve proje ekibiyle iş birimleri arasında ortak bir karar zemini oluşturur. Başarılı bir UAT, daha az destek talebi ve daha kontrollü bir geçiş anlamına gelir. Asıl kazanım ise şudur: sistem yalnızca çalışmaz, gerçekten kullanılır.
