Author Archives: ebaldizzoni

¿Puede alguien pensar en los datos?

En todo proceso de QA se requiere un set de datos válido para poder realizar la correcta manipulación del sistema y transitar por sus estados internos con el fin de detectar defectos en el uso. Para esto se requiere un lugar central para almacenarlos y distribuirlos para todo el equipo.
Esta tarea suele ser responsabilidad del Rol de QA debido a que es quien primero los requiere. Cuando la tarea de recolección de los datos no se asocia a ningún Rol suele ser un problema grave de todo el equipo por el simple motivo de ser escasos o inexistentes.
En resumen son simplemente datos para poder probar la aplicación y son útiles no solo para el QA sino que también para todos los actores que involucran el desarrollo o puesta en marcha de un sistema desde el inicio de los requerimientos hasta la capacitación a los usuarios.
En varios estudios y en experiencias personales es evidente que una pobreza de datos y de entornos de prueba constituye los principales problemas a los cuales nos enfrentamos los profesionales de la ingeniería de software ágiles en cada proyecto. (una fuente https://www.sogeti.com/explore/reports/world-quality-report-2017-2018/).

Para entender un poco más de que se trata es posible categorizarlos.
• Datos correctos para enfoque positivo.
• Datos incorrectos para enfoque negativo.
• Datos no válidos para ver errores relevantes o no.
• Datos de límite
• Datos ausentes

Puede notarse lo complejo de tener datos correctos y útiles. Para delimitar su búsqueda y entendimiento es posible determinar diferente formas de obtenerlos:
• A mano
• Entorno de producción
• Duplicación de sistemas existentes viejos
• Datos post ejecución de automatización
Cabe aclarar que de ninguna manera se debe recurrir a modificar la base de datos para preparar o simular un estado, siempre basarse en estados generados por la aplicación en su manipulación manual o automática.

Los datos en implementaciones específicas de QA por ejemplo, si se piensa a QA como servicio (Testing-as-a-Service [TaaS]), la tarea de gestión de datos es fundamental. Aumenta la velocidad de prueba hasta en un 25% y reduce el costo entre un 5 y un 10%.

Que se necesita para una correcta Gestión de los datos en Test Data Management
Eficiencia. Los Testers pasan mucho tiempo buscando y creando datos para las pruebas. se calcula que esta tarea consume del 50 al 75% del esfuerzo.
Cobertura: Los datos productivos cuentan con un porcentaje muy bajo de posibilidades de prueba. Mas si los datos que provocan fallos no son almacenados. Alrededor del 20% son los casos que cubren.
Skills: Se requieren muchos conocimientos en bases de datos, documentación en contratos de apis, herramientas de login, bases de datos no relacionales, etc. Para esta tarea es necesario hurgar en los datos por lo que se requieren skills amplios además de entender cómo modelar los datos.

En cuanto a los procesos

Los procesos tradicionales se ejecutan en forma que en su mayoría requiere de procesos manuales, en ocasiones solo el tester es quien entiendo como armar y crear estos datos debido a la carencia de procesos estándar.
Por otra parte, los datos que se utilizan en ambientes de prueba, en el momento en que crecen la cantidad de pruebas a ejecutar al momento de una regresión y en mayor medida cuando se realizan las pruebas de forma paralela generan un problema aún más grave que es la necesidad de trazabilidad de los casos con el fin de dejar el ambiente de una forma esperada para el siguiente script de tal forma de poder ejecutarlo debido a que es imposible ejecutarlos sin un estado previo. Esto se agudiza en pruebas automatizadas, extremadamente necesarias en procesos de CI/CD.

Con respecto a los ambientes

Inicialmente debemos pensar en la ética y la privacidad, los datos de prueba deben ser lo más reales posibles teniendo en cuenta estas premisas.
Por estos motivos se recurre a la preparación de los ambientes para que cuenten con un estado necesario antes de iniciar haciendo que siempre se usen los mismos datos provocando falsos negativos o positivos cuando estos cambian de forma inesperada producido esto por cambios en el orden de la ejecución.
También a complejas soluciones de flujos de casos de pruebas o escenarios para lograr preparar los datos de entrada para otros flujos lo que termina en casos de prueba que demorar demasiado teniendo regresiones manuales que duran meses y en el caso de los automatizados demasiadas horas retrasando los procesos de entrega.
Esto si pensamos que los datos son los correctos, el problema se profundiza cuando estos datos cuentan con defectos producto de problemas tradicionales.

Mantenimiento

El Test Data Management tiene un costo grande en mantenimiento, hacerla de forma desprolija y sin un sentido claro es aún peor. A medida que pasa el tiempo y el software evoluciona los datos deben seguir esas evoluciones y por ende requieren un seguimiento y control.
También se requieren diferentes ejemplos de datos para casos de prueba o ambientes.
Los casos de prueba y sus datos deben estar diseñados para detectar defectos, cuanto más robustos son estos dos elementos más posibilidades de éxito tiene el software o sea más garantías.
En un contexto ágil esto se vuelve más importante dado que las entregas son más frecuentes (para reducir el Time-To-Market) y más en la automatización donde esta tarea es un eslabón fundamental del pipeline de entrega en CI/CD.

Esto demuestra una necesidad en formalizar procesos de Data Management o en simplificar la tarea sin restarle la importancia que merece sin perder de vista que continuar agregando complejidades a los proyectos de desarrollo conlleva a mayores costos. En post posteriores comentaremos algunas de las medidas que tomamos para
Nos centraremos en la segunda premisa con el fin de reducir la necesidad de horas hombre.

Los Microservicios y APIs

Con el avance de las tecnologías y más con el gran crecimiento que tuvieron las arquitecturas de microservicios y la gran utilización de apis como contratos de comunicación y distribución de los datos entre los diferentes actores, es muy probable que con el uso de mocks se logre una agilidad en la generación de los casos de prueba. Esto hace que las necesidades de los equipos de QA cambien requiriendo antes que nada la documentación de los contratos pudiendo retrasar las tareas de búsqueda y generación de datos de prueba mejorando la agilidad en la entrega de los casos automatizados y colaborando con los requerimientos de procesos de CI/CD en cuanto a pruebas de integración.
Con lippia logramos orquestas un espacio de pruebas con docker-compose el cual cuenta con un wiremock configurado para mockear tres endpoint de ejemplo y con sus debidas pruebas las cuales corren con un comando docker-compose. Esto puede probarse en:
https://github.com/Crowdar/Lippia-API-sample-project.git
En este proceso se puede comenzar a preparar los datos para el siguiente paso. Para esto es necesario documentar los datos usados. Tener en cuenta en los escenarios positivos y los negativos. También se puede observar el estado previo de los datos, los datos utilizados para la prueba y el estado siguiente con el fin de documentar en profundidad los cambios y contar con estados intermedios.
Luego de que las APIS están listas pueden apagarse los endpoint en los mocks y cambiarse por los ya desarrollados por lo que a esta altura los datos pueden estar listos disminuyendo los bloqueos en los equipos de QA y reduciendo cambios por defectos en los datos o por cambios en las bases de datos que se realizan en el desarrollo.

Las bases de dato copias

Para el caso de datos que provienen de bases de datos de ejemplo puede utilizarse liquibase, esto nos permite un versionado de datos y una alta disponibilidad, además de facilidad en la recreación del ambiente. También pueden usarse scripts shell con datos y estructuras en archivos físicos como sql pero reducirían la mantenibilidad y comprensión.
En varios de nuestros proyectos agregamos archivos sql con una base de datos inicial y con sus debidos scripts para preparar el ambiente para las pruebas. Esto fue agregado al pipeline en el cual posterior a la creación de la imagen docker del artefacto se iniciaba en el ambiente de test y se configuraba con estos scripts para luego comenzar las pruebas automáticas.

La ofuscación o masking

Para facilitar el uso de datos productivos y evitar los problemas mencionados existen técnicas que ocultan la información sensible como ser datos personales, tarjetas de crédito, datos importantes de la empresa, etc. Para esto se pueden desarrollar soluciones para que desde las consultas a la base de datos se presenten vistas a las tablas que contengan datos sensibles sean mostrados reemplazandolos o enmascarandolos de alguna forma que cambien pero que sirvan. También es interesante pensar en APIs que sirvan estos datos ya enmascarados para evitar tener otras bases de datos o para facilitar la actualización.
Como los casos anteriores, estas tareas pueden agregarse al pipeline para configurar y preparar el ambiente previo a la corrida de los tests. Al estar los tests dockerizados puede agregarse en cualquier pipeline y en cualquier momento.

Existen más técnicas pero estas quizá ayudan a la automatización de los datos. Logrando la automatización podremos obtener los datos necesarios con más facilidad y con una alta disponibilidad para todo el equipo sin necesidad de procesos que hagan más costosa esta tarea en cuanto a recursos humanos.

El desafío actual de QA…

Creo que el mejor software es aquel que se utiliza mientras el usuario hace su trabajo, crear software para ser usado luego del trabajo como documentación post tarea no es del todo efectivo y la única forma de lograr su uso es obligando de una forma u otra a las personas a hacerlo.
La historia dice por sí sola, que la documentación del software tiene dos problemas importantes, uno es que es necesario tiempo extra para poder generarla y luego leerla e interpretarla.
Si logramos que el sistema de trabajo sea autodocumentado puede ser solucionado sin esfuerzo, ahora tenemos el segundo problema, Lleva también tiempo leerla pero además la libre interpretación conlleva un problema en sí dado que a través de los años cada párrafo puede cambiar de forma por el conocimiento de base del lector.
Las metodologías ágiles ponen foco a este problema dando lugar a uno de sus manifiestos y en una forma correcta logran una velocidad estupenda en la tarea del desarrollo donde a su vez gracias a las nuevas herramientas queda autodocumentado, quizá no con el detalle deseado en el pasado pero sí, con la eficacia suficiente.
Otra de las innovaciones que hacen mejorar otra de las tareas importantes en el desarrollo de software esta aparejada a DevOps donde gracias a herramientas como docker y su forma de auto documentar los procesos de creación de infraestructura lograron aumentar la velocidad, control y reproducibilidad, muchos de los problema del pasado.
Por otra parte, el área de QA está siendo la que más afectada se encuentra debido a la falta de automatización y la reducida velocidad en sus procesos los cuales, con ayuda de herramientas de desarrollo de software, disminuyen esa brecha, pero se ven desplazados sus recursos humanos por su falta de respuesta.
Cabe destacar que tal como pasa en todos los casos la madurez del equipo en la utilización de las herramientas es directamente proporcional al éxito del objetivo.
A la hora de disminuir el time to market del software es fundamental encontrar una solución a esto sin la necesidad de desplazar al personal de QA y a su vez no generar más dependencia de recursos calificado en desarrollo de software.
Hace ya más de 3 años que me dedico al área de QA Automation como QA Automation Engineer. Todo comenzó gracias a mi experiencia en desarrollo, contaba con más de 10 años desarrollando java, pero estoy seguro que tanto conocimiento es innecesario para solo desarrollar casos de prueba. Una vez que el proyecto base está completo, uniendo todas las partes: el runner, el intérprete gherkin, el reporting, los datasets, etc, con muy poco conocimiento puede desarrollarse casos de prueba sin necesidad de complejizar nada y llegando a un buen resultado. Este es uno de los motivos por los cuales armamos el framework lippia, un proyecto base que sirva para cualquier tipo de proyecto de pruebas automatizadas: web, mobile, api, performance, base de datos, seguridad, accesibilidad y en realidad cualquier tipo de pruebas dado que todo lo que va surgiendo lo vamos agregando. Si bien esto es muy útil, sigue existiendo una alta demanda de personal con conocimientos en desarrollo, programadores sin mucho conocimiento pero en si con algo, lo que deriva con mucha probabilidad en que deje afuera a muchos QA muy capacitados no solo por su bajo conocimiento en desarrollo sino que también quizá al desinterés por esta rama de la ingeniería de software.
Para esto es necesario una serie de herramientas que logren una auto documentación y la posibilidad de reutilización o automatización en futuras ejecuciones, tal como lo hacen las herramientas de CI/CD en desarrollo o los contenedores en el caso de operaciones.
Es nuestro desafío encontrar una forma de lograr esto y es donde se encuentra nuestro esfuerzo en investigador y desarrollo.