User Acceptance Test atau UAT adalah tahap ketika pengguna sebenarnya mencoba sistem dengan skenario kerja nyata, sebelum sistem itu dipakai untuk pekerjaan harian. Dalam banyak proyek, tahap ini menyusut menjadi satu pertemuan dua jam yang berakhir dengan penandatanganan berita acara.
Padahal, secara biaya, UAT adalah tahap paling menguntungkan dalam seluruh proyek. Memperbaiki sesuatu di fase ini masih berarti mengubah kode di lingkungan uji. Memperbaiki hal yang sama tiga bulan setelah go-live berarti mengubah kode, memperbaiki data yang sudah terlanjur masuk, dan melatih ulang orang.
Siapa yang seharusnya duduk di depan layar
Ini penentu utama antara UAT yang berguna dan UAT yang cuma formalitas.
UAT formalitas dihadiri kepala bagian atau pejabat yang menandatangani. Mereka membuka lima menu, melihat tampilannya rapi, lalu menandatangani. Tidak ada yang salah dengan orangnya, hanya saja mereka bukan orang yang akan memakai sistem itu setiap hari.
UAT yang berguna dihadiri staf yang benar-benar menginput data. Orang yang tahu bahwa nomor surat baru keluar sore hari, bahwa ada pemohon yang namanya sering ganda, dan bahwa setiap akhir bulan ada satu jenis transaksi khusus yang tidak pernah disebut di dokumen kebutuhan.
Kalau harus memilih satu perubahan saja untuk memperbaiki proyek Anda, ubahlah siapa yang hadir di UAT.
Menyiapkan skenario, bukan sekadar mencoba-coba
UAT tanpa skenario akan berubah menjadi sesi klik-klik acak yang berakhir dengan kesimpulan "sepertinya sudah bagus". Yang dibutuhkan adalah daftar tertulis berisi kasus yang harus dicoba, disusun sebelum hari pelaksanaan.
Skenario yang baik ditulis dalam bahasa kerja, bukan bahasa teknis. Contohnya:
- Warga datang membawa berkas lengkap, petugas mendaftarkan sampai nomor register keluar.
- Warga datang tetapi satu lampiran kurang, petugas menyimpan sebagai draf lalu melengkapinya keesokan hari.
- Berkas yang sudah disetujui ternyata harus dibatalkan karena salah input.
- Dua pemohon memiliki nama yang sama persis.
- Petugas menutup laporan bulanan pada tanggal terakhir.
Perhatikan bahwa hanya kasus pertama yang berjalan mulus. Empat sisanya adalah kasus yang tidak ideal, dan justru di situlah sistem biasanya patah.
Kasus yang paling sering terlewat
Dari proyek-proyek yang kami tangani, ada beberapa jenis kasus yang hampir selalu terlupakan saat menyusun kebutuhan dan baru muncul di UAT kalau skenarionya disiapkan dengan benar:
- Pembatalan setelah disetujui. Hampir semua alur kerja punya kemungkinan ini, tetapi jarang disebut di dokumen kebutuhan.
- Data yang harus diperbaiki setelah tersimpan. Siapa yang boleh mengubah, dan apakah perubahannya tercatat.
- Pengguna yang lupa logout lalu komputernya dipakai orang lain.
- Dua orang mengubah data yang sama di waktu bersamaan.
- Perilaku sistem saat jaringan putus di tengah proses simpan.
Menemukan kasus-kasus ini di fase UAT adalah keberuntungan. Menemukannya setelah go-live adalah masalah.
Cara mencatat temuan agar bisa ditindaklanjuti
Temuan UAT yang dicatat sebagai "tampilannya kurang enak" atau "ada error" hampir tidak bisa dikerjakan. Yang berguna adalah catatan yang memuat empat hal: apa yang dilakukan, apa yang diharapkan terjadi, apa yang sebenarnya terjadi, dan seberapa mengganggu.
Bagian terakhir itu penting. Tidak semua temuan harus diperbaiki sebelum go-live. Memisahkan mana yang menghalangi pekerjaan dari mana yang sekadar kurang nyaman membuat jadwal tetap realistis, dan membuat keputusan menunda menjadi keputusan sadar, bukan kelalaian.
Kami biasanya memakai tiga tingkat saja: menghalangi pekerjaan, mengganggu tetapi ada jalan lain, dan sekadar penyempurnaan. Tingkat pertama wajib selesai sebelum rilis, tingkat kedua dijadwalkan, tingkat ketiga dicatat untuk nanti.
Berapa lama UAT sebaiknya berlangsung
Tidak ada angka baku, tetapi satu pertemuan hampir tidak pernah cukup. Yang kami sarankan adalah UAT berjalan beberapa hari kerja, dengan pengguna mencoba sistem di sela pekerjaan asli mereka, bukan dalam sesi khusus yang steril.
Alasannya sederhana: dalam sesi khusus, orang mengikuti skenario. Dalam pekerjaan nyata, orang menemukan hal yang tidak ada di skenario mana pun. Justru temuan jenis kedua itu yang paling berharga.
Menutup UAT dengan benar
Berita acara UAT sebaiknya memuat lebih dari sekadar pernyataan bahwa sistem diterima. Idealnya juga memuat daftar temuan beserta keputusannya: mana yang sudah diperbaiki, mana yang dijadwalkan, dan mana yang disepakati tidak dikerjakan.
Daftar ini melindungi kedua pihak. Bagi klien, ini jaminan bahwa temuan tidak menguap begitu saja. Bagi pengembang, ini kesepakatan tertulis tentang apa yang masuk lingkup dan apa yang tidak. Tanpa itu, tiga bulan kemudian akan muncul perbedaan ingatan yang tidak bisa diselesaikan siapa pun.