Es fundamental probar tanto código como sea posible,para eso hay que tener varias estrategias de pruebas y tener distintas estrategias para medir la cobertura de las pruebas y maximizarla a largo plazo.
La cobertura de la prueba es una medida de la calidad que nos permite saber que parte de aplicación se ha probado ya.
Una cobertura del 100% no garantiza que la aplicación este libre de defectos y de errores.
De hecho el porcentaje de la cobertura no es tan importante porque se debe realizar un análisis de riesgos y establecer la prioridad antes de determinar el objetivo de cobertura.
A continuación os voy a hablar de los distintos tipos de cobertura que existen.
Cobertura de código
La cobertura de código es la que se cubre con las pruebas de componentes o unitarias y se prueba las instrucciones o lineas de código y los caminos que nacen de puntos de decisión que generan ramas de ejecución de código.
Cobertura orientada a Datos
Con la cobertura orientada de datos,tienes parámetros de entrada de entrada y salida y se puede intentar probar todas las combinaciones posibles.
También puedes utilizar la cobertura de cada opción,que consiste en elegir cada valor al menos una vez.
La otra opción es la de todos los pares ,elegir los datos que estén en posición par.Esta opción se dice que es la que tiene mejor coste-beneficio.
Otros tipos de cobertura de pruebas
Una cobertura que es importante es la de la fragmentación móvil,que consiste en intentar probar los dispositivos móviles más utilizados,sistemas operativos y tamaños de pantalla.
Por ejemplo, probar smartphones y tablets con los sistema operativos de Android y IPhone con los tamaños de pantalla más comunes.
En cuanto portátiles lo normal seria con sistemas operativos de MacOS,Linux y Windows.
En cuanto a la cobertura de navegadores y sistemas operativos lo normal seria probar la aplicación web con los navegadores más habituales(Chrome,Edge y Firefox) con los sistemas de MacOS,Linux y Windows.
Diseño de un plan
Imaginemos que tenemos que probar una funcionalidad y tenemos un conjunto de suites de pruebas con sus correspondientes casos de pruebas y sus correspondientes datos.
Supongamos que son 4 suite ,uno para pruebas funcionales,otros para pruebas de rendimiento,otro para pruebas de seguridad y otras para pruebas de usabilidad.
Para que a largo plazo se tenga la máxima cobertura necesitamos probar los casos más críticos de cada suite con todos los navegadores y para eso podemos ejecutar las pruebas en fechas diferentes o sprints diferentes pero con un solo navegador y a la larga después de 4 sprints o ciclos conseguimos probar la funcionalidad en todos los navegadores y con todos las suites.
En cada ciclo no tenemos una gran cobertura pero después de varios ciclo la cobertura es mucho mejor.
Esta cobertura se puede aplicar en sprint de 1 semana en que están muy apretados de tiempo y se necesita tener claro que se reduce el riesgo .
Este es un ejemplo de cómo planificar una buena cobertura de prueba durante múltiples ciclos de testing.
Para algunos de ellos, es obligatorio ejecutar la prueba cada vez en todos los navegadores (probablemente las más críticas). Otros se pueden dividir en grupos y ejecutar solo en un navegador,los que no son tan críticos.
Aquí hay otro ejemplo aplicado a las pruebas móviles para reducir el riesgo relacionado con la “fragmentación” del dispositivo.
Después de la tercera ejecución, tendríamos la cobertura de todos los dispositivos.
Conclusión
Los criterios de cobertura se deben elegir en función de las necesidades de cada uno,no todas los requerimientos tienen la misma importancia y por lo tanto prioridad.
¡Sígueme en LinkedIn, Twitter, Facebook, Instagram y YouTube para ser parte de nuestra comunidad y aprender más sobre testing y QA.
[dlm_buy id=»695″]
Visitas: 22
Soy Alejandro Juan Canosa Ferreiro, experto en calidad de software y escritor. Tengo publicado el libro Scrum. Teoría e implementación práctica, tiene 9 versiones, y acabo de publicar mi segundo libro Certificación ISTQB Certified Foundation Level 4.0.
Actualmente soy responsable de calidad en un proyecto para SEPI en la empresa pública tragsa.
