Cara Menulis Laporan Bug yang Baik (untuk AI atau Developer)

Laporan bug yang baik memungkinkan orang lain, baik developer maupun AI, melihat masalah yang sama dengan yang Anda lihat, tanpa perlu bertanya apa pun kepada Anda. Laporan itu membutuhkan judul yang spesifik, langkah yang tepat untuk mereproduksi masalah, apa yang Anda harapkan, apa yang sebenarnya terjadi, pesan error yang disalin kata demi kata, dan di mana kejadiannya: halaman, browser, perangkat, dan pengguna mana. Satu bug per laporan, dengan tangkapan layar jika membantu.

Kebanyakan bug lebih lama dipahami daripada diperbaiki. Laporan yang jelas menghilangkan bagian memahami itu. Ini lebih penting lagi dengan alat AI: AI tidak bisa mengajukan pertanyaan lanjutan tentang maksud Anda dengan "checkout-nya aneh", sehingga ia menebak, dan tebakan yang salah bisa merusak hal lain.

Templat

Salin dan isi:

Judul: [Apa yang salah, di mana] — misalnya "Formulir pemesanan menolak jam setelah pukul 18.00"

Langkah untuk mereproduksi:
1. ...
2. ...
3. ...

Diharapkan: [apa yang seharusnya terjadi]
Yang terjadi: [apa yang terjadi sebagai gantinya]

Pesan error: [teks persis, jika ada]
Di mana: [halaman/URL, browser, perangkat, login sebagai pengguna mana]
Seberapa sering: [setiap kali / kadang-kadang / sekali]
Tangkapan layar atau rekaman: [terlampir]

Sisa panduan ini menjelaskan setiap bagiannya.

Langkah 1: Reproduksi terlebih dahulu

Sebelum menulis, coba buat bug itu terjadi lagi. Anda akan belajar langkah mana yang penting, dan apakah bug itu terjadi setiap kali.

• Mulai dari keadaan bersih: refresh, atau keluar lalu masuk lagi.
• Catat setiap klik dan setiap yang Anda ketik.
• Coba temukan jalur yang paling singkat untuk memicunya.
• Coba browser atau akun kedua. Jika hanya terjadi pada satu pengguna, itu petunjuk besar.

Untuk lebih lanjut tentang ini, lihat cara men-debug aplikasi buatan AI.

Langkah 2: Tulis judul yang spesifik

Judul harus menyebutkan apa yang salah dan di mana, sehingga orang yang memindai daftar tahu bug mana itu.

Langkah 3: Daftar langkah yang tepat

Beri nomor. Bersikaplah harfiah: halaman mana, tombol mana, apa yang Anda ketik.

1. Masuk sebagai pelanggan (akun uji: customer@example.com).
2. Tambahkan "Starter kit" ke keranjang.
3. Masukkan kode diskon WELCOME10 dan klik Terapkan.
4. Klik Checkout.

"Coba checkout dengan kode" menghilangkan detail yang sering penting: pengguna mana, produk apa, kode apa, dan apakah kode diterapkan dulu.

Langkah 4: Diharapkan vs yang terjadi

Ini inti laporan. Sebutkan keduanya, karena perbedaannya adalah bugnya.

• Diharapkan: halaman checkout terbuka dengan diskon 10% yang ditampilkan dalam total.
• Yang terjadi: tombol menampilkan spinner selama sedetik, lalu tidak terjadi apa-apa. Tanpa kode diskon, checkout berfungsi.

Tanpa "diharapkan", pembaca mungkin tidak tahu bahwa perilakunya salah. Tanpa "yang terjadi", mereka tidak tahu apa yang harus dicari.

Langkah 5: Salin error dengan persis

Pesan error adalah jalur tercepat ke penyebabnya. Salin sebagai teks, kata demi kata, jangan diparafrasekan.

Tempat menemukannya:

• Di layar: pesan apa pun yang ditampilkan aplikasi.
• Konsol browser: buka developer tools (F12, atau klik kanan → Inspect) dan lihat tab Console untuk baris merah.
• Tab Network: di developer tools, temukan permintaan yang gagal dan catat URL serta kode statusnya (misalnya POST /api/checkout → 500).
• Log server, jika Anda punya akses.

Baris seperti TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48 sering langsung menunjuk ke masalahnya.

Langkah 6: Tambahkan konteks

• Di mana: URL halaman, lingkungan (preview, staging, atau live).
• Siapa: pengguna atau peran mana: admin, anggota, belum login.
• Perangkat dan browser: "Safari di iPhone" dan "Chrome di Windows" bisa berbeda hasilnya.
• Data: apa pun yang tidak biasa tentang catatannya, seperti teks yang sangat panjang, karakter khusus, atau jumlah item yang besar.
• Kapan mulai: "setelah perubahan kemarin pada kode diskon" sangat berharga.
• Seberapa sering: setiap kali, atau sekali dari sepuluh percobaan.

Langkah 7: Tunjukkan

Tangkapan layar dengan masalah yang dilingkari, atau rekaman layar singkat, menghilangkan ambiguitas, terutama untuk bug tata letak. Jika alat AI Anda menerima gambar, lampirkan satu. Potong apa pun yang bersifat pribadi, termasuk key dan data orang lain.

Menulis laporan bug untuk AI builder

Struktur yang sama bisa dipakai sebagai prompt. Dua tambahan membantu:

• Sebutkan apa yang tidak boleh berubah, supaya perbaikan tidak menimbulkan masalah baru.
• Minta AI memverifikasi perbaikannya, bukan hanya menulisnya.

Masuk sebagai pelanggan, dengan "Starter kit" di keranjang dan kode WELCOME10 sudah diterapkan, klik Checkout tidak melakukan apa-apa. Diharapkan: halaman checkout terbuka dengan diskon 10% dari total. Yang terjadi: spinner sebentar, lalu tidak ada apa-apa. Tab network menunjukkan POST /api/checkout mengembalikan 500. Checkout tanpa kode berfungsi. Temukan penyebabnya dan perbaiki tanpa mengubah cara harga dihitung untuk pesanan tanpa kode. Lalu periksa checkout dengan kode persentase, kode nominal tetap, dan tanpa kode.

Jika Anda tidak yakin penyebabnya, minta diagnosis dulu:

Jangan ubah kode dulu. Berdasarkan laporan ini, apa saja kemungkinan penyebabnya, dan apa yang akan mengonfirmasi masing-masing?

Kesalahan umum

• "Ini rusak." Tanpa langkah, tanpa hasil yang diharapkan, tidak ada yang bisa ditindaklanjuti.
• Beberapa bug dalam satu laporan. Ada yang diperbaiki, yang lain hilang.
• Error yang diparafrasekan. "Sesuatu undefined" menyembunyikan bagian yang berguna.
• Lupa menyebutkan pengguna atau peran. Banyak bug hanya memengaruhi admin, atau hanya pengguna baru.
• Hanya menjelaskan perbaikan yang Anda inginkan ("tambahkan pengecekan null") alih-alih masalahnya.
• Membagikan rahasia di tangkapan layar atau log yang ditempel.

Daftar periksa

• Saya mereproduksi bug dan menemukan langkah yang paling singkat.
• Judulnya menyebutkan apa yang salah dan di mana.
• Langkah diberi nomor dan harfiah.
• Yang diharapkan dan yang terjadi keduanya dinyatakan.
• Pesan error disalin persis, dengan permintaan gagal dan kode status jika ada.
• Halaman, lingkungan, pengguna, perangkat, dan browser disertakan.
• Saya menyebutkan seberapa sering terjadinya dan kapan mulai.
• Tangkapan layar atau rekaman dilampirkan, dengan data pribadi dihapus.
• Satu bug per laporan.

Melaporkan bug ke agen Mythex

Di proyek Mythex, laporan itu sendiri adalah prompt. Beberapa fitur membantu:

• Lampirkan tangkapan layar dari preview atau layar error, hingga 5 file per pesan.
• /fix memfokuskan agen untuk memperbaiki bug; mode Plan membiarkannya menyelidiki sebelum mengedit.
• /test meminta agen mereproduksi alur di preview itu sendiri dan melaporkan apa yang dilihatnya.
• Kembali ke titik ini membatalkan perbaikan yang membuat keadaan lebih buruk.

Halaman men-debug dengan prompt di dokumentasi menggunakan struktur langkah / diharapkan / yang terjadi yang sama. Untuk siklus perbaikan dan pemeriksaan di sekitarnya, lihat cara beriterasi pada aplikasi buatan AI.

Pertanyaan