Terkadang tim QA saya melaporkan bug, tetapi baik saya maupun mereka tidak punya ide tentang cara mereproduksi mereka. Ini mengarah ke sesi debugging yang sangat panjang dan membuat frustasi yang terkadang bahkan tidak membuahkan hasil.

Perangkat lunak saya sangat terkait dengan perangkat keras berpemilik sehingga bug dapat datang dari berbagai arah sekaligus.

Haruskah saya mengharapkan lebih dari mereka daripada "perangkat lunak Anda macet ketika saya menekan tombol" atau haruskah saya membayangkan sendiri apa yang terjadi?

EDIT:

Salah satu rekan kerja saya menunjukkan bahwa kita mungkin semua pengembang di sini sehingga hasilnya mungkin sedikit bias

QA harus selalu mencoba dan membuat bug semudah Anda mereproduksi mungkin dan deskripsi bug harus berisi langkah-langkah yang diambil.

Namun, jika mereka tidak dapat dengan mudah mereproduksi bug, mereka harus tetap masuk ke dalam database bug dengan judul / judul yang sesuai dan deskripsi lengkap tentang apa yang mereka lakukan untuk menyebabkan bug. Deskripsi bug harus dengan jelas menyatakan bahwa mereka tidak dapat mereproduksi bug (mungkin dengan beberapa komentar di sepanjang baris "mencobanya lima kali, itu terjadi sekali"). Dengan cara ini, jika orang lain melihat bug yang sama, mereka dapat menambahkan ke database bug dengan temuan mereka dan Anda juga mendapatkan informasi sebanyak mungkin yang selanjutnya akan membantu Anda menghemat waktu untuk melacak masalah.

Selain itu, Anda dapat memfilter informasi - mungkin ada banyak bug dalam sistem yang berbeda yang Anda tahu semuanya ditautkan ke (misalnya) satu area kode - jika QA tidak melaporkan apa pun (karena mereka tidak dapat mereproduksi mereka ) maka informasi ini tidak sampai kepada Anda.

Sepertinya departemen QA Anda melakukan terlalu banyak pengujian eksplorasi (mis. Mereka tidak memiliki rencana pengujian yang baik).

Pengujian eksplorasi adalah baik, dan mengidentifikasi area masalah, tetapi dari sana mereka harus mendefinisikan uji kasus yang dapat direproduksi (mis. Rencana pengujian) untuk melakukan yang akan mengungkapkan bug tertentu.

Ada sejumlah alasan mengapa repro yang benar diperlukan (tidak hanya bagus, tetapi perlu):

1. Anda harus mengulang sehingga Anda dapat men-debug / melacak penyebabnya.
2. QA harus dapat memverifikasi perbaikan setelah Anda selesai.
3. Tes lulus lebih lanjut perlu dilakukan regresi pada bug sebelumnya.
4. Bug yang dikenal dapat dibuang jika eksposur terlalu kecil atau repro terlalu kecil kemungkinannya.

Jadi, seperti yang dicatat SteveCzetty: Tutup tanpa repro dan kembali bekerja.

Jika bug tidak dapat direproduksi secara konsisten, bagaimana QA akan tahu apakah itu diperbaiki?

Ya, Anda harus mengharapkan lebih dari mereka. Mereka harus bisa mengatakan:

1. Memulai program baru
2. Saya menekan tombol A
3. Masukkan "tes teks" ke dalam bidang TEST NAME pada Formulir # 1
4. Tekan tombol B
5. Mengamati bahwa program macet dengan pesan ini (lihat tangkapan layar terlampir).

Jika yang mereka katakan adalah "macet", itu tidak terlalu baik. Bahkan jika langkah-langkah di atas tidak 100% dapat direproduksi, sampel crash yang cukup besar dapat membantu mempersempit penyebabnya, begitu sebuah pola terdeteksi.

Saran saya adalah membaca bug itu dan memberi mereka pemikiran lama yang bagus. Jika Anda tidak dapat menemukan penyebab potensial, lupakan saja untuk saat ini.

QA harus mendokumentasikan setiap masalah yang mereka temukan, bahkan jika mereka tidak tahu bagaimana itu terjadi. Adalah tugas QA untuk mencoba dan mereproduksi masalah, tetapi secara realistis ini tidak selalu mungkin. Terkadang itu tidak ada hubungannya dengan apa yang mereka lakukan dalam 10 menit terakhir. Sesuatu masuk ke keadaan tidak valid sehari yang lalu, dan itu menjadi jelas karena salah satu dari 10 langkah terakhir.

Dengan bug "1 dalam 1000" ini, QA harus mencoba mereproduksi mereka sedikit. Jika mereka tidak berhasil, mereka harus mendokumentasikan bug, lalu coba lagi.

Alasan mengapa mereka harus memasukkan bug cukup awal adalah bahwa programmer mengetahui kode jauh lebih baik daripada QA, dan mungkin segera tahu masalahnya. Mungkin kode yang mereka refactored. Bisa jadi fungsi yang setengah mereka implementasikan lalu lupakan. Mereka mungkin tidak tahu, tetapi tidak ada gunanya dalam penguji menghabiskan beberapa jam mencoba mereproduksi masalah yang jelas bagi orang yang mengkodekannya. Penguji selalu dapat menambahkan rincian lebih lanjut ke bug nanti.

Bug harus menyertakan informasi sebanyak mungkin. Apa pun yang dapat diingat oleh penguji tentang penyebab masalah ini harus ditulis dengan sangat rinci. Log Crash, snapshot basis data, atau tangkapan layar yang relevan juga harus dilampirkan.

Jika bug tidak pernah direproduksi, hebat! Tidak ada salahnya menyimpannya di database. Jika program ini dirilis dan pengguna melaporkan bug yang sama nanti, Anda dapat membandingkan pengalaman mereka dengan apa yang ada di laporan dan mencari kesamaan.

Dalam pengalaman saya, bug yang paling baru tidak ditemukan dari mengikuti rencana pengujian. Kadang-kadang Anda harus membiarkan hal-hal rebus selama beberapa minggu agar bulan dan bintang sejajar yang menyebabkan bug jahat. Jika QA dapat melakukan beberapa pekerjaan detektif dan menemukan beberapa kemungkinan penyebabnya, beri tepukan pada mereka. Namun terkadang, siapa yang tahu apa yang terjadi?

Banyak bug tidak dapat direproduksi sampai Anda tahu cara memperbaikinya. Itu tidak berarti mereka tidak perlu diperbaiki. Saya memperbaiki bug tahun lalu yang masih belum bisa saya reproduksi. Dibutuhkan beberapa kombinasi aneh dari kesalahan transmisi tepat waktu bersama-sama dengan data sampah yang sangat spesifik di lokasi memori tertentu pada stack. Sayangnya, salah satu pelanggan kami "cukup beruntung" untuk memasuki kondisi itu setiap saat.

Jadi, tentu saja dorong QA untuk memasukkan langkah-langkah reproduksibilitas jika memungkinkan, tetapi jangan salahkan mereka jika mereka tidak bisa. Terkadang ini akan membantu Anda tahu di mana menambahkan logging. Terkadang yang dilakukan adalah memberi tahu Anda apa yang tidak menyebabkan bug, tetapi laporan bug selalu bermanfaat.

Jika Anda maksudnya harus QA menyertakan langkah-langkah untuk mereproduksi bug jika mereka bisa, maka jawabannya adalah ya. Jika yang Anda maksud adalah mereka hanya merekam bug yang dapat diperbanyak, maka sama sekali tidak. Bug adalah bug, apakah itu hanya terjadi pada tengah malam di bulan purnama, atau setiap kali Anda melihatnya. Beberapa bug bersifat non-deterministik (contoh klasik adalah variabel tidak diinisialisasi, di mana nilai yang diambil adalah semi-acak), itu tidak berarti mereka tidak boleh direkam, diselidiki, dan jika mungkin diperbaiki.

Bug yang tidak dapat direproduksi umumnya harus memiliki prioritas rendah, tetapi bug itu harus direkam.

IMO, kamu harus. QA tidak melakukan pekerjaan mereka jika mereka tidak dapat memberikan Anda langkah-langkah reproduksi. Jangan buang waktu Anda mencoba mereproduksi sesuatu yang Anda tidak bisa, tutup saja sebagai "Tidak dapat mereproduksi" dan lanjutkan.

Waktu Anda jauh lebih berharga dari itu.

Laporan bug harus berisi:

• Langkah-langkah mereproduksi
• Perilaku yang sebenarnya
• Perilaku yang diharapkan

Misalnya:

• Saya menghapus semua pemasok dari basis data (menggunakan DELETE * FROM tSuppliers), membuka dialog pemasok, dan mengklik daftar drop-down Pemasok.
• Daftar itu berisi pesan berikut: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Ketika saya mengklik pesan itu, aplikasi menghilang dari layar, dan Task Manager.
• Saya berharap melihat daftar kosong atau (lebih disukai) pesan seperti "Tidak ada pemasok yang ditemukan". Mengklik daftar kosong atau pesan tidak akan berpengaruh. Aplikasi ini jelas tidak boleh hilang tanpa peringatan dalam kondisi apa pun.

Jadi, ya - harus berisi langkah-langkah untuk mereproduksi. Fakta bahwa mereka tidak merasa perlu untuk memasukkan ini tampaknya mengindikasikan bahwa mereka berpikir pekerjaan mereka adalah "merusak perangkat lunak", daripada mengidentifikasi kesalahan.

QA harus dapat mereproduksi bug berdasarkan langkah-langkah yang dimasukkan. Jika mereka berusaha keras, masih tidak dapat mereproduksi, mereka masih harus memasukkan bug dengan sebanyak yang mereka miliki dengan stempel waktu sehingga pengembang dapat melihat aplikasi dan men-debug log untuk detail lebih lanjut.

Uang dipertaruhkan di sini. Mengapa setiap anggota tim dapat membuat tugas yang tidak jelas, peluang rendah kesuksesan yang membebani pengembang (mudah-mudahan) berbayar tinggi?

Ini bukan tentang mematuk urutan, hierarki, kesombongan, kita vs. mereka, atau semacamnya. Ini hanya tentang berinvestasi dalam kegiatan yang menambah nilai pada produk.

Ketika masalah dapat didemonstrasikan untuk secara negatif dan terukur mempengaruhi nilai produk, maka itu harus diselidiki, direproduksi, dan diperbaiki. Perbaiki pipa cacat produk Anda untuk menyaring kebisingan.

Tim QA Anda menyebalkan

Pergi ke mereka dan suruh mereka membaca dokumen yang harus dicetak oleh penguji profesional mana pun di dalam otak mereka (saya pernah menjadi penguji dan saya masih memilikinya di otak saya): Cara Melaporkan Bug dengan Efektif .

Terutama, arahkan mereka ke bagian "Tunjukkan saya cara menunjukkan diri" :

Ini adalah era Internet. Ini adalah era komunikasi di seluruh dunia. Ini adalah era di mana saya dapat mengirim perangkat lunak saya kepada seseorang di Rusia dengan satu sentuhan tombol, dan dia dapat mengirim saya komentar tentang hal itu dengan mudah. Tetapi jika dia memiliki masalah dengan program saya, dia tidak bisa membuat saya berdiri di depannya sementara itu gagal. "Tunjukkan padaku" itu bagus ketika kamu bisa, tetapi seringkali kamu tidak bisa.

Jika Anda harus melaporkan bug ke programmer yang tidak dapat hadir secara langsung, tujuan latihan ini adalah untuk memungkinkan mereka mereproduksi masalah. Anda ingin programmer menjalankan salinan programnya sendiri, melakukan hal yang sama dengannya, dan membuatnya gagal dengan cara yang sama. Ketika mereka dapat melihat masalah terjadi di depan mata mereka, maka mereka dapat mengatasinya ...

Jika mereka mulai berteriak pada Anda mengeluh bahwa "bug dapat datang dari berbagai arah sekaligus" , beri tahu mereka bahwa mereka mengisap lebih dari yang Anda pikirkan sebelumnya. Beri tahu mereka bahwa Testability adalah fitur yang harus mereka evaluasi di antara fitur-fitur proyek lainnya dan mereka harus menginvestasikan upaya untuk memperbaiki fitur ini.

• Peningkatan kemampuan uji yang bisa didapat ketika ada tester profesional yang berfokus pada hal itu bisa seperti sulap. Saya belajar itu sendiri beberapa bulan yang lalu. Insinyur QA yang bekerja dengan tim kami memberi saya beberapa permintaan pengujian untuk dikembangkan untuk beberapa komponen dalam aplikasi kami. Hal-hal yang dia tanyakan kurang masuk akal bagi saya, tetapi saya hanya memberikannya dengan anggapan bahwa dia lebih tahu sebagai seorang profesional. Segera setelah saya selesai, dia datang dengan alat yang mengurangi upaya pengujian berdasarkan urutan besarnya . Dia mengatakan sebagian besar didasarkan pada permintaan rahasia yang saya laksanakan, lanjutkan.