Membuat pengguna menulis laporan bug yang layak dan berguna

32

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.

client-relations bug-report Benteng
sumber
2
Saya bisa mengerti memilih untuk menutup programer, tetapi offtopic? Laporan bug di situs programmer ?!
Benteng
1
Apakah itu penting? Mereka akan tetap menulis laporan bug yang buruk. Apa yang biasanya perlu Anda lakukan adalah berkomunikasi dengan pengguna entah bagaimana.
David Thornley
@ Davidvidhorn - Kami berada dalam semacam industri tertentu. Dengan sebagian besar pengguna, saya tidak pernah berkomunikasi, atau mendapatkan laporan itu beberapa bulan kemudian. Jangan tanya.
Benteng
3
Bangun mekanisme pelaporan ke dalam aplikasi Anda, sehingga pengguna dapat mengklik tombol, menambahkan komentar, dan menyatukan status yang sesuai dengan aplikasi tersebut. "Sekarang, silakan klik lokasi pada layar di mana itu salah" ...
3
Beri tahu saya jika Anda menemukan jawaban. Saya mengalami cukup banyak masalah dalam mendapatkan laporan bug yang berguna dari penguji, apalagi pengguna.
Kristof Provost

Jawaban:

16

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? "
agas
sumber
27

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.

kesalahan besar
sumber
2
Jawaban yang bagus Singkat dan komunikatif. Saya akan mencuri ini untuk menjelaskan kepada orang-orang.
Erik Dietrich
Ini juga harus menjadi template yang dimulai dengan pertanyaan SO.
Cody Piersall
5
Saya memang menekan tombol biru , dan berharap hal-hal berfungsi , tetapi tidak terjadi apa - apa . : D
Songo
"Aku sudah _____, dan berharap _______ akan terjadi, tetapi _______ malah terjadi." Saya menggunakan perangkat lunak ______ versi _____ pada lingkungan produksi / qa / tes.
kubanczyk
10

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

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.

Brian Snow
sumber
10
Saya tidak begitu mengerti mengapa ini mendapat begitu banyak suara. Pertanyaannya bukan "bagaimana menulis laporan bug yang layak?" tetapi "bagaimana membuat pengguna menulis laporan bug yang layak".
Tamás Szelei
8
Sumber daya tersebut sebagian besar ditargetkan pada orang-orang teknis. Juga Mozilla adalah organisasi yang membawa kami Bugzilla. Saya tidak mengatakan bahwa Bugzilla buruk, tetapi dibuat oleh insinyur untuk insinyur: Ini benar-benar bukan alat pengguna akhir sama sekali .
Joachim Sauer
3
Harus setuju dengan @fish. Kami dapat memberikan semua panduan kepada penguji kami di dunia - tidak membuatnya benar - benar menghasilkan laporan bug yang berguna. Dan saya berbicara tentang orang yang tugasnya melaporkan bug - jika kita tidak bisa memotivasi mereka dengan panduan, kita sama sekali tidak punya harapan dengan pengguna yang sebenarnya. Satu-satunya hal yang kami temukan efektif adalah secara aktif menutup laporan bug "tidak berguna" sebagai "tidak cukup informasi" - mereka mendapat pesan dengan cukup cepat. Saya tidak menyarankannya untuk pengguna eksternal :-)
HappyCat
3
Saya tidak memperdebatkan kegunaan pos sama sekali (sumber daya yang cukup bagus di sana, sungguh) tapi ini tidak menjawab pertanyaan, dan saya pikir kebijakan pemilihan didasarkan pada itu (saya mungkin salah).
Tamás Szelei
1
Aku adalah tipe orang yang dituju ini dan bahkan aku tidak bisa duduk membaca semuanya. Apa yang membuat Anda berpikir pengguna akan pergi?
Tacroy
4

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.

Wladimir Palant
sumber
4

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."

Mert Akcakaya
sumber
3

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.

mattnz
sumber
1
Saya tidak berpikir OP mengatakan mereka tidak ingin berurusan dengan pengguna. Saya pikir OP mengatakan bahwa mereka tidak dapat memperbaiki apa pun berdasarkan laporan bug 'crash'. OP menginginkan cara untuk mendapatkan hasil maksimal dari pengguna yang mengeluh, sehingga OP benar-benar dapat memperbaiki masalah.
Michael Kohne
1
Maksud saya adalah jika "itu crash" adalah apa yang terjadi dari perspektif pengguna. Ketika saya membawa mobil saya ke seorang mekanik, dia tidak mengharapkan saya untuk memberikan kepadanya laporan diagnostik yang terperinci secara ahli tentang apa yang salah - dia bertanya kepada saya pertanyaan untuk membantunya menggunakan keahliannya untuk mendiagnosis masalahnya. Misalnya satu kunjungan masalah saya adalah "Itu berhenti ketika dingin, tapi tidak apa-apa ketika panas", beberapa pertanyaan yang dipertimbangkan dengan baik (dengan ya tidak ada jawaban) kemudian dia cukup yakin (dan ternyata benar) itu salah termometer. Tugas kita adalah mengajukan pertanyaan, dibingkai untuk memberikan jawaban ya tidak.
mattnz