Status cacat: "TIDAK AKAN MEMPERBAIKI" vs. "Dibatalkan"

13

Saya telah terlibat dalam beberapa proyek baik sebagai penguji atau pengembang. Dalam banyak proyek ada status cacat berikut:

  1. Tidak akan memperbaiki
  2. Dibatalkan

Apakah Anda menggunakan status seperti itu dan bagaimana Anda membedakannya? Saya bertanya, karena kebanyakan orang tidak dapat menjelaskan perbedaannya. Pemahaman saya adalah:

TIDAK AKAN MEMPERBAIKI - pengembang tidak akan memperbaiki cacat, karena itu bukan cacat;
Dibatalkan - cacat tidak boleh diperbaiki, karena prioritas terendah

tools issue-tracking sergionni
sumber

Jawaban:

12

Seperti yang dicatat orang lain, nama-nama status ini tidak begitu jelas. Saya lebih suka nama status yang lebih tepat dan rinci:

  • Won't Fix (biaya perbaikan ini tidak dibenarkan)
  • Solusi Disediakan (dan itu cukup untuk membuat pengguna senang)
  • Bukan Bug (tapi fitur)
  • Tidak Dapat Diproduksi Kembali
  • Duplikat
Péter Török
sumber
Solusi Disediakan, ini adalah sesuatu yang baru, status lainnya diketahui
sergionni
1
"Fix in Later Version" dapat menjadi status berguna lainnya. Biasanya kami menggunakannya di dekat akhir periode pengembangan, karena kami tidak punya waktu atau sumber daya untuk memperbaikinya (meskipun kami ingin). Sampai diperbaiki, pelanggan diberi tahu melalui SVA (penilaian kerentanan perangkat lunak). Menyingkirkan SVA itu, memberi kami insentif ekstra untuk memperbaikinya di rilis berikutnya.
Sparky
Anda bisa saja mengubah versi tugas di Jira alih-alih menggunakan status "Perbaiki di Versi Selanjutnya"
sergionni
6

Saya pikir Anda sudah mendapat jawabannya

Tidak akan memperbaiki - akan berlaku untuk bug kecil yang tidak berdampak atau mungkin dalam versi yang lebih lama karena itu tidak sepadan dengan biaya pengembang waktu untuk memperbaikinya tetapi mereka mengakui bahwa itu adalah bug.

Dibatalkan - Ini bisa jadi laporan bug yang buruk kalau itu tidak dapat direproduksi atau mungkin itu bukan bug sama sekali.


sumber
yah Saya menganggap "dibatalkan" untuk diterapkan ketika "perbaikan" sedang dalam pengembangan tetapi tidak selesai karena pada pemutaran kedua ditemukan tidak diperlukan (baik karena seluruh bagian kode diganti dengan sesuatu yang lain atau karena ditemukan tidak menjadi masalah). "Tidak akan memperbaiki" bisa berarti memutuskan itu bukan masalah atau sangat kecil sehingga tidak layak investasi yang diperlukan untuk memperbaikinya.
jwenting
5

Mengambil 2 deskripsi Anda:

TIDAK AKAN MEMPERBAIKI - pengembang tidak akan memperbaiki cacat, karena itu bukan cacat;

Dibatalkan - cacat tidak boleh diperbaiki, karena prioritas terendah

Jelas bahwa perbedaan yang dimaksudkan adalah:

TIDAK AKAN MEMPERBAIKI - Ini tidak rusak, kami sengaja ditujukan untuk perilaku ini (Misalnya, fitur bukan bug);

Dibatalkan - Kami setuju ini rusak, tetapi sangat sepele / tidak penting kami tidak akan pernah repot untuk memperbaikinya.

Dan McGrath
sumber
sebenarnya, ada status "Bukan bug" juga, yang tertutup untuk perilaku "Tidak akan memperbaiki" Anda
sergionni
Deskripsi ini sangat masuk akal jika Anda membalikkannya: "Tiket dibatalkan karena ini bukan bug", "Kami tidak akan memperbaikinya karena sepele"
Kevin Laity
@ Kevin, saya sepenuhnya setuju. Saya berpendapat mereka sebenarnya lebih masuk akal ketika dibalik. Saya menjawab berdasarkan murni berdasarkan informasi dalam pertanyaan.
Dan McGrath
1

Di perusahaan saya, kami tidak menggunakan status seperti itu dan saya pikir itu bukan pilihan label yang baik untuk negara yang Anda gambarkan.

Negara kami terdiri dari

Baru
Sedang Berlangsung
Siap Untuk Tes
Tertutup
Dibuka Kembali

Dan negara harus sesederhana ini. Apa pun yang lebih terperinci seperti bug atau prioritas yang terlalu rendah harus dimasukkan ke dalam catatan.

Tim
sumber
1

Dibatalkan tampaknya menyiratkan bahwa salah satu perbaikan dimulai tetapi kemudian dihentikan, mungkin karena ternyata membutuhkan lebih banyak sumber daya daripada yang diperkirakan sebelumnya dan lebih dari yang dibenarkan cacat atau bahwa orang yang masuk ke tiket cacat mengubah pikiran mereka bahwa itu adalah cacat. Tidak akan memperbaiki sepertinya ada kesepakatan bahwa cacat memang ada tetapi ada alasan untuk tidak ingin memperbaikinya saat ini (biaya vs manfaat, dampak potensial pada fungsi lainnya, dll.).

Jason
sumber