Apa itu Kepadatan Cacat? Rumus untuk menghitung dengan Contoh

Oleh: Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Ringkasan Cerdas

Kepadatan Cacat mengukur jumlah cacat yang terkonfirmasi dalam sebuah modul perangkat lunak dibagi dengan ukuran modul tersebut, biasanya dinyatakan per seribu baris kode, dan ini menandakan apakah sebuah build siap untuk dirilis.

  • 🔘 Formula: Kepadatan Cacat sama dengan jumlah cacat yang terkonfirmasi dibagi dengan ukuran rilis, yang paling sering diukur dalam KLOC.
  • ☑️ Contoh yang dikerjakan: Empat puluh cacat di tiga ribu baris kode menghasilkan 0.0133 cacat per baris kode, atau 13.333 cacat per KLOC.
  • ✅ Tolok ukur: Sekitar satu cacat per seribu baris kode secara umum dianggap sebagai tanda kualitas proyek yang baik.
  • 🧪 Pengaruh: Code Kompleksitas, aturan penghitungan cacat, jendela pengukuran, dan keterampilan tim semuanya memengaruhi angka tersebut.
  • 📊 Perbandingan: Indeks kebocoran cacat, efisiensi penghapusan cacat, dan tingkat keparahan menjawab pertanyaan yang tidak dapat dijawab hanya oleh kepadatan cacat.
  • ⚠️ Peringatan: Nilai yang rendah dapat berarti pengujian yang lemah, bukan kode yang bersih, sehingga metrik ini tidak pernah berdiri sendiri.
Baca Selengkapnya

Kepadatan Cacat

Apa itu Kepadatan Cacat?

Kepadatan Cacat adalah jumlah cacat yang terkonfirmasi dalam suatu perangkat lunak atau modul selama periode operasi atau pengembangan tertentu, dibagi dengan ukuran perangkat lunak atau modul tersebut. Hal ini memungkinkan tim untuk memutuskan apakah suatu perangkat lunak siap untuk dirilis.

Kepadatan Cacat dihitung per seribu baris kode, juga dikenal sebagai KLOC. Karena hitungan dinormalisasi berdasarkan ukuran, modul besar dengan banyak cacat dan modul kecil dengan sedikit cacat dapat dibandingkan pada skala yang sama, yang tidak mungkin dilakukan dengan penghitungan bug mentah.

Metrik ini biasanya dilaporkan di akhir siklus pengujian dan tracrilis ked secara bertahap, jadi posisinya sejajar dengan yang lainnya. proses manajemen cacat dalam siklus hidup pengujian perangkat lunak.

Cara Menghitung Kepadatan Cacat

Rumus untuk mengukur Kepadatan Cacat:

Defect Density = Defect count/size of the release

Ukuran rilis dapat diukur dalam satuan baris kode (LOC).

Tiga hal menentukan apakah angka yang dihasilkan memiliki arti atau tidak:

  • Satuan ukuran. LOC dan KLOC adalah satuan yang paling umum. Function point digunakan ketika tim menginginkan ukuran yang tidak berubah dengan bahasa pemrograman, dan beberapa tim menormalkan berdasarkan modul atau komponen.
  • Apa yang dianggap sebagai cacat? Hanya cacat yang terkonfirmasi yang termasuk dalam pembilang. Duplikat, laporan yang ditolak, dan permintaan peningkatan harus dikecualikan, atau angkanya akan membengkak tanpa perubahan apa pun pada kualitas kode.
  • Jendela pengukuran. Cacat yang ditemukan selama pengujian sistem, selama pengujian regresi, dan setelah dirilis, hal-hal yang dijelaskan berbeda, jadi periode tersebut harus dinyatakan dengan angka.

Contoh Kepadatan Cacat

Misalkan Anda memiliki 3 modul yang terintegrasi ke dalam produk perangkat lunak Anda. Setiap modul memiliki jumlah bug yang ditemukan sebagai berikut:

  • Modul 1 = 10 bug
  • Modul 2 = 20 bug
  • Modul 3 = 10 bug

Jumlah total bug = 10+20+10 = 40

Jumlah baris kode untuk setiap modul adalah:

  • Modul 1 = 1000 LOC
  • Modul 2 = 1500 LOC
  • Modul 3 = 500 LOC

Jumlah Baris Total Code = 1000+1500+500 = 3000

Kepadatan Cacat dihitung sebagai:

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

Perhitungan yang sama yang diterapkan per modul lebih bermanfaat daripada angka gabungan, seperti yang ditunjukkan grafik di bawah ini: Modul 2 memiliki 20 cacat dalam 1500 baris kode dan Modul 3 memiliki 10 cacat hanya dalam 500 baris kode, sehingga Modul 3 lebih padat dan berisiko dibandingkan Modul 2 meskipun melaporkan lebih sedikit bug.

Diagram batang yang membandingkan jumlah cacat dan baris kode dari tiga modul yang digunakan dalam perhitungan Kepadatan Cacat.

Standar untuk Kepadatan Cacat

Tidak ada standar tetap untuk Kepadatan Cacat. Studi menunjukkan bahwa salah satu cacat Jumlah baris kode per seribu baris umumnya dianggap sebagai tanda kualitas proyek yang baik, dan angka tersebut merupakan aturan praktis yang paling banyak dikutip di industri ini.

Ekspektasi memang berubah seiring dengan bidangnya. Perangkat lunak yang kritis terhadap keselamatan dan diatur, seperti avionik dan perangkat medis, ditargetkan jauh di bawah satu cacat per KLOC, sementara aplikasi bisnis biasa secara rutin berada di atasnya. Karena aturan penghitungan, satuan ukuran, dan kedalaman pengujian berbeda antar organisasi, tolok ukur yang diambil dari studi yang dipublikasikan hanya dapat dibandingkan dengan proyek yang mengukur dengan cara yang sama. Oleh karena itu, penggunaan praktis metrik ini bersifat internal: bandingkan rilis dengan rilis sebelumnya dari produk yang sama, yang diukur secara identik.

Faktor-faktor yang Mempengaruhi Kepadatan Cacat

Basis kode yang sama dapat menghasilkan angka Kepadatan Cacat yang sangat berbeda tergantung pada faktor-faktor berikut:

  • Code kompleksitas. Logika yang sangat kompleks dan tinggi kompleksitas siklomatik menghasilkan lebih banyak kesalahan per baris dibandingkan kode yang sederhana.
  • Jenis cacat yang diperhitungkan. Menghitung hanya cacat fungsional, atau termasuk kegunaan, dokumentasi, dan tidak berfungsi temuan tersebut mengubah pembilang secara substansial.
  • Durasi waktu yang dipertimbangkan. Angka yang diukur selama siklus uji dua minggu tidak dapat dibandingkan dengan angka yang diukur selama enam bulan penggunaan produksi.
  • Keterampilan pengembang dan penguji. Pengembang berpengalaman memasukkan lebih sedikit cacat, dan penguji berpengalaman menemukan lebih banyak cacat yang ada, sehingga kedua efek tersebut menarik metrik ke arah yang berlawanan.
  • Cakupan pengujian. Cacat yang tidak pernah dicari tidak pernah dihitung, jadi cakupan tes secara diam-diam membatasi seberapa tinggi kepadatan yang terukur dapat mencapai.

ARTIKEL TERKAIT

Kepadatan Cacat vs Metrik Cacat Lainnya

Kepadatan Cacat menjawab satu pertanyaan: seberapa terkonsentrasi cacat yang diketahui. Tiga metrik pelengkap menjawab pertanyaan yang tidak dapat dijawab oleh metrik pertama, dan sebagian besar tim melaporkan ketiganya secara bersamaan.

metrik Apa yang diukur Pertanyaan itu menjawab
Kepadatan Cacat Cacat yang terkonfirmasi dibagi berdasarkan ukuran (KLOC atau poin fungsi) Modul mana yang memiliki jumlah kerusakan terbanyak untuk ukurannya?
Cacat Kebocoran Cacat yang ditemukan setelah rilis sebagai bagian dari semua cacat. Seberapa banyak yang lolos dari proses pengujian dan sampai ke pengguna?
Efisiensi Penghapusan Cacat Cacat yang dihilangkan sebelum rilis sebagai bagian dari semua cacat. Seberapa efektif pengujian dalam mendeteksi cacat tepat waktu?
Indeks Tingkat Keparahan Cacat Cacat dinilai berdasarkan tingkat keparahannya, bukan dihitung secara merata. Seberapa merusakkah cacat tersebut, bukan hanya berapa jumlahnya?

Jika dibaca bersama-sama, keempatnya memberikan gambaran yang lebih lengkap: Kepadatan Cacat yang rendah dengan Kebocoran Cacat yang tinggi menunjukkan pengujian yang dangkal daripada kode yang bersih, yang justru merupakan kesalahan penafsiran yang diperingatkan pada bagian selanjutnya.

Keunggulan Kepadatan Cacat

Berikut adalah keunggulan dari Kepadatan Cacat:

  • Hal ini membantu mengukur efektivitas pengujian.
  • Hal ini membantu membedakan konsentrasi cacat antara komponen dan modul perangkat lunak.
  • Hal ini berguna untuk mengidentifikasi area yang perlu dikoreksi atau ditingkatkan.
  • Hal ini berguna untuk menunjukkan komponen berisiko tinggi, yang secara langsung berkaitan dengan pengujian berbasis risiko.
  • Hal ini membantu dalam mengidentifikasi kebutuhan pelatihan dari berbagai sumber daya.
  • Hal ini dapat membantu dalam memperkirakan upaya pengujian dan pengerjaan ulang yang disebabkan oleh cacat.
  • Hal ini dapat memperkirakan cacat yang masih tersisa dalam perangkat lunak.
  • Sebelum peluncuran, hal ini membantu menentukan apakah pengujian yang telah dilakukan sejauh ini sudah memadai.
  • Hal ini membangun tolok ukur historis yang dapat digunakan untuk mengukur rilis selanjutnya.

Keterbatasan Kepadatan Cacat

Metrik ini mudah dihitung dan mudah disalahartikan. Batasan-batasan berikut menentukan seberapa besar bobot yang layak diberikan dalam keputusan perilisan:

  • Cacat yang tidak terdeteksi tidak terlihat. Pembilang hanya mencantumkan cacat yang benar-benar ditemukan melalui pengujian, sehingga modul yang pengujiannya kurang menyeluruh akan menghasilkan angka yang lebih baik.
  • Tingkat keparahan diabaikan. Satu cacat yang merusak pembayaran dan satu masalah penataan kosmetik memiliki bobot yang sama, itulah sebabnya diperlukan pandangan yang mempertimbangkan tingkat keparahan di sampingnya.
  • Definisi cacat bervariasi. Dua tim yang menghitung dengan cara berbeda menghasilkan angka yang tidak dapat dibandingkan, bahkan di dalam organisasi yang sama.
  • Jumlah baris kode bukanlah indikator ukuran yang akurat. Kode yang bertele-tele menurunkan kepadatan tanpa meningkatkan apa pun, dan satuannya tidak dapat dibandingkan antar bahasa pemrograman.
  • Metrik tersebut dapat dimanipulasi. Menolak laporan yang berada di ambang batas atau melebih-lebihkan jumlah baris hanya akan meningkatkan angka tanpa meningkatkan kualitas produk.

Semua ini tidak membuat Kepadatan Cacat menjadi tidak berguna. Ini menjadikannya indikator tren untuk satu produk yang diukur secara konsisten, bukan skor untuk membandingkan tim satu sama lain.

Cara Mengurangi Kepadatan Cacat

Menurunkan Kepadatan Cacat secara nyata, bukan hanya di atas kertas, berarti mencegah cacat sejak dini dan menemukan sisanya sebelum rilis. Praktik-praktik di bawah ini adalah praktik yang berulang di seluruh panduan yang diterbitkan:

  • Lakukan pengujian lebih awal. Melibatkan penguji pada tahap persyaratan dan desain dapat mendeteksi ambiguitas sebelum menjadi kode, yang merupakan tahap di mana cacat paling murah untuk dihilangkan.
  • RevLihat kode sebelum digabungkan. Peer review dapat mendeteksi kesalahan logika, salah tafsir persyaratan, dan kekurangan desain yang tidak dapat diatasi oleh siapa pun. tes unit ditulis untuk dicari.
  • Otomatiskan rangkaian pengujian regresi. Menjalankan pemeriksaan pada setiap commit melalui integrasi berkelanjutan Mencegah munculnya kembali kesalahan lama saat kode baru sedang ditulis.
  • Buatlah tes terlebih dahulu. Pengembangan berbasis tes memaksa setiap perilaku untuk ditentukan sebelum diimplementasikan, dan pengujian mutasi kemudian dapat mengkonfirmasi bahwa hasil tes tersebut benar-benar menegaskan sesuatu.
  • Gunakan analisis statis. Pemindaian kode otomatis menandai dereferensi null, kebocoran sumber daya, dan titik-titik kompleksitas tinggi sebelum satu pun pengujian dijalankan.
  • Lakukan refactoring pada modul-modul yang padat. Setelah Defect Density mengidentifikasi komponen terburuk, memisahkan dan menyederhanakannya biasanya mengurangi kompleksitas dan jumlah cacat.
  • Masukkan kembali cacat ke dalam proses. Analisis akar penyebab pada retrospektif mengubah cacat individual menjadi perbaikan proses, bukan sekadar tambalan sekali waktu.

Tracrilis ked atas rilis bersamaan teknik pengujian perangkat lunak Dengan data cakupan, Kepadatan Cacat menjadi sistem peringatan dini, bukan sekadar laporan penilaian.

Pertanyaan Umum Demo Slot

Sebagian besar tim menghitungnya di akhir pengujian sistem, ketika laporan cacat telah dipilah dan dikonfirmasi. Pengukuran di tengah siklus meremehkan angka sebenarnya karena laporan masih terbuka, dan pengukuran hanya setelah rilis mengubahnya menjadi metrik kebocoran.

Tidak. Hitung hanya kode yang ditulis dan dapat diubah oleh tim. Memasukkan file yang dihasilkan, pustaka vendor, atau kode pengujian akan memperbesar penyebut dan menurunkan kepadatan secara artifisial, yang menyembunyikan modul yang benar-benar membutuhkan perhatian.

Ya. Tim biasanya melaporkan angka kedua yang terbatas pada cacat kritis dan tingkat keparahan tinggi. Modul dengan kepadatan keseluruhan yang moderat tetapi memiliki beberapa cacat kritis merupakan risiko rilis yang lebih besar daripada modul dengan banyak masalah kosmetik.

Ya, dengan penyebut yang berbeda. Tim yang gesit Seringkali, normalisasi cacat dilakukan per user story, per story point, atau per fitur yang telah diselesaikan. Satuan ukurannya kurang penting dibandingkan dengan penggunaan satuan yang sama secara konsisten di seluruh sprint.

Model prediksi cacat belajar dari metrik kode dan proses historis, seperti kompleksitas, perubahan, dan jumlah cacat di masa lalu, untuk menentukan peringkat file mana yang paling mungkin mengandung cacat. Penguji kemudian memfokuskan upaya pada modul dengan risiko tertinggi sebelum hasil build diukur.

Secara tidak langsung. Copilot membuat draf pengujian unit, skenario kasus ekstrem, dan pernyataan standar dengan cepat, yang meningkatkan cakupan dan memunculkan cacat lebih awal. Ia juga menghasilkan kode yang membutuhkan tinjauan yang sama seperti kode lainnya, sehingga tidak pernah menghilangkan kebutuhan akan tinjauan sejawat.

Pemimpin pengujian atau manajer QA biasanya melaporkannya, tetapi aturan penghitungan harus disepakati terlebih dahulu dengan tim pengembangan dan manajer proyek. Tanpa definisi yang disepakati tentang cacat yang terkonfirmasi dan kode yang dapat dihitung, angka tersebut tidak dapat dipertanggungjawabkan dalam rapat rilis.

Belum tentu. Lonjakan sering kali berarti pengujian akhirnya mencapai modul yang sebelumnya belum tersentuh, yang merupakan kabar baik yang ditemukan terlambat. Bacalah bersamaan dengan cakupan pengujian dan tren cacat sebelum menganggapnya sebagai kegagalan kualitas.

Ringkaslah postingan ini dengan: