jueves, 20 de abril de 2017

Cápsulas de pruebas - Estrategias de Datos v2


En los equipos que desarrollan ágilmente se busca que todos los miembros del equipo tenga un conocimiento mínimo de las actividades de testing. También que los testers profundicen su conocimiento.

¿Cómo podemos distribuir ese conocimiento?
Las cápsulas de información de testing son una manera incremental de incorporar conceptos a partir de ejemplos del equipo o externos. Pueden servir como guía para realizar círculos de aprendizaje en el equipo de desarrollo o para profundizar conocimientos en comunidades de práctica.
Algunas cápsulas de conocimiento: Arquitectura de la prueba Automática, Modelo del Oráculo y Pruebas Diagnósticas.

En este caso, nos encontraremos 45 min el 21 de abril de 2017 (¡mañana!) para hablar sobre las estrategias de preparación de datos para pruebas automatizadas, de 13:15 a 14:00hs Bs As.

Agenda

  • Presentar el concepto (10 min).
  • Trabajar en grupos para analizar el ejemplo, o un caso particular (20 min).
  • Presentar los resultados (10 min).
  • Cierre (5 min).
Anotate

(Próximo encuentro, viernes 28 de abril, votá los temas)



Cápsula de Pruebas - Datos de Prueba

¿Cómo generar los datos de prueba?
¿Cómo lograr que los datos estén en disponibles en el momento de la prueba?


¿Cómo lo he hecho?

Para ejecutar las pruebas automáticas, necesitamos que la aplicación o SUT (System Under Test) esté en un estado conocido. Ese estado incluye los datos necesarios para la prueba.


Toma una prueba que estés realizando en este momento o que realizaste hace poco, piensa y anota:
  • ¿Cómo obtuviste o generaste los datos de prueba?
  • ¿Cómo lograste que esos casos de prueba estén cargados o disponibles para el SUT?


Generación de datos

Por Diseño: Se inventan datos que ejercitan la funcionalidad a desarrollar. Los ejemplos pueden estar basados en la experiencia en el negocio o en las hipótesis de uso futuro. Por ejemplo, generar datos que corresponden a situaciones límites y de error, hayan ocurrido o no.


Datos Reales: Tomar un conjunto de datos de la aplicación actual o del problema a resolver. Por ejemplo, tomar los conceptos facturados  en el último mes, o los clientes y movimientos de una sucursal durante el año pasado.


Simulados: Utilizar un algoritmo para generar datos. Por ejemplo, todas las combinaciones posibles de los variables de entrada, o valores aleatorios.


Object Mother: Cada entidad de la aplicación tiene un mecanismo para generar objetos de prueba. Normalmente con datos default y las entidades adicionales las genera recursivamente. Por ejemplo, una prueba que necesita un cliente, la prueba le pide a la entidad Cliente una instancia de prueba. Cliente genera un cliente que tiene un nombre y apellido default (Juan Perez). Para completar el país de nacimiento,  Cliente le pide a la entidad Pais una instancia de prueba.


Estado conocido

Cargar cada vez: Cargar los datos para cada prueba. Esto puede hacerse a diferentes niveles: desde el repositorio de los datos (base de datos, archivos), desde una capa de servicios o componentes, a través de la funcionalidad disponible para el usuario final. Puede cargarse a partir de un estado inicial vacío, o como incremento. Puede ser necesario modificar datos (fechas, números de referencias cruzadas).


No cambiar: Se llega al estado conocido y se lo proteje. Por ejemplo backup y restore de bases de datos, se utilizan transacciones de base de datos, se realizan operaciones que no modifiquen datos o se realizan operaciones que revierten la operación realizada en la prueba.


Existentes: Asumiendo que tenemos un volumen alto y variado de datos, realizamos una búsqueda que nos traiga un dato con las características que necesitamos.


Mock (o dobles): Reemplazamos un componente del sistema, que no nos interesa probar, por un mecanismo que devuelva datos conocidos. Pueden ser siempre los mismos datos o puede ser más inteligente.


Actividades

Analiza el siguiente ejemplo y proponer la estrategia para los datos de prueba:


Tenemos una aplicación monolítica que resuelve una parte central del negocio de nuestra organización. Siguiendo las buenas prácticas actuales, se busca migrar hacia una arquitectura de microservicios. La migración será incremental, y en cada micro servicio se va a realizar en dos fases: duplicar funcionalidad mínima de la aplicación actual, y luego agregar funcionalidad nueva, valiosa para el negocio.
La aplicación actual tiene algunas pruebas automatizadas a través de la UI.
Queremos que puedan trabajar en paralelo los equipos que modifican el sistema monolítico remanente y los que desarrollan cada nuevo micro servicio.
¿Qué alternativas tenemos para generar los datos de prueba?
¿Cuáles son los pros y contras de cada una de las alternativas?