Parte 3: Proceso de creación de pruebas y mejores prácticas
Tags: tip, desarrollo, software
Published: 2021-04-09 14:42:47

# 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.

1. 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.

1. 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.

1. 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](https://marceloandrader.github.io/blog/2021/02/01/github-actions/)

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

1. 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](https://marceloandrader.github.io/blog/2013/11/15/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 en https://marceloandrader.github.io/about/.