Tanggung jawab untuk mereproduksi bug


25

Saya mengembangkan program menggunakan perpustakaan yang dibuat oleh programmer lain (dia bekerja di perusahaan yang sama). Baru-baru ini saya menemukan kebocoran di perpustakaan, yang terjadi pada kondisi jaringan tertentu setelah beberapa jam berjalan. Saya mengajukan bug dengan deskripsi kondisi untuk membuat kebocoran ini terjadi. Pengembang itu menjawab bahwa "ini tidak cukup", "itu bukan tanggung jawabnya untuk mereproduksi bug" dan saya harus membuat unit test untuk mereproduksi bug ini, kalau tidak dia tidak melakukan apa-apa.

  1. Apakah dia benar
  2. Apa yang bisa saya lakukan dalam situasi ini? Membuat unit test tidak mungkin, karena itu tergantung pada beberapa timing jaringan acak.

26
Jika Anda akan menulis unit test, Anda sebaiknya memperbaiki bug dan mengambil kredit untuk semuanya.
JeffO

3
@ Jeff, dia mengelola perpustakaan itu dan tidak akan menerima perbaikan bug. Karena "dia tidak yakin bug itu pernah ada"
user626528


Apakah mungkin pengelola perpustakaan ada di tim yang kebijakannya adalah bahwa bug tidak diterima tanpa tes otomatis? Saya juga pernah mendengar istilah unit test batal tentang ketika apa yang sebenarnya diharapkan mungkin berupa tes otomatis, terutama untuk tes integrasi.
Joshua Drake

Jawaban:


30

Apakah dia benar mungkin adalah pertanyaan yang tidak dapat benar-benar dijawab tanpa mengetahui perusahaan Anda. Namun, dia tentu saja tidak terlalu membantu.

Saya akan meningkatkan bug dengannya (yang telah Anda lakukan), jika hal itu menyebabkan masalah dengan proyek Anda, maka saya akan meningkatkannya sebagai pemblokir dengan manajer proyek Anda dan membuatnya sangat jelas bahwa Anda telah meningkatkan bug dengan tepat orang tetapi itu akan berdampak pada proyek Anda jika tidak segera diperbaiki.

Saya juga akan pergi dan berbicara dengan pengembang dan menjelaskan mengapa itu tidak layak untuk membuat unit test tetapi Anda akan senang menunjukkannya di mesin Anda (dengan asumsi itu layak?).


48

Ia 100% benar bahwa Anda harus memberikan informasi yang cukup untuk membuat bug dapat direproduksi - jika tidak, tidak ada peluang untuk mengetahui apakah perbaikan yang diberikannya akan benar-benar berfungsi.

Tapi - dia IMHO 100% salah bahwa ini harus dalam bentuk unit test. Jika Anda dapat menggambarkan skenario pengujian sedemikian rupa sehingga ia dapat mereproduksi kegagalan (setidaknya dengan probabilitas tinggi dalam jumlah waktu yang wajar, atau dengan pengujian manual), Anda memiliki bukti bahwa masalahnya ada - yang seharusnya mengatur kolega Anda dalam tanggung jawab untuk memperbaikinya. Tentu saja, jika Anda dapat membuat skenario yang mereproduksi bug lebih cepat, itu akan sangat membantu baginya. Idealnya, seseorang akan membuat tes otomatis dari itu, dan itu tergantung pada organisasi Anda yang memiliki tanggung jawab untuk ini.


11
Jadi, jika aplikasi mogok "sesekali", tanpa pola yang dapat dicerna bagi pengguna, maka pengembang tidak harus memperbaikinya karena pengguna tidak dapat mereproduksinya atas perintah? Saya sangat tidak setuju di sini ...
Heinzi

20
@Heinzi: jika saya mendapatkan laporan bug "aplikasi crash setiap sekarang", saya akan memberikan masalah itu prioritas yang sangat rendah untuk dikerjakan juga. Hal minimum yang saya harapkan dari pengguna adalah menuliskan seberapa sering "sekarang dan kemudian", apa yang dia lakukan persis dengan apa yang ada di aplikasi pada saat aplikasi crash terakhir kali, dan pesan kesalahan yang tepat.
Doc Brown

3
@ user626528: IMHO pemilik perpustakaan harus mencoba untuk melalui langkah-langkah yang Anda katakan padanya untuk mereproduksi bug - ia tidak harus mencoba 500 skenario yang sedikit berbeda ketika deskripsi Anda tidak menunjukkan bug apa pun.
Doc Brown

6
Reporter seharusnya tidak perlu memberikan langkah-langkah reproduksi; cukup sering kami cukup memasang dump dari proses macet, terutama jika itu terjadi selama menjalankan otomatis. Penerima bertanggung jawab untuk menemukan langkah-langkah reproduksi sehingga perbaikan dapat diverifikasi.
avakar

2
(Itu tidak berarti reporter tidak boleh mencoba membantu dan menyediakan langkah-langkah jika mereka mengetahuinya. Namun, untuk crash sporadis, reporter tidak berkewajiban untuk menghabiskan waktu untuk meneliti sesuatu yang mungkin akan diketahui oleh pemilik komponen dengan lebih cepat. )
avakar

9

Kedua belah pihak harus berusaha.

Pengembang perpustakaan harus melakukan upaya tambahan bahkan tanpa tes unit, karena beberapa masalah tidak dapat direproduksi dengan tes unit. Kadang-kadang perangkat keras, kadang-kadang beberapa urutan tindakan yang benar dari sisa program yang membuat perpustakaan menghasilkan hasil yang buruk.

Anda harus melakukan upaya tambahan, karena bagaimanapun ini saya tidak menjadi bug di perpustakaan, tetapi hasil dari tindakan yang salah dari sisa program (mis. Tumpukan yang rusak dapat membuat perpustakaan berperilaku aneh). Jadi masuk akal untuk mengurangi sebanyak mungkin kode non-perpustakaan yang terlibat dalam mereproduksi bug. Dan Anda mungkin akan melakukan ini lebih cepat dan lebih bersih daripada orang yang tidak terbiasa dengan kode aplikasi Anda.


5

Jika penulis perpustakaan tidak dapat mereproduksi bug berdasarkan laporan Anda, maka tidak masuk akal untuk mengharapkan dia menghabiskan banyak waktu untuk bug itu, apalagi memperbaikinya.

Tetapi Anda juga memiliki jumlah terbatas waktu yang dihabiskan untuk mengerjakan suatu produk yang sesuai dengan minat Anda. Sayangnya, ini mungkin berarti bahwa bug terus ada, dan tidak ada pekerjaan yang dilakukan untuk menyelesaikannya.

Untungnya ini belum tentu menjadi bencana - sementara di dunia yang ideal, semua perangkat lunak akan bebas bug, dan bukan itu masalahnya, jadi kami harus memprioritaskan berdasarkan masalah yang disebabkan AS.

Ini berarti bahwa memang Anda bertanggung jawab untuk mengembangkan test case yang dapat direproduksi JIKA ANDA INGIN MEMPERBAIKI. Anda mungkin tidak peduli apakah itu diperbaiki, dan dalam hal ini, Anda telah melakukan semua yang dapat dan seharusnya diharapkan dari Anda. Anda mungkin ingin memperbaikinya, tetapi tidak cukup mencurahkan waktu untuk membuatnya dapat diulang saat ini. Itu bisa diterima.

Melaporkan bug dengan kemampuan terbaik Anda saat Anda harus mengatasinya adalah kewarganegaraan yang baik, Anda tidak perlu melampaui itu kecuali jika diperlukan untuk program Anda. Dan Anda mungkin tidak ingin melakukannya meskipun begitu, mungkin ada perpustakaan lain yang bisa Anda gunakan, atau dimungkinkan untuk menggulung sendiri dalam jangka waktu yang wajar. Pada dasarnya terserah Anda untuk memutuskan apa dan usaha apa yang layak untuk Anda.


1
Jawaban Anda terlihat sangat aneh bagi saya. Saya memperbaiki bug saya sendiri, dan jangan menunggu seseorang melakukan pekerjaan kotor, bukan saya. Saya akan mengatakan itu adalah tanggung jawab utama pembuat kode untuk melakukan yang terbaik untuk memperbaiki kodenya.
user626528

1
Karena ANDA adalah orang yang ingin memperbaikinya sekarang, Anda bertanggung jawab untuk meyakinkannya bahwa ada baiknya HIS memperbaikinya sekarang, alih-alih dalam 10 atau 12 tahun ketika ia tidak memiliki hal lain yang lebih penting untuk diperbaiki. theregister.co.uk/2013/01/21/kde_bug_quashed . Mengingat bug yang tidak dapat direproduksi, dengan signifikansi X, dan bug yang dapat direproduksi dengan signifikansi yang sama, saya akan mengerjakan bug yang dapat direproduksi setiap waktu.
jmoreno

terlalu banyak ego. Dia dibayar untuk bekerja di perpustakaan yang aneh itu.
user626528

1
@ user626528: Ini bukan tentang ego, ini tentang prioritas - ketidakmampuan untuk mereproduksi bug yang lebih rendah, itu prioritasnya. Diberi dua bug EOI (Execute Operator Immediately), satu bug yang dapat direproduksi dan satu tidak, saya akan mengerjakan bug yang bisa direproduksi lebih dulu, dan saya akan memberi tahu pengembang lain untuk melakukan hal yang sama. Dan jika perpustakaan tidak banyak digunakan, saya mungkin mengerjakan proyek lain sepenuhnya - bahkan jika bug di dalamnya tidak sepenting itu. Jika dia / semata-mata / dibayar untuk bekerja di perpustakaan ini DAN tidak ada permintaan fitur luar biasa atau bug selain yang ini, maka ya dia harus melakukannya.
jmoreno

2

Aku akan cenderung untuk membiarkan anjing tidur berbaring untuk saat ini - Anda sudah mengangkat masalah ini dan ditugaskan kepadanya. Mungkin ada proses di tempat untuk melacak bug yang luar biasa dan mengejar ini?

Jika Anda ingin secara aktif meningkatkan ini lebih lanjut, saya sarankan berbicara dengan manajer Anda untuk melihat apakah ada alat uji yang tersedia yang dapat mereproduksi masalah dengan andal.

Dari sisi pengembang - akan sangat lamban bagi mereka untuk tidak melakukan apa pun mengingat Anda telah memberikan informasi yang diperlukan. Dimungkinkan namun bahwa mereka memiliki beban kerja yang besar sehingga tidak dapat mencurahkan waktu yang dibutuhkan untuk melacak masalah ini melalui.


2

Anda menemukan bug, Anda melaporkannya dan dia menyebalkan tentang itu.

Seandainya kalian berdua teman dekat, dia akan melakukan sesuatu untuk membantu, tetapi dia lebih suka hanya mendorong masalah itu kembali.

Anda dapat melakukan lebih banyak, dengan melaporkan detail lebih lanjut dan mencoba mendukung klaim Anda bahwa itu bocor memori. Namun, Anda memiliki tanggung jawab Anda sendiri dan harus menyelesaikan pekerjaan Anda sendiri.

Masuk sebanyak mungkin informasi ke pelacak bug, dan lanjutkan.

Jika Anda melihat orang ini lagi di masa depan. Bersikap ramah, cobalah untuk berbicara tentang minat bersama dan pahami bahwa hubungan yang baik jauh lebih efektif untuk memperbaiki keadaan, maka sejumlah fakta yang dapat Anda berikan untuk mendukung klaim.


Saya memiliki simpati dengan pengembang perpustakaan. Mungkin sudut pandang mereka adalah bahwa pengembang aplikasi mencoba menggunakan pustaka dan membuatnya rusak dengan kode mereka. Itu tidak dilaporkan di alam liar atau oleh pengembang lain sehingga bagi mereka itu adalah bug yang relatif prioritas rendah (atau palsu).
Robbie Dee

@RobbieDee ya benar, ini bukan salah satu jawaban terbaik saya. Saya hanya berpikir itu aneh bahwa keduanya tidak bisa bekerja sama mengingat mereka bekerja untuk perusahaan yang sama. Maksudku, jika pemilik bisnis mendengar seorang karyawan harus datang ke sini untuk mendapatkan dukungan. Aku ingin tahu apa yang akan dia pikirkan tentang itu. Bukannya aku ingin sesuatu berjalan di tempatku.
Reactgular

0

Seringkali, apa yang saya temui dalam situasi yang serupa adalah asumsi bahwa semua bug harus diperbaiki dan walaupun sangat mengagumkan, itu pasti tujuan yang bagus untuk dimiliki (mari kita hadapi bahwa kita tidak pernah memulai untuk menulis bug!) Itu akhirnya tidak realistis di setiap proyek dengan ukuran yang layak untuk memperbaiki bug hanya karena itu adalah bug (jika Anda dapat menemukannya!) Itu sebabnya kami memiliki manajemen proyek dan metodologi pengkodean, pola & praktik dll.

Jadi, satu hal yang akan saya katakan dalam pembelaan pemilik perpustakaan (dan telah menjadi kasus ketika saya telah mengerjakan beberapa proyek besar) adalah bahwa waktu dev memerlukan biaya dan sumber daya yang terbatas sehingga keputusan mengenai bagaimana sebuah laporan ditangani , siapa yang menyelidiki, tes apa yang dihasilkan / dibutuhkan dan pada akhirnya jika (dan jika demikian, kapan) perbaikan dilakukan didasarkan murni pada dampak bisnis. Apa dampak dari memulai kembali proses lama Anda sesekali jika gagal dan dapatkah Anda dengan mudah mengotomatiskannya (dan mungkin sebaiknya Anda tidak menjadi ukuran pemrograman defensif?) Apakah hanya waktu atau ada yang lebih dari itu ?

Juga melihat dari sudut pandang mereka, laporan bug dari satu pengguna dari masalah tak terduga dalam sedikit kode yang terjadi sangat jarang, hanya dalam hubungannya dengan kode mereka, mungkin hanya pada satu mesin dan hanya di bawah satu set waktu yang tidak biasa kondisi tidak akan memiliki pembenaran yang kuat untuk sejumlah besar waktu dev untuk menemukan dan memperbaiki - jika itu mungkin. Tapi kalau itu kasus bisnis yang cukup kuat untuk itu pengguna ingin / perlu meluangkan waktu untuk menyelidiki lebih teliti dan memberikan handal ujian / aplikasi atau deskripsi masalah secara radikal lebih rinci dari satu awal mereka maka itu bisa menjadi ballgame lain .

Ini mungkin masalah komunikasi yang belum dipertimbangkan oleh pemilik perpustakaan dan jika Anda memiliki kasus bisnis yang kuat (seperti kode Anda mahal untuk bisnis, memiliki persyaratan kepatuhan hukum, celah keamanan atau memiliki beberapa efek knock-on utama lainnya) maka saatnya untuk menendang ke manajemen dan membiarkan mereka berkelahi habis-habisan.


1
Saya memiliki simpati bahwa seseorang sedang mempertimbangkan jawaban Anda (yang merupakan kemungkinan praktis) buruk dan tidak memilih. Hal yang sama terjadi pada jawaban saya.
isntn

-3

Anda telah menyebutkan bahwa 'Saya mengajukan bug dengan uraian kondisi untuk membuat kebocoran ini terjadi.'

Jika Anda yakin deskripsi itu benar-benar cukup untuk mereproduksi bug, maka Anda sudah tahu persis kondisinya. Sekarang, jika Anda tidak dapat menulis unit test setelah mengetahui kondisinya, maka itu jelas berarti bahwa Anda tidak dapat mengejek beberapa komponen yang terlibat atau beberapa bagian kode terlalu erat digabungkan untuk memungkinkan untuk membuat unit test praktis.

Anda harus meminta pemilik perpustakaan untuk membuat ulang kode untuk memungkinkan Anda membuat tes unit. Anda harus menjelaskan dengan jelas apa yang ada di perpustakaan yang menghentikan Anda untuk membuat unit test. Dia harus memperbaiki kode jika tidak mengakui bahwa unit test tidak mungkin dengan kode saat ini. Kedua cara, Anda menang.

Jika ini tidak berhasil, berikut adalah opsi yang Anda miliki:

  • Anda dapat mereproduksi bug dengan lebih banyak bukti.
  • Coba melibatkan otoritas yang lebih tinggi dan meminta dia / dia untuk mengevaluasi bukti-bukti Anda.
  • Coba gunakan perpustakaan dalam aplikasi prototipe dengan lingkungan tiruan untuk dikodekan hanya untuk mereproduksi bug. Dengan begitu, Anda akan dapat membuktikan setidaknya itu bug ada.

3
Bukan tanggung jawab OP untuk membuat unit test untuk pengelola perpustakaan.
Andy

6
Jika pengembang lain mengabaikan laporan bug dari seseorang, hampir tidak ada peluang baginya untuk menanggapi permintaan untuk refactoring besar. Juga, tidak semua jenis masalah dapat dengan mudah direproduksi melalui pengujian unit: programmers.stackexchange.com/questions/196105/…
Dan Neely

1
@DanNeely: Dia tidak mengabaikan, dia mengklaim bahwa reporter harus melakukan sesuatu yang lebih - yang tidak mungkin dilakukan untuk reporter. Dan reporter harus berkomunikasi kembali! Saya juga telah menyarankan untuk melibatkan otoritas, karena ini mungkin akan menjadi masalah.
isntn

1
@Andy Dalam beberapa posisi adalah kebijakan perusahaan bahwa bug tidak diterima tanpa tes otomatis.
Joshua Drake

5
Anda tampak bingung tentang penggunaan suara yang tepat, dan mengomentari hal itu tidak akan membantu kasus Anda. Downvotes adalah cara yang diterima untuk mengatakan "Saya pikir ini adalah jawaban yang buruk". Bahasa yang ofensif harus ditangani tidak (semata-mata) melalui voting turun, tetapi dengan mengedit atau menandai tergantung pada apakah sisa jawaban berguna. Suatu di luar konteks jawaban dapat ditangani dengan cara apa pun tergantung pada seberapa mengerikan itu.
Dan Neely
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.