Introducción
Definir criterios de cobertura, en este caso para medir la base de prueba, es de mucha utilidad para cualquier nivel de prueba o tipo de prueba [*] que estemos pensando implementar. Podemos representarlos por medio de KPI’s (Indicadores Claves de Desempeño).
Algunos ejemplos:
Cobertura de declaración (Statement Coverage):
- Definición: Esta métrica mide la cantidad de declaraciones de código ejecutadas durante la ejecución de las pruebas.
- Medición: Se establece un porcentaje que indica la proporción de declaraciones ejecutadas con respecto al total de declaraciones en el código.
- Importancia: Un alto porcentaje de cobertura de declaración sugiere que la mayoría de las líneas de código se han ejecutado, lo que puede indicar una buena exploración del código.
Cobertura de camino (Path Coverage):
- Definición: Esta métrica se centra en la cobertura de los diferentes caminos o rutas de ejecución a través del código.
- Medición: Se analizan y cuentan los diferentes caminos que pueden tomar las ejecuciones del programa, y se mide la proporción de estos caminos que se han cubierto durante las pruebas.
- Importancia: La cobertura de camino ayuda a garantizar que se hayan probado diferentes escenarios de ejecución, identificando posibles ramas lógicas o decisiones en el código.
Estos criterios de cobertura son medibles y proporcionan indicadores clave para evaluar la efectividad de las pruebas de software. Tener altos niveles de cobertura en estas métricas puede ser indicativo de una cobertura exhaustiva del código fuente.
¿Porqué es útil y necesario?
Medición del Alcance de las Pruebas:
Establecer criterios de cobertura permite medir cuánto del código fuente o de los caminos lógicos del programa se ha evaluado durante las pruebas.
Indicadores de Desempeño:
Los criterios de cobertura actúan como indicadores clave de desempeño. Un alto nivel de cobertura sugiere que se han explorado diversas partes del software, lo que puede ser indicativo de un proceso de prueba sólido.
Control de Actividades de Prueba:
Ayudan a controlar y gestionar las actividades de prueba. Al establecer metas de cobertura, se puede supervisar el progreso y garantizar que se estén cubriendo adecuadamente diferentes aspectos del software.
Demostración de Objetivos Alcanzados:
Los criterios medibles son útiles para demostrar que los objetivos de las pruebas se han alcanzado. Esto es esencial para validar la calidad del software y asegurar que cumple con los requisitos especificados.
Identificación de Áreas No Probadas:
Al definir criterios específicos, se pueden identificar áreas del código que no han sido cubiertas por las pruebas. Esto puede ayudar a enfocar los esfuerzos de prueba en áreas críticas o descuidadas.
[*]
Niveles de Prueba:
- Pruebas Unitarias: Se centran en verificar el correcto funcionamiento de unidades individuales de código.
- Pruebas de Integración: Verifican la interacción correcta entre módulos o componentes del sistema.
- Pruebas de Sistema: Evalúan el sistema completo para asegurar que cumple con los requisitos especificados.
- Pruebas de Aceptación del Usuario (UAT): Realizadas por los usuarios finales para validar si el sistema cumple con sus necesidades y expectativas.
Tipos de Prueba:
- Pruebas Funcionales: Verifican que el software funcione según lo esperado.
- Pruebas No Funcionales: Evalúan atributos no funcionales como rendimiento, seguridad, usabilidad, etc.
- Pruebas de Regresión: Se realizan para asegurar que los cambios en el código no afecten negativamente a funcionalidades existentes.
- Pruebas de Carga: Evaluación del rendimiento del sistema bajo condiciones de carga máxima.
- Pruebas de Estrés: Determinan cómo se comporta el sistema bajo condiciones extremas.
- Pruebas de Seguridad: Evalúan la resistencia del software a amenazas de seguridad.
- Pruebas de Usabilidad: Se centran en la experiencia del usuario y la facilidad de uso del software.
Conclusiones
Obviamente, todos estos items son gestionado como corresponde por medio de las herramientas que permiten una gestión integral de testing.
