En esta parte vamos a revisar el proceso para la creación de pruebas y algunas mejores prácticas.

Si no han leído las partes anteriores:

• primera parte
• segunda parte

Ciclo de vida de las pruebas

Cualquiera sea la metodología para las diferentes partes del sistema, se espera poder seguir un proceso que permita mantenernos enfocados en los requerimientos del producto y en desarrollar características una a la vez.

Este proceso tiene 6 pasos:

1. Análisis de requerimientos: El equipo de desarrollo se reune con los usuarios para revisar que requerimientos y características va a tener el producto. Por cada característica el grupo analiza una especificación que pueda ser probada y que permita indicar que se ha hecho correctamente.

2. Plan de pruebas: Aquí el equipo de desarrollo analiza the forma específica cómo se desarrollaran las pruebas. Puntos comunes son: qué recursos se necesitan? qué métricas cuantitativas podemos usar para probar el requerimiento? y cuáles factores de riesgo iniciales pueden afectar el resultado? Lo más importante es tener las métricas y los casos específicos muy enlazados a la especificación del producto.

3. Desarrollo de los casos de prueba: En este paso ya se desarrolla los casos de prueba o el conjunto de pruebas que verifica que el requerimiento se ha completado. Aquí usamos los procesos de pruebas funcionales para pruebas generales, o procesos de pruebas no funcionales para requerimientos específicos como pruebas de usabilidad.

4. Configuración de ambiente de pruebas: Se creará un amgiente de pruebas. Si el producto se va a instalar en varias plataformas, se requiere al menos un ambiente de pruebas por cada plataforma. Esto se logra generalmente con frameworks de pruebas y algunas máquinas virtuales. O a través de un sistema de integración continua como Github actions

5. Ejecución de las pruebas: En este paso se ejecuta las pruebas y se guarda todas las métricas decididas.

6. Análisis de resultados: En este punto se verifica cómo estuvo la ejecución de las pruebas. Es posible que para los próximos tests se requiere diferentes métricas, un ambiente de pruebas más refinado (diferentes dependencias), regresar al desarrollo de la solución para mejorar las métricas alcanzadas.

Todo este proceso es iterativo y generalmente no se lo ve como pasos, si te dan un requerimiento generalmente en tu cabeza analizas que tipos de pruebas puedes ejecutar para revisar la funcionalidad, qué voy a medir como parte del desarrollo del producto, se genera el caso de prueba usando Red-Green development que es escribo el test, lo ejecuto, da error RED, implemento el código mínimo para pasar la prueba y hacerlo GREEN y sigo implementado el programa al mismo tiempo que el test.

Mejores prácticas de pruebas de software

• No usen solamente pruebas automatizadas Las pruebas automatizadas solo verifican defectos que el programador sabe y busca. Al menos tener un paso de pruebas manuales para verificar defectos inesperados.

• Escribir casos de pruebas en lenguaje simple o pseudocódigo Esto permite compartir la verificación de las pruebas con los miembros no técnicos del equipo.

• Usar solo ambientes de tests controlados y aislados para evitar interferencia externa Es preferible trabajar en un ambiente repetible como un contenedor docker, ya que se sabe específicamente qué está instalado en ese contenedor, no ejecutarlos en la máquina local ya que puede haber dependencias no controladas.

• Escojer métricas específicas y cuantificables De esta forma se puede llevar un registro para agregar a los reportes.

• Probar antes del paso de QA Esto permite probar siempre durante el desarrollo y no solo al final, ayuda a ahorrar mucho tiempo al probar los componentes centrales bien desde el principio.

• Crear pruebas incrementales Hay que ir agregando condiciones dentro de la prueba para verificar dónde el programa falla.

• Maximizar cobertura Lo ideal es llegar a un 100% de cobertura, que quiere decir que las pruebas ejecutan todo el código fuente. De tal forma que todos los posibles caminos dentro del programa son ejecutados por las pruebas.

• Hacer que otro desarrollador cree las pruebas de integración o aceptación Esto permite evitar un sesgo de confirmación, ya que los casos de pruebas son escritos por alguien más.

• Usar nombres útiles Los casos se deben nombrar de acuerdo a la condición y requerimiento de la prueba. Evitar nombres como test1 o performanceTest, usar algo más específico por ejemplo calculoDeHorasParaEmpleadosConTurnosDeCambioDeDia

• Usar herramientas de pruebas de software En el mercado hay un sin número de herramientas que permiten realizar las pruebas analiza la que mejor se adapte a tu equipo.

El siguiente artículo será un caso de ejemplo, si quieres recibir una notificación regístrate.