Test ve Kabul: UAT Nasil Yönetilir? (Kontrol Listeli)

UAT Nedir ve Neden Önemlidir?

İş birimleri ve teknik ekip aynı masaya oturmadan sağlıklı bir UAT yürümez

User Acceptance Testing (UAT), yazılım geliştirme döngüsünün en son test aşamasıdır. Burada sorulan soru “sistem teknik olarak çalışıyor mu?” değil; “sistem işin gerçekten ihtiyaç duyduğu şeyi yapıyor mu?” sorusudur. Ve bu sorunun cevabını IT değil, sistemi her gün kullanacak son kullanıcılar verir.

UAT’in Temel Amacı

• İş Gereksinimlerinin Doğrulanması: Baştan tanımlanan gereksinimler sisteme doğru yansıdı mı?
• Kullanıcı Deneyimi Testi: Sistem, kullanıcının anlayabileceği ve rahat kullanabileceği bir şey mi?
• İş Süreci Bütünlüğü: Uçtan uca süreçler kesintiye uğramadan akıyor mu?
• Entegrasyon Doğrulaması: Dış sistemlerle veri alışverişi doğru çalışıyor mu?

UAT Neden Kritik?

UAT atlandığında ya da baştan savma yapıldığında, fatura genellikle canlıya geçtikten sonra kesilir:

• Kullanıcılar sistemi kullanamaz, iş süreçleri olduğu yerde durur
• Gereksinim eksikleri geç fark edilir; düzeltmenin maliyeti katlanır
• Kullanıcı direnci başlar, sistem bir türlü benimsenmez
• Yönetimin güveni sarsılır ve proje “başarısız” olarak hafızaya kazınır

UAT Öncesi Hazırlık Adımları

UAT’in kalitesi büyük ölçüde başlamadan önce yapılan hazırlıkta belli olur

1. UAT Takvimi ve Kaynak Planlaması

UAT’i proje planında ayrı bir faz olarak konumlandırın; “arta kalan zamanda yaparız” yaklaşımı en sık yapılan hatadır.

• UAT’in başlangıç ve bitiş tarihleri net olmalı
• Test kullanıcıları, günlük işlerinin yanında UAT’e ayrıca zaman ayırabilmeli
• Her test kullanıcısı için haftada en az 10-15 saat planlayın
• Departman yöneticilerinden bu kaynağı resmi olarak onaylatın

2. Entry Criteria (Giriş Kriterleri)

UAT başlamadan önce aşağıdaki koşullar sağlanmış olmalı:

• System Integration Testing (SIT) başarıyla tamamlandı
• Tüm kritik (blocker) hatalar kapatıldı
• UAT ortamı hazır ve erişime açık
• Test verileri yüklendi ve doğrulandı
• Test senaryoları ve kabul kriterleri onaylandı
• Kullanıcı eğitimi tamamlandı

3. UAT Ekibinin Oluşturulması

Doğru ekibi kurmak, çoğu zaman iyi senaryo yazmaktan daha belirleyicidir:

• UAT Koordinatörü: Tüm süreci yürütür, ekipler arası iletişimi sağlar
• İş Analisti: Test senaryolarını hazırlar, sonuçları değerlendirir
• Anahtar Kullanıcılar: Her departmandan, süreci gerçekten bilen temsilciler
• Teknik Destek: Ortam sorunları ve hata analizi için bir geliştirici

Test Senaryoları ve Kabul Kriterleri

Zayıf senaryo, zayıf UAT demektir; bütün süreç bu metinlerin üzerinde durur

Test Senaryosu Yapısı

İşe yarayan bir test senaryosu şu bileşenleri taşır:

Senaryo Tanımlama

• Senaryo ID: Benzersiz tanımlayıcı (örnek: UAT-FIN-001)
• Senaryo Adı: Kısa ve okuyunca ne test edildiği anlaşılan bir başlık
• İş Süreci: Hangi iş sürecini test ettiği
• Öncelik: Critical, High, Medium, Low
• Ön Koşullar: Test başlamadan önce hazır olması gerekenler

Test Adımları

• Adım adım yapılacak işlemler
• Her adımda girilecek veriler
• Her adımda beklenen sonuç
• Ekran görüntüleri veya referanslar

Kabul Kriterleri

Her senaryonun net bir kabul kriteri olmalı; “çalışıyor gibi” bir ifade UAT’te işe yaramaz:

• Pass/Fail kriteri açık ve ölçülebilir olmalı
• Beklenen veri sonuçları sayısal olarak belirtilmeli
• Performans beklentileri (örnek: 3 saniye içinde yanıt)
• Entegrasyon kontrolü (örnek: e-fatura sisteminden başarılı yanıt)

Senaryo Kategorileri

UAT senaryolarını şu kategorilerde gruplayın:

• Happy Path: Normal iş akışı, beklenen kullanım
• Negative Testing: Hatalı veri girişi, sınır değerler
• Edge Cases: Nadir ama mümkün durumlar
• End-to-End: Birden fazla modülü kapsayan uçtan uca süreçler
• Integration: Dış sistem entegrasyonlarının doğrulanması

UAT Ortamının Hazırlanması

UAT ortamı üretime ne kadar yakınsa, testin size verdiği güven o kadar gerçektir

Ortam Gereksinimleri

UAT ortamının taşıması gereken özellikler şunlar:

Teknik Altyapı

• Üretim ortamıyla aynı yazılım versiyonu
• Yeterli performans kapasitesi (temsili: üretimin %50’si)
• İzole network segmenti (geliştirme/test ortamından ayrı)
• Günlük yedekleme ve geri yükleme imkanı

Veri Hazırlığı

• Anonimleştirilmiş gerçek veriden türetilmiş test verisi
• Yeterli veri çeşitliliği (farklı müşteri tipleri, ürün grupları)
• Geçmiş dönem verileri (raporlama testleri için)
• Entegrasyon test verileri (banka, e-fatura, lojistik)

Erişim Yönetimi

• Her UAT kullanıcısı için kişisel hesap
• Rol bazlı yetkilendirme (üretimle aynı)
• Erişim logları ve denetim izi
• Ortam kullanım kuralları ve sorumluluklar

Ortam Yönetim Kuralları

• UAT ortamına kod değişikliği yalnızca onayla yapılır
• Her değişiklik öncesi mevcut durum yedeklenir
• Veri sıfırlama takvimi belirlenir (örnek: haftalık)
• Ortam erişim saatleri tanımlanır

Hata Takibi ve Defect Management

Hataları düzenli kaydetmek, UAT’in kontrolden çıkmasını engelleyen tek şeydir

Hata Kayıt Süreci

Bulunan her hata şu bilgilerle kayıt altına alınmalı; eksik kayıt, aynı hatayı iki kez konuşmak demektir:

• Hata ID: Otomatik atanan benzersiz numara
• Başlık: Sorunu özetleyen kısa açıklama
• Detaylı Açıklama: Adım adım yeniden üretim adımları
• Beklenen Sonuç: Ne olması gerekiyordu
• Gerçekleşen Sonuç: Ne oldu
• Ekran Görüntüleri: Görsel kanıtlar
• Ortam Bilgisi: Tarayıcı, versiyon, kullanıcı

Hata Önceliklendirme Matrisi

Hatalar şu seviyelerde sınıflandırılır:

Hata Yaşam Döngüsü

Her hata şu aşamalardan geçer:

1. New: Yeni kaydedildi
2. Assigned: Geliştiriciye atandı
3. In Progress: Çözüm üzerinde çalışılıyor
4. Fixed: Düzeltme yapıldı, teste hazır
5. Retest: UAT ekibi yeniden test ediyor
6. Closed: Doğrulandı, kapatıldı
7. Reopened: Hata devam ediyor, yeniden açıldı

Regression Testing Stratejisi

Bir hatayı düzeltirken üç yeni hata doğurmadığınızı ancak regression gösterir

Regression Testing Nedir?

Bir hata düzeltildikten ya da yeni bir özellik eklendikten sonra, çalışan mevcut işlevlerin bozulup bozulmadığını doğrulamak için yapılan testtir. Kısaca: “Bir yeri onarırken başka bir yeri kırdık mı?” sorusunun cevabıdır.

Ne Zaman Regression Yapılmalı?

• Her critical/high hata düzeltmesi sonrası
• Toplu kod değişikliği (patch/release) sonrası
• Veritabanı değişiklikleri sonrası
• Entegrasyon güncellemeleri sonrası
• Final sign-off öncesi (full regression)

Regression Test Seti Oluşturma

Her seferinde bütün senaryoları çalıştırmak pratikte mümkün değil. Regression setini şu kriterlere göre daraltın:

• Core Business Processes: Sipariş, fatura, ödeme gibi ana süreçler
• High-Risk Areas: Karmaşık hesaplamalar, entegrasyonlar
• Frequently Used Functions: Günlük kullanılan özellikler
• Recently Changed Areas: Son değişikliklerden etkilenen bölümler

Otomasyon Önerisi

Sık tekrarlanan regression testlerinde otomasyonu masaya yatırın:

• Smoke test otomasyonu (temel işlevsellik kontrolü)
• API entegrasyon testleri otomasyonu
• Veri doğrulama scriptleri
• Performans izleme otomasyonu

Sign-Off Süreci ve Dokümantasyon

Sign-off, işin sistemi kabul ettiğine dair attığı resmi imzadır; sözlü onay sayılmaz

Exit Criteria (Çıkış Kriterleri)

UAT’in bitmiş sayılması için şu koşulların sağlanması gerekir:

• Test senaryolarının büyük çoğunluğu (temsili: %95+) çalıştırıldı
• Critical ve High öncelikli hatalar kapatıldı
• Medium hatalar için ya çözüm planı ya da kabul kararı verildi
• Regression testi tamamlandı
• Performans kabul kriterleri karşılanıyor
• Kullanıcı eğitimi tamamlandı

Sign-Off Seviyeleri

Sign-off’u tek bir imzaya sıkıştırmak yerine katmanlı yürütün:

1. Modül Bazlı Sign-Off

• Her modül için ilgili departman temsilcisi onay verir
• Modül test özet raporu hazırlanır
• Açık hatalar ve çözüm planları listelenir

2. Entegrasyon Sign-Off

• Uçtan uca iş süreçleri doğrulanır
• Dış sistem entegrasyonları onaylanır
• Veri tutarlılığı kontrol edilir

3. Final Sign-Off

• Proje sponsoru veya steering committee onay verir
• Go-live kararı için yetki verilir
• Kabul edilmeyen hatalar için workaround veya erteleme kararı alınır

Sign-Off Dokümantasyonu

Sign-off süreci şu dokümanları içerir:

• Test Özet Raporu: Çalıştırılan senaryo sayısı, pass/fail oranları
• Hata Özet Raporu: Açık/kapalı hata sayıları, öncelik dağılımı
• Risk Değerlendirmesi: Kabul edilen riskler ve mitigation planları
• Sign-Off Formu: İmzalı kabul belgesi

UAT Kontrol Listesi (30+ Madde)

Bu kontrol listesini, iletişim sayfasından bize ulaşarak projenize özel olarak genişletebilirsiniz.

Sıkça Sorulan Sorular (SSS)