ERP kabul testi (UAT) rehberi: senaryo, kabul kriteri ve hata yönetimi

ERP projelerinin en pahalı anlarından biri, canlıya geçişten sonraki ilk hafta ortaya çıkan "bu rapor yanlış çıkıyor" cümlesidir. Çoğu zaman o hata aslında canlıya geçmeden önce yakalanabilirdi. Yakalanmamasının nedeni test yapılmaması değil, testin kimin tarafından, hangi veriyle ve hangi ölçüye göre yapıldığının belirsiz kalmasıdır.

Bu yazıda ERP kabul testini, yani yazılımı kullanacak ekibin "bu sistem benim işimi yapıyor mu" sorusuna kanıtla cevap verdiği aşamayı anlatıyoruz. Sektörde buna sık sık UAT (user acceptance test) denir. Biz Türkçe karşılığıyla kabul testi diyeceğiz.

Kabul testi neyi sınar, neyi sınamaz

Satıcının ya da uygulama ortağının yaptığı teknik testler yazılımın çalışıp çalışmadığına bakar: ekran açılıyor mu, kayıt kaydediliyor mu, entegrasyon bağlanıyor mu. Kabul testi ise farklı bir soruyu yanıtlar: sizin işiniz, sizin verinizle, sizin çalışanlarınızın kullandığı ekranlarda baştan sona yürüyor mu?

Bunu bir araba benzetmesiyle düşünün. Fabrikadaki kalite kontrol aracın motorunun çalıştığını doğrular. Kabul testi ise aracı sizin yolunuzda, sizin yükünüzle sürmektir. İkisi birbirinin yerine geçmez.

Kabul testinin kapsamı dışında kalanlar da baştan bilinmeli:

• Yazılımın standart hatalarını bulmak (bu satıcının sorumluluğundadır)
• Yük ve performans ölçümü (ayrı bir teknik çalışmadır)
• Eğitim yerine geçmek (test sırasında öğrenen kullanıcı iyi test edemez, önce temel eğitim verilmelidir)

Teste başlamadan önce hazır olması gerekenler

Kabul testi, hazırlığı yarım kalmış bir projede zaman kaybıdır. Başlamadan önce şu dört şeyin hazır olduğunu doğrulayın:

1. Kapsam belgesi. Hangi süreçler ve modüller canlıya çıkacak? Test edilecek her şeyin kaynağı budur. Kapsamı baştan yazmak için ERP ihtiyaç analizi ve gereksinim listesi rehberi işe yarar.
2. Gerçeğe yakın veri. Boş bir sistemde yapılan test, eksik stok kartlarının, çift cari kayıtlarının ve hatalı birimlerin ortaya çıkmasını engeller. Veri aktarımı nasıl planlanır sorusu için ERP veri taşıma ve migrasyon rehberine bakabilirsiniz.
3. Ayrı bir test ortamı. Canlı veriyi bozma riski olmadan denemek gerekir. Ortamın canlıdan ne kadar farklı olduğunu satıcıdan yazılı isteyin.
4. Yetki yapısı. Test kullanıcıları gerçek rollerle girmeli. Herkes yönetici yetkisiyle test ederse yetki hataları canlıda patlar. Bu konuda yetkilendirme ve görevler ayrılığı rehberi yol gösterir.

Test senaryoları nasıl yazılır

İyi bir senaryo, bir iş olayını başından sonuna izler. "Sipariş ekranını aç" bir senaryo değildir. "Müşteriden gelen siparişi gir, stoktan ayır, sevk et, faturala, tahsilatı kapat ve cari bakiyenin sıfırlandığını doğrula" bir senaryodur.

Her senaryoda şu beş alan bulunmalı:

• Kim test ediyor: gerçek kullanıcı, ismiyle
• Başlangıç verisi: hangi müşteri, hangi ürün, hangi tutar
• Adımlar: kısa ve sıralı
• Beklenen sonuç: rakamla ve ekran bazında
• Gerçekleşen sonuç ve durum: geçti, kaldı, kısmen geçti

Senaryo listesini üç gruba ayırmak yönetimi kolaylaştırır: her gün yapılan işler (sipariş, irsaliye, fatura, tahsilat), dönemsel işler (ay sonu kapanış, KDV hazırlığı, stok sayımı) ve istisnalar (iade, iptal, kur farkı, kısmi sevkiyat). Hataların çoğu üçüncü grupta saklanır, çünkü demo sırasında hiç gösterilmez.

Türkiye'ye özgü senaryoları atlamayın. e-fatura, e-arşiv, e-irsaliye, e-defter ve beyanname çıktıları her projede ayrıca denenmelidir. e-belge çözümünün yerleşik mi entegratörlü mü olacağı kararı test planını da etkiler, çünkü entegratör tarafında ayrı bir deneme ortamı gerekir.

Kimler test etmeli

En sık yapılan hata, testi projenin BT sorumlusuna ya da uygulama ortağının danışmanına bırakmaktır. Süreci her gün yürüten kişi, ekranın nerede takıldığını en iyi bilendir. Muhasebe sorumlusu, depo sorumlusu, satın alma uzmanı ve satış yöneticisi kendi senaryolarını kendisi koşmalı.

Pratik bir dağılım şöyle olabilir:

Proje liderliğini iç ekibin mi dış danışmanın mı yapacağı ayrı bir karardır; iç ekip mi dış danışman mı yazısı bunu ele alıyor.

Hata nasıl sınıflandırılır

Her bulgu aynı ağırlıkta değildir. Önceden anlaşılmış bir sınıflandırma, kabul tartışmasını duygudan çıkarır. Yaygın kullanılan üç seviye:

• Engelleyici: Süreç yürümüyor ya da yanlış rakam üretiyor (fatura tutarı hatalı, stok eksiye düşüyor). Canlıya geçişi durdurur.
• Ciddi: Süreç yürüyor ama kullanıcı geçici çözümle uğraşıyor. Canlıya geçişten önce düzeltilmesi ya da yazılı bir geçici çözümle kabul edilmesi gerekir.
• Kozmetik: Ekran düzeni, etiket adı, rapor başlığı gibi işi etkilemeyen konular. Canlıya geçişten sonraya bırakılabilir.

Bu sınıflandırmayı sözleşmeye ya da proje planına yazın. "Kaç engelleyici hata açıkken kabul verilmez" sorusunun cevabı önceden belli olmalı. Sözleşme tarafı için ERP sözleşmesi kontrol listesi kabul kriterleri, ödeme aşamaları ve gecikme hükümleri için iyi bir başlangıçtır.

Kabul kriteri: "bitti" ne zaman denir

Kabul kriteri olmayan test sonsuza uzar ya da baskıyla aceleye gelir. Ölçülebilir birkaç ölçüt belirleyin:

• Tüm kritik senaryoların tamamı geçmiş olmalı
• Açık engelleyici hata sayısı sıfır olmalı
• Ciddi hataların her biri için yazılı çözüm ya da geçici yöntem ve tarih bulunmalı
• Eski sistemdeki bir ay sonu bakiyesiyle yeni sistemdeki bakiye uyuşmalı (cari, stok, kasa ve banka için ayrı ayrı)
• Süreç sahipleri imzalı kabul formunu vermiş olmalı

Bakiye mutabakatı en güçlü kanıttır. Eski sistemde belirli bir tarihteki stok değeri ve cari bakiyeler, aktarım sonrası yeni sistemle birebir karşılaştırılırsa veri kalitesi hakkında tahmin yürütmeye gerek kalmaz.

Test takvimi nasıl kurulur

Kabul testi tek bir güne sığmaz. Mantıklı bir sıra şöyledir: önce her bölüm kendi günlük senaryolarını koşar, ardından bölümler arası akışlar (satıştan muhasebeye, satın almadan stoka) denenir, en sonda dönem kapanışı ve resmi çıktılar test edilir. Her turun ardından hata düzeltme ve yeniden test için boş gün bırakın. Kullanıcıların test için ayırdığı saatler gündelik işlerinin üstüne binerse sonuç yüzeysel olur; bu yüzden test günlerinde kullanıcıların işlerinin bir kısmını başkasına devretmesi gerekir. Bu küçük planlama kararı, kabul testinin gerçekten yapılıp yapılmayacağını çoğu zaman belirler.

Sık yapılan hatalar

Testi takvimin sonuna sıkıştırmak. Proje geciktiğinde ilk kısılan şey test süresi olur. Test süresini proje planında sabit tutun ve gecikmeyi başka kalemlerden karşılayın.

Demo verisiyle test etmek. Satıcının hazırladığı temiz veri, sizin kirli verinizin yarattığı sorunları göstermez.

Hata kaydını sözlü yürütmek. Telefonda söylenen hata unutulur. Her bulgu tek bir ortak listede, tarihi ve sahibiyle tutulmalı.

Kabulü imzaya indirgemek. İmza, testin sonucudur, yerine geçmez. Kullanıcılar formu imzalıyor ama senaryoyu koşmamışsa belge değersizdir.

Testi tek turla bitirmek. Düzeltilen hata başka bir yeri bozabilir. En az bir tur yeniden test (gerileme testi) planlayın.

Ürüne göre değişen pratik

Kabul testinin ağırlığı seçtiğiniz yazılıma ve kurulum biçimine göre değişir. SAP Business One ve Microsoft Dynamics 365 Business Central gibi iş ortağı kanalıyla uygulanan ürünlerde test ortamı ve senaryo desteği ortağın sözleşme kapsamına bağlıdır, bu nedenle kapsamı yazılı netleştirin. Odoo gibi modüler yapılarda ise her modül ayrı bir test turu gerektirebilir. Birçok özel uyarlama içeren projelerde test süresi, standart kuruluma göre belirgin biçimde uzar; bu konuda standart mı uyarlama mı yazısı riski anlatıyor. Süreçleri karmaşık üretim firmalarında kabul testi için üretim sektörü sayfasına göz atmak, hangi senaryoların öncelikli olduğunu görmenizi sağlar. Yerli ve yabancı çözümlerin test ve destek yaklaşımı farkları için yerli ve global ERP karşılaştırması de yararlıdır.

Kesin süre ve efor vermek mümkün değil; hepsi kapsama, veri kalitesine ve ekibin kullanılabilirliğine bağlıdır. Satıcıdan test fazı için ayrı bir süre ve destek taahhüdü isteyin.

Kabul testinden sonraki dönem de planlanmalı: canlıya geçişin ardından ilk haftaların nasıl yönetileceğini ilk 90 gün rehberinde anlattık. Hangi sistemin size uyduğundan henüz emin değilseniz önce Uygun ERP bul aracını deneyebilir, ardından keşif formu üzerinden bağımsız bir değerlendirme isteyebilirsiniz.