Test atlandığında hatalar canlıda ortaya çıkar. Test senaryolarını ve kabul kriterlerini nasıl kuracağınızı anlatıyoruz.
ERP projelerinde zaman baskısı en çok test aşamasını sıkıştırır. Oysa canlıda ortaya çıkan bir hata; yanlış fatura, yanlış stok ve yanlış maliyet demektir — düzeltmesi test etmekten çok daha pahalıdır.
Test türleri
| Test | Kim yapar | Amaç |
|---|---|---|
| Birim testi | Danışman | Her ayar doğru çalışıyor mu |
| Süreç testi | Anahtar kullanıcı | Uçtan uca akış çalışıyor mu |
| Entegrasyon testi | BT + danışman | Sistemler arası akış |
| Veri testi | Veri sorumlusu | Göç doğru mu |
| Kullanıcı kabul testi (UAT) | Son kullanıcılar | Gerçek işi yapabiliyor muyuz |
| Yük testi | BT | Yoğunlukta performans |
| Yetki testi | BT | Kim neyi görüyor/yapıyor |
En kritik olanı UAT'dir: sistemin teknik olarak çalışması yetmez, gerçek işi yapabilmesi gerekir.
Test senaryoları nasıl yazılır?
Senaryo, gerçek bir iş akışını baştan sona tarif etmelidir:
Örnek senaryo:
- Müşteriden 100 adet A ürünü siparişi gelir.
- Sipariş sisteme girilir; stok 40 adet, kredi limiti uygun.
- 60 adet için üretim emri açılır.
- MRP çalıştırılır, eksik hammadde için satın alma önerisi çıkar.
- Satın alma siparişi verilir, mal kabul yapılır.
- Üretim yapılır, geri bildirim girilir.
- Mamul stoka alınır.
- Sevkiyat yapılır, irsaliye kesilir.
- Fatura üretilir.
- Tahsilat kaydedilir.
- Maliyet ve kârlılık raporu kontrol edilir.
Beklenen sonuç her adım için yazılmalıdır. Beklenen sonuç yazılmayan test, "çalışıyor gibi göründü" ile geçilir.
Hangi senaryolar test edilmeli?
- En sık yapılan işlemler (hacmin çoğunu oluşturanlar)
- Kritik işlemler (fatura, sevkiyat, üretim)
- İstisnai durumlar (iade, iptal, kısmi sevkiyat, fire)
- Dönem sonu işlemleri
- Mevzuat çıktıları (e-fatura, e-irsaliye, beyanname verileri)
- Entegrasyon akışları
- Yetki sınırları
Üçüncü madde en çok atlanan ve canlıda en çok sorun çıkaranıdır: istisnalar test edilmediğinde ilk iade işleminde sistem kilitlenir.
Test ortamı
- Canlıdan ayrı bir test ortamı bulunmalı.
- Gerçekçi veriyle doldurulmalı.
- Testler tekrarlanabilmeli (ortam sıfırlanabilmeli).
- Canlıya geçişten sonra da korunmalı (yeni ayarlar önce burada denenir).
Son madde uzun vadede değerlidir: canlıda deneme yapmak, ERP'de en riskli alışkanlıktır.
Hata yönetimi
- Her hata kaydedilir (ne yapıldı, ne bekleniyordu, ne oldu).
- Ekran görüntüsü eklenir.
- Öncelik atanır (kritik / yüksek / orta / düşük).
- Sorumlu atanır.
- Çözüldükten sonra tekrar test edilir.
- Kapatılır.
Beşinci adım atlanırsa "düzeltildi" denen hatalar canlıda tekrar ortaya çıkar.
Kabul kriterleri
Canlıya geçiş için sağlanması gerekenler önceden yazılmalıdır:
- Kritik senaryoların tamamı başarılı
- Kritik ve yüksek öncelikli hata kalmamış
- Mevzuat çıktıları doğru üretiliyor
- Entegrasyonlar çalışıyor
- Veri doğrulaması tamamlanmış
- Yetkiler doğru
- Performans kabul edilebilir
- Kullanıcılar senaryoları yardımsız yapabiliyor
Son madde en anlamlı ölçüttür: danışman yanındayken çalışan sistem, canlıda çalışmayabilir.
Test disiplini
- Test için takvimde gerçek zaman ayırın.
- Test edenleri rutin işlerinden geçici olarak boşaltın.
- Testi "ekranı gezmek" değil senaryo yürütmek olarak tanımlayın.
- Sonuçları yazılı kaydedin.
- Kabul kriterleri sağlanmadan geçiş tarihini zorlamayın.
Son madde en zor olanıdır ama en çok koruyan kuraldır: hazır olmayan bir sistemle canlıya geçmek, kazanılan iki haftayı iki ay kaybettirir.
Özet
Test sürecinde en kritik aşama kullanıcı kabul testidir. Senaryoları gerçek iş akışlarıyla yazın, beklenen sonuçları belirtin ve istisnai durumları mutlaka kapsayın. Düzeltilen hataları tekrar test edin, kabul kriterlerini önceden yazın ve kriterler sağlanmadan geçiş tarihini zorlamayın.
Yorumlar (0)
Henüz yorum yok — ilk yorumu siz yazın.
Yorum yaz