ERP belum siap digunakan hanya karena semua menu sudah terlihat dan tidak ada error saat demo. Sistem baru layak masuk operasional setelah pengguna bisnis membuktikan bahwa transaksi, stok, keuangan, hak akses, laporan, dan proses koreksi bekerja sesuai kebutuhan.
UAT ERP atau User Acceptance Testing adalah pengujian penerimaan oleh perwakilan bisnis menggunakan skenario kerja nyata. UAT menjawab pertanyaan paling penting: apakah sistem dapat dipakai untuk menjalankan operasi dengan risiko yang dapat diterima?
Ringkasan: UAT harus memakai data uji yang terkontrol, role pengguna yang benar, hasil yang diharapkan, serta bukti. Pengujian mencakup alur normal, kesalahan, pembatalan, approval, posting, rekonsiliasi, dan hak akses. Temuan yang belum diuji tetap berstatus belum diketahui, bukan lulus.
Perbedaan Demo, Testing Teknis, dan UAT
| Kegiatan | Fokus | Pemilik Utama |
|---|---|---|
| Demo | Menunjukkan fitur dan alur | Vendor/tim produk |
| Testing teknis | Fungsi, integrasi, keamanan, performa | Developer dan QA |
| UAT | Kesesuaian terhadap proses dan penerimaan bisnis | Process owner dan pengguna kunci |
Ketiganya saling melengkapi. UAT bukan pengganti security test atau performance test. Sebaliknya, kelulusan teknis juga belum membuktikan bahwa alur bisnis benar.
Persiapan Sebelum UAT ERP
- scope dan versi build dibekukan untuk sesi pengujian;
- requirement prioritas memiliki acceptance criteria;
- master data dan saldo awal uji disiapkan;
- role serta segregation of duties dikonfigurasi;
- integrasi kritis tersedia atau mock-nya dijelaskan;
- tester, owner keputusan, jadwal, dan kanal defect ditetapkan;
- backup serta reset data uji tersedia.
Skenario Kritis yang Perlu Diuji
1. Penjualan sampai Penerimaan Pembayaran
Uji quotation atau order, ketersediaan stok, approval diskon/kredit, pengiriman, invoice, pembayaran sebagian, pelunasan, retur, dan dampaknya pada jurnal serta piutang.
2. Pembelian sampai Pembayaran Vendor
Uji permintaan, purchase order, penerimaan berbeda jumlah, invoice vendor, pajak, retur, approval, pembayaran, dan utang.
3. Gudang dan Persediaan
Uji penerimaan, pengeluaran, transfer, penyesuaian, batch/serial bila ada, stok negatif, pembatalan, dan kecocokan kartu stok dengan laporan.
4. Akuntansi
Uji posting otomatis, jurnal manual, periode terbuka/tertutup, reversal, rekonsiliasi, trial balance, laba rugi, neraca, serta audit trail. Angka harus direkonsiliasi dari transaksi sumber sampai laporan.
5. Hak Akses dan Approval
Pastikan pengguna dapat melakukan pekerjaannya tetapi tidak memperoleh kewenangan yang tidak semestinya. Uji penolakan akses, bukan hanya akses yang diizinkan.
6. Kondisi Gagal
Uji data wajib kosong, duplikasi, koneksi terputus, integrasi gagal, dokumen sudah diproses, approval ditolak, dan transaksi dibatalkan. Sistem harus memberikan status serta jalur pemulihan yang jelas.
Format Test Case yang Dapat Dipertanggungjawabkan
- ID dan tujuan skenario;
- role serta precondition;
- data uji;
- langkah;
- expected result per langkah penting;
- actual result dan bukti;
- status Passed, Failed, Blocked, atau Not Run;
- severity dan owner temuan;
- hasil retest serta regression check.
Status Blocked tidak boleh diubah menjadi Passed hanya karena kendalanya berasal dari data, akses, atau integrasi pihak lain. Hambatan tersebut justru bagian dari kesiapan operasional.
Kapan UAT Dapat Ditandatangani?
Kriteria sign-off harus disepakati sebelum pengujian. Contohnya: seluruh skenario kritis selesai, tidak ada defect blocker/critical terbuka, defect high memiliki keputusan tertulis, rekonsiliasi transaksi prioritas sesuai, akses sensitif diuji, dokumentasi serta training tersedia, dan cutover plan disetujui.
Sign-off tidak berarti sistem bebas bug selamanya. Dokumen tersebut menyatakan versi, scope, bukti, exception, dan risiko yang diterima pada waktu tertentu.
Kesalahan UAT yang Sering Terjadi
- tester hanya mengikuti demo vendor;
- hanya menguji happy path;
- menggunakan akun admin untuk semua skenario;
- tidak menghitung dampak ke stok dan jurnal;
- temuan disampaikan lewat chat tanpa ID atau bukti;
- retest dilakukan tanpa regression test;
- go-live diputuskan meski banyak skenario belum dijalankan.
Baca juga peran Quality Assurance dalam software enterprise. Untuk baseline kebutuhan sebelum pengujian, lihat studi kasus ERP discovery.
Pertanyaan yang Sering Diajukan
Siapa yang harus menandatangani UAT?
Process owner atau pihak yang diberi kewenangan bisnis, dengan bukti teknis dari tim proyek. Vendor tidak seharusnya menyatakan penerimaan atas nama pengguna.
Apakah semua bug harus selesai?
Defect blocker dan critical seharusnya ditutup. Temuan lain dapat diterima dengan keputusan risiko, workaround, owner, dan target yang jelas.
Apakah UAT sama dengan go-live?
Tidak. Setelah UAT masih ada cutover, migrasi final, kesiapan support, backup, rollback, monitoring, training, dan persetujuan go-live.
Siapkan UAT Sebelum Menentukan Go-Live
Layana.ID dapat membantu menyusun test scenario, acceptance criteria, defect workflow, retest, dan readiness review. Diskusikan kebutuhan UAT ERP.