Status "Buka" dan "Dibuka Kembali"


9

Mengapa sistem pelacak masalah biasanya memiliki status "Terbuka" dan "Dibuka" yang berbeda?

Jawaban:


6

Masalah-masalah yang Terbuka umumnya merupakan kejadian pertama dari masalah apa pun itu.

Masalah yang dibuka kembali adalah 1) terjadi kembali dan / atau 2) tidak diperbaiki dengan benar. Mungkin ada sejumlah alasan untuk itu - yang utama mungkin sering dikaitkan dengan deskripsi asli masalah kepada pengguna akhir.

Saya tidak berpikir toko yang masuk akal akan menggunakannya sebagai metrik untuk menilai staf teknis [sendirian] tetapi berguna sebagai ukuran untuk mengidentifikasi seberapa efektif tanggapan, dan juga menandakan masalah mendasar yang perlu ditangani.


4

Perusahaan lama saya menggunakan status itu untuk melacak berapa kali masalah Anda masuk ke "Dibuka Kembali" untuk melihat seberapa buruk pengembang Anda. Mereka berpikir bahwa ada korelasi antara berapa kali item kerja mendapat "Dibuka Kembali" dan nilai Anda sebagai programmer.

Saya tidak bekerja di sana lagi.


ugh, langkah bagus Robert. Di mana pun yang menggunakan metrik dev seperti ini untuk menilai dev, itu bukanlah tempat yang baik.
ozz

1
ya, jika Anda akhirnya melacak segala jenis metrik, seseorang pasti akan menggunakannya untuk kejahatan.
Robert Greiner

Saya pernah membaca tentang sebuah perusahaan yang menghargai penguji untuk bug yang ditemukan, dan pengembang untuk waktu rata-rata untuk memperbaiki bug. Anda menebaknya. Pengembang mengatakan kepada penguji apa "bug" yang harus dicari ... setelah dilaporkan, mereka "memperbaiki" mereka dengan sangat cepat ...
mattnz

@ mattnz ya, biasanya ketika Anda memiliki metrik jenis bullcrap ini, devs / penguji selalu menemukan cara untuk memiringkan hal-hal yang menguntungkan mereka.
Robert Greiner

3

Seumur hidup bug sering:

  1. Terbuka
  2. Terselesaikan
  3. (Opsional) Dibuka Kembali
  4. Terselesaikan
  5. (Opsional) Ke: 3
  6. Tutup

yaitu.

Seseorang menemukan bug dan membukanya di pelacak. Dev memperbaikinya sebaik mungkin dengan pemahaman mereka tentang masalah tersebut. Penguji menguji ulang untuk memverifikasi perbaikan bekerja dan membuka kembali jika mereka dapat memverifikasi bahwa itu tidak. Jika perbaikan diverifikasi maka bug ditutup.

Skenario lain, adalah bahwa perbaikan di tempat lain menyebabkan kemunduran dan bug harus diperbaiki kembali. Dengan demikian, dibuka kembali.


2

Mungkin juga untuk membuatnya lebih jelas bahwa masalah tersebut membutuhkan perhatian yang lebih dekat atau perhatian yang lebih cepat karena terus menjadi masalah setelah masalah itu diyakini telah diselesaikan.


2

Dibuka berarti itu adalah masalah baru. Dibuka kembali berarti adalah masalah yang Dibuka-> Clossed dan kemudian Dibuka lagi.

Kenapa dibuka lagi? Mungkin pengembang dan penguji berpikir masalah itu sudah diperbaiki tetapi tidak benar-benar diperbaiki. Atau mungkin masalah ini benar-benar diperbaiki tetapi beberapa perubahan kode selanjutnya menyebabkan masalah ini terulang kembali. Tidak masalah bagaimana tetapi masalah yang dibuka kembali adalah pertanda buruk dan karenanya dikategorikan berbeda.


1

Cara kami menggunakannya di sini:

Tugas Baru: Dibuat pada awal proyek untuk menunjukkan semua pekerjaan yang perlu dilakukan. Itu terbuka sampai seseorang kode itu, maka itu diselesaikan. Ini hanya dibuka kembali jika sesuatu tidak diimplementasikan, atau jika fungsi berubah dan pengembang harus kembali dan menghabiskan banyak waktu untuk mengerjakannya.

Bug / Cacat: Dibuka oleh seseorang di QA atau pengembang lain yang memeriksa keseluruhan produk yang berfungsi. Jika Anda diberi bug, Anda memperbaikinya dan kemudian menyelesaikannya dan kembali ke pengujian. Jika QA merasa belum diperbaiki mereka akan membukanya kembali dan melampirkan info lain yang mereka miliki. Siklus Diselesaikan / Dibuka Kembali bisa berlanjut hingga QA puas bahwa bug telah diperbaiki, kemudian mereka menutup tiket.

Jadi, pada dasarnya Anda menggunakan Reopen untuk mengatakan bahwa tiket telah dilihat dan seseorang telah mengerjakannya sehingga mereka merasa terselesaikan, tetapi bukan itu masalahnya.


1

Ini pada dasarnya jenis konsistensi: Bug (atau masalah secara umum) "terbuka" jika telah dibuat dari awal. Ini "dibuka kembali" jika telah dibuat setelah pemrosesan sebelumnya dilakukan.

Untuk pengembang (atau siapa pun yang menangani masalah ini) seharusnya tidak ada bedanya. Suatu penerbitan telah dinaikkan dan sekarang harus diproses.

Namun status "buka kembali" yang berbeda masih dapat berguna untuk sejumlah skenario:

Pertama, ini dapat digunakan sebagai cara melacak apakah proses penjaminan kualitas Anda berfungsi atau tidak. Jika QA melakukan segalanya dengan benar, bug seharusnya tidak pernah terjadi setelah diperbaiki. Jadi, Anda bisa mengatakan berapa kali bug telah diatur ke status "buka kembali" adalah berapa kali QA belum cukup melakukan tugasnya dengan benar. Ini tentu saja menyiratkan bahwa ada proses QA yang baik didirikan dan bahwa pengguna secara aktif berpartisipasi dalam proses dan tahu kapan harus "membuka" dan kapan "membuka kembali" masalah.

Penggunaan lain adalah bahwa, ketika bug terjadi lagi, Anda tidak perlu memunculkan masalah lain tetapi dapat menambahkan informasi masalah yang sudah ada (dan karena itu menyimpan informasi penting seperti riwayat masalah, file tambahan yang telah diunggah, komentar sebelumnya, dan seterusnya) tetapi masih menunjukkan "hei, ini terjadi lagi ).


1

Salah satu alasan utama untuk melacak "buka kembali" adalah bahwa hal itu dapat memberi Anda indikasi masalah rute yang mendalam, daripada slipup sederhana dan pengawasan detail. Jika modul atau fungsi tertentu memiliki banyak "repopens", itu menunjuk pada kelemahan yang perlu ditangani. Sejumlah besar poin terbuka untuk pekerjaan yang terburu-buru dan / atau latihan yang ceroboh.

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.