En los proyectos de software, lo más importante es medir la calidad, el costo y la eficacia del proyecto y los procesos. Sin medir estos, un proyecto no se puede completar con éxito. En el artículo, aprenderemos con ejemplos y gráficos: métricas y medidas de prueba de software y cómo usarlas en el proceso de prueba de software.
Hay una frase famosa: “No podemos controlar las cosas que no podemos medir”.
¿Qué son las métricas de prueba de software?
Una métrica es una medida cuantitativa utilizadas para estimar el progreso, la calidad, la productividad y el estado del proceso de prueba de software.
Las métricas se pueden definir como “ESTÁNDARES DE MEDICIÓN ”.
Las métricas de software se utilizan para medir la calidad del proyecto. Simplemente, una métrica es una unidad utilizada para describir un atributo. La métrica es una escala para medir.
Supongamos que, en general, “Kilogramo” es una métrica para medir el atributo “Peso”. De manera similar, en el software, “¿Cuántos problemas se encuentran en mil líneas de código?”, Aquí el número de problemas es una medida y el número de líneas de código es otra medida. La métrica se define a partir de estas dos medidas.
Ejemplo de métricas de prueba:
¿Cuántos defectos existen dentro del módulo? ¿Cuántos usuarios puede soportar el software simultáneamente?¿Cuántos casos de prueba se ejecutan por persona?¿Qué es el % de cobertura de prueba?
¿Por qué probar métricas de prueba de software?
La generación de métricas de prueba de software es la responsabilidad más importante del líder/gerente de prueba de software.
Las métricas de prueba se utilizan para,
- Tomar la decisión para la siguiente fase de actividades, como estimar el costo y el cronograma de proyectos futuros.
- Comprender el tipo de mejora requerida para el éxito del proyecto.
- Tomar una decisión sobre el Proceso o Tecnología a modificar, etc.
Importancia de las métricas de prueba de software:
Como se explicó anteriormente, las métricas de prueba son las más importantes para medir la calidad del software.
Ahora bien, ¿cómo podemos medir la calidad del software utilizando Métricas ?
Supongamos que, si un proyecto no tiene ninguna métrica, ¿Cómo se medirá la calidad del trabajo realizado por un analista de pruebas?
Por ejemplo, un analista de pruebas tiene que,
- Diseñe los casos de prueba para 5 requisitos
- Ejecutar los casos de prueba diseñados
- Registre los defectos y la necesidad de fallar en los casos de prueba relacionados
- Una vez resuelto el defecto, debemos volver a probar el defecto y volver a ejecutar el caso de prueba fallido correspondiente.
En el escenario anterior, si no se siguen las métricas, el trabajo realizado por el analista de pruebas será subjetivo, es decir, el informe de prueba no tendrá la información adecuada para conocer el estado de su trabajo/proyecto.
Tipos de métricas de prueba
- Métricas de proceso: se puede utilizar para mejorar la eficiencia del proceso del SDLC (Ciclo de vida de desarrollo de software)
- Métricas del producto: Se trata de la calidad del producto de software.
- Métricas del proyecto: se puede usar para medir la eficiencia de un equipo de proyecto o cualquier herramienta de prueba que utilicen los miembros del equipo.
La identificación de las métricas de prueba correctas es muy importante. Se deben considerar algunas cosas antes de identificar las métricas de prueba
- Fijar el público objetivo para la preparación de métricas
- Definir el objetivo de las métricas
- Introducir todas las métricas relevantes basadas en las necesidades del proyecto
- Analice el aspecto de costo-beneficio de cada métrica y la fase de estilo de vida del proyecto en la que da como resultado el máximo rendimiento
Métricas de prueba manuales
En ingeniería de software, las métricas de prueba manual se clasifican en dos clases
- Métricas base
- Métricas calculadas
Las métricas base son los datos sin procesar recopilados por Test Analyst durante el desarrollo y la ejecución del caso de prueba (cantidad de casos de prueba ejecutados, cantidad de casos de prueba ). Mientras que las métricas calculadas se derivan de los datos recopilados en las métricas base. El administrador de pruebas generalmente sigue las métricas calculadas para fines de informes de pruebas ( % completado, % de cobertura de pruebas ).
Dependiendo del proyecto o modelo de negocio, algunas de las métricas importantes son
- Métricas de productividad de ejecución de casos de prueba
- Métricas de productividad de preparación de casos de prueba
- Métricas de defectos
- Defectos por prioridad
- Defectos por gravedad
- Relación de deslizamiento de defectos
Ciclo de vida de las métricas
Cómo calcular la métrica de prueba
| Pasos para probar métricas | Ejemplo | |
| 1 | Identificar los procesos clave de prueba de software que se medirán | Probar el proceso de seguimiento del progreso |
| 2 | En este paso, el evaluador utiliza los datos como referencia para definir las métricas | El número de casos de prueba planeados para ser ejecutados por día |
| 3 | Determinación de la información a seguir, frecuencia de seguimiento y responsable | La ejecución real de la prueba por día será capturada por el administrador de la prueba al final del día. |
| 4 | Cálculo, gestión e interpretación efectivos de las métricas definidas | Los casos de prueba reales ejecutados por día |
| 5 | Identificar las áreas de mejora en función de la interpretación de las métricas definidas | La ejecución del Caso de Prueba cae por debajo del objetivo establecido, necesitamos investigar el motivo y sugerir las medidas de mejora. |
Ejemplos de prueba de software
Tomemos un ejemplo para calcular varias métricas de prueba utilizadas en los informes de prueba de software: A continuación, se muestra el formato de la tabla para los datos recuperados del Analista de pruebas que está realmente involucrado en las pruebas:
Para entender cómo calcular las métricas de prueba, veremos un ejemplo de un caso de prueba porcentual ejecutado.
Para obtener el estado de ejecución de los casos de prueba en porcentaje, usamos la fórmula.
Porcentaje de casos de prueba ejecutados= (Nº de casos de prueba ejecutados/Nº total de casos de prueba escritos) X 100
Del mismo modo, puede calcular otros parámetros como casos de prueba no ejecutados, casos de prueba aprobados, casos de prueba fallidos, casos de prueba bloqueados, etc.
En Atentus, entendemos que el rendimiento de tu software importa mucho, y es por eso que nuestro servicio de prueba de Software y de pruebas de carga y estrés se realizan con la máxima precisión y eficiencia. De esta manera, podemos monitorear que tu software, sitio web o aplicación esté funcionando a pleno rendimiento cuando llegue el momento de los eventos de descuentos.
¿Quiere realizar tu prueba software, de carga y estrés? Solicita aquí una demostración gratis.
Glosario de métricas de prueba
- Proporción de esfuerzo de reelaboración = (Esfuerzos reales de reelaboración gastados en esa fase/esfuerzos reales totales gastados en esa fase) X 100
- Flujo de requisitos = (Número total de requisitos añadidos/Nº de requisitos iniciales)X100
- Variación del cronograma = (Fecha real de entrega – Fecha planificada de entrega)
- Costo de encontrar un defecto en las pruebas = (Esfuerzo total gastado en las pruebas/defectos encontrados en las pruebas)
- Desviación del cronograma = (Fecha de finalización real – Fecha de finalización estimada) / (Fecha de finalización planificada – Fecha de inicio planificada) X 100
- Porcentaje de casos de prueba aprobados = (Número de pruebas aprobadas/Número total de pruebas ejecutadas) X 100
- Porcentaje de casos de prueba fallidos = (Número de pruebas fallidas/Número total de pruebas ejecutadas) X 100
- Porcentaje de casos de prueba bloqueados = (Número de pruebas bloqueadas/Número total de pruebas ejecutadas) X 100
- Porcentaje de defectos reparados = (Defectos reparados/Defectos informados) X 100
- Porcentaje de defectos aceptados = (Defectos aceptados como válidos por el equipo de desarrollo/Total de defectos informados) X 100
- Porcentaje de defectos diferidos = (Defectos diferidos para versiones futuras/Total de defectos informados) X 100
- Porcentaje de defectos críticos = (Defectos críticos / Defectos totales informados) X 100
- Tiempo medio para que un equipo de desarrollo repare los defectos = (Tiempo total necesario para la corrección de errores/Número de errores)
- Número de pruebas ejecutadas por período de tiempo = Número de pruebas ejecutadas/Tiempo total
- Eficiencia del diseño de pruebas = Número de pruebas diseñadas/Tiempo total
- Eficiencia de revisión de pruebas = Número de pruebas revisadas/Tiempo total
- Error de búsqueda de memoria o Número de defectos por hora de prueba = Número total de defectos/Número total de horas de prueba