Checklist UAT Aplikasi dari Vendor: Cara Menguji Sebelum Menandatangani Serah Terima

UAT atau user acceptance testing adalah tahap terakhir sebelum Anda menerima aplikasi buatan vendor. Di banyak kontrak, tanda tangan di akhir UAT juga memicu pembayaran termin terakhir dan memulai masa garansi. Begitu dokumen itu ditandatangani, posisi tawar Anda berubah: memperbaiki sesuatu sebelum serah terima adalah kewajiban vendor, sedangkan setelahnya bisa menjadi pembahasan baru.

Checklist UAT di bawah ditulis untuk pihak pembeli, bukan untuk tim QA vendor. Isinya: syarat sebelum UAT dimulai, cara menyusun skenario dari pekerjaan nyata, cara mengelompokkan temuan, kriteria lulus yang bisa diukur, dan apa yang harus tertulis di berita acara serah terima.

UAT bukan pengujian teknis vendor

Vendor yang baik sudah menguji aplikasinya sendiri sebelum menyerahkan ke Anda. Pengujian itu menjawab pertanyaan teknis: apakah fungsi berjalan, apakah integrasi tersambung, apakah aplikasi stabil. UAT menjawab pertanyaan yang berbeda: apakah tim Anda bisa menyelesaikan pekerjaan sehari-hari dengan aplikasi ini, sesuai yang disepakati di kontrak dan dokumen kebutuhan.

Karena itu pelaksana UAT adalah pengguna dari bisnis Anda, bukan programmer. Jika di hari pertama UAT tim Anda sudah menemukan banyak kesalahan dasar, misalnya halaman tidak terbuka atau tombol simpan gagal, itu tanda pengujian internal vendor belum selesai. Hentikan UAT dan minta vendor menyelesaikannya dulu.

Syarat sebelum UAT dimulai

Sepakati syarat masuk ini secara tertulis. Jangan memulai UAT bila salah satunya belum terpenuhi, karena waktu penguji Anda adalah biaya.

• Acuan yang jelas. Dokumen kebutuhan atau lingkup kerja yang disepakati, termasuk semua perubahan lingkup yang sudah disetujui.
• Lingkungan uji terpisah. UAT berjalan di lingkungan yang mirip produksi, bukan di sistem yang sedang dipakai, dan integrasi diarahkan ke sandbox pihak ketiga.
• Data uji realistis. Pakai contoh transaksi sungguhan dari bisnis Anda, dengan data pribadi pelanggan disamarkan. Data contoh yang terlalu rapi menyembunyikan masalah.
• Catatan dari vendor. Hasil pengujian internal dan daftar masalah yang sudah diketahui.
• Akun per peran. Setiap penguji masuk dengan peran yang akan ia pakai sehari-hari, bukan dengan akun admin.
• Penguji dan jadwal. Nama penguji dari tiap bagian, berapa jam per hari mereka dibebaskan dari pekerjaan rutin, dan kapan putaran uji ulang dilakukan.

Pembagian peran selama UAT

UAT berjalan lebih tertib bila setiap orang tahu tugasnya. Pembagian yang sederhana biasanya cukup:

• Pemilik proyek di pihak Anda. Memutuskan apakah sebuah temuan termasuk bug atau permintaan perubahan, dan menandatangani hasil akhir.
• Koordinator UAT. Menjaga jadwal, memastikan setiap skenario dijalankan, dan merapikan daftar temuan setiap sore.
• Penguji dari setiap bagian. Menjalankan skenario bagiannya, melaporkan temuan dengan bukti, lalu mencoba ulang setelah perbaikan.
• Vendor. Mendampingi, menjawab pertanyaan, memperbaiki temuan, dan memberi tahu kapan versi perbaikan siap diuji.

Satu kebiasaan yang sangat membantu adalah pertemuan singkat setiap hari selama UAT untuk membahas temuan baru. Masalah yang dibahas di hari yang sama jarang berubah menjadi perselisihan di akhir.

Menyusun skenario dari pekerjaan nyata

Skenario yang baik adalah satu pekerjaan utuh dari awal sampai akhir, bukan satu tombol. Contoh: "Admin gudang menerima barang dari pemasok, sebagian barang rusak, stok bertambah sesuai jumlah yang diterima, dan laporan selisih terkirim ke bagian pembelian."

Untuk setiap skenario catat peran, langkah, data yang dipakai, hasil yang diharapkan, status lulus atau gagal, dan bukti berupa tangkapan layar. Daftar proses beserta pengecualiannya biasanya sudah ada bila Anda pernah melakukan pemetaan proses sebelum proyek dimulai; pakai daftar itu sebagai bahan.

Pastikan skenario mencakup enam hal:

1. Jalur normal untuk setiap pekerjaan utama.
2. Pengecualian, seperti pembatalan, retur, data kosong, input salah, atau transaksi yang diubah setelah disetujui.
3. Hak akses, yaitu peran yang tidak boleh melihat atau mengubah data tertentu benar-benar tidak bisa.
4. Angka di laporan, dicocokkan dengan perhitungan manual untuk periode uji yang sama.
5. Integrasi, misalnya data yang harus muncul di sistem lain setelah transaksi selesai.
6. Beban kasar, yaitu beberapa pengguna bekerja bersamaan seperti di jam sibuk.

Mengelompokkan temuan agar tidak berdebat

Setiap temuan masuk ke satu daftar bersama, dengan nomor, skenario, langkah untuk mengulang masalahnya, bukti, tingkat, dan status. Tingkatnya sepakati sejak awal:

• Kritis. Pekerjaan utama tidak bisa diselesaikan, data salah atau hilang, atau ada celah hak akses. Wajib diperbaiki sebelum serah terima.
• Tinggi. Pekerjaan bisa selesai, tetapi dengan jalan memutar yang merepotkan. Diperbaiki sebelum serah terima, atau disepakati tenggat tertulisnya.
• Sedang. Mengganggu, tetapi ada jalan memutar yang wajar.
• Rendah. Masalah tampilan atau teks.

Tambahkan satu label lagi: permintaan perubahan. Ini untuk hal yang ternyata tidak ada di dokumen kebutuhan, misalnya penguji baru sadar butuh laporan tambahan. Permintaan perubahan bukan bug. Ia dicatat, diestimasi, dan diputuskan terpisah, supaya UAT tidak berubah menjadi negosiasi lingkup. Temuan dinyatakan selesai hanya setelah penguji yang melaporkannya mencoba ulang dan menyatakan lulus.

Checklist UAT: kriteria lulus yang terukur

Kriteria lulus sebaiknya ditulis sebelum UAT dimulai, bukan dirumuskan ketika tenggat sudah dekat.

• Semua skenario untuk pekerjaan utama lulus.
• Tidak ada temuan kritis yang masih terbuka.
• Temuan tinggi sudah diperbaiki, atau masing-masing punya tenggat tertulis.
• Angka laporan cocok dengan perhitungan manual untuk periode uji.
• Hak akses setiap peran sudah diuji.
• Bila ada migrasi data, jumlah dan total sudah dicocokkan dengan sistem lama, dan sampel dicek satu per satu.
• Panduan pengguna tersedia untuk setiap peran.
• Penguji dari setiap bagian menandatangani hasil bagiannya.

Isi berita acara serah terima

Berita acara adalah dokumen yang akan dibaca lagi ketika ada perselisihan. Minimal ia memuat:

• Versi aplikasi yang diuji dan periode UAT.
• Daftar skenario beserta hasilnya.
• Daftar masalah yang diterima untuk sementara, lengkap dengan tingkat, jalan memutar, dan tenggat perbaikan.
• Pernyataan bahwa cacat yang baru ditemukan setelah serah terima tetap menjadi tanggung jawab vendor selama masa garansi.
• Termin pembayaran yang jatuh tempo karena berita acara ini.
• Status serah terima source code, dokumentasi, dan akun. Daftar lengkapnya ada di panduan kepemilikan source code.
• Nama, jabatan, dan tanda tangan pihak yang berwenang dari kedua sisi.

Kesalahan yang sering terjadi

UAT dikerjakan satu orang. Biasanya pemilik atau orang IT. Pengguna sebenarnya baru melihat aplikasi saat go-live, dan masalahnya muncul bersamaan.

Menguji dengan data contoh. Data yang rapi tidak pernah memicu pengecualian yang terjadi di dunia nyata.

"Lulus dengan catatan" tanpa tenggat. Catatan tanpa tanggal hampir selalu berakhir sebagai pekerjaan yang tidak pernah selesai.

Go-live diumumkan sebelum UAT selesai. Tekanan jadwal membuat semua orang ingin cepat menandatangani.

Setelah tanda tangan

Masa garansi adalah waktu untuk mencatat semua yang muncul saat aplikasi dipakai sungguhan. Setelah itu, perawatan berjalan sesuai kontrak maintenance. Di lini Enterprise Software Etzal Group, serah terima disertai dokumentasi dan garansi 30 hari sebelum masuk masa maintenance. Jika Anda sedang menyiapkan UAT dan ingin daftar skenario Anda diperiksa, gunakan sesi konsultasi gratis.