Parte 3: Proceso de creación de pruebas y mejores prácticas

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 en https://marceloandrader.github.io/about/.