Memilih Vendor Sistem Custom Berdasarkan UAT Fungsional

Memilih vendor sistem custom tidak cukup dengan melihat daftar fitur, demo, atau janji bahwa aplikasi akan diuji. Untuk membandingkan penawaran secara lebih terarah, periksa bagaimana vendor merencanakan user acceptance testing (UAT): siapa yang menguji, alur bisnis apa yang dicakup, apa arti “lulus”, dan bagaimana temuan dicatat. Rencana UAT yang dapat dibahas bersama membantu calon pembeli memahami cara memeriksa kesesuaian fungsi sebelum menyetujui hasil pekerjaan.

UAT bukan satu-satunya ukuran kualitas vendor dan tidak menjamin sistem bebas dari semua masalah. Namun, rencana yang jelas membuat percakapan tentang penerimaan pekerjaan lebih konkret. Artikel ini membantu pemilik bisnis, tim pengadaan, dan penanggung jawab operasional membandingkan rencana tersebut tanpa menganggap satu format cocok untuk semua proyek.

Membedakan demo, QA vendor, dan UAT pengguna

Demo biasanya memperlihatkan kemampuan yang dipilih untuk presentasi. QA adalah aktivitas pemeriksaan yang dilakukan tim pengembang atau penguji untuk menemukan masalah berdasarkan pendekatan pengujian mereka. UAT melibatkan perwakilan pengguna atau pemilik proses untuk menilai apakah fungsi yang disepakati mendukung kebutuhan operasional.

Batas antara aktivitas-aktivitas ini dapat berbeda menurut proyek. Karena itu, jangan hanya menanyakan “apakah ada testing?” Mintalah vendor menjelaskan tahapan yang dimaksud, peserta yang terlibat, lingkungan pengujian, dan bagaimana hasilnya berpengaruh pada keputusan penerimaan. Atlassian juga menjelaskan UAT sebagai pengujian oleh pengguna untuk memeriksa apakah kebutuhan bisnis terpenuhi; gunakan sumber tersebut sebagai penjelasan umum, bukan standar kontrak yang otomatis berlaku untuk setiap proyek.

Memilih vendor sistem custom berdasarkan UAT fungsional

Untuk membandingkan vendor sistem custom berdasarkan UAT fungsional, berikan konteks bisnis yang sama kepada setiap kandidat. Minta mereka menjelaskan bagaimana konteks itu diterjemahkan menjadi skenario uji dan bagaimana hasilnya akan didokumentasikan. Jangan membandingkan satu vendor yang menerima daftar fitur saja dengan vendor lain yang diminta menyiapkan rencana rinci tanpa menyamakan ruang lingkup pertanyaannya.

1. Periksa apakah skenario mewakili alur kerja nyata

Pilih beberapa alur penting, bukan sekadar menguji setiap tombol secara terpisah. Contohnya, untuk proses pemesanan, skenario dapat mengikuti perjalanan dari pencatatan permintaan, pemeriksaan data, perubahan status, sampai keluaran yang dibutuhkan petugas. Contoh ini hanya ilustrasi; setiap bisnis perlu menentukan proses dan data ujinya sendiri.

Tanyakan bagaimana vendor menentukan prioritas skenario: berdasarkan frekuensi penggunaan, dampak kesalahan, kebutuhan peran tertentu, atau kriteria lain yang disepakati. Skenario harus cukup spesifik untuk diuji, tetapi tidak perlu memuat data pribadi atau rahasia saat tahap evaluasi penawaran. Gunakan data contoh yang aman.

2. Minta kriteria lulus yang bisa diamati

Kriteria seperti “mudah digunakan” atau “berjalan dengan baik” terlalu umum jika berdiri sendiri. Mintalah contoh hasil yang dapat diperiksa: setelah pengguna mengirim formulir dengan isian yang ditentukan, sistem menampilkan status yang disepakati; atau laporan menunjukkan rekaman sesuai filter yang dipilih. Kriteria konkret membantu pihak terkait membedakan hasil yang sesuai dari temuan yang perlu dibahas.

Materi Atlassian mengenai acceptance criteria membahas kriteria sebagai kondisi yang harus dipenuhi agar pekerjaan dapat diterima. Dalam proyek nyata, rumuskan kondisi bersama vendor dan pemilik proses, lalu sesuaikan dengan ruang lingkup, risiko, dan kesepakatan proyek. Hindari menyalin contoh generik tanpa memastikan artinya bagi operasi Anda.

3. Pastikan peran dan jadwal pengujian realistis

Rencana perlu menyebut siapa yang menyiapkan skenario, siapa yang menjalankan uji, siapa yang mencatat temuan, dan siapa yang berwenang menyetujui hasil. Di sisi klien, tentukan perwakilan yang memahami pekerjaan sehari-hari dan memiliki waktu untuk mencoba alur yang relevan. Di sisi vendor, tanyakan siapa yang membantu menyiapkan lingkungan dan menjelaskan cara melaporkan masalah.

Jadwal UAT juga perlu memperhitungkan ketersediaan pengguna, kesiapan data uji, serta waktu untuk meninjau dan mengulang skenario setelah perbaikan. Jangan menyamakan waktu respons vendor dengan waktu sampai semua temuan selesai; keduanya adalah hal berbeda dan perlu dijelaskan sesuai kesepakatan.

4. Tinjau bentuk bukti dan pencatatan hasil

Tanyakan bentuk catatan yang akan tersedia setelah pengujian. Misalnya, daftar skenario, status lulus/gagal/belum diuji, catatan kondisi, dan bukti yang disepakati seperti tangkapan layar dari data uji. Bukti harus cukup untuk membantu tim memahami hasil, tetapi jangan memasukkan kredensial, informasi pribadi, atau data bisnis sensitif secara tidak perlu.

Samakan pula istilah status. “Belum diuji” tidak sama dengan “gagal”; “gagal” tidak selalu menjelaskan penyebab; dan temuan yang tidak menghalangi proses utama mungkin perlu diprioritaskan berbeda dari kegagalan alur inti. Mintalah kandidat menjelaskan cara membahas tingkat dampak tanpa mengasumsikan semua vendor memakai klasifikasi yang sama.

Contoh membandingkan rencana UAT untuk satu alur

Misalkan sistem harus mencatat permintaan layanan sampai menjadi laporan untuk supervisor. Tabel berikut adalah contoh kerangka diskusi, bukan spesifikasi wajib:

Ketika membandingkan beberapa penawaran, nilai apakah tiap kandidat membahas unsur serupa. Jika suatu hal belum termasuk, catat sebagai pertanyaan terbuka—jangan langsung menganggapnya termasuk atau tidak termasuk tanpa konfirmasi tertulis.

Sepakati cara menangani temuan dan penerimaan bersyarat

Sebelum UAT dimulai, bahas bagaimana temuan akan direkam, siapa yang menilai dampaknya, bagaimana keputusan perbaikan atau perubahan ruang lingkup dibuat, dan bagaimana pengujian ulang dilakukan. Bedakan cacat yang bertentangan dengan kriteria yang disepakati dari permintaan baru yang muncul setelah skenario dirumuskan. Penentuan tanggung jawab dan konsekuensi kontraktual perlu mengikuti kesepakatan proyek, bukan asumsi dari artikel ini.

Dalam beberapa proyek, pemilik proses mungkin mempertimbangkan penerimaan dengan catatan untuk temuan tertentu. Jika opsi ini relevan, pastikan kondisi, batas, tindak lanjut, dan pihak yang menyetujui dicatat dengan jelas. Jangan menafsirkan penerimaan bersyarat sebagai pengganti kesepakatan kontrak atau sebagai rekomendasi hukum.

Checklist pertanyaan sebelum memilih vendor sistem custom

• Alur bisnis mana yang akan menjadi skenario UAT, dan bagaimana prioritasnya ditentukan?
• Siapa dari pihak vendor dan klien yang menyiapkan, menjalankan, serta menyetujui pengujian?
• Apakah kriteria lulus dapat diamati dan ditautkan ke kebutuhan yang telah disepakati?
• Lingkungan dan data seperti apa yang dipakai, serta bagaimana informasi sensitif dilindungi?
• Bagaimana hasil dicatat, temuan diprioritaskan, dan pengujian ulang dilakukan?
• Bagaimana permintaan baru dibedakan dari temuan terhadap ruang lingkup yang disepakati?
• Dokumen apa yang akan diterima dan siapa yang menyetujui hasil akhir?

Gunakan jawaban vendor bersama faktor lain seperti pemahaman kebutuhan, ruang lingkup, komunikasi, dukungan, dan kesesuaian anggaran. Rencana UAT yang rinci tidak dengan sendirinya membuktikan vendor paling tepat, tetapi dapat menunjukkan apakah proses penerimaan hasil dibahas secara terbuka.

Pertanyaan umum tentang UAT saat memilih vendor

Apakah UAT sama dengan pengujian QA?

Tidak selalu. QA umumnya mencakup pemeriksaan yang dilakukan tim pengembang atau penguji, sedangkan UAT berfokus pada penilaian pengguna atau pemilik proses terhadap kesesuaian kebutuhan bisnis. Pembagian tepatnya bergantung pada proyek dan perlu disepakati.

Siapa yang sebaiknya mengikuti UAT?

Libatkan perwakilan yang memahami alur kerja yang diuji dan pihak yang berwenang menilai hasil. Untuk proses lintas fungsi, mungkin diperlukan lebih dari satu perwakilan. Tentukan peserta berdasarkan proses dan ruang lingkup, bukan sekadar jabatan.

Apakah semua temuan harus diselesaikan sebelum penerimaan?

Jawabannya bergantung pada kriteria, tingkat dampak, ruang lingkup, dan perjanjian proyek. Bahas cara klasifikasi dan keputusan sebelum pengujian, serta dokumentasikan kesepakatan yang berlaku.

Bagaimana bila kebutuhan berubah saat UAT?

Catat perubahan sebagai pembahasan terpisah dari hasil uji terhadap kebutuhan yang telah disepakati. Minta vendor menjelaskan dampaknya pada ruang lingkup, jadwal, dan keputusan penerimaan sebelum perubahan dilakukan.

Langkah berikutnya

Jika Anda sedang menyiapkan kebutuhan sistem baru, gunakan panduan checklist kebutuhan sistem informasi sebelum meminta penawaran untuk merapikan konteks dan pertanyaan awal. Untuk memahami pilihan solusi yang disesuaikan dengan proses organisasi, baca juga penjelasan tentang sistem informasi custom.

Untuk membahas kebutuhan dan ruang lingkup proyek, pelajari layanan jasa pembuatan website dan sistem Sahabat Sistem. Kesesuaian layanan dan rincian pengujian perlu dikonfirmasi berdasarkan kebutuhan proyek Anda.

Ingin mendiskusikan kebutuhan sistem bisnis Anda? Hubungi Sahabat Sistem untuk membahas kebutuhan proyek.

Referensi umum: Atlassian — User Acceptance Testing dan Atlassian — Acceptance Criteria. Keduanya membantu menjelaskan konsep, bukan pengganti kesepakatan ruang lingkup atau kontrak proyek.

Kredit gambar: Yan Krukau — sumber gambar — Pexels License
Deskripsi gambar: Tim kerja meninjau dokumen dan catatan bersama di meja rapat dengan laptop
Relevansi: Ilustrasi kolaborasi dan peninjauan dokumen yang relevan dengan proses menyusun serta mengevaluasi rencana UAT, tanpa mengklaim isi dokumen sebagai bukti pengujian tertentu.