DEV Community

loading...

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

Marcelo Andrade R.
husband, father, software engineer
Originally published at marceloandrader.github.io ・3 min read

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

Discussion (0)