Langkah-langkah untuk memelihara basis data bug yang baik

Mempertahankan basis data bug adalah penting untuk setiap proyek. Saya terbiasa menyimpan yang berikut di database bug

• Tanggal waktu penerbitan
• Siapa yang ditugaskan
• Apakah sudah dipecahkan atau belum
• Jika dipecahkan maka, waktu tanggal dipecahkan

Apakah itu cukup untuk memelihara basis data bug yang baik?

Basis data bug yang baik mungkin memiliki yang berikut

// Tanggal Waktu Terkait

• Menerbitkan waktu tanggal bug
• Memperbaiki / memecahkan waktu tanggal yang diharapkan
• Jika dipecahkan maka, waktu tanggal dipecahkan

// Ditugaskan oleh + Ke

• Ditugaskan oleh (terdeteksi oleh)
• Ditugaskan untuk

// Perilaku bug

• Perilaku yang diamati (buggy)
• Tangkapan Layar (Apakah mungkin)
• Langkah-langkah lengkap untuk mereproduksi bug
• Perilaku yang diharapkan

// Prioritas

• Prioritas bug

// Tautan, Status, dan Lainnya

• Tautan bug terkait
• Status bug
• Apakah sudah dipecahkan atau belum
• Jika dipecahkan maka, bagaimana dipecahkan dengan penjelasan

EDIT: Saya juga ingin merekomendasikan

• Dalam revisi / cabang apa bug ditemukan
• Dalam revisi / cabang apa bug telah diperbaiki

EDIT: Saya suka komentar @ jgauffin

• Tidak akan memperbaiki, Bukan bug, Gandakan, Terpecahkan

EDIT: Sistem basis data bug yang baik juga dipertahankan

• Matriks penugasan tanggung jawab

Mungkin ada sejumlah bidang khusus yang perlu Anda log, tergantung pada kebutuhan proyek. Saya datang dengan daftar berikut yang mungkin perlu Anda pertimbangkan juga:

• Masalah DateTimeBug / Cacat
• Deskripsi Bug - langkah-langkah untuk membuat kembali.
• Lingkungan tempat ditemukannya (Dev, QA, QC, Staging, Prod)
• Tangkapan layar masalah ini
• Siapa yang mencatatnya (terdeteksi oleh)
• Siapa yang ditugaskan (ditugaskan oleh)
• Tingkat Permasalahan Bug (Rendah, Sedang, Tinggi)
• Resolusi yang diharapkan DateTime
• Triage Negara (Diusulkan, Sedang Berlangsung, Diatasi, Ditutup)
• Bug Ditutup DateTime- ketika bug diselesaikan dan ditutup
• Ditugaskan untuk diuji (diuji oleh)

Sunting: Sebagian besar informasi umum yang memiliki nilai untuk dilacak dijelaskan dengan baik dalam perangkat lunak seperti Bugzilla . Bugzilla adalah bugtracker untuk keperluan umum dan alat pengujian yang awalnya dikembangkan dan digunakan oleh proyek Mozilla, dan dilisensikan di bawah Lisensi Publik Mozilla- dan GRATIS . Saya akan sangat menyarankan mengambil mereka sebagai contoh utama dan memperluasnya pada kebutuhan proyek Anda.

Sebagian besar bidang yang bermanfaat tampaknya telah dicakup oleh jawaban lain, tetapi beberapa yang menurut saya berguna adalah:

• Dalam revisi / cabang apa bug ditemukan.
• Dalam revisi apa / cabang sudah diperbaiki.

Ini sedikit lebih spesifik daripada tanggal / waktu bug ditemukan / diperbaiki.

Jika perangkat lunak Anda berjalan pada beberapa platform (OS atau perangkat keras), Anda mungkin juga menginginkan bidang yang mencantumkan platform tempat bug terjadi.

Tetapi ada lebih banyak hal untuk memelihara basis data bug dari pada bidang apa yang seharusnya dikandungnya. Anda juga perlu mempertimbangkan bagaimana Anda menggunakan basis.

Usahakan agar jumlah bug yang terbuka / tidak terselesaikan serendah mungkin. Ini mungkin tampak jelas, tetapi mungkin lebih sulit dari yang diharapkan, setidaknya untuk proyek yang lebih besar. Saya sering melihat orang terlalu takut untuk menutup masalah yang tidak dapat direproduksi atau kekurangan informasi yang tidak pernah diberikan oleh pengirim asli masalah tersebut. Juga bug yang telah bertelur selamanya dan terakhir terlihat dalam versi kuno perangkat lunak tidak boleh dibiarkan bertebaran. Ini membuat basis data tumbuh dengan masalah yang mungkin atau mungkin bukan masalah nyata, dan memperlambat pengembangan.

Anda akan sering perlu melihat riwayat bug _ mungkin dapat diselesaikan, kemudian dibuka kembali, kemudian diselesaikan lagi, dll. Jadi, selain apa yang telah disarankan, saya akan menyarankan Anda untuk memiliki tabel terpisah untuk melacak dari sejarah bug setiap kali dibuka (kembali). Tabel tersebut akan berada dalam hubungan banyak-ke-satu dengan tabel bug dan kemungkinan akan memiliki bidang seperti:

• Tanggal Dibuka
• Dibuka oleh
• Tanggal Terselesaikan
• Diselesaikan oleh
• Waktu yang dihabiskan
• Bagaimana terselesaikan
• dll.

Anda juga mungkin membutuhkan tabel serupa untuk melacak kepada siapa dan kapan bug tersebut ditetapkan, terutama jika Anda bekerja dalam tim besar.

Saya juga menyarankan Anda melihat sistem yang ada. IMHO Jira adalah salah satu sistem pelacakan masalah terbaik. Ini memiliki fitur yang sangat kaya, dan Anda bisa menggunakan beberapa di antaranya sebagai panduan untuk sistem Anda sendiri.

Proses pelacakan bug sama pentingnya dengan data. Coba pikirkan hal berikut juga:

• Bagaimana cara Pengguna melaporkan bug?
• Siapa yang memasukkan bug ke dalam repositori?
• Siapa yang dapat mengonfirmasi adanya bug?
• Siapa yang dapat mengonfirmasi bahwa bug telah diatasi?
• Siapa yang memberi tahu pengguna akhir bahwa bug telah diatasi?

Bangun Bagan RACI sehingga semua orang di tim Anda (termasuk pengguna akhir mengetahui tanggung jawab mereka. Gabungkan ini dengan teknik entri data yang tepat dan Anda akan melihat lebih banyak nilai dengan sedikit usaha ekstra.