Smoke Test dan UAT dari Acceptance Criteria: Cara Membuktikan Aplikasi Buatan AI Benar-Benar Siap Dicoba

Aplikasi buatan AI sering terlihat selesai lebih cepat daripada benar-benar siap dipakai. Tombol ada, dashboard cantik, dan data contoh muncul. Tetapi ketika pemilik mencoba alur nyata—mendaftar, membuat transaksi, membayar, lalu membuka laporan—sering muncul pertanyaan yang tidak pernah diuji: status tidak berubah, angka salah, hak akses bocor, atau data hilang saat halaman dimuat ulang.

Smoke test dan UAT memberi cara yang sederhana untuk membedakan “tampil” dari “berfungsi”. Smoke test memeriksa jalur inti secara cepat setelah build atau deploy. User acceptance testing, atau UAT, memeriksa apakah perilaku aplikasi benar-benar memenuhi kebutuhan pengguna. Di Skematik, acceptance criteria dan edge case menjadi bahan untuk merencanakan pengujian, sehingga test tidak hanya bergantung pada ingatan setelah kode sudah banyak berubah.

Mulai dari alur pengguna yang paling penting

Pilih tiga sampai lima perjalanan ujung-ke-ujung yang menentukan nilai aplikasi. Untuk kasir: masuk, pilih produk, buat transaksi, pembayaran tercatat, stok berkurang, dan laporan menampilkan angka baru. Untuk booking: pilih jadwal, sistem menolak slot bentrok, konfirmasi tersimpan, lalu pelanggan atau admin dapat melihat statusnya. Jangan mulai dari semua fitur kecil; mulai dari perjalanan yang jika gagal membuat aplikasi tidak berguna.

Tulis setiap langkah dengan data konkret yang dapat diketik orang lain. “Buat satu pesanan” terlalu kabur. Lebih baik: “buat pesanan dua item dengan jumlah 2 dan 1; total yang terlihat harus sama dengan harga item dikali jumlah; setelah simpan, stok dua item berkurang sesuai jumlah.” Data yang nyata membuat hasil lebih mudah diperiksa dan bug lebih mudah direproduksi.

Turunkan langkah uji dari acceptance criteria

• Kriteria “nama wajib diisi” menjadi uji submit form kosong dan cek pesan error.
• Kriteria “nomor invoice unik” menjadi uji dua transaksi dengan nomor sama dan cek penolakan.
• Kriteria “kasir hanya melihat cabangnya” menjadi uji login dengan dua peran atau cabang berbeda.
• Kriteria “stok tidak boleh minus” menjadi uji transaksi melebihi stok yang tersedia.
• Kriteria “laporan menampilkan transaksi baru” menjadi uji dari input sampai hasil agregat muncul.

Dengan pola ini, UAT tidak perlu diciptakan dari nol. Ia mengikuti janji yang sudah Anda tulis ketika menyusun fitur. Jika Anda kesulitan membuat langkah uji dari sebuah kriteria, biasanya kriteria itu masih terlalu abstrak dan perlu diperjelas sebelum agent menulis lebih banyak kode.

Kriteria yang bisa diuji adalah jembatan antara bahasa bisnis dan bukti teknis. Tanpa jembatan itu, “sudah selesai” hanya berarti “kelihatannya jalan di komputer saya.”

Jangan lupa jalur gagal dan kasus tepi

Jalur normal penting, tetapi aplikasi paling sering mengecewakan ketika kondisi tidak ideal: koneksi putus, dua orang mengirim data hampir bersamaan, pembayaran gagal, pengguna tidak punya izin, atau input kosong. Pilih satu sampai tiga edge case paling berisiko untuk setiap fitur inti. Tidak semua kemungkinan harus diuji di awal, tetapi risiko yang dapat merusak data, uang, atau kepercayaan pengguna harus terlihat.

Catat hasil aktual saat UAT. Jika gagal, jangan hanya menulis “error”. Simpan langkah, data uji, hasil yang terlihat, dan perilaku yang diharapkan. Catatan itu dapat menjadi prompt bugfix yang lebih kuat untuk agent, sekaligus memperbaiki acceptance criteria bila aturan produk ternyata belum jelas.

Bedakan smoke test, test otomatis, dan UAT

Test otomatis memeriksa aturan atau fungsi secara berulang lewat kode. Smoke test adalah pemeriksaan cepat bahwa aplikasi hidup dan jalur inti tidak langsung patah. UAT adalah penerimaan oleh pemilik atau pengguna yang memahami apakah aplikasi memecahkan masalah mereka. Ketiganya saling mengisi. Test otomatis menangkap regresi cepat, smoke test menjaga rilis tidak buta, dan UAT memastikan tim tidak membangun hal yang teknisnya benar tetapi secara bisnis salah.

Jangan menunggu semua fitur selesai untuk UAT pertama. Uji milestone pertama yang sudah bisa dipakai ujung-ke-ujung. Masukan lebih awal dapat mengubah arah dengan biaya kecil, sementara UAT di akhir proyek sering menemukan masalah ketika banyak task sudah bergantung pada keputusan lama.

Checklist sebelum membagikan aplikasi

1. Jalankan smoke test untuk alur inti dengan data uji nyata.
2. Uji minimal satu kasus gagal atau edge case pada setiap fitur berisiko.
3. Pastikan hasil sesuai acceptance criteria, bukan hanya tidak ada error di layar.
4. Catat bug dengan reproduksi dan perilaku target sebelum mengirim ke agent.
5. Minta pemilik produk mencoba aplikasi tanpa didampingi pembuatnya dan catat titik kebingungan.