Saat aplikasi selesai dibuat, godaan terbesar adalah langsung memakainya. Padahal pengembang biasanya menguji apakah fitur berjalan sesuai rancangan, sedangkan pengguna memakainya dengan cara yang sering tidak terduga. Jarak antara keduanya hanya bisa ditutup dengan uji coba oleh orang yang akan memakainya setiap hari. Tahap ini sering disebut User Acceptance Testing, atau UAT.
Tujuan UAT bukan mencari sebanyak mungkin kesalahan kecil. Tujuannya memastikan aplikasi benar-benar bisa menyelesaikan pekerjaan perusahaan. Sebuah tombol bisa berfungsi sempurna, tetapi tetap tidak berguna jika alurnya tidak sesuai cara kerja di lapangan. Karena itu, penilaian terbaik datang dari pengguna, bukan dari pembuat aplikasi.
Langkah pertama adalah menentukan siapa yang terlibat. Pilih perwakilan dari setiap bagian yang akan memakai sistem, termasuk orang yang paling paham proses sehari-hari. Tunjuk satu koordinator yang mengatur jadwal dan merapikan temuan. Pastikan mereka diberi waktu khusus. Uji coba yang dikerjakan di sela kesibukan biasanya berakhir dengan pemeriksaan sekadarnya.
Tuliskan skenario berdasarkan pekerjaan nyata. Jangan hanya menulis uji menu penjualan. Tulislah cerita lengkap, misalnya pelanggan memesan tiga barang, satu barang stoknya habis, pelanggan membayar sebagian, lalu sisanya dilunasi minggu depan. Skenario seperti ini memeriksa beberapa fitur sekaligus dan sering mengungkap masalah yang tidak terlihat saat fitur diuji satu per satu.
Sertakan skenario yang tidak biasa. Coba pembatalan transaksi, retur, kesalahan input, atau dua orang mengubah data yang sama. Uji juga batas hak akses, misalnya apakah staf biasa bisa melihat data yang seharusnya hanya untuk pimpinan. Justru pada kasus seperti inilah banyak masalah muncul setelah aplikasi dipakai.
Gunakan data yang mendekati kenyataan. Jika aplikasi akan menyimpan ribuan barang atau pelanggan, jangan menguji dengan sepuluh baris contoh. Banyak masalah kecepatan dan laporan baru terlihat saat datanya besar. Jika memakai salinan data asli, samarkan informasi pribadi seperti nomor telepon dan alamat pelanggan, lalu batasi siapa yang boleh mengaksesnya.
Bandingkan hasil dengan yang seharusnya. Bagian keuangan, misalnya, bisa memasukkan transaksi satu hari dari periode yang sudah ditutup, lalu mencocokkan laporan aplikasi dengan catatan lama. Jika angkanya berbeda, cari penyebabnya sebelum sistem dipakai. Selisih kecil yang dibiarkan sekarang bisa berubah menjadi masalah besar saat tutup buku.
Catat setiap temuan dengan rapi. Satu lembar kerja bersama sudah cukup. Tuliskan langkah yang dilakukan, hasil yang diharapkan, hasil yang muncul, dan tangkapan layar. Beri tingkat prioritas: tinggi jika menghalangi pekerjaan utama, sedang jika ada jalan lain, dan rendah jika hanya soal tampilan. Dengan begitu, tim pengembang tahu apa yang harus diselesaikan lebih dulu.
Bedakan kesalahan dengan permintaan baru. Selama uji coba, pengguna sering mendapat ide fitur tambahan. Ide itu tetap berharga, tetapi jangan dicampur dengan perbaikan. Catat di daftar terpisah untuk dibahas setelah aplikasi berjalan. Jika tidak, proyek bisa terus molor karena ruang lingkupnya terus bertambah.
Setiap perbaikan perlu diuji ulang. Perubahan di satu bagian kadang memengaruhi bagian lain, jadi ulangi skenario utama setelah perbaikan besar. Tentukan juga syarat kelulusan sejak awal, misalnya semua skenario utama berhasil dan tidak ada temuan prioritas tinggi yang tersisa. Keputusan siap atau belum sebaiknya diambil berdasarkan daftar ini, bukan perasaan.
Sebelum benar-benar dipakai, siapkan rencana cadangan. Pastikan data lama tersimpan aman, tentukan siapa yang berhak memutuskan kembali ke cara lama jika terjadi masalah serius, dan latih tim untuk prosedur tersebut. Rencana ini mungkin tidak terpakai, tetapi membuat peluncuran jauh lebih tenang.
Uji coba juga sebaiknya mencakup perangkat dan kondisi kerja yang sebenarnya. Aplikasi yang lancar di komputer kantor pengembang belum tentu nyaman di ponsel staf lapangan atau di jaringan internet cabang yang lambat. Coba juga printer struk, pemindai barcode, dan alat lain yang akan dipakai sehari-hari. Lakukan pengujian pada jam sibuk, saat banyak orang bekerja bersamaan, supaya kendala yang hanya muncul dalam kondisi nyata bisa terlihat lebih awal.
EXE AJA melayani pengembangan aplikasi dan sistem informasi sesuai alur kerja perusahaan, serta konsultasi IT. Jika Anda sedang merencanakan sistem baru, ceritakan kebutuhan Anda lewat halaman kontak.
Foto ilustrasi: X (@disruptxn) via Unsplash.
