Test ve Kabul: UAT Nasil Yönetilir? (Kontrol Listeli)
UAT Nedir ve Neden Önemlidir?
Başarıli UAT süreci, is birimleri ve teknik ekibin ortak çalışmasını gerektirir
User Acceptance Testing (UAT), yazılım geliştirme yaşam döngüsünün son test aşamasıdır. Sistemin teknik olarak çalışıp çalışmadığı değil, is gereksinimlerini karsilayip karsilamadiginin son kullanıcılar tarafından doğrulanmasıdır.
UAT’in Temel Amacı
- Is Gereksinimlerinin Doğrulanması: Tanımlanan gereksinimler sisteme doğru yansitilds mi?
- Kullanıcı Deneyimi Testi: Sistem kullanıcılar için anlaşılır ve kullanışlı mi?
- Is Süreci Bütünlüğü: Uc uca is süreçleri kesintisiz çalışıyor mu?
- Entegrasyon Doğrulaması: Dış sistemlerle veri alisi verisi doğru çalışıyor mu?
UAT Neden Kritik?
UAT atlandiginda veya yetersiz yapıldığında, canlı ortama geçiş sonrası su sorunlar yaşanır:
- Kullanıcılar sistemi kullanamaz, is süreçleri durur
- Gereksinim eksiklikleri geç fark edilir, maliyet artar
- Kullanıcı direnci oluşur, sistem adapte edilmez
- Yönetim güveni sarsılır, proje başarısizlik olarak algılanır
UAT Öncesi Hazırlık Adimleri
UAT başlamadan önce kapsamlı hazırlık yapılmalıdır
1. UAT Takvimi ve Kaynak Planlaması
UAT süreci, proje planinda ayrı bir faz olarak tanımlanmalıdır:
- UAT baslangic ve bitiş tarihleri netleştirilmeli
- Test kullanıcıları günlük işleri dışında UAT için zaman ayırmali
- Her test kullanıcısı için haftalık en az 10-15 saat planlanmalı
- Departman yöneticilerinden resmi kaynak onayı alinmali
2. Entry Criteria (Giriş Kriterleri)
UAT başlamadan önce su koşullar sağlanmis olmalı:
- System Integration Testing (SIT) başarıyla tamamlanmış
- Tüm kritik (blocker) hatalar kapatılmış
- UAT ortamı hazır ve erişime açık
- Test verileri yuklenmiş ve doğrulanmış
- Test senaryoları ve kabul kriterleri onaylanmış
- Kullanıcı eğitimi tamamlanmış
3. UAT Ekibinin Oluşturulması
Doğru ekip yapısı başarıli UAT’in anahtarıdır:
- UAT Koordinatörü: Tüm süreci yönetir, iletişimi sağlar
- Is Analisti: Test senaryolarını hazırlar, sonuçları değerlendirir
- Anahtar Kullanıcılar: Her departmandan süreci bilen temsilciler
- Teknik Destek: Ortam sorunları ve hata analizi için geliştirici
Test Senaryoları ve Kabul Kriterleri
Iyi yazılmış test senaryoları, UAT’in temelini oluşturur
Test Senaryosu Yapısi
Her test senaryosu su bileşenleri içermelidir:
Senaryo Tanımlama
- Senaryo ID: Benzersiz tanimlayici (örnek: UAT-FIN-001)
- Senaryo Adı: Kısa ve anlaşılır baslik
- Is Süreci: Hangi is sürecini test ediyor
- Öncelik: Critical, High, Medium, Low
- On Koşullar: Test başlamadan önce mevcut olması gerekenler
Test Adimleri
- 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 senaryo için net kabul kriterleri tanımlanmalıdır:
- Pass/Fail kriterleri 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 sistemi başarıli yanıt)
Senaryo Kategorileri
UAT senaryoları su kategorilerde gruplanmalidir:
- Happy Path: Normal iş akışi, 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 uc uca süreçler
- Integration: Dış sistem entegrasyonlarinin doğrulanması
UAT Ortaminin Hazırlanması
UAT ortamı üretim ortamına mümkün olduğunca yakın olmalıdir
Ortam Gereksinimleri
UAT ortamı su özelliklere sahip olmalıdir:
Teknik Altyapı
- Üretim ortamıyla aynı yazılım versiyonu
- Yeterli performans kapasitesi (temsili: üretimin %50’sı)
- Izole 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 sadece onay ile yapılır
- Her degisiklik öncesi mevcut durum yedeklenir
- Veri sıfırlama takvimi belirlenir (örnek: haftalık)
- Ortam erişim saatleri tanımlenir
Hata Takibi ve Defect Management
Sistematik hata takibi, UAT sürecinin kontrollü ilerlemesini sağlar
Hata Kayıt Süreci
Bulunan her hata su bilgilerle kayıt altına alınmalıdır:
- Hata ID: Otomatik atanan benzersiz numara
- Baslik: Sorunu özetleyen kısa açıklama
- Detaylı Açıklama: Adım adım yeniden üretim adimleri
- Beklenen Sonuç: Ne olması gerekiyordu
- Gerçeklesen Sonuç: Ne oldu
- Ekran Görüntüleri: Görsel kanıtlar
- Ortam Bilgisi: Tarayıcı, versiyon, kullanıcı
Hata Önceliklendirme Matrisi
Hatalar su seviyelerde sınıflandırilir:
| Seviye | Taniim | Çözüm Süresi | Sign-off Etkisi |
|---|---|---|---|
| Critical | Is süreci tamamen durur, veri kaybı riskı | 24 saat içinde | Sign-off engeller |
| High | Önemli islevsellik etkilenir, workaround var | 48-72 saat içinde | Sign-off engeller |
| Medium | Küçük islevsellik problemi, kullanıcı deneyimi etkisi | 1 hafta içinde | Koşullu sign-off |
| Low | Kozmetik sorunlar, küçük düzeltmeler | Sonraki sürüm | Sign-off etkilemez |
Hata Yaşam Dongusi
Her hata su asamalardan geçer:
- New: Yeni kaydedildi
- Assigned: Geliştiriciye atandı
- In Progress: Çözüm üzerinde çalışılıyor
- Fixed: Düzeltme yapıldı, teste hazır
- Retest: UAT ekibi yeniden test ediyor
- Closed: Doğrulandi, kapatıldı
- Reopened: Hata devam ediyor, yeniden acildi
Regression Testing Stratejisi
Hata düzeltmeleri sonrası regression testi zorunludur
Regression Testing Nedir?
Bir hata düzeltildikten veya yeni özellik eklendikten sonra, mevcut çalışn islevselliklerin bozulup bozulmadigini doğrulamak için yapılan testtir.
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üncellomeleri sonrası
- Final sign-off öncesi (full regression)
Regression Test Seti Oluşturma
Tüm senaryoları her seferinde test etmek mümkün değildir. Regression seti su kriterlere göre belirlenir:
- 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 degisikliklerden etkilenen bölümler
Otomasyon Önerisi
Sik tekrarlanan regression testleri için otomasyon değerlendirilmelidir:
- Smoke test otomasyonu (temel islevsellik kontrolü)
- API entegrasyon testleri otomasyonu
- Veri doğrulama scriptleri
- Performans izleme otomasyonu
Sign-Off Süreci ve Dokümantasyon
Sign-off, is birimlerinin sistemi kabul ettiğinin resmi onagidir
Exit Criteria (Çıkış Kriterleri)
UAT’in tamamlanmış sayılması için su koşullar sağlanmalidir:
- Tüm test senaryoları (temsili: %95+) çalıştirilmis
- Critical ve High öncelikli hatalar kapatılmış
- Medium hatalar için çözüm planı veya kabul kararı verilmiş
- Regression testi tamamlanmış
- Performans kabul kriterlerini karsilaniyor
- Kullanıcı eğitimi tamamlanmış
Sign-Off Seviyeleri
Çok katmanlı sign-off yaklaşimi uygulanmalıdır:
1. Modül Bazlı Sign-Off
- Her modül için ilgili departman temsilcisi onay verir
- Modüul test özet raporu hazırlanır
- Açık hatalar ve çözüm planları listelenir
2. Entegrasyon Sign-Off
- Uc uca is 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 yetkilendirme yapılır
- Kabul edilmeyen hatalara workaround veya erteleme kararı verilir
Sign-Off Dokumantasyonu
Sign-off süreci su 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: Imzali kabul belgesi
UAT Kontrol Listesi (30+ Madde)
Aşağıdaki UAT kontrol listesi, kullanıcı kabul testi sürecinin eksiksiz yönetimi için kapsamlı bir rehberdir. Her maddeyi sırasıyla işaretleyin:
A. UAT Öncesi Hazırlık
- SIT (System Integration Testing) başarıyla tamamlandı
- UAT baslangic kriterleri (entry criteria) karşılandı
- UAT ortamı kuruldu ve erişime acildi
- Test verileri hazırlandi ve doğrulandi
- Tüm test senaryoları yazıldı ve onaylandı
- Kabul kriterleri her senaryo için tanimlandi
- UAT ekibi belirlendi ve kaynakları ayrıldi
- Kullanıcı eğitimi tamamlandı
- Hata takip sistemi kuruldu ve erişimler tanimlandi
- UAT takvimi ve toplantı planı paylaşıldı
B. Test Senaryosu Yönetimi
- Happy path senaryoları tanimlandi
- Negative test senaryoları tanimlandi
- Edge case senaryoları belirlendi
- End-to-end süreç senaryoları hazırlandi
- Entegrasyon test senaryoları oluşturuldu
- Her senaryo için on koşullar belirlendi
- Senaryo önceliklendirmesi yapıldı (Critical/High/Medium/Low)
- Senaryo atama ve sorumluluklar belirlendi
C. Test Yurutme
- Günlük test ilerleme toplantıları yapılıyor
- Test sonuçları sisteme kayıt ediliyor
- Bulunan hatalar standart formatta raporlanıyor
- Hata önceliklendirmesi doğru yapılıyor
- Hatalar zamanında geliştiricilere ataniyor
- Düzeltilen hatalar yeniden test ediliyor (retest)
- Test kapsamı izleniyor ve raporlanıyor
D. Regression Testing
- Regression test seti belirlendi
- Her kod değişikliği sonrası regression yapılıyor
- Core business process testleri tekrarlanıyor
- Entegrasyon noktaları yeniden doğrulanıyor
- Final regression testi planlandı
E. Sign-Off Hazırlığı
- Tüm senaryoların en az bir kez çalıştirildi
- Critical ve High hatalar kapatıldı
- Medium hatalar için karar verildi (fix/defer/accept)
- Test özet raporu hazırlandi
- Hata özet raporu hazırlandi
- Risk değerlendirmesi tamamlandı
- Modül bazlı sign-off alındı
- Final sign-off toplantısı planlandı
- Sign-off formu imzaya hazır
F. Dokümantasyon
- Tüm test sonuçları arşivlendi
- Hata geçmişi kayıt altında
- Sign-off belgeleri imzalandı
- Lessons learned dokumani hazırlandi
- Go-live öncesi bilinen sorunlar listesi oluşturuldu
Bu kontrol listesi, iletişim sayfasından ulaşarak projenize özel olarak genişletilebilir.
Sikca Sorulan Sorular (SSS)
UAT süresi proje büyüklugune ve karmaşıklığına bağlı olarak değişir. Küçük ölçekli projeler için 1-2 hafta, orta ölçekli projeler için 2-4 hafta, büyük ölçekli kurumsal projeler için 4-8 hafta planlanmalıdır. Kritik olan süre değil, tüm kabul kriterlerinin test edilmiş olmasıdır.
SIT, teknik ekip tarafından sistemlerin birbirleriyle entegrasyonunu test eder; odağı teknik uyumluluktur. UAT işe is birimleri tarafından gerçek is süreçlerinin çalışıp çalışmadığını test eder; odağı kullanıcı deneyimi ve is gereksinimlerinin karsilanmasıdır. SIT başarısiz olursa UAT baslamaz.
Hatalar dört seviyede önceliklendirilir: Critical (is süreci durur, çözüm olmadan devam edilemez), High (önemli islevsellik etkilenir, workaround var), Medium (küçük islevsellik problemi, kullanıcı deneyimini etkiler), Low (kozmetik sorunlar, hata mesajı düzeltmeleri). Critical ve High hatalar UAT sign-off öncesi mutlaka kapatılmalıdır.
Her kritik is süreci için en az bir anahtar kullanıcı UAT ekibinde yer almalıdır. Temsili olarak: Finans’tan 2-3 kişi, Operasyon’dan 2-3 kişi, Satış’tan 1-2 kişi, IT’den 1-2 kişi. Toplam 8-15 kişilik çekirdek UAT ekibi çoğu proje için yeterlidir. Önemli olan sayıdan çok, süreci bilen doğru kişilerin secilmesidir.
UAT ortamı üretim ortamına mümkün olduğunca yakın olmalıdir: aynı versiyon, benzer veri hacmi (anonimleştirilmiş gerçek veri tercih edilir), aynı entegrasyon bağlantileri (test modunda). UAT ortamı, geliştirme ve test ortamlarından izole edilmeli, yalnızca UAT ekibinin erişiminde olmalıdir.
Sign-off yetkisi teknik ekipte değil, is birimlerinde olmalıdir. Her modül için ilgili departman yöneticisi sign-off verir. Final sign-off işe proje sponsoru veya steering committee tarafından verilir. IT ekibi teknik hazırlık onayını verir ancak is kabulü is birimleri tarafından yapılır.
Projeniz İçin Destek Alın
Dijital dönüşüm yolculuğunuzda size rehberlik edebilirim. Ücretsiz ön görüşme için randevu alın.