Bagaimana cara mengklasifikasikan keparahan bug untuk melengkapi klasifikasi prioritas kami?


14

Pada pekerjaan saya saat ini, kami memiliki bug Rendah, Sedang, Prioritas tinggi.

  • Bug prioritas rendah adalah kesalahan kecil yang tidak menghentikan pengiriman atau menyebabkan masalah nyata bagi pengguna mana pun.
  • Bug prioritas sedang menyebabkan beberapa masalah pengguna internal tetapi memiliki solusi yang diketahui.
  • Bug prioritas tinggi adalah masalah yang akan dilihat pelanggan, dapat merusak data, atau merusak sistem.

Bagaimana cara mengklasifikasikan keparahan bug untuk melengkapi klasifikasi prioritas kami?


13
Mengapa Anda memiliki nama yang tidak mungkin dipahami seperti "rendah", "sedang" dan "tinggi"? Mengapa tidak menggunakan hanya menggunakan kata-kata nyata seperti "crash", "korupsi", "solusi yang diketahui", dan "jengkel"?
S.Lott

1
Karena saya tidak ada hubungannya dengan penamaan level prioritas. Saya hanya bisa menggunakan apa yang diberikan kepada saya. Aku suka namamu untuk mereka.
Erin

2
Kami memiliki tingkat ke-4, "Kritis". Ini lebih buruk dari yang Anda akan diklasifikasikan sebagai "tinggi" (mis. Kegagalan server produksi tiba-tiba).
FrustratedWithFormsDesigner

1
Saya menemukan Rendah tidak pernah digunakan ... semua orang mengatakan Sedang, Tinggi, atau Mendesak
Rachel

1
@ Thorbjørn Ketika sebuah kesalahan membutuhkan lebih banyak waktu untuk dilacak daripada diperbaiki di sana ketika saya melihatnya, saya cenderung untuk memperbaikinya. (Ingat, kami tidak memiliki proses QA formal, jadi tidak ada tugas orang lain untuk memasukkan bug ke dalam pelacak. Ini lebih merupakan daftar "untuk dikerjakan nanti" bagi kami daripada antrian pekerjaan dari orang lain.)
CodexArcanum

Jawaban:


23

Kami mengklasifikasikan bug dan cacat kami berdasarkan prioritas dan tingkat keparahannya.

Tingkat prioritas adalah indikasi seberapa mendesaknya untuk memperbaiki / memperbaiki masalah (mendesak, tinggi, sedang, rendah, tidak ada).

Tingkat keparahan, membantu kami mengidentifikasi berapa banyak atau jenis kerusakan yang dapat disebabkan oleh cacat (berbahaya / destruktif, terdegradasi dan tidak ada solusi, terpengaruh tetapi ada solusi, gangguan / kosmetik, tidak ada dampak).

Biasanya, semakin berbahaya dan destruktif bug, semakin tinggi prioritasnya. Namun, itu tidak dijamin. Akibatnya kita dapat menemukan bug yang terdaftar sebagai berbahaya dan destruktif, tetapi karena kelangkaan situasinya, atau jumlah perubahan yang mungkin diperlukan untuk memperbaikinya, prioritasnya secara teori dapat menjadi sangat rendah.


10

Tingkat keparahan sangat subyektif dengan jenis produk yang Anda buat dan bisnis Anda. Pada pekerjaan terakhir saya, kami membuat pilot otomatis untuk kapal kontainer / kapal pesiar besar, jadi beratnya kami

  • Sangat Tinggi - Gunung Es Di Depan! Oh, tunggu, sepertinya kendali kapal bisa hilang atau membingungkan siapa yang punya kendali! Seseorang mencari tahu bagaimana mengubah kapal ini !!!
  • Tinggi - Keluhan penerimaan pelanggan, kapal pesiar berubah terlalu cepat, pelanggan menumpahkan minuman mereka. Kami tidak dapat menggunakan barang-barang Anda sampai ini diperbaiki!
  • Medium - Fungsi yang akan meningkatkan kemudahan penggunaan bagi pelanggan / teknisi lapangan. Hal-hal yang menghemat waktu orang.
  • Barang kosmetik rendah

Saya membayangkan tingkat keparahan / prioritas akan sangat berbeda jika Anda membuat aplikasi web dan Anda memiliki model bisnis / basis pelanggan yang sama sekali berbeda. Ini pada akhirnya tentang apa yang pelanggan Anda harapkan dan seberapa marah mereka tentang masalah ini :)


Anda harus terlalu memikirkan klasifikasi barang kosmetik Anda. Bug kosmetik menunjukkan bahwa Anda tidak peduli. Jika Anda tidak peduli maka bug yang lebih buruk tidak dikaitkan dengan nasib buruk dan dimaafkan tetapi dikaitkan dengan kecerobohan.
gnasher729

@ gnasher729: Apa perbedaan pendapat spesifik Anda? Apakah Anda mengatakan bahwa bug kosmetik yang tidak signifikan mempengaruhi berapa banyak waktu pelanggan menghabiskan mendapatkan perangkat lunak untuk pekerjaan harus diklasifikasikan sebagai lebih penting daripada bug yang tidak mempengaruhi itu dan tidak kosmetik? Atau apa? Prioritas relatif, tidak absolut, dan selalu ada lagi yang harus dilakukan.
Nathan Tuggy

0

Kriteria keparahan yang saya gunakan:

  • Apakah itu mencegah pengguna mendapatkan apa yang diinginkannya dari program?
  • Apakah terlihat jika pengguna melakukan tugas-tugas tipikal?
  • Apakah itu mengungkapkan informasi yang masuk akal atau memungkinkan untuk melakukan tindakan yang tidak sah?

Tingkat keparahan bug tertentu adalah kombinasi dari poin-poin ini.


1
Juga penting adalah jumlah pengguna yang terpengaruh. Dan pengguna mana , jika aplikasi Anda memiliki fitur yang tidak tersedia untuk semua.
FrustratedWithFormsDesigner

-1

Klasifikasi bug berdasarkan faktor gangguannya, yang dapat menghentikan orang membeli perangkat lunak. Bug yang tidak memengaruhi pengiriman atau menyebabkan masalah nyata bagi pengguna mungkin mengganggu saya setiap kali saya menemui bug. Dan akhirnya Anda kehilangan pengguna dan bagian dari penghasilan Anda.

Sekarang jika Anda menggabungkan bug semacam itu dengan antarmuka pengguna yang telah diubah tanpa alasan yang jelas dan tanpa manfaat nyata bagi pengguna, maka Anda memiliki pemenang mutlak yang akan membuat orang membenci perangkat lunak Anda.

Jangan biarkan itu terjadi. Jangan kirim bug yang membuat pelanggan berpikir bahwa Anda tidak memberikan ****.


ini bahkan tidak berusaha menjawab pertanyaan yang diajukan, "Bagaimana cara mengklasifikasikan keparahan bug untuk melengkapi klasifikasi prioritas kami?" Lihat Cara Menjawab
agas
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.