Membuat pengguna menulis laporan bug yang layak dan berguna

Adakah yang tahu cara yang baik untuk membuat pengguna menulis laporan bug yang semestinya (baca: berguna ) ?

Kami ingin memasang sesuatu yang masuk akal bagi sebagian besar pengguna (mudah dibaca dan dipahami), namun juga memberikan informasi yang bermanfaat bagi pengembang.

Tidak berfungsi ketika saya mengklik tombol biru! Ahhh, aku baru saja kehilangan pekerjaan seminggu ... membuatnya bekerja.

tidak begitu berguna, seperti itu.

Saya mulai memperbaiki daftar, tetapi berpikir untuk memeriksa dengan kalian, apakah metode yang sama sudah ada.

Cara paling efektif untuk membuat pengguna menulis laporan bug yang layak dan berguna adalah

1. untuk membiarkan mereka melihat laporan mereka secara online ...
   ^{[Sistem] Terima kasih telah melaporkan, Anda dapat menemukan status permintaan Anda di sini: ...}
2. ... beserta evaluasi dan komentar dari insinyur yang ditugaskan ...
   ^{[Insinyur] Permintaan ditolak, karena detail berikut tidak ada: ...}
3. ... dengan opsi untuk mengedit / meningkatkan laporan mereka.
   ^{[Pengguna] Detail yang diminta ditambahkan, harap evaluasi ulang: ...}

Saya akan mengklaim bahwa itu satu - satunya cara yang efektif.

Mari kita hadapi itu, keterampilan untuk menulis laporan bug secara efektif datang hanya dengan pengalaman. Seseorang perlu belajar untuk mendapatkan pengalaman. Belajar melibatkan berlatih, mendapatkan umpan balik, dan meningkatkan.

Laporan bug daring yang dapat diedit pengguna adalah cara paling efisien untuk mengajarkan peningkatan pada pengguna .

• ^{Pilihan alternatif di atas adalah 1) untuk mengatur sesi pembelajaran tatap muka dengan pengguna (ya tentu, terutama ketika ada ribuan dari mereka yang tersebar di seluruh dunia). Atau 2) jelaskan hal-hal itu melalui telepon ("lihat, jika Anda hanya dapat melihat omong kosong yang Anda tulis di baris 225 ..."). Apa lagi? Oh 3) melalui email, tentu saja "dalam surat yang Anda kirimkan kepada kami dua bulan lalu, Anda menyebutkan ... tidak bukan itu email, Anda mengirimi kami lima email hari ini, tiga dari mereka dengan subjek Re: klik tombol biru , lihat yang kedua, yang dengan tangkapan layar 10 MB melekat padanya ... apa? Anda tidak dapat menemukannya? "}

Menurut pendapat saya, yang lebih penting adalah menggunakan bug untuk membangun hubungan yang berarti dengan pengguna. Menulis dan memahami laporan bug adalah keterampilan, dan saran saya adalah membuatnya semudah mungkin bagi pengguna untuk melakukan kontak pertama, kemudian secara progresif membuat umpan balik mereka dengan nilai lebih sesuai kebutuhan.

Misalnya, dapatkan saja email pengguna, dan beri mereka bidang teks biasa dengan teks berikut untuk diisi:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Setelah Anda menerima email, lakukan balas otomatis untuk mendapatkan dua pilihan untuk mengonfirmasi mereka mengirimkan bug, Anda telah menerimanya, dan menindaklanjuti bug tidak apa-apa.

Anda mungkin mempertimbangkan untuk mengambil beberapa ide dari Mozilla dan Sun pada topik ini:

• Pedoman penulisan bug - artikel Mozilla MDN
• Cara Menulis Bug yang Tepat - artikel Mozilla QMO
• Cara Menulis Laporan Bug yang Bermanfaat - artikel Sun SDN

Khususnya (dari halaman Mozilla "Cara Menulis Bug yang Tepat"):

Garis Besar Umum Laporan Bug

Ringkasan : Bagaimana Anda menggambarkan bug dalam kurang dari 60 karakter? Seharusnya dengan cepat dan unik mengidentifikasi laporan bug serta menjelaskan masalahnya, bukan solusi yang Anda sarankan.

Bagus : “Membatalkan dialog Salinan File akan membuat crash Pengelola File”

Buruk : “Perangkat lunak rusak”

Buruk : "Peramban harus bekerja dengan situs web saya"

Komponen : Di mana sub-bagian dari perangkat lunak itu ada? Bidang ini adalah persyaratan untuk mengirimkan laporan bug. Klik kata "Komponen" untuk melihat deskripsi setiap komponen. Jika tidak ada yang sesuai, sorot komponen "Umum".

OS : Di sistem operasi (OS) mana Anda menemukannya? (mis. Linux, Windows XP, Mac OS X.) Contoh: "Jika Anda tahu bug terjadi pada lebih dari satu jenis sistem operasi, pilih" Semua ". Jika OS Anda tidak terdaftar, pilih Lainnya ”.

Deskripsi : Detail laporan masalah Anda, termasuk:

- Tinjauan umum : Ini adalah pernyataan ulang detail yang lebih besar. Contohnya adalah: “Menyeret-pilih sembarang halaman macet yang dibuat Mac dalam fungsi NSGetFactory”.

- Bangun Id : Untuk menemukan ini buka halaman "about:" melalui bilah lokasi atau, jika Anda memiliki ekstensi Alat Penguji Malam Hari MozQA, kemudian buka Alat | Nightly Tester Tools dan pilih opsi yang berisi output dari build id. Seharusnya terlihat seperti ini: "Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3 ″.

- Bangun dan Platform Tambahan : Apakah bug terjadi pada platform lain (atau browser, jika ada). Seharusnya terlihat seperti ini: "Tidak Terjadi Pada Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Langkah-langkah untuk Direproduksi : Diminimalkan, langkah mudah diikuti yang akan memicu bug. Jika perlu, pastikan untuk memasukkan langkah-langkah pengaturan khusus. Contoh yang baik dari ini akan terlihat seperti berikut: 1) Lihat halaman web apa pun. (Saya menggunakan halaman contoh default, http://www.google.com/ ). 2) Seret-pilih halaman. Secara khusus, sambil menahan tombol mouse, seret penunjuk mouse ke bawah dari titik mana pun di wilayah konten browser ke bagian bawah wilayah konten browser.

Hasil Aktual : Apa yang dilakukan aplikasi setelah melakukan langkah-langkah di atas. Contohnya adalah: Aplikasi macet.

Hasil yang Diharapkan : Apa yang seharusnya dilakukan oleh aplikasi, jika bug tidak ada. Contohnya adalah: Jendela akan bergulir ke bawah. Konten yang digulir harus dipilih. Atau, setidaknya, aplikasi seharusnya tidak macet.

Ada Cara Melaporkan Bug secara Efektif oleh Simon Tatham. Itu menjelaskan hal-hal dengan baik, untuk membuatnya mudah dimengerti bagi pengguna yang kurang berpengalaman. Namun kekurangannya adalah sedikit teks. Ketika Anda memiliki pengguna yang mencoba melaporkan masalah tetapi gagal menjelaskannya, Anda biasanya tidak dapat meyakinkannya untuk membaca semua ini.

Anda dapat mengajukan pertanyaan yang mudah dimengerti dan mudah menjawab pertanyaan kepada pengguna untuk mengharapkan laporan yang bermanfaat.

Misalnya, "Apa tindakan terakhir Anda sebelum kesalahan ini?", "Apakah Anda mencoba ... tepat sebelum kesalahan ini?".

Tidak ada pengguna yang menulis laporan bug kepada Anda seperti: "Driver video saya tidak uptodate. Perpustakaan grafis Anda mungkin tidak kompatibel dengan driver grafis lama."

Dengan asumsi basis pengguna adalah pengguna akhir yang memiliki masalah dengan perangkat lunak yang Anda tulis ....

Bukan tugas pengguna Anda untuk menjadi Insinyur Perangkat Lunak atau profesional Pengujian yang mahir, dan Anda seharusnya tidak mengharapkannya. Pengguna Anda adalah orang biasa yang mengharapkan perangkat lunak untuk "bekerja". Ketika tidak, mereka akan melaporkan apa pun yang menurut mereka harus mereka perhatikan untuk mendapatkan perhatian Anda. Anda tidak dapat mengubah itu, dan jangan mencoba untuk itu. Setiap upaya untuk menuntut jenis laporan yang diharapkan dilakukan oleh seorang profesional akan mengakibatkan hilangnya laporan bug, dan pelanggan - "Saya punya masalah dengan perangkat lunak itu, tetapi alih-alih membantu saya, mereka malah mengisi semua jenis bentuk tidak berguna yang tidak berarti apa-apa dan tidak memiliki nilai bagi saya. Saya akan mencari beberapa perangkat lunak yang benar-benar berfungsi. "

Yaitu itu bukan pekerjaan mereka .....

Jika Anda ingin laporan bug yang baik, mempekerjakan profesional untuk menemukan bug Anda. Jika Anda, sebagai pengembang perangkat lunak, tidak bisa repot berurusan dengan pelanggan, pekerjakan seseorang yang bisa.