{"id":10801,"date":"2026-04-22T08:39:37","date_gmt":"2026-04-22T01:39:37","guid":{"rendered":"https:\/\/binus.ac.id\/bekasi\/?p=10801"},"modified":"2026-04-22T08:40:55","modified_gmt":"2026-04-22T01:40:55","slug":"lima-metrik-defect-penting-dari-defect-density-sampai-mean-time-to-detect","status":"publish","type":"post","link":"https:\/\/binus.ac.id\/bekasi\/2026\/04\/lima-metrik-defect-penting-dari-defect-density-sampai-mean-time-to-detect\/","title":{"rendered":"Lima Metrik Defect Penting: Dari Defect Density sampai Mean Time to Detect"},"content":{"rendered":"

\"\"Gambar 1. Pengguna Komputer (sumber: https:\/\/www.pexels.com\/)<\/span><\/p>\n

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

<\/h2>\n

1. Defect Density: Seberapa “Padat” Bug di Kode Anda?<\/strong><\/h2>\n

Defect Density<\/strong> mengukur jumlah defect<\/em> per ukuran modul, yang biasanya dihitung per seribu baris kode (KLOC – Kilo Lines of Code<\/em>) atau per function point<\/em> (FP).<\/p>\n

Rumus sederhananya adalah:<\/p>\n

\"\"Gambar 2. Rumus Defect Density<\/span><\/p>\n

Contoh Kasus:<\/strong> Jika sebuah modul memiliki ukuran 10 KLOC dan terdapat 25 bug<\/em> di dalamnya, maka defect density<\/em>-nya adalah 2,5 defect<\/em> per KLOC. Angka ini bisa dianggap masih dalam rentang “baik” jika benchmark<\/em> perusahaan Anda adalah 1\u20133 defect<\/em>\/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 Density<\/em>tidak bisa berdiri sendiri; coverage testing<\/em> yang rendah bisa menghasilkan density<\/em> yang tampak bagus padahal pada kenyataannya masih banyak bug<\/em> yang belum ditemukan.<\/p>\n

<\/h2>\n

2. Defect Leakage: Berapa Banyak Bug yang Lolos ke Produksi?<\/strong><\/h2>\n

Defect Leakage<\/strong> mengukur persentase bug<\/em> yang tidak tertangkap di environment testing<\/em> dan baru ditemukan setelah rilis di production<\/em>.<\/p>\n

Rumusnya adalah:<\/p>\n

\"\"Gambar 3. Rumus Defect Leakage<\/span><\/p>\n

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

<\/h2>\n

3. Defect Removal Efficiency (DRE): Seberapa Efektif Testing Menangkap Bug?<\/strong><\/h2>\n

Defect Removal Efficiency (DRE)<\/strong> adalah sisi lain dari koin Leakage<\/em>. Metrik ini mengukur persentase total defect<\/em> yang berhasil ditemukan oleh tim QA sebelum produk rilis ke produksi.<\/p>\n

Rumusnya adalah:<\/p>\n

\"\"Gambar 4. Rumus Defect Removal Efficiency (DRE)<\/span><\/p>\n

Secara matematis, DRE + Leakage \u2248 100%<\/strong>. Jika QA menemukan 92 bug<\/em> dan setelah rilis user<\/em> menemukan 8 bug<\/em>tambahan, 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?”<\/em>. Organisasi dengan proses QA yang matang sering menargetkan DRE di atas 95% (terutama pada domain heavily regulated<\/em>) dan memantau tren DRE per rilis untuk melihat dampak dari perbaikan proses atau automation testing<\/em>.<\/p>\n

<\/h2>\n

4. Defect Severity Index (DSI): Mengukur Dampak, Bukan Sekadar Jumlah<\/strong><\/h2>\n

Defect Severity Index (DSI)<\/strong> tidak hanya menghitung jumlah defect<\/em>, tetapi juga mempertimbangkan tingkat keparahannya (severity<\/em>) dengan memberikan bobot tertentu pada setiap level bug<\/em>.<\/p>\n

Rumus umum yang sering dipakai adalah:<\/p>\n

\"\"Gambar 5. Rumus Defect Severity Index (DSI)<\/span><\/p>\n

Contoh Pembobotan:<\/strong> Critical = 10, High = 5, Medium = 3, Low = 1.<\/p>\n

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

<\/h2>\n

5. Mean Time to Detect (MTTD): Kecepatan Menemukan Masalah<\/strong><\/h2>\n

Mean Time to Detect (MTTD)<\/strong> mengukur rata-rata waktu yang dibutuhkan tim untuk menemukan defect<\/em> sejak bug<\/em>tersebut muncul di kode atau sejak fase testing<\/em> dimulai.<\/p>\n

Rumusnya sangat sederhana:<\/p>\n

\"\"Gambar 6. Rumus Mean Time to Detect (MTTD)<\/span><\/p>\n

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

<\/h2>\n

Mengombinasikan Lima Metrik Ini dalam Praktik<\/strong><\/h2>\n

Kelima metrik di atas akan memberikan insight<\/em> yang jauh lebih kuat jika dianalisis sebagai satu kesatuan paket, bukan secara terpisah:<\/p>\n