Mengapa tidak disarankan untuk mengirim beberapa cacat dalam masalah / tiket yang sama?

Saya tidak yakin apakah ini tempat untuk mengajukan pertanyaan konseptual berikut (Stackoverflow jelas tidak).

Saya melihat pertanyaan ini dalam ujian pilihan ganda (jawaban tunggal), mirip dengan ujian ISTQB :

Mengapa tidak disarankan untuk melaporkan beberapa cacat dalam masalah / tiket yang sama?

Sebuah. Agar laporannya singkat dan jelas.

b. Karena pengembang mungkin memperbaiki hanya satu bug.

c. Karena penguji kelompok pengujian dinilai oleh jumlah bug yang mereka temukan.

d. Sistem manajemen bug tidak mendukung fitur multi bug ini.

Satu-satunya pendapat saya adalah itu aadalah jawaban yang benar.

b- tidak mungkin karena perbaikan-umpan balik-diselesaikan-ditutup harus menghindari kasus itu. c- Jelas salah.

d - Plugin Redmine / Trac mendukung banyak bidang.

Jawabannya sesuai dengan lembar jawaban adalah b.

Adakah yang bisa menjelaskan mengapa? Komentar dengan pendapat tentang jawaban dipersilahkan.

Bayangkan jika Stack Overflow memiliki pedoman: alih-alih mengajukan satu pertanyaan, Anda datang dan bertanya, dalam pertanyaan yang sama, apa pun yang ada dalam pikiran Anda, semua masalah Anda selama dua minggu terakhir. Apa yang akan berarti upvote dan downvote? Apa yang akan menjadi judul pertanyaan? Bagaimana cara menerima jawaban terbaik? Bagaimana cara menandai pertanyaan?

Sistem pelacakan bug dilakukan untuk ... melacak bug. Melacak bug berarti:

1. Membuat catatan yang mengatakan bahwa bug mungkin ada, dengan informasi tentang cara mereproduksinya,

2. Mengkonfirmasi bahwa memang, bug itu ada dan merupakan bug, bukan sesuatu dengan desain,

3. Menyatakan bahwa bug sekarang telah dipecahkan,

4. Mengkonfirmasi bahwa bug telah dipecahkan.

Dalam model yang sangat sederhana, 1 dan 4 akan dilakukan oleh pelanggan, dan 2 dan 3 - oleh pengembang.

Bayangkan log berikut:

• Hari 1 [Pelanggan] Saat menekan tombol "Hapus" di jendela "Detail produk", aplikasi hang. Restart aplikasi menunjukkan bahwa produk tidak dihapus. Perilaku yang diharapkan adalah menghapus produk.

• Hari 4 [Pengembang] <Masalah direproduksi>

• Hari 5 [Pengembang] <Masalah dipecahkan dalam revisi 5031>

• Hari 12 [Pelanggan] <Tiket ditutup: masalah diselesaikan>

Lognya sederhana dan jelas . Anda dapat dengan mudah melacak apa yang telah dilakukan dan kapan , revisi mana yang memecahkan bug mana, dll. Misalnya, jika sistem pelacakan bug terintegrasi dengan kontrol versi, ketika Anda melihat revisi tertentu, Anda dapat memeriksa bug apa yang dipecahkan di dalamnya.

Sangat mudah untuk menemukan informasi . Sangat mudah untuk melihat kondisinya (apakah itu direproduksi? Jika tiketnya ditutup, mengapa?). Sangat mudah untuk memfilter tiket (saya ingin menampilkan tiket yang hanya menyangkut UI plugin, mengingat bahwa saya hanya menginginkan tiket yang terbuka, lebih dari satu minggu dan ditugaskan kepada saya oleh perancang interaksi kami dan merupakan prioritas menengah atau tinggi).

Sangat mudah untuk menetapkan kembali tiket atau untuk menentukan orang yang seharusnya bertanggung jawab atas bug tersebut.

Sekarang bayangkan log berikut:

• Hari 1 [Pelanggan] Aplikasi hang ketika saya menekan tombol "Hapus" di jendela "Detail produk". Juga, warna latar belakang panel kiri adalah biru tua, sementara itu harus ungu. Saya juga mencatat bahwa teks dari jendela "Detail produk" tidak diterjemahkan dengan baik ke Jerman; apakah itu diharapkan? Kapan terjemahan akhir akan tersedia? BTW, sudahkah Anda menerima ikon baru yang saya kirim untuk tindakan "Terbitkan produk"? Saya tidak melihatnya di jendela “Sinkronkan data”.

• Hari 6 [Pengembang] Saya mengubah warna menjadi ungu.

• Hari 7 [Pengembang] Ya, itu normal bahwa terjemahan ke Jerman tidak lengkap.

• Hari 8 [Pelanggan] Oke untuk bahasa Jerman. Bagaimana dengan Italia? Lucia mengirimi Anda file XML dua hari yang lalu.

• Hari 9 [Pengembang] Tidak apa-apa sekarang.

• Hari 10 [Pelanggan] Oke untuk tombol "Hapus"? Aneh, di komputer saya, masih hang.

• Hari 11 [Pengembang] Tidak, saya ingin mengatakan tidak apa-apa untuk terjemahan bahasa Italia.

• Hari 12 [Pelanggan] saya mengerti. Terima kasih. Tapi ada masalah dengan warnanya. Anda mengubahnya menjadi ungu gelap, tetapi harus ungu muda, seperti panel atas di jendela utama.

• Hari 13 [Pengembang] saya memperbarui ikon.

• Hari 14 [Pelanggan] Ikon? Ikon apa?

• Hari 15 [Pengembang] Ikon yang Anda minta saya perbarui.

• Hari 16 [Pelanggan] Saya tidak pernah meminta Anda untuk memperbarui ikon apa pun.

• Hari 17 [Pengembang] Tentu saja Anda bertanya. Lihat tiket ini. Anda menulis bahwa ikon produk terbitkan harus diperbarui. Saya sudah melakukannya.

  ⁞

• Hari 100 [Pelanggan] Jadi, bagaimana dengan entri dalam log?

• Hari ke-101 [Pengembang] Saya tidak tahu apa yang Anda bicarakan. Bahkan tidak ada di tiket ini, tetapi di 6199. Saya menutup yang ini sebagai dipecahkan. <Tiket ditutup: masalah terpecahkan>

• Hari ke 102 [Pelanggan] Maaf untuk membukanya kembali, tetapi masalahnya tidak terpecahkan. Saya berbicara tentang entri dalam log: Saya katakan minggu lalu bahwa teks kadang-kadang tidak valid ketika berisi karakter unicode. Apakah kamu ingat? <Tiket dibuka kembali>

• Hari 103 [Pengembang] Samar-samar saya ingat sesuatu seperti itu, tetapi setelah mencari tiga halaman terakhir dari tiket ini, saya tidak dapat menemukan jejak. Bisakah Anda menulis lagi apa masalahnya?

  ⁞

• Hari 460 [Pengembang] Saya menghabiskan dua jam mencari jejak apa yang Anda katakan tentang file yang dikirim terenkripsi melalui jaringan. Saya tidak yakin dapat menemukan permintaan yang tepat.

• Hari 460 [Pelanggan] Kalian harus benar-benar lebih terorganisir. Saya memberi tahu Anda empat kali tentang masalah ini selama dua minggu terakhir. Kenapa kamu lupa semuanya?

  ⁞

Tentang apa log ini? Itu dipecahkan 43 kali dan dibuka kembali 43 kali. Apakah itu berarti bahwa pengembang itu sangat bodoh sehingga ia tidak dapat menyelesaikan masalah yang sama selama 460 hari? Ah, tidak, tunggu, tiket ini ditugaskan untuk 11 pengembang sementara itu. Apa masalahnya? Bagaimana cara mencari masalah tertentu? Ini sebenarnya ditugaskan untuk Vanessa, tetapi lima rekannya prihatin juga dengan tujuh dari sebelas masalah dalam tiket ini. Kapan tiket harus ditutup? Apakah ketika setengah dari masalah diselesaikan? Atau mungkin sepuluh dari sebelas?

Catatan: Anda mungkin percaya bahwa log seperti itu tidak ada. Percayalah, saya pernah melihat yang lebih dari satu kali.

Hanya untuk mengomentari pernyataan Anda:

tidak mungkin karena perbaikan-umpan balik-diselesaikan-ditutup harus menghindari kasus itu

Ini mengasumsikan bahwa semua bug yang diangkat akan diperbaiki pada saat yang sama. Bayangkan sebuah skenario di mana tiket dinaikkan terhadap v1 produk dengan dua masalah:

1. Tombol reset formulir sebenarnya mengirimkan formulir, daripada membersihkan nilai-nilai
2. Ukuran font pada tombol adalah 110% padahal seharusnya 115%.

Keduanya benar untuk meningkatkan tester, karena keduanya kesalahan dengan implementasi. Tetapi katakanlah bahwa pemilik produk memutuskan bahwa subtugas pertama adalah pemblokir untuk dilepaskan (yaitu harus diperbaiki sebelum produk dapat ditayangkan), tetapi tugas kedua adalah masalah kecil (yaitu dapat diperbaiki dalam v1. 1 rilis).

Dalam hal ini, kami tidak punya pilihan selain membagi # 2 menjadi tiketnya sendiri (atau berisiko lupa tentang itu). Jika kita dapat melakukan ini, itu berarti mereka dapat diimplementasikan, diuji dan disebarkan secara independen satu sama lain, dalam hal ini masuk akal untuk memiliki masalah individu sejak awal.

Cakupan:

Jawaban ini (dan pertanyaannya) tampaknya hanya berlaku untuk pelacakan cacat kode, di mana kode sumber tidak berkinerja sesuai dengan spesifikasi atau maksud pemrogram.

Sebaliknya, biasanya tiket cacat GUI mengandung banyak spesifikasi, karena setiap tiket GUI secara efektif merupakan "desain ulang" (cacat desain), "spesifikasi yang direvisi" atau "permintaan fitur" (fungsi hilang).

Salah satu tujuan penting pelacakan cacat adalah untuk berkomunikasi dan berkoordinasi antara berbagai peran (pemrogram, penguji, pelanggan, dan manajer).

Dalam proyek-proyek di mana kualitas kode memiliki signifikansi tinggi (dibandingkan dengan keramahan pengguna misalnya), pelacakan cacat dapat terdiri dari beberapa aspek, salah satunya akan fokus pada pelacakan cacat kode , secara terpisah dari pelacakan peningkatan dan permintaan dukungan pelanggan.

Tujuan dari sistem pelacakan kerusakan kode adalah:

• Untuk mengaktifkan independen pelacakan dan ambigu independen direproduksi cacat, dan
• Untuk memberikan perkiraan terbaik (korespondensi satu-ke-satu) dengan akar-penyebab dari setiap cacat.

Saat melakukan hal itu, itu harus memaksimalkan kualitas yang diinginkan berikut:

• Skala secara efisien karena jumlah cacat meningkat seiring waktu.
• Cegah sindrom target bergerak.

Penafian: frasa ini berasal dari pengalaman pribadi saya. Mungkin tidak cukup atau salah untuk tujuan ujian sertifikasi.

Pelacakan independen dan tidak ambigu berarti bahwa:

1. Setiap cacat yang valid dapat diselesaikan atau tidak , tanpa ambiguitas.

   • Alasan 1: untuk menyederhanakan manajemen,
     • Contoh: ini memungkinkan penggunaan "jumlah tiket yang tidak terselesaikan" sebagai metrik.
   • Alasan 2: untuk menerjemahkan ke dalam item yang dapat ditindaklanjuti
     • Contoh: jika tidak diselesaikan, tanggung jawab terletak pada programmer yang ditugaskan. Jika diselesaikan tetapi tidak ditutup, tanggung jawab terletak pada penguji yang ditugaskan (verifikasi).
   • Konsekuensi: Dalam metodologi ini, cacat yang diselesaikan sebagian pantas untuk dipecah menjadi beberapa cacat tergantung.

2. Cacat yang dapat direproduksi secara independen harus dilacak secara independen.

   • "Dapat direproduksi secara mandiri" berarti mereka dapat memiliki status yang berbeda. Satu dapat tampak diperbaiki sementara yang lain tetap rusak.
   • Alasan: untuk meminimalkan ketidaksesuaian antara pelacakan cacat dan analisis akar-penyebab.
     • Setiap akar-penyebab yang dapat ditelusuri ke cacat kode diyakini membutuhkan setidaknya satu perubahan kode.
     • Jika dua cacat dapat direproduksi secara independen, maka diperlukan beberapa perubahan kode.
     • Jika dua cacat dapat direproduksi secara independen, keduanya harus diuji (diverifikasi), karena lulus dari satu tes tidak menyiratkan bahwa tes lain akan lulus.
   • Contoh 2: jika dua gejala pada awalnya diyakini memiliki akar penyebab yang sama dan dengan demikian diklasifikasikan menjadi tiket yang sama, dan mereka kemudian terbukti dapat direproduksi secara independen, maka mereka harus dibagi menjadi dua tiket.

Lihatlah dari sudut pandang orang lain yang menggunakan sistem, muncul beberapa bulan kemudian. Mereka menemukan bug di program. Mereka berkeliling dan melihat bahwa ada tiket dukungan yang cocok dengan masalah yang mereka hadapi. Dan hei, sudah ditutup! Luar biasa! Sudah diperbaiki dalam versi terbaru! Jadi, mereka memperbarui ... dan bug itu masih ada? Apa yang salah dengan pengembang bodoh ini?!?

Sebenarnya tidak ada apa-apa. Ternyata ada yang salah dengan orang yang mengirimkan laporan bug. Mereka mengirimkan dua bug di tiket yang sama. Yang satu mudah diperbaiki, dan diperbaiki dengan cepat, dan yang lainnya tidak. Bahkan jika Anda menggunakan sesuatu seperti fix-feedback-resolved-closed, masih bisa menjadi kurang jelas apa yang terjadi, terutama kepada pengamat luar.

Jauh lebih baik untuk memberi setiap bug tiketnya sendiri, dan jika Anda memiliki banyak bug yang terkait tetapi tampaknya berbeda, sebagian besar sistem pelacakan bug memiliki fitur yang memungkinkan Anda menautkan satu bug dengan bug lainnya. (Dan jika tidak, Anda bisa memasukkannya ke dalam laporan. "Lihat juga bug # 12345.")