Gambar 1. Pengguna Komputer (sumber: https://www.pexels.com/)

Dalam pengujian software modern, metrik defect (cacat/bug) bukan sekadar angka. Metrik ini adalah kompas untuk menilai kualitas produk, efektivitas proses testing, dan risiko yang akan dibawa ke production. Tanpa metrik yang tepat, diskusi soal “Apakah kita sudah siap rilis atau belum?” akan mudah berubah menjadi debat opini tak berujung antara tim QA, developer, dan manajemen.

1. Defect Density: Seberapa “Padat” Bug di Kode Anda?

Defect Density mengukur jumlah defect per ukuran modul, yang biasanya dihitung per seribu baris kode (KLOC – Kilo Lines of Code) atau per function point (FP).

Rumus sederhananya adalah:

Gambar 2. Rumus Defect Density

Contoh Kasus: Jika sebuah modul memiliki ukuran 10 KLOC dan terdapat 25 bug di dalamnya, maka defect density-nya adalah 2,5 defect per KLOC. Angka ini bisa dianggap masih dalam rentang “baik” jika benchmark perusahaan Anda adalah 1–3 defect/KLOC. Metrik ini sangat berguna untuk membandingkan kualitas antar modul atau komponen, sehingga tim bisa memprioritaskan area mana yang paling “kotor” dan butuh perhatian ekstra. Namun, Defect Densitytidak bisa berdiri sendiri; coverage testing yang rendah bisa menghasilkan density yang tampak bagus padahal pada kenyataannya masih banyak bug yang belum ditemukan.

2. Defect Leakage: Berapa Banyak Bug yang Lolos ke Produksi?

Defect Leakage mengukur persentase bug yang tidak tertangkap di environment testing dan baru ditemukan setelah rilis di production.

Rumusnya adalah:

Gambar 3. Rumus Defect Leakage

Contoh Kasus: Jika total defect untuk satu rilis adalah 120 (100 ditemukan saat testing, 20 dilaporkan user di produksi), maka defect leakage Anda adalah sekitar 16,7%. Metrik ini krusial untuk mengukur risiko yang dirasakan langsung oleh pengguna. Setiap defect yang bocor ke produksi berpotensi merusak kepercayaan user dan menaikkan biaya perbaikan. Banyak organisasi menetapkan target leakage di bawah 5–10% sebagai indikator kesehatan testing, khususnya untuk sistem bisnis kritikal seperti finansial atau kesehatan.

3. Defect Removal Efficiency (DRE): Seberapa Efektif Testing Menangkap Bug?

Defect Removal Efficiency (DRE) adalah sisi lain dari koin Leakage. Metrik ini mengukur persentase total defect yang berhasil ditemukan oleh tim QA sebelum produk rilis ke produksi.

Rumusnya adalah:

Gambar 4. Rumus Defect Removal Efficiency (DRE)

Secara matematis, DRE + Leakage ≈ 100%. Jika QA menemukan 92 bug dan setelah rilis user menemukan 8 bugtambahan, maka DRE-nya adalah 92%. Ini umumnya dianggap cukup baik, tetapi tentu masih memiliki ruang untuk perbaikan. DRE membantu tim menjawab: “Seberapa jauh kita bisa mengandalkan proses testing saat ini?”. Organisasi dengan proses QA yang matang sering menargetkan DRE di atas 95% (terutama pada domain heavily regulated) dan memantau tren DRE per rilis untuk melihat dampak dari perbaikan proses atau automation testing.

4. Defect Severity Index (DSI): Mengukur Dampak, Bukan Sekadar Jumlah

Defect Severity Index (DSI) tidak hanya menghitung jumlah defect, tetapi juga mempertimbangkan tingkat keparahannya (severity) dengan memberikan bobot tertentu pada setiap level bug.

Rumus umum yang sering dipakai adalah:

Gambar 5. Rumus Defect Severity Index (DSI)

Contoh Pembobotan: Critical = 10, High = 5, Medium = 3, Low = 1.

Jika Anda memiliki 50 defect dengan rincian: 3 Critical, 8 High, 15 Medium, dan 24 Low, maka total poinnya adalah 139. DSI-nya adalah 139 / 50 = 2,78. Angka ini menunjukkan bahwa sebagian besar defect relatif berada di tingkat moderat (mendekati Medium). DSI membantu tim menghindari jebakan “bug count” semata. Seringkali, ratusan defect kecil (Low) bisa menutupi fakta bahwa masih ada 2-3 bug Critical yang belum diselesaikan. Dengan memantau DSI, QA Lead dapat memastikan kualitas rilis membaik secara keseluruhan, terutama dari sisi dampaknya terhadap pengguna.

5. Mean Time to Detect (MTTD): Kecepatan Menemukan Masalah

Mean Time to Detect (MTTD) mengukur rata-rata waktu yang dibutuhkan tim untuk menemukan defect sejak bugtersebut muncul di kode atau sejak fase testing dimulai.

Rumusnya sangat sederhana:

Gambar 6. Rumus Mean Time to Detect (MTTD)

Contoh Kasus: Jika tim memerlukan total waktu 160 jam untuk menemukan 40 defect, maka MTTD-nya adalah 4 jam per defect. Semakin kecil MTTD, semakin cepat tim menyadari adanya masalah. Ini berarti peluang untuk memperbaiki bug sebelum merembet ke area sistem yang lain atau bocor ke produksi semakin besar. MTTD sering dipantau berpasangan dengan Mean Time to Repair (MTTR) untuk memetakan di mana bottleneck terjadi: apakah di sisi deteksi (tim QA) atau di sisi perbaikan (tim Developer).

Mengombinasikan Lima Metrik Ini dalam Praktik

Kelima metrik di atas akan memberikan insight yang jauh lebih kuat jika dianalisis sebagai satu kesatuan paket, bukan secara terpisah:

  • Defect Density yang rendah belum tentu berarti kualitas tinggi jika Defect Leakage dan MTTD masih besar. Hal ini bisa menandakan test coverage yang kurang luas atau proses deteksi yang lambat.
  • DRE yang tinggi tetapi DSI tetap besar menunjukkan bahwa meskipun sebagian besar defect tertangkap, banyak di antaranya bersifat kritikal dan menunjukkan kualitas awal kode yang kurang stabil.

Dalam implementasi sehari-hari, tim QA biasanya memilih 3–5 metrik inti dari daftar ini untuk dilaporkan secara rutin di dashboard dan dibahas saat Sprint Retrospective. Pastikan setiap metrik berujung pada tindakan praktis, misalnya:

“Defect Leakage rilis ini > 10%, kita perlu menunda rilis (hold release) dan memperluas regression suite test kita,” atau “MTTD meningkat selama dua sprint berturut-turut, saatnya kita mengaudit strategi testing dan alat monitoring yang kita gunakan.”

 

 

Referensi