Kabul Testi (UAT) Rehberi: Yazılım Teslimini Onaylamadan Önce Yapmanız Gerekenler

Kısaca: Kabul testi (UAT — User Acceptance Testing), yazılımın gerçek kullanıcılar tarafından, gerçek iş senaryolarıyla denenip “bu bizim ihtiyacımızı karşılıyor” diye onaylanmasıdır. Firmanın kendi testi (birim testi, entegrasyon testi, güvenlik taraması) teknik doğruluğu kontrol eder; kabul testi ise işe uygunluğu doğrular ve bunu en iyi siz bilirsiniz. İyi bir UAT için şunlar gerekir: 1) Önceden yazılmış kabul kriterleri, 2) gerçek iş akışlarından türetilmiş test senaryoları, 3) gerçek kullanıcılar, 4) gerçekçi (veya anonimleştirilmiş) test verisi, 5) hataları önceliklendiren ve takip eden bir düzen, 6) “kabul” kararının net kuralları. Kabulden sonra “keşke şunu da denesek” demek çok pahalıdır; çünkü kabul genellikle ödeme ve garanti süresini de tetikler. Bu rehber, müşteri olarak UAT'yi nasıl planlayıp yöneteceğinizi anlatır.

Son güncelleme: Ekim 2026

Kabul testi nedir, neden önemlidir?

Yazılım teslim edilmeden önce birkaç test katmanından geçer:

UAT'nin farkı: “Doğru yapılmış mı?” değil, “Doğru şey mi yapılmış?” sorusunu sorar. Teknik olarak kusursuz bir sistem, iş akışınıza uymuyorsa işe yaramaz. Bu yüzden UAT, firma seçimi ve müşteri sorumlulukları süreçlerinin doğal devamıdır.

Kabul kriterleri: Baştan yazın

Kabul kriteri, bir özelliğin “tamam” sayılması için sağlanması gereken koşuldur. Teslimden önce, hatta kapsamla birlikte yazılmalıdır; kabul sırasında tartışmaya yol açmasın.

Zayıf kriter: “Sipariş ekranı kullanışlı olmalı.” Güçlü kriter: “Satış temsilcisi, yeni bir müşteri için sipariş oluşturup 5 kalem ekleyerek 2 dakika içinde kaydedebilmeli; sipariş, depo listesinde görünmeli ve müşteriye e-posta bildirimi gitmeli.”

Kriterler ölçülebilir, gözlenebilir ve net olmalı: kim, ne yapınca, ne sonuç görmeli? Kapsam ve kabul kriterleri sözleşmeye de ek olarak girmelidir; bkz. yazılım sözleşmesi kontrol listemiz.

UAT planı: 8 adımda

1. Kapsam ve hedef

Neyi test edeceksiniz? Tüm sistem mi, bu sürümde teslim edilen özellikler mi? Başarı ölçütü ne? (Örn. “Tüm kritik senaryolar geçer, açık kritik/yüksek hata yok.”)

2. Ekip ve roller

• Test koordinatörü: Genellikle ürün sahibi; planı yönetir, bulguları toplar.
• Test kullanıcıları: Sistemi gerçekten kullanacak kişiler (satış, depo, muhasebe, yönetici). Farklı rollerden en az bir kişi olsun.
• Firma tarafı: Hataları düzelten, soruları yanıtlayan bir muhatap.
• Test için zaman ayırın: Kullanıcılar günlük işlerinin yanında test yapacaksa, bunun planlı ve korunmuş bir zaman olduğundan emin olun.

3. Test ortamı

• Üretimden ayrı bir test (staging) ortamı kullanın; canlı veriye dokunmayın.
• Ortam, canlıya mümkün olduğunca benzemeli (sürüm, ayarlar, entegrasyonlar).
• Entegrasyonlar (ödeme, e-posta, ERP) için test/sandbox hesapları kullanın.

4. Test verisi

• Gerçekçi veriyle test edin: farklı müşteri türleri, uzun isimler, Türkçe karakterler (ı, ş, ğ, İ), boş alanlar, büyük sayılar, tarih sınırları.
• Gerçek kişisel veri kullanacaksanız anonimleştirin veya test ortamını canlı kadar korumalı tutun; KVKK yükümlülüklerini unutmayın. Taşınan eski veri varsa doğrulaması için veri taşıma rehberimize bakın.

5. Test senaryoları

Senaryoları iş akışlarından türetin; ekran ekran gezmek yerine uçtan uca deneyin. (Aşağıda ayrıntılı.)

6. Hata yönetimi

Bulguları tek bir yerde (tablo veya takip aracı) toplayın: ne, nerede, nasıl tekrarlanır, önem derecesi, durum. (Aşağıda şablon.)

7. Tekrar test (regresyon)

Düzeltmelerden sonra, hatayı ve çevresini yeniden test edin; bir düzeltme başka bir yeri bozabilir.

8. Kabul kararı

Kabul kriterlerine ve açık hataların durumuna göre yazılı kabul verin (şartlı kabul gerekiyorsa hataların listesiyle).

Test senaryosu nasıl yazılır?

İyi bir senaryo bir iş hikâyesi anlatır:

Kapsanması gereken senaryo türleri

1. Mutlu yol (happy path): Her şey yolunda giderken ana akışlar.
2. Hatalı girdi ve sınır durumları: Eksik alan, yanlış biçim, çok uzun metin, negatif sayı, aynı kaydı iki kez ekleme.
3. İstisnalar ve iş kuralları: İade, iptal, kısmi sevkiyat, stok yok, limit aşımı, indirim kombinasyonları.
4. Yetki ve roller: Her rol yalnızca görmesi gerekeni görüyor mu? Yetkisiz kullanıcı bir işlemi yapabiliyor mu?
5. Entegrasyonlar: E-posta/SMS bildirimi, ödeme, ERP aktarımı, dosya yükleme/indirme.
6. Raporlar ve çıktılar: Rakamlar gerçek iş verisiyle uyuşuyor mu? Dışa aktarma doğru mu?
7. Farklı cihaz ve tarayıcılar: Kullanıcılarınızın gerçekten kullandığı ortamlarda deneyin (mobil dahil).
8. Performans hissi: Gerçek veri hacminde ekranlar makul sürede açılıyor mu?
9. Veri doğruluğu: Taşınan eski veriden rastgele örnekler doğru mu?
10. Geri alma ve hata mesajları: Hata olduğunda kullanıcıya anlaşılır mesaj veriliyor mu? Veri kaybı olmuyor mu?

Önemli: Senaryolara gerçekte yaptığınız işlerin istisnalarını ekleyin; çoğu sorun “normal” akışta değil, istisnada çıkar.

Hata (bulgu) kaydı ve önceliklendirme

Hata kaydı şablonu

• Kimlik: Benzersiz numara
• Başlık: Kısa özet
• Rol / ortam: Kim, hangi cihaz/tarayıcıda gördü?
• Adımlar: Nasıl tekrarlanır?
• Beklenen / gerçek sonuç
• Ekran görüntüsü / video
• Önem derecesi (aşağıda)
• Durum: Yeni / İncelemede / Düzeltildi / Tekrar test edilecek / Kapatıldı

Önem dereceleri

Önemli ayrım: Hata (kapsamdaki bir özellik doğru çalışmıyor) ile yeni istek (kapsamda olmayan bir şey) farklıdır. Yeni istekler değişiklik yönetimi sürecine girer ve ek kapsam/maliyet doğurabilir. Bu ayrımı net tutmak, tartışmaları azaltır. Kavramlar için yazılım terimleri sözlüğümüze bakabilirsiniz.

Kabul kararı nasıl verilir?

Kabul, bir “his” değil, önceden belirlenmiş kurallara göre verilen bir karardır. Örnek kurallar:

• Tüm kritik ve yüksek hatalar düzeltilmiş ve tekrar test edilmiştir.
• Orta hatalar için düzeltme planı ve tarihi yazılıdır.
• Tüm kritik senaryolar geçmiştir.
• Kabul kriterlerinin tamamı (veya anlaşılan oranı) karşılanmıştır.
• Gerekli dokümantasyon, eğitim ve erişimler (kaynak kod, hesaplar) teslim edilmiştir.

Karar türleri:

1. Kabul: Kriterler karşılandı.
2. Şartlı kabul: Küçük açık hatalar var; belirli sürede düzeltilmesi koşuluyla kabul. (Hataların listesi ve tarihleri yazılı olmalı.)
3. Ret / yeniden test: Kritik eksikler var; düzeltme sonrası tekrar test.

Dikkat: Kabul çoğu sözleşmede ödeme, garanti süresinin başlangıcı ve bazen sorumluluğun devri ile ilişkilidir. Acele edilmemeli, sessizlikle kabul sayılma gibi hükümler (belirli süre içinde itiraz edilmezse kabul) sözleşmede varsa dikkatle takip edilmelidir. Ayrıntı için sözleşme maddelerine ve hukuk danışmanınıza bakın.

Yayın (go-live) kontrolü

Kabulden sonra canlıya geçmeden önce:

• Veri taşıma tamamlandı ve doğrulandı; geri dönüş planı hazır
• Kullanıcı eğitimi yapıldı; kısa bir kullanım rehberi var
• Yedekleme ve geri yükleme testi yapıldı
• Güvenlik temelleri (yönetici MFA, yetkiler, HTTPS, güvenlik başlıkları) doğrulandı: güvenlik rehberimiz
• İzleme ve uyarılar kuruldu
• Hesap ve erişimler (alan adı, sunucu, kaynak kod) size teslim edildi
• Destek kanalı ve bakım planı belli: bakım ve SLA rehberimiz
• Yayın sonrası ilk günler için yakın takip planı var

UAT'de sık yapılan 8 hata

1. Testi son güne bırakmak. Zaman ve kullanıcı ayrılmazsa sorunlar canlıda çıkar.
2. Yalnızca “mutlu yolu” denemek. İstisnalar ve hatalı girdiler ihmal edilir.
3. Gerçek kullanıcıyı dışarıda bırakmak. Yönetici kendi gözünden “iyi” der, çalışan işi göremez.
4. Kabul kriterlerini baştan yazmamak. Sonradan her şey tartışma konusu olur.
5. Hata ile yeni isteği karıştırmak.
6. Bulguları dağınık (e-posta, mesaj, sözlü) iletmek. Takip edilemez.
7. Düzeltmeleri yeniden test etmemek.
8. Eksiklerle “şartlı kabul” verip listeyi yazılı tutmamak.

Kısa UAT kontrol listesi

• Kabul kriterleri yazılı ve onaylı
• Test ekibi ve koordinatör belirlendi; zaman ayrıldı
• Ayrı test ortamı ve gerçekçi/anonim test verisi hazır
• Senaryolar iş akışlarından türetildi; istisnalar dahil
• Her rol için test yapıldı (yetki kontrolleri dahil)
• Entegrasyonlar test edildi
• Raporlar ve rakamlar doğrulandı
• Bulgular tek yerde, önem dereceleriyle takip ediliyor
• Düzeltmeler tekrar test edildi
• Kabul kararı yazılı verildi
• Yayın öncesi kontrol listesi tamamlandı

Aktaş Digital ile teslim ve kabul

Projelerimizde teslimi kabul kriterleriyle planlıyoruz: kapsam ve kabul koşullarını baştan yazıyor, düzenli çalışan sürümler gösteriyor, test ortamı sağlıyor, bulguları takip ediyor ve düzeltmelerin tekrar testini birlikte yapıyoruz. Kabulden sonra da destek ve bakım planıyla yanınızda kalıyoruz. Web uygulamaları, CRM, ERP ve stok takip sistemleri gibi iş yazılımlarında bu yöntemi uyguluyoruz. Projenizi anlatmak için teklif formumuzu kullanabilirsiniz. Başlangıçtan sona süreç için MVP yol haritamıza da göz atın.

Sık Sorulan Sorular

UAT'yi kim yapmalı, firma mı müşteri mi?

Kabul testini müşteri tarafı yapar; çünkü işe uygunluğu ancak siz bilirsiniz. Firma, test ortamını hazırlar, soruları yanıtlar ve hataları düzeltir. Firmanın kendi iç testleri ayrıca yapılır.

UAT ne kadar sürer?

Sistemin büyüklüğüne ve senaryo sayısına bağlıdır; birkaç günden birkaç haftaya kadar sürebilir. Süreyi baştan planlayın ve kullanıcıların zamanını koruyun; hata düzeltme ve tekrar test turlarını da hesaba katın.

Teknik bilgim yok; test edebilir miyim?

Evet. Kabul testi teknik değil, iş testidir: gerçek işlerinizi sistemde yapıp sonuç doğru mu diye bakarsınız. Teknik inceleme (güvenlik, kod kalitesi) için gerekirse bağımsız bir uzmandan destek alın.

Hata çıkarsa ödemeyi durdurabilir miyim?

Bu, sözleşmenizdeki ödeme ve kabul hükümlerine bağlıdır. Ödemeler teslimlere ve kabule bağlıysa, kriterleri karşılamayan teslimde itiraz hakkınız olur. Hukuki detaylar için hukuk danışmanınıza başvurun.

Canlıya aldıktan sonra da hata çıkar mı?

Evet; hiçbir test her durumu kapsamaz. Bu yüzden garanti süresi, destek kanalı ve yayın sonrası izleme önemlidir. İyi bir UAT riski büyük ölçüde azaltır ama sıfırlamaz.

Otomatik test ile UAT aynı şey mi?

Hayır. Otomatik testler kodun teknik doğruluğunu hızla ve tekrar tekrar kontrol eder; UAT ise gerçek kullanıcıların işe uygunluğu onaylamasıdır. İkisi birbirini tamamlar.

Sonuç

Kabul testi, yazılıma “evet, bu bizim işimizi görüyor” demeden önceki son ve en değerli güvencedir. Kabul kriterlerini baştan yazın, gerçek kullanıcılarla gerçek senaryoları (istisnalarıyla) deneyin, bulguları önceliklendirip takip edin, düzeltmeleri yeniden test edin ve kabulü yazılı verin. Bugün yapabileceğiniz ilk iş: projenizdeki en kritik üç iş akışını uçtan uca senaryo olarak yazmak ve bunlar için ölçülebilir kabul kriterleri belirlemek.