Kalkulator Metrik QA: Pass Rate, DRE, dan Defect Density

Mengapa QC perlu angka

"Sudah dites kok" bukan jawaban yang membantu ketika klien atau manajer bertanya apakah aplikasi siap rilis. Metrik pengujian mengubah perasaan menjadi data: berapa banyak skenario yang sudah diuji, berapa yang gagal, dan seberapa efektif proses pengujian menangkap bug sebelum sampai ke pengguna.

Rumus metrik

Execution rate = (pass + fail + blocked) ÷ total direncanakan × 100%
Pass rate = pass ÷ (pass + fail + blocked) × 100%
DRE = bug sebelum rilis ÷ (bug sebelum + sesudah rilis) × 100%
Defect density = total bug ÷ KLOC

• Execution rate menunjukkan seberapa banyak rencana pengujian yang sudah dijalankan.
• Pass rate menunjukkan kualitas build yang sedang diuji.
• Defect Removal Efficiency (DRE) mengukur efektivitas tim QA: berapa persen bug yang tertangkap sebelum sampai ke pengguna.
• Defect density membandingkan jumlah bug dengan ukuran kode, berguna untuk membandingkan modul atau rilis.

Contoh

Dari 250 test case, 235 sudah dijalankan: 210 lulus, 18 gagal, dan 7 terblokir. Selama pengujian ditemukan 46 bug, dan setelah rilis pengguna melaporkan 4 bug lagi. Ukuran kodenya sekitar 25 KLOC.

• Execution rate = 235 ÷ 250 = 94%
• Pass rate = 210 ÷ 235 ≈ 89,4%
• DRE = 46 ÷ 50 = 92%
• Defect density = 50 ÷ 25 = 2 bug per KLOC

Membaca hasilnya untuk keputusan rilis

Tidak ada angka ajaib yang berlaku untuk semua proyek. Yang lebih penting adalah kriteria keluar (exit criteria) yang disepakati bersama klien sebelum pengujian dimulai. Contohnya:

• Semua test case prioritas tinggi sudah dijalankan dan lulus.
• Tidak ada bug kritis atau tinggi yang masih terbuka.
• Bug sedang dan rendah yang tersisa sudah didokumentasikan dan disetujui klien untuk diperbaiki di rilis berikutnya.

Satu bug kritis, misalnya obat tercatat ke pasien yang salah atau tagihan terhitung ganda, lebih menentukan daripada pass rate 95%. Karena itu, catat juga tingkat keparahan setiap bug, bukan hanya jumlahnya.

Hati-hati menyalahgunakan metrik

Jika jumlah bug dijadikan ukuran kinerja programmer, orang akan cenderung menyembunyikan bug. Jika jumlah test case dijadikan target tester, akan muncul banyak test case dangkal. Gunakan metrik untuk melihat tren dan memperbaiki proses, bukan untuk menyalahkan orang.

Jenis-jenis pengujian dan cara menulis test case dibahas di artikel QA tester: jenis pengujian dan cara menulis test case.

Terakhir diperbarui 24 September 2026