¿Qué es la densidad de defectos? Fórmula para calcular con ejemplo

¿Qué es la densidad de defectos?

Densidad de defectos Es el número de defectos confirmados en un software o módulo durante un período específico de operación o desarrollo, dividido por el tamaño de dicho software o módulo. Permite a un equipo decidir si un software está listo para su lanzamiento.

La densidad de defectos se calcula por cada mil líneas de código, también conocidas como KLOC. Dado que el recuento se normaliza según el tamaño, un módulo grande con muchos defectos y un módulo pequeño con pocos defectos pueden compararse en la misma escala, algo que un recuento de errores sin procesar nunca permite.

La métrica normalmente se informa al final de un ciclo de prueba y traclanzamiento tras lanzamiento, por lo que se sitúa junto al resto de los proceso de gestión de defectos en el ciclo de vida de las pruebas de software.

Cómo calcular la densidad de defectos

Una fórmula para medir la densidad de defectos:

Defect Density = Defect count/size of the release

El tamaño de una versión se puede medir en términos de una línea de código (LOC).

Tres detalles determinan si el número resultante tiene algún significado:

• La unidad de tamaño. LOC y KLOC son las unidades más comunes. Los puntos de función se utilizan cuando los equipos desean una medida de tamaño que no varíe con el lenguaje de programación, y algunos equipos normalizan por módulo o por componente.
• ¿Qué se considera un defecto? Solo los defectos confirmados deben incluirse en el numerador. Los duplicados, los informes rechazados y las solicitudes de mejora deben excluirse, ya que de lo contrario la cifra se inflaría sin que ello suponga ningún cambio en la calidad del código.
• La ventana de medición. Defectos encontrados durante las pruebas del sistema, durante pruebas de regresióny después del lanzamiento describen cosas diferentes, por lo que el período debe indicarse con el número.

Ejemplo de densidad de defectos

Supongamos que tienes 3 módulos integrados en tu producto de software. Cada módulo tiene la siguiente cantidad de errores detectados:

• Módulo 1 = 10 errores
• Módulo 2 = 20 errores
• Módulo 3 = 10 errores

Total de errores = 10+20+10 = 40

El número total de líneas de código para cada módulo es:

• Módulo 1 = 1000 LOC
• Módulo 2 = 1500 LOC
• Módulo 3 = 500 LOC

Línea total de Code = 1000+1500+500 = 3000

La densidad de defectos se calcula como:

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

El mismo cálculo aplicado por módulo es más útil que la cifra combinada, como muestra el gráfico a continuación: el módulo 2 tiene 20 defectos en 1500 LOC y el módulo 3 tiene 10 defectos en solo 500 LOC, por lo que el módulo 3 es el más denso y arriesgado de los dos, aunque reportó menos errores.

Un estándar para la densidad de defectos

No existe un estándar fijo para la densidad de defectos. Los estudios sugieren que uno precisa Por cada mil líneas de código, generalmente se considera un indicador de buena calidad del proyecto, y esa cifra es la regla general más citada en la industria.

Las expectativas varían según el ámbito. El software crítico para la seguridad y regulado, como el de aviónica y dispositivos médicos, se rige por un objetivo muy inferior a un defecto por KLOC, mientras que las aplicaciones empresariales comunes suelen superarlo. Dado que las reglas de conteo, las unidades de medida y la profundidad de las pruebas difieren entre organizaciones, un valor de referencia extraído de un estudio publicado solo es comparable con un proyecto que utilice el mismo método de medición. Por lo tanto, el uso práctico de la métrica es interno: comparar una versión con la versión anterior del mismo producto, medidas de forma idéntica.

Factores que afectan la densidad de defectos

El mismo código fuente puede producir cifras de densidad de defectos muy diferentes dependiendo de los siguientes factores:

• Code complejidad. Lógica profundamente anidada y alta complejidad ciclomática Producen más defectos por línea que un código sencillo.
• El tipo de defectos que se tienen en cuenta. Contando solo los defectos funcionales, o incluyendo la usabilidad, la documentación y no funcional Los hallazgos modifican sustancialmente el numerador.
• La duración del tiempo considerada. Una cifra medida durante un ciclo de prueba de dos semanas no es comparable a una medida durante seis meses de uso en producción.
• Habilidades de desarrollador y probador. Los desarrolladores experimentados introducen menos defectos, y los probadores experimentados encuentran más de los que ya existen, por lo que ambos efectos influyen en la métrica en direcciones opuestas.
• Cobertura de la prueba. Los defectos que nunca se buscaron nunca se contabilizan, por lo tanto prueba de cobertura Limita silenciosamente el valor máximo que puede alcanzar la densidad medida.

Densidad de defectos frente a otras métricas de defectos

La densidad de defectos responde a una pregunta: ¿cuán concentrados están los defectos conocidos? Tres métricas complementarias responden a las preguntas que no puede responder, y la mayoría de los equipos las reportan conjuntamente.

En conjunto, los cuatro elementos ofrecen una visión más completa: una baja densidad de defectos con una alta fuga de defectos apunta a pruebas superficiales en lugar de a un código limpio, que es precisamente la interpretación errónea sobre la que advierte la siguiente sección.

Ventajas de la densidad de defectos

A continuación se detallan las ventajas de la densidad de defectos:

• Ayuda a medir la eficacia de las pruebas.
• Ayuda a diferenciar la concentración de defectos entre componentes y módulos de software.
• Resulta útil para identificar las áreas que necesitan corrección o mejora.
• Es útil para señalar componentes de alto riesgo, lo que alimenta directamente la pruebas basadas en riesgos.
• Ayuda a identificar las necesidades de capacitación de los distintos recursos.
• Puede resultar útil para estimar el esfuerzo de prueba y reelaboración causado por los defectos.
• Puede estimar los defectos restantes en el software.
• Antes del lanzamiento, ayuda a determinar si las pruebas realizadas hasta el momento son suficientes.
• Esto crea una base histórica con la que se pueden comparar las versiones posteriores.

Limitaciones de la densidad de defectos

Esta métrica es fácil de calcular y fácil de interpretar erróneamente. Las siguientes limitaciones determinan la importancia que merece en una decisión de lanzamiento:

• Los defectos no detectados son invisibles. El numerador solo incluye los defectos que se detectaron durante las pruebas, por lo que un módulo que no ha sido sometido a pruebas exhaustivas arroja una cifra engañosa.
• Se ignora la gravedad. Un defecto que corrompe un pago y un problema de alineación cosmética cuentan lo mismo, por lo que es necesario tener en cuenta la gravedad.
• Las definiciones de defectos varían. Dos equipos que cuentan de forma diferente producen cifras que no se pueden comparar, ni siquiera dentro de la misma organización.
• Las líneas de código son un indicador de tamaño poco fiable. El código extenso reduce la densidad sin mejorar nada, y la unidad no es comparable entre diferentes lenguajes de programación.
• Esta métrica puede ser manipulada. Rechazar informes dudosos o inflar el número de líneas mejoran la cifra sin mejorar el producto.

Nada de esto hace que la densidad de defectos sea inútil. Simplemente la convierte en un indicador de tendencias para un producto medido de forma consistente, en lugar de una puntuación para comparar equipos entre sí.

Cómo reducir la densidad de defectos

Reducir la densidad de defectos de forma real, en lugar de solo en teoría, significa prevenir los defectos con antelación y detectar el resto antes del lanzamiento. Las siguientes prácticas son las que se repiten en las guías publicadas:

• Adelanta las pruebas. Involucrar a los evaluadores en la etapa de requisitos y diseño permite detectar ambigüedades antes de que se conviertan en código, que es donde resulta más económico corregir los defectos.
• RevRevisa el código antes de que se fusione. La revisión por pares detecta errores de lógica, requisitos mal interpretados y fallas de diseño que no prueba de unidad fue escrito para buscar.
• Automatice el conjunto de pruebas de regresión. Ejecutar comprobaciones en cada confirmación a través de integración continua Evita que los defectos antiguos reaparezcan mientras se escribe código nuevo.
• Primero escribe las pruebas. Desarrollo guiado por pruebas obliga a que cada comportamiento se especifique antes de su implementación, y prueba de mutación De esta forma, se puede confirmar que las pruebas resultantes realmente afirman algo.
• Utilice análisis estático. El escaneo automatizado de código detecta desreferencias nulas, fugas de recursos y puntos críticos de complejidad antes de que se ejecute una sola prueba.
• Refactorizar los módulos densos. Una vez que Defect Density ha identificado los componentes más problemáticos, dividirlos y simplificarlos suele reducir tanto la complejidad como la cantidad de defectos.
• Reintroduce los defectos en el proceso. El análisis de la causa raíz en las retrospectivas convierte los defectos individuales en soluciones de proceso en lugar de parches puntuales.

Traclanzamiento ked sobre lanzamiento junto con técnicas de prueba de software Con los datos de cobertura y la densidad de defectos, esta se convierte en un sistema de alerta temprana en lugar de un simple informe de calificaciones.

Preguntas Frecuentes