Métrica de prueba de software
Introducción:
Cuando podemos medir lo que estamos hablando y expresarlo en números, sabemos algo al respecto; pero cuando no podemos medir, cuando no podemos expresarlo en números, nuestro conocimiento es de un tipo escaso e insatisfactorio: puede ser el comienzo del conocimiento, pero en sus pensamientos apenas hemos avanzado a la etapa de la ciencia.
- Cómo conseguir un trabajo en desarrollo de software sin título y desde cero
- ¿Trabajar en Google o Facebook como ingeniero de software es mejor que la vida universitaria?
- ¿Las compañías se están alejando de Ruby on Rails o cada vez más compañías están adoptando RoR?
- ¿Qué software es realmente bueno para la arquitectura?
- ¿Es posible obtener una oferta de compañías tecnológicas de primer nivel como Google, Facebook, Twitter, etc., después de graduarme de Hack Reactor?
¿Qué es la métrica?
Una escala de medición y el método utilizado para la medición.
¿Por qué necesitamos métricas?
“No podemos mejorar lo que no podemos medir”
“No podemos controlar lo que no podemos medir”
Test Metrics ayuda en,
• Tomar la decisión para la próxima fase de actividades.
• Evidencia del reclamo o predicción
• Comprender el tipo de mejora requerida
• Tomar una decisión sobre el proceso o el cambio tecnológico
Tipo de métrica
1) Métricas base (medida directa)
Las métricas base constituyen los datos sin procesar recopilados por un analista de pruebas durante todo el esfuerzo de prueba. Estas métricas se utilizan para proporcionar informes de estado del proyecto al Test Lead y al Project Manager; También alimentan las fórmulas utilizadas para derivar las métricas calculadas.
Ej: # de casos de prueba, # de casos de prueba ejecutados
2) Métricas calculadas (Medida indirecta)
Las métricas calculadas convierten los datos de las métricas base en información más útil. Estos tipos de métricas son generalmente responsabilidad del líder de prueba y pueden rastrearse en muchos niveles diferentes (por módulo, probador o proyecto).
Ej:% completado,% de cobertura de prueba
Métricas base y fases de prueba
o # de casos de prueba (fase de desarrollo de prueba)
o # de casos de prueba ejecutados (fase de ejecución de prueba)
o # de casos de prueba aprobados (fase de ejecución de prueba)
o Número de casos de prueba fallidos (fase de ejecución de prueba)
o # de casos de prueba bajo investigación (fase de desarrollo de prueba)
o # de casos de prueba bloqueados (desarrollo de prueba / fase de ejecución)
o # de casos de prueba ejecutados nuevamente (fase de regresión)
o # de fallas en la primera ejecución (fase de ejecución de prueba)
o Ejecuciones totales (fase de informe de prueba)
o Pases totales (fase de informe de prueba)
o Fallas totales (fase de informe de prueba)
o Tiempo de ejecución del caso de prueba ((Fase de informe de prueba)
o Tiempo de ejecución de prueba (Fase de informe de prueba
Métricas calculadas y fases de prueba
Las siguientes métricas se crean en la fase de informes de prueba o en la fase de análisis posterior a la prueba
o% completado
o% de defectos corregidos
o% de cobertura de prueba
o% de retrabajo
o% de casos de prueba aprobados
o% de efectividad de la prueba
o% de casos de prueba bloqueados
o% de eficiencia de prueba
o Tasa de falla de la primera ejecución
o Tasa de descubrimiento de defectos
o Tasa de falla general
III) Métricas cruciales de pruebas basadas en la web
1) Requisito de volatilidad
Número de requisitos acordados versus número de requisitos modificados.
• (Cantidad de requisitos agregados + eliminados + modificados) * 100 / Cantidad de requisitos originales
• Asegúrese de que los requisitos estén normalizados o definidos correctamente mientras se estima
Ejemplo: la versión VSS 1.3 tenía un total de 67 requisitos inicialmente, luego agregaron otros 7 nuevos requisitos y eliminaron 3 de los requisitos iniciales y modificaron 11 requisitos.
Entonces, la volatilidad del requisito es
(7 + 3 + 11) * 100/67 = 31,34%
Significa que casi 1/3 de los requisitos cambiaron después de la identificación inicial
2) Cobertura del plan de prueba sobre funcionalidad
Número total de requisitos frente a número de requisitos cubiertos a través de scripts de prueba.
• (No de requisitos cubiertos / Número total de requisitos) * 100
Definir requisitos en el momento de la estimación del esfuerzo
Ejemplo: el número total de requisitos estimados son 46, el número total de requisitos probados 39; bloqueado 7 … definir cuál es la cobertura?
Nota: defina el requisito claramente a nivel de proyecto
3) Densidad del defecto del caso de prueba
Número total de defectos encontrados en los scripts de prueba versus desarrollados y ejecutados.
• (Scripts de prueba defectuosos / Scripts de prueba totales) * 100
Ejemplo:
Total de scripts de prueba desarrollados 1360,
Total de scripts de prueba ejecutados 1280,
Total de scripts de prueba pasados 1065,
El script de prueba total falló 215
Entonces, la densidad del defecto del caso de prueba es
215 X 100
—————- = 16.8%
1280
Este valor de 16.8% también se puede llamar como% de eficiencia de caso de prueba, que depende del número total de casos de prueba que descubrieron defectos
4) Relación de deslizamiento de defectos
Número de defectos deslizados (reportados desde la producción) vs. número de defectos reportados durante la ejecución.
• Número de defectos deslizados / (Número de defectos aumentados – Número de defectos retirados)
Ejemplo:
Los defectos archivados por el cliente son 21,
Los defectos totales encontrados durante las pruebas son 267,
El número total de defectos inválidos es 17,
Entonces, la relación de deslizamiento es
[21 / (267-17)] X 100 = 8,4%
IV) Eficiencia de revisión
La eficacia de la revisión es una métrica que ofrece información sobre la calidad de la revisión y las pruebas. Algunas organizaciones también usan este término como eficiencia de “Pruebas estáticas” y su objetivo es obtener un mínimo de 30% de defectos en las pruebas estáticas.
Eficiencia de revisión = 100 * Número total de defectos encontrados por revisiones / Número total de defectos del proyecto
Ejemplo:
Un proyecto encontró un total de 269 defectos en diferentes revisiones, que fueron reparadas y el equipo de prueba obtuvo 476 defectos que fueron reportados y válidos
Entonces, la eficiencia de revisión es [269 / (269 + 476)] X 100 = 36.1%
Eficiencia y efectividad de los procesos
• Efectividad: hacer lo correcto. Se trata de cumplir con los atributos deseables que espera el cliente.
• Eficiencia: hacer lo correcto. Se trata de los recursos utilizados para prestar el servicio.
Métricas importantes para pruebas de software:
Eficacia de eliminación de defectos
DRE = defectos eliminados durante la fase de desarrollo x 100% de defectos latentes en el producto
Defectos latentes en el producto = defectos eliminados durante la fase de desarrollo + defectos encontrados más tarde por el usuario
Eficiencia del proceso de prueba (defina el tamaño en KLoC o FP, Req.)
Eficiencia de prueba = Tamaño del software probado / Recursos utilizados
Términos importantes:
¿Qué es la métrica?
Una escala de medición y el método utilizado para la medición.
¿Qué es la medición?
El proceso de asignar un número o categoría a una entidad para describir un atributo de esa entidad.
¿Qué es la escala de medición?
Una escala que restringe el tipo de análisis de datos que se puede realizar en él.
¿Qué es la medida?
El número o categoría asignada a un atributo de una entidad al realizar una medición.
Test Metrics Life Cycle
Fase 1: Análisis
• Identificación de métricas
• Definir las métricas identificadas
Fase 2: Comunicación
• Explicar la necesidad de métricas a las partes interesadas
• Educar al equipo de pruebas sobre los puntos de datos
Fase 3: Evaluación
• Capture y verifique los datos
• Calcular las métricas
Fase 4: Informe
• Desarrollar el informe
• Distribuya el informe a las partes interesadas
• Recibir comentarios de los interesados