Cara menguji aplikasi buatan AI-mu ketika kamu belum pernah menguji software sebelumnya
Panduan praktis untuk menguji aplikasi buatan AI ketika kamu tidak punya background QA. Di mana harus mengklik, apa yang harus dirusak dengan sengaja, dan cara tahu kapan ia sudah cukup baik untuk dibagikan.
Kamu membangun aplikasi dengan AI. Ia berfungsi di happy path — kamu mengetik namamu, mengklik tombol, melihat layar sukses. Sekarang apa? Apakah ia siap dikirim ke tiga pengguna beta-mu? Timmu? Pelangganmu?
Kalau kamu tidak punya background software, pengujian terasa seperti salah satu hal yang dilakukan “developer sungguhan” — dengan framework dan assertion dan CI pipeline. Kabar baiknya: bukan itu pengujian sebenarnya bagi sebagian besar orang. Sebagian besar pengujian, terutama saat kamu merilis sesuatu yang kecil dan baru, adalah satu orang mengklik-klik dengan niat. Kamu bisa melakukan itu. Postingan ini tentang melakukannya secara sengaja, supaya kamu menemukan bug-nya sebelum penggunamu menemukannya.
Tujuannya bukan menguji aplikasi buatan AI-mu seperti seorang profesional. Tujuannya adalah mengujinya seperti seorang teman paranoid yang benar-benar ingin ia berfungsi.
Trik dua-daftar
Sebelum kamu mengklik apa pun, duduklah sepuluh menit dengan dokumen kosong dan tulis dua daftar.
Daftar A — happy path. Apa tiga atau empat hal yang seharusnya dilakukan pengguna dengan aplikasi ini? Untuk SaaS pada umumnya, itu mungkin: daftar, membuat proyek pertama, mengundang satu rekan tim, mengekspor sebuah hasil. Untuk aplikasi gaya direktori: cari, filter, klik sebuah listing, simpan. Tiga atau empat alur nyata, dalam bahasa sederhana.
Daftar B — unhappy path. Bagaimana kalau pengguna melakukan sesuatu yang hampir benar tapi tidak persis? Mengetik email mereka dengan salah ketik. Menekan tombol back di tengah alur. Membuka dua tab dan mengedit hal yang sama di keduanya. Mengirim formulir kosong. Menempelkan isi dokumen Word — beserta formatnya — ke dalam kolom teks. Menutup laptop dan membukanya kembali sepuluh menit kemudian. Mencoba mengundang rekan tim memakai alamat email yang sudah ada di sistem.
Daftar happy path adalah apa yang dioptimalkan oleh AI app builder-mu. Itulah yang secara mental diuji oleh AI saat menulis kodenya. Daftar unhappy path adalah tempat bug bersembunyi, karena hampir tak seorang pun — bukan AI-nya, bukan kamu saat kamu mem-prompt — yang memikirkan kasus-kasus itu.
Saat kamu benar-benar menguji, jalani Daftar A dulu untuk memastikan hal dasarnya berfungsi. Lalu habiskan sebagian besar waktumu di Daftar B. Daftar B-lah tempat nilainya berada. Daftar B juga tempat kamu menemukan apa yang sebenarnya kamu inginkan dari aplikasi ketika segala sesuatu menyimpang, yang sering memaksa sebuah obrolan klarifikasi dengan AI builder (“ketika formulir terisi separuh, haruskah ia memperingatkan atau menyimpan otomatis?”).
Tiga hal untuk dirusak dengan sengaja
Begitu kamu punya daftarmu, berikut tiga kategori yang menangkap mayoritas bug nyata di aplikasi buatan AI.
Input kosong dan aneh. Kirim formulir tanpa terisi apa pun. Kirim dengan satu kolom terisi. Kirim nama yang panjangnya 500 karakter. Kirim nama dengan emoji. Tempelkan URL ke kolom yang mengharapkan sebuah nama. Coba kolom email dengan “test”, dengan “test@”, dengan “test@example”, dengan alamat “a@b.co” — apakah ia menerima email pendek yang sah? AI app builder sering menambahkan validasi, tapi validasinya bisa salah ke arah mana pun — terlalu ketat (menolak pengguna asli) atau terlalu longgar (menerima sampah).
Bergerak mundur dan menyamping. Sebagian besar aplikasi bekerja baik kalau kamu menjalaninya seperti rombongan tur yang patuh. Mereka rusak begitu seseorang menjelajah. Klik tombol back. Klik forward lagi. Refresh halaman di tengah alur. Buka halaman yang sama di dua tab dan edit di keduanya. Logout dan login lagi. Kalau kamu punya tombol “undo”, klik tiga kali berturut-turut. Ini bukan kasus pinggiran. Ini cara orang sungguhan memakai software.
Datanya setelahnya. Bangun hal yang dibangun aplikasimu. Sebuah proyek, sebuah postingan, sebuah record, apa pun itu. Lalu kembalilah besok. Apakah ia masih ada? Apakah formatnya bertahan? Kalau kamu mengeditnya, apakah editnya tersimpan? Kalau kamu menghapusnya, apakah ia benar-benar lenyap, atau muncul lagi saat kamu refresh? AI app builder sering pas di alur “create” dan lupa bahwa semua yang kamu buat perlu bertahan dan bisa diedit kemudian.
Seperti apa “cukup baik” itu
Kamu tidak akan pernah menguji aplikasi buatan AI-mu hingga sempurna. Software terlalu ruwet dan waktumu terlalu berharga. Pertanyaannya bukan “apakah ia sempurna” — melainkan “apakah ia cukup baik untuk kelompok orang berikutnya yang akan kuhadapkan padanya.”
Berikut hierarki kasar yang bisa kamu pinjam.
Cukup baik untuk demo: happy path berfungsi tanpa crash. Tombol pergi ke tempat yang seharusnya. Kamu bisa menampilkan rekaman layar tanpa memotong apa pun.
Cukup baik untuk pengguna yang ramah: unhappy path tidak menghilangkan data. Formulir memberi tahu apa yang salah alih-alih gagal diam-diam. Refresh halaman tidak merusak hal-hal. Tiga teman bisa memakainya tanpa mengirim pesan minta bantuan.
Cukup baik untuk pengguna yang membayar: aplikasi menangani pengguna yang belum pernah kamu temui. Browser mereka, data mereka, kebiasaan mereka. Kamu punya cara untuk melihat ketika ada yang rusak (error tracking dasar sudah cukup — kamu tidak butuh dashboard mewah). Kamu bisa memperbaiki dan men-deploy ulang tanpa merusak orang-orang yang sudah memakainya.
Sebagian besar builder merilis di tingkat “pengguna ramah” lalu meningkatkannya seiring feedback masuk. Itu benar. Kesalahannya adalah mencoba melompat dari “cukup baik untuk demo” langsung ke “cukup baik untuk pengguna yang membayar” tanpa langkah perantara. Pengguna yang ramah menemukan hal-hal yang akan ditemukan pengguna sungguhan — tapi mereka tidak marah karenanya. Manfaatkan jeda itu.
Kapan meminta AI menguji untukmu
AI app builder-mu bisa membantu pengujian, tapi kamu harus spesifik soal apa yang kamu inginkan. “Tambahkan tes” adalah prompt yang buruk. Ia akan menghasilkan kode yang tampak seperti tes dan mungkin lolos, tanpa benar-benar memeriksa apa pun yang kamu pedulikan. Sebagian besar tes yang dibuat otomatis itu memastikan bahwa 1+1 masih 2.
Prompt yang lebih baik: “Aku baru saja mencoba mengirim formulir signup dengan kolom email kosong dan ia crash. Temukan di mana itu ditangani dan tambahkan pemeriksaan yang menampilkan error ramah alih-alih crash.” Bug spesifik, perbaikan spesifik, hasil spesifik. AI pandai dalam hal ini. Ia buruk dalam “pastikan aplikasiku bebas bug” karena itu bukan tugas — itu sebuah harapan.
Hal lain yang dikuasai AI builder adalah memutar ulang bug-mu. Kalau kamu menjelaskan apa yang kamu lakukan, apa yang kamu harapkan, dan apa yang terjadi, builder biasanya bisa menelusuri kodenya dan mengusulkan perbaikan. Disiplin yang kamu butuhkan adalah disiplin menuliskan tiga hal itu dengan jelas. Sebagian besar laporan bug pemula adalah versi dari “ini nggak jalan.” Sebagian besar laporan bug yang bisa diperbaiki adalah “aku klik X, mengharapkan Y, dapat Z.”
Pengujian itu membaca, bukan cuma mengklik
Satu hal terakhir. Kamu tidak harus memahami setiap baris kode di aplikasi buatan AI-mu untuk mengujinya dengan baik. Tapi kamu setidaknya harus membacanya sekilas. Buka file yang baru saja diubah AI. Baca fungsi yang ia tambahkan. Kamu tidak perlu tahu arti setiap keyword — kamu perlu tahu apakah fungsi itu tampaknya melakukan apa yang kamu minta.
Banyak bug buatan AI bukanlah “kodenya rusak.” Melainkan “kodenya melakukan sesuatu yang sedikit berbeda dari yang kamu inginkan.” Sebuah kolom tersimpan ke tempat yang salah. Sebuah tombol memperbarui satu hal tapi bukan hal yang terkait. Sebuah tombol “hapus” menyembunyikan alih-alih menghapus. Kamu tidak bisa menangkap itu tanpa membaca apa yang sebenarnya dibangun.
Perlakukan kode sebagai sesuatu yang bisa kamu audit, bukan sesuatu yang harus kamu tulis. Itulah perbedaan antara aplikasi buatan AI yang kamu percayai dan yang cuma kamu harapkan berfungsi.
Versi sederhananya
Kalau kamu tidak mengingat apa pun yang lain: tulis dua daftar itu, rusak hal-hal dengan sengaja, dan putuskan di tingkat “cukup baik” yang mana kamu merilis. Sebagian besar bug di aplikasi buatan AI tidak halus. Mereka duduk di daftar unhappy path yang tak ada yang repot-repot menuliskannya.
Kalau kamu mau PR kecil: pilih satu aplikasi yang sudah kamu bangun dan coba empat hal — kirim formulir kosong, tekan refresh di tengah alur, edit sebuah record dan periksa besok, dan minta seorang teman memakainya tanpa kamu mengawasi. Apa pun yang rusak adalah daftar bug nyatamu. Sisanya hanyalah menunda-nunda.