important software test metrics
En los proyectos de software, es más importante 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 de hoy, aprenderemos con ejemplos y gráficos – Métricas y medidas de prueba de software y cómo utilizarlos en el proceso de prueba de software.
Hay una declaración famosa: 'No podemos controlar cosas que no podemos medir'.
Aquí, controlar los proyectos significa cómo un jefe de proyecto / líder puede identificar las desviaciones del plan de prueba lo antes posible para reaccionar en el Tiempo perfecto. La generación de métricas de prueba basadas en las necesidades del proyecto es muy importante para lograr la calidad del software que se prueba.
Lo que vas a aprender:
- ¿Qué son las métricas de pruebas de software?
- ¿Qué es la medición de prueba de software?
- ¿Por qué probar las métricas?
- Ciclo de vida de las métricas
- Tipos de métricas de prueba manuales
- Ejemplos de métricas de pruebas de software
- Conclusión
- Lectura recomendada
¿Qué son las métricas de pruebas de software?
Una métrica es una medida cuantitativa del grado en que un sistema, componente del sistema o proceso posee un atributo determinado.
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 que se utiliza para describir un atributo. La métrica es una escala de medición.
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?', H además 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 casos de prueba se ejecutan por persona?
- ¿Qué es el porcentaje de cobertura de prueba?
¿Qué es la medición de prueba de software?
La medida es la indicación cuantitativa de la extensión, cantidad, dimensión, capacidad o tamaño de algún atributo de un producto o proceso.
Ejemplo de medición de prueba: Número total de defectos.
Consulte el diagrama a continuación para obtener una comprensión clara de la diferencia entre medición y métricas.
¿Por qué probar las métricas?
La generación de métricas de prueba de software es la responsabilidad más importante del jefe / gerente de prueba de software.
Las métricas de prueba se utilizan para,
- Tome la decisión para la siguiente fase de actividades, como estimar el costo y el cronograma de proyectos futuros.
- Comprender el tipo de mejora necesaria 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, ¿Cómo podemos medir la calidad del software utilizando métricas? ?
Supongamos que, si un proyecto no tiene métricas, ¿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
- Ejecute los casos de prueba diseñados
- Registre los defectos y necesite fallar 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, entonces el trabajo completado por el analista de prueba será subjetivo, es decir, el Informe de prueba no tendrá la información adecuada para conocer el estado de su obra / proyecto.
Si Metrics está involucrado en el proyecto, entonces se puede publicar el estado exacto de su trabajo con los números / datos adecuados.
es decir, en el Informe de prueba, podemos publicar:
- ¿Cuántos casos de prueba se han diseñado por requisito?
- ¿Cuántos casos de prueba quedan por diseñar?
- ¿Cuántos casos de prueba se ejecutan?
- ¿Cuántos casos de prueba se aprobaron / fallaron / bloquearon?
- ¿Cuántos casos de prueba aún no se han ejecutado?
- ¿Cuántos defectos se identifican y cuál es la gravedad de esos defectos?
- ¿Cuántos casos de prueba fallan debido a un defecto en particular? etc.
En base a las necesidades del proyecto podemos tener más métricas que una lista antes mencionada, para conocer el estado del proyecto en detalle.
Con base en las métricas anteriores, el Jefe de prueba / Gerente comprenderá los puntos clave mencionados a continuación.
- % de trabajo completado
- % de trabajo aún por completar
- Tiempo para completar el trabajo restante
- ¿Si el proyecto va según el cronograma o está retrasado? etc.
Según las métricas, si el proyecto no se completará según el cronograma, entonces el gerente dará la alarma al cliente y otras partes interesadas al proporcionar las razones del retraso para evitar sorpresas de último minuto.
Ciclo de vida de las métricas
destripador de dvd freeware para windows 8
Tipos de métricas de prueba manuales
Las métricas de prueba se dividen principalmente en 2 categorías.
- Métricas base
- Métricas calculadas
Métricas base: Las métricas base son las métricas que se derivan de los datos recopilados por el analista de pruebas durante el desarrollo y la ejecución del caso de prueba.
Se hará un seguimiento de estos datos durante todo el ciclo de vida de la prueba. Es decir. recolectando los datos como Total no. de casos de prueba desarrollados para un proyecto (o) no. de los casos de prueba deben ejecutarse (o) no. de casos de prueba aprobados / fallidos / bloqueados, etc.
Métricas calculadas: Las métricas calculadas se derivan de los datos recopilados en las métricas base. Estas métricas generalmente son rastreadas por el líder de prueba / gerente para propósitos de informes de prueba.
Ejemplos de métricas de pruebas 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:
Definiciones y fórmulas para calcular métricas:
java agregando valores a una matriz
# 1)% ge Casos de prueba ejecutados : Esta métrica se utiliza para obtener el estado de ejecución de los casos de prueba en términos de% ge.
% ge Casos de prueba ejecutados = ( No de casos de prueba ejecutados / No total de casos de prueba escritos) * 100.
Entonces, a partir de los datos anteriores,
% ge Casos de prueba ejecutados = (65/100) * 100 = 65%
# 2)% ge Casos de prueba no ejecutados : Esta métrica se utiliza para obtener el estado de ejecución pendiente de los casos de prueba en términos de% ge.
% ge Casos de prueba no ejecutados = ( No de casos de prueba no ejecutados / No total de casos de prueba escritos) * 100.
Entonces, a partir de los datos anteriores,
% ge Casos de prueba bloqueados = (35/100) * 100 = 35%
# 3)% ge Casos de prueba aprobados : Esta métrica se utiliza para obtener el Pass% ge de los casos de prueba ejecutados.
% ge Casos de prueba aprobados = ( No. de casos de prueba Aprobados / No. total de casos de prueba ejecutados) * 100.
Entonces, a partir de los datos anteriores,
% ge Casos de prueba aprobados = (30/65) * 100 = 46%
# 4)% ge Casos de prueba fallidos : Esta métrica se usa para obtener el% de falla de los casos de prueba ejecutados.
% ge Casos de prueba fallidos = ( No. de casos de prueba Fallidos / No. total de casos de prueba ejecutados) * 100.
Entonces, a partir de los datos anteriores,
% ge Casos de prueba Pasados = (26/65) * 100 = 40%
# 5)% ge Casos de prueba bloqueados : Esta métrica se utiliza para obtener el% ge bloqueado de los casos de prueba ejecutados. Se puede enviar un informe detallado especificando el motivo real del bloqueo de los casos de prueba.
% ge Casos de prueba bloqueados = ( No. de casos de prueba bloqueados / No. total de casos de prueba ejecutados) * 100.
Entonces, a partir de los datos anteriores,
% ge Casos de prueba bloqueados = (9/65) * 100 = 14%
# 6) Densidad de defectos= No. de defectos identificados / tamaño
( Aquí 'Tamaño' se considera un requisito. Por lo tanto, aquí la Densidad de defectos se calcula como un número de defectos identificados por requerimiento. De manera similar, la Densidad de Defectos se puede calcular como un número de Defectos identificados por 100 líneas de código (O) No. de defectos identificados por módulo, etc. )
Entonces, a partir de los datos anteriores,
Densidad de defectos = (30/5) = 6
# 7) Eficiencia de eliminación de defectos (DRE)= ( No. de defectos encontrados durante las pruebas de control de calidad / (No. de defectos encontrados durante las pruebas de control de calidad + No. de defectos encontrados por el usuario final)) * 100
DRE se utiliza para identificar la eficacia de la prueba del sistema.
Supongamos que durante las pruebas de desarrollo y control de calidad, hemos identificado 100 defectos.
Después de las pruebas de QA, durante las pruebas Alpha y Beta, el usuario final / cliente identificó 40 defectos, que podrían haber sido identificados durante la fase de prueba de QA.
Ahora, el DRE se calculará como,
DRE = (100 / (100 + 40)) * 100 = (100/140) * 100 = 71%
# 8) Fuga por defecto: La fuga por defecto es la métrica que se utiliza para identificar el eficiencia de las pruebas de control de calidad es decir, cuántos defectos se pasan por alto / se deslizan durante las pruebas de control de calidad.
Fuga por defecto = ( No. de defectos encontrados en UAT / No. de defectos encontrados en pruebas de control de calidad.) * 100
Supongamos que durante las pruebas de desarrollo y control de calidad, hemos identificado 100 defectos.
Después de las pruebas de QA, durante las pruebas Alpha y Beta, el usuario final / cliente identificó 40 defectos, que podrían haberse identificado durante la fase de prueba de QA.
Fuga por defecto = (40/100) * 100 = 40%
# 9) Defectos por prioridad : Esta métrica se utiliza para identificar el no. de defectos identificados en función de la gravedad / prioridad del defecto que se utiliza para decidir la calidad del software.
% ge Defectos críticos = No. de defectos críticos identificados / No. total de defectos identificados * 100
De los datos disponibles en la tabla anterior,
% ge Defectos críticos = 6/30 * 100 = 20%
% ge High Defects = N. ° de defectos elevados identificados / N. ° total de defectos identificados * 100
De los datos disponibles en la tabla anterior,
% ge High Defects = 10/30 * 100 = 33.33%
% ge Defectos medianos = No. de defectos medianos identificados / No. total de defectos identificados * 100
De los datos disponibles en la tabla anterior,
% ge Defectos medios = 6/30 * 100 = 20%
% ge Low Defects = No. de defectos bajos identificados / No. total de defectos identificados * 100
De los datos disponibles en la tabla anterior,
% ge Defectos bajos = 8/30 * 100 = 27%
Lectura recomendada=> Cómo escribir un informe de resumen de prueba eficaz
Conclusión
Las métricas proporcionadas en este artículo se utilizan principalmente para generar el Informe de estado diario / semanal con datos precisos durante la fase de desarrollo / ejecución del caso de prueba y esto también es útil para rastrear el estado del proyecto y la calidad del software.
Sobre el Autor : Esta es una publicación invitada de Anuradha K. Tiene más de 7 años de experiencia en pruebas de software y actualmente trabaja como consultora para una multinacional. También tiene un buen conocimiento de las pruebas de automatización móvil.
¿Qué otras métricas de prueba utiliza en su proyecto? Como de costumbre, háganos saber sus pensamientos / consultas en los comentarios a continuación.
Lectura recomendada
- Ejercicios de prueba de software: nueva plataforma para probar sus habilidades de prueba y compartir ideas prácticas
- ¿Qué son las pruebas de resistencia en las pruebas de software (ejemplos)?
- Cómo revisar el documento SRS y crear escenarios de prueba - Capacitación sobre pruebas de software en un proyecto en vivo - Día 2
- Capacitación sobre pruebas de software: capacitación integral sobre un proyecto en vivo - Capacitación gratuita en línea sobre control de calidad, parte 1
- Pruebas de aplicaciones: ¡los conceptos básicos de las pruebas de software!
- Tutorial de QTP n. ° 18: marcos híbridos y controlados por datos explicados con ejemplos de QTP
- ¿Qué es el ciclo de vida de las pruebas de software (STLC)?
- Metadatos en el almacén de datos (ETL) explicados con ejemplos