Nama perusahaan yang salah eja di halaman beranda dan kerusakan pada fitur ekspor yang jarang digunakan: mana yang harus Anda perbaiki terlebih dahulu? Argumen seperti inilah yang menjadi alasan tim penguji memisahkan keparahan vs prioritas. Yang satu menggambarkan kerusakan teknis, dan yang lainnya menggambarkan urgensi bisnis.

Tanpa pembedaan tersebut, setiap bug akan diberi label “kritis”, label tersebut kehilangan maknanya dan pengembang tidak lagi mempercayainya. Panduan ini memberi Anda definisi dan contoh yang jelas, serta proses sederhana untuk mengambil keputusan. Contoh yang diberikan bersifat ilustratif, dan skala pastinya berbeda antara tim dan alat.

Jawaban singkatnya

Keparahan jawaban: seberapa parah pengaruh bug ini terhadap produk? Kecelakaan atau kehilangan data merupakan hal yang parah, sedangkan kesalahan tampilan tidak.

Jawaban Prioritas: seberapa cepat kita harus memperbaikinya? Hal ini bergantung pada pelanggan yang terkena dampak, tenggat waktu, pendapatan, paparan hukum, dan reputasi merek.

Bayangkan sebuah rumah sakit. Tingkat keparahannya adalah seberapa serius kondisi pasien. Prioritas adalah urutan perawatan pasien, yang juga bergantung pada faktor lain, seperti siapa yang dapat menunggu dengan aman dan sumber daya apa yang tersedia secara gratis.

Tingkat keparahan vs prioritas berdampingan

Tingkat keparahan

Kebanyakan tim menggunakan sekitar empat atau lima level. Berikut adalah skala umum:

Tingkat prioritas

Tuliskan arti setiap level bagi tim Anda, idealnya dengan target waktu respons untuk masing-masing level. “P1 berarti seseorang memulai dalam waktu satu jam” jauh lebih berguna daripada “P1 berarti sangat penting”.

Empat kombinasi, beserta contohnya

Cara paling jelas untuk memahami hal ini adalah dengan melihat setiap kombinasi:

Tingkat keparahan tinggi, prioritas tinggi

Pembayaran gagal untuk semua orang, bisnis kehilangan uang setiap menitnya, dan tidak ada solusi. Ini adalah kasus yang jelas: tinggalkan semuanya dan perbaiki.

Tingkat keparahan tinggi, prioritas rendah

Aplikasi lumpuh saat mengekspor ke format lawas. Secara teknis, ini adalah kegagalan yang serius. Namun jika hanya sebagian kecil pengguna yang pernah menyentuh fitur ini, dan format modern berfungsi dengan baik, maka fitur tersebut dapat menunggu jadwal rilis.

Tingkat keparahan rendah, prioritas tinggi

Nama perusahaan salah eja di halaman beranda. Tidak ada yang rusak, dan tidak ada data yang terancam. Namun setiap pengunjung melihatnya, hal ini merusak kepercayaan, dan jika peluncuran besar dijadwalkan besok, maka hal tersebut perlu diperbaiki hari ini.

Tingkat keparahan rendah, prioritas rendah

Kesalahan ketik kecil pada artikel bantuan yang jarang dikunjungi. Perbaiki bila nyaman. Jika simpanan Anda penuh dengan hal-hal tersebut, pertimbangkan untuk mengelompokkannya ke dalam satu tugas pembersihan.

Satu bug, dua prioritas berbeda

Cacat yang sama mungkin memerlukan prioritas berbeda tergantung pada konteksnya. Misalkan email konfirmasi pesanan keluar dengan logo yang salah.

Tingkat keparahannya tidak berubah, karena dampaknya terhadap sistem tetap sama. Namun situasi bisnis memang demikian. Waktu juga dapat mengubah banyak hal. Bug yang merupakan P3 hari ini mungkin menjadi P1 pada minggu sebelum klien utama ditayangkan.

Siapa yang menentukan tingkat keparahan dan prioritas?

• Penguji biasanya mengusulkan tingkat keparahan, karena mereka telah melihat perilaku dan memahami dampaknya terhadap sistem.
• Pemilik atau manajer produk biasanya menentukan prioritas, karena mereka mempertimbangkan pelanggan, pendapatan, dan peta jalan.
• Pengembang menambahkan informasi tentang penyebabnya, risiko perbaikan, dan berapa lama waktu yang dibutuhkan.
• Tim pendukung memberikan bukti mengenai berapa banyak pelanggan yang terkena dampak dan seberapa parah dampaknya.

Sumber dan tim memiliki tanggung jawab yang berbeda-beda, dan dalam startup kecil, satu orang dapat melakukan semuanya. Yang penting adalah semua orang tahu siapa yang mengambil keputusan terakhir, jadi perselisihan diakhiri dengan keputusan.

Cara menilai bug

Jika Anda tidak yakin, kerjakan pertanyaan-pertanyaan ini.

Untuk tingkat keparahan:

1. Apakah datanya hilang atau rusak, atau informasi pribadi terekspos?
2. Apakah ini menghentikan fungsi utama agar tidak berfungsi?
3. Apakah ada solusinya, dan dapatkah pengguna biasa menemukannya?
4. Berapa banyak fitur yang terpengaruh?

Untuk prioritas:

1. Berapa banyak pengguna yang terpengaruh, dan yang mana?
2. Apakah hal ini memerlukan biaya, atau menimbulkan risiko hukum atau kepatuhan?
3. Apakah akan ada rilis, demo, atau penjualan?
4. Seberapa terlihatnya hal tersebut, dan apakah hal tersebut dapat merusak reputasi Anda?
5. Apakah itu menghalangi pekerjaan lain, seperti pengujian?

Menjalankan triase bug

Triage adalah pertemuan rutin di mana tim meninjau bug baru dan memutuskan apa yang akan terjadi selanjutnya. Format sederhana berfungsi dengan baik:

1. Persiapkan. Penguji memastikan bahwa setiap bug baru memiliki langkah-langkah yang jelas, bukti, dan tingkat keparahan yang diusulkan.
2. Konfirmasi. Periksa apakah dapat direproduksi dan bukan duplikat.
3. Putuskan. Sepakati tingkat keparahan, tetapkan prioritas, dan tetapkan pemilik.
4. Tutup loop. Tolak, tunda, atau jadwalkan setiap bug, dan catat alasannya.

Jaga agar tetap singkat dan sering. Selama hari-hari terakhir sebelum rilis, triase harian selama 15 menit adalah hal biasa. Tingkat keparahan dan prioritas juga menentukan keputusan rilis Anda, jadi sepakati aturan terlebih dahulu, seperti “tidak ada bug S1 atau S2 yang terbuka saat rilis”, sebagai bagian dari kriteria keluar.

Tingkat keparahan dan prioritas dalam laporan bug

Entri yang singkat dan jelas membantu semua orang membuat keputusan yang baik:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Angka-angka tersebut adalah contohnya. Dalam laporan nyata, gunakan angka terukur dari catatan Anda, dan jelaskan alasan Anda. Pelajari lebih lanjut di panduan kami tentang cara menulis laporan bug. Mengetahui apa arti kode kesalahan juga akan membantu, jadi siapkan lembar contekan kode status HTTP kami.

Kesalahan umum

• Memperlakukan keduanya sebagai bidang yang sama. Jika keduanya selalu cocok, Anda kehilangan informasi berguna.
• Meningkatkan tingkat keparahan untuk mendapatkan perhatian. Begitu semuanya menjadi penting, tidak ada yang penting.
• Membiarkan penguji menetapkan prioritasnya sendiri. Mereka jarang mendapatkan gambaran bisnis yang lengkap.
• Jangan pernah meninjau backlog. Prioritas menjadi basi, jadi periksa kembali bug lama secara rutin.
• Tidak ada definisi tertulis. Tanpa definisi tersebut, orang akan memberikan label yang berbeda, dan Anda akhirnya akan memperdebatkan kata-kata.
• Mengabaikan penumpukan dengan tingkat keparahan rendah. Lima puluh masalah kecil dapat membuat produk terasa rusak, meskipun tidak ada masalah yang serius.

Penutup

Pisahkan kedua pertanyaan ini: seberapa buruknya, dan seberapa cepat harus diperbaiki? Sepakati definisi tertulis untuk setiap tingkat, dan jelaskan siapa yang memutuskan. Sebagai langkah selanjutnya, ambil sepuluh bug tertua di pelacak Anda dan nilai ulang bug tersebut menggunakan pertanyaan di atas. Anda mungkin akan menemukan beberapa yang harus dipindahkan, dan beberapa yang harus ditutup.

Pertanyaan yang sering diajukan

Teruslah belajar