1.6.2 Severity vs Priority: Simulasi Penentuan Prioritas Bug ha

Dalam proses pengujian perangkat lunak, tugas QA tidak hanya menemukan bug, tetapi juga perlu menentukan mana yang harus diperbaiki terlebih dahulu. Tidak semua bug bersifat mendesak, ada yang bersifat fatal dan harus segera diperbaiki, ada juga yang bisa ditunda karena dampaknya kecil atau jarang terjadi. Di sinilah peran konsep Severity dan Priority menjadi sangat penting.

Meskipun kedua istilah ini sering digunakan secara bersamaan, Severity dan Priority bukanlah hal yang sama. Keduanya mewakili dua aspek yang berbeda dalam menilai sebuah bug.

 

Severity vs Priority

Severity (tingkat keparahan) mengacu pada seberapa besar dampak teknis dari bug terhadap sistem. Ini menggambarkan seberapa besar kerusakan yang ditimbulkan bug terhadap fungsionalitas aplikasi. Penilaian severity biasanya dilakukan oleh QA saat bug pertama kali dilaporkan.

Berikut adalah kategori umum severity yang sering digunakan dalam pengujian perangkat lunak:

●      Critical: Bug menyebabkan sistem tidak bisa digunakan sama sekali atau menyebabkan data hilang.

●      High: Fitur utama rusak, tetapi sistem masih bisa dijalankan sebagian.

●      Medium: Masalah muncul pada fitur tambahan, tetapi tidak menghambat proses utama.

●      Low: Masalah minor seperti tampilan antarmuka (UI) atau typo yang tidak memengaruhi logika.

Adapun beberapa contoh bug berdasarkan tingkat severity-nya untuk membantu memahami perbedaannya dalam konteks nyata, diantaranya:

●      Critical Severity: Aplikasi crash saat membuka halaman utama.

●      Medium Severity: Teks tidak muncul di halaman bantuan.

●      Low Severity: Terdapat salah ejaan, misalnya “Regristration” seharusnya “Registration”.

 

Priority (tingkat urgensi) mencerminkan urgensi perbaikan, atau seberapa penting bug tersebut untuk segera diselesaikan berdasarkan kebutuhan bisnis, pengalaman pengguna, atau jadwal rilis. Penilaian priority sering kali ditentukan bersama oleh QA Lead, Product Owner, atau Project Manager.

Berikut adalah kategori umum priority yang sering digunakan dalam pengujian perangkat lunak:

●      High (P1): Harus diperbaiki segera karena berdampak besar terhadap operasi atau user.

●      Medium (P2): Penting, tetapi tidak mendesak. Bisa diperbaiki setelah yang lebih krusial.

●      Low (P3): Tidak perlu segera diperbaiki, bisa ditunda hingga siklus selanjutnya.

Adapun beberapa contoh bug berdasarkan tingkat priority-nya untuk membantu memahami perbedaannya dalam konteks nyata, yaitu:

●      High Priority: Promo 11.11 tidak muncul saat user checkout → harus diperbaiki dalam waktu 1 hari.

●      Low Priority: Warna tombol login tidak sesuai brand → bisa diperbaiki pada literasi selanjutnya.


Menentukan severity dan priority secara tepat sangat penting dalam proses manajemen bug. Kesalahan dalam mengklasifikasikan dapat menyebabkan:

●      Bug krusial terabaikan karena dianggap “tidak penting”.

●      Developer membuang waktu memperbaiki hal kecil yang bisa ditunda.

●      Risiko regresi atau penundaan rilis meningkat.

 

Dalam konteks Agile dan pengembangan cepat, QA perlu memiliki kepekaan terhadap konteks produk dan pengguna akhir agar dapat membantu menyampaikan klasifikasi bug secara efektif dan bisa dipertanggungjawabkan. Untuk memberikan pemahaman yang lebih jelas, berikut perbandingan keduanya berdasarkan beberapa aspek.

Aspek

Severity

Priority

Fokus

Dampak teknis

Urgensi bisnis

Siapa yang menilai

QA / Tester

QA Lead / PO / PM

Kapan ditentukan

Saat bug dilaporkan

Saat bug triage atau perencanaan

Contoh pertimbangan

Crash, data hilang, error logic

Target rilis, user experience, reputasi

Tabel 1.6.1 Perbedaan Severity dan Priority

Tidak semua bug perlu ditangani dengan urgensi yang sama. Matriks ini membantu membedakan prioritas penanganan berdasarkan tingkat keparahan (severity) dan urgensinya (priority), sehingga tim dapat fokus pada isu yang paling berdampak.

Gambar 1.6.2 Matriks SLA Berdasarkan Severity dan Priority

 

Studi Kasus: Penangan Bug Berdasarkan Severity vs Priority

1. Kasus 1: Bug Fatal yang Tidak Mendesak

Deskripsi Bug: Sistem crash saat pengguna mengunggah file gambar dengan ekstensi .docs.

●      Severity: Critical karena sistem crash adalah kondisi parah.

●      Priority: Low karena pengguna tidak diizinkan mengunggah tipe file tersebut secara normal. Terjadi hanya jika memaksa melalui teknik bypass.

Analisis: Bug ini tetap harus diperbaiki, tetapi tidak perlu ditangani segera karena kondisi sangat jarang terjadi. Tim memutuskan untuk memperbaikinya di backlog sprint mendatang.

2. Kasus 2: Bug Kecil yang Harus Segera Diperbaiki

Deskripsi Bug: Terdapat typo besar di halaman beranda aplikasi: “Selamat Datanag” (seharusnya “Selamat Datang”).

●      Severity: Low

●      Priority: High

Alasan: Meskipun tidak berpengaruh secara teknis, typo pada halaman utama dapat menciptakan kesan buruk bagi pengguna baru dan dapat mencoreng citra profesional produk.

3. Kasus 3: Konflik Penentuan Prioritas dalam Sprint Planning

QA melaporkan dua bug:

●      Bug A: Fitur export PDF tidak bisa digunakan di browser Safari.

○      Severity: Major

○      Priority: Medium

●      Bug B: Icon button tidak konsisten antara iOS dan Android.

○      Severity: Minor

○      Priority: High (karena ada demo penting untuk stakeholder di minggu depan)

Keputusan: PO memutuskan Bug B dikerjakan lebih dulu karena berpengaruh langsung pada demo, meskipun Bug A lebih berat secara teknis. QA menyetujui dengan catatan bahwa Bug A masuk backlog sprint berikutnya.

 

Last modified: Wednesday, 20 August 2025, 10:41 PM