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

Tips Crowdar para el trabajo en casa

En esta sección queremos compartirte parte de nuestra experiencia en el trabajo remoto para que puedas aplicar en tu día a día.

Antes que nada

Ahora bien, debes ser muy organizado en tu día. Comienza tu rutina diaria de la misma forma que lo hacías cuando íbas a la oficina. Define a que hora comienzas el día, tu desayuno, gimnasia en el hogar y demas rutina diaria a la cual estas acostumbrado. Tu horario de comienzo y fin de la jornada, tu tiempo de almuerzo y refrigerio.

Es importante definir los descansos pero también es muy fácil entretenerte con otras cosas en tu casa y perder el tiempo. Al final del día puede ser que te encuentres que no fuiste muy productivo.

Para resolver esto es muy útil definir objetivos diarios pero que también sean alcanzables, anotarlos e ir completando de a uno a la vez.

Y por último

Espero que estos #crowdartips te hayan ayudado a sobrellevar esta realidad que nos toca con el #covid19.

No dudes en consultarnos lo que necesites al respecto.
Nos vemos la próxima

700 millas recorridas, 2 eventos y gratas experiencias

Bitácora de mi último tour en UK

Este viaje comenzó como uno de tantos de negocios, llegando de Argentina a Reino Unido como tantas veces en estos últimos años, desde 2016 cuanto decidí que Crowdar tenía que ser una empresa con presencia en el Reino Unido. 

Muchas cosas me unen a UK, entre ellas parte de mi familia que se encuentra en Leicester, hermoso lugar con paisajes rurales y gente agradable y buenas cervezas 🙂 

En lugar de pasar la semana en Londres decidí, luego de la confirmación de un lugar disponible en SwanseaCon V (thank you Viv Richard por tu amable atención y predisposición para sumarme al evento a pesar de mi tardía solicitud) , y por cierto que valió la pena. 

El viaje comenzó por Londres, donde luego de muchas dudas, decidí alquilar un auto, para tener más flexibilidad para recorrer los múltiples destinos que tenía por delante, ya que luego de Swansea tenía como siguiente parada Manchester donde planeaba asistir originalmente al evento de Transformación Digital en Manchester. 

Retiré mi auto en Gatwick Airport el día Domingo 7 e inicié mi viaje hacia Swansea, aunque dado que el viaje era largo para hacerlo en un solo tramo, decidí pasar la noche visitar a mi sobrino Josh, quien toca la guitarra como los dioses, a sus 25 años, además de su trabajo como panadero, es Lead Guitar en Hush Mosey, banda de rock originaria de Bristol (si tienen un minuto denle una vuelta a su último álbum Pretty Little Seanse

Luego de compartir unas cervezas y una cena en un bar de tapas bastante particular con comida poco española pero con agradable fusión, dormí una noche en un excelente sofá que me facilitó mi sobrino (todavía duele un poco la espalda, pero se agradece el hospedaje). 

A la mañana siguiente, bien temprano, salí tratando de no despertar a nadie, en mi camino a Swansea, 6.30am, primera vez a Wales, con mucha expectativa. Me recibió una autopista con una agradable lluvia torrencial, que puso a prueba mis habilidades de conducción en Reino Unido :-O

Al llegar a Swansea, llegué al hotel del evento, el Village Swansea Hotel, muy agradable y bien instalado. El evento estaba muy bien organizado, y con varias charlas interesantes. Luego del habitual merchandising en este tipo de eventos, (el cual me sorprendió por su cantidad y calidad de materiales), hizo lugar a las charlas que se desarrollaron durante el día. 

Me encantó la Keynote de inicio, donde Sander Hoogendoor y Kim Val Wilgem hicieron una irónica pero muy divertida descripción de las peores prácticas de metodología, para rescatar el por qué de poner primero a las personas antes que la pura práctica metodológica y entender que son herramientas y debemos tomar la que más nos sirva para la companía, proyecto, y equipo de gente con el que estemos encarando un proyecto. 

Luego siguieron varias charlas interesantes, de las cuales rescato la de Callum White sobre aplicación de AI en seguridad en la web, que a pesar de que Azure no quiso que las demos funcionaran, y que sonó la alarma en medio de la misma (solo un simulacro) gracias al estoico esfuerzo de Callum la misma salió airosa. 

Otras charlas en las que participé no fueron tan interesantes como esperaba, con lo cual fui rotando entre las mismas, hasta que asistí a la de Simon Stuard presentando Selenium 4, que como padre y uno de los creadores del mismo, explicó las nuevas features y el por qué de las mismas, entre ellas destacando la detección de objetos por proximidad (https://dzone.com/articles/what-to-expect-from-the-new-version-of-selenium-4) junto con él, conocí a Liz Keogh, una de las creadoras de JBehave, plataforma que hemos utilizado por años y seguimos utilizando en algunos de nuestros principales clientes, hasta que desarrollamos Lippia con Cucumber (https://lippia.io)

La última charla del evento me hizo sentir muy identificado, y darme cuenta que el camino que elegimos en Crowdar hace 4 años, de ser una compañía totalmente remota valió la pena. Rachel Davies mostró cómo puede hacerse para que el concepto RemoteFirst sea la primera regla de un equipo de trabajo y sobrevivir en el intento. Vi plasmadas muchas cosas que nos imaginamos en Crowdar y de hecho implementamos día a día, pero no con una vision de que es correcto, sino de que siempre estábamos a contramano del mundo, ya que no muchas empresas conciben al trabajo remoto (home office o nómade) como algo viable. Me hizo recapacitar y entender que de hecho funcionamos así, aunque no tengamos reglas escritas que lo indiquen y logramos los objetivos más desafiantes que tenemos. Aprendí varias cosas, entre ellas que el equipo remoto tiene una dinámica particular, que debe ser respetada, en la cual conviven cosas de la vida cotidiana y actividades de una oficina. 

Creo que debemos entender que el concepto de trabajo cambió, no es más importante viajar 3 horas al día, para estar 9 horas sentado en una oficina en 5 reuniones por día, sino lograr que los objetivos de los proyectos se produzcan, como decía un jefe mío hace tiempo, “el resultado manda”, si hiciste todas tus reuniones, pero al final del mes no lograste tus objetivos, no lograste nada….

Otra cosa importante que aprendí, es que los equipos remotos deben tener algunas condiciones básicas para operar, como ser entre otras, una buena conexión a internet, sea donde sea que estés, auriculares decentes con buena aislación de ruido ambiente, tanto en escucha como en micrófono, y un código de comportamiento distinto al de las reuniones presenciales, como por ej usar la cámara en la medida de lo posible, escuchar al otro y no hablar al mismo tiempo, etc. Creo que se puede armar un decálogo de estas y tomarlos como best practices.

Después del evento tuve la oportunidad de compartir unas cervezas con los sponsors y algunos speakers del evento para luego ir al hotel donde pasé la noche, un pequeño pero agradable hotel frente al mar en The Mumbles, una zona preciosa.

A la mañana siguiente luego de un desayuno espectacular, inicié mi viaje a Manchester, para asistir al evento de Transformación Digital el día jueves. Durante el viaje puse a prueba la red móvil ya que tenía un par de calls en el camino, las cuales tomé en una estación de servicio a la sombra de un árbol, como buen trabajador nómade (Fer Martinez te robé por un ratito el concepto). 

Luego de las calls seguí viaje a Manchester donde pasé la mayor parte de la semana en reuniones hasta el tan ansioso evento The Digital Transformation Conference Manchester 2019. 

El evento estaba repleto de gente, muy interesantes stands de expositores. Me detuve en el de Senheiser, que tenía unos muy preciados auriculares de altísima calidad, los cuales seriamente estoy considerando en comprar para nuestros equipos de trabajo, aunque la inversión es alta creo que valen la pena, veremos ….. 

Entre los speakers varios llamaron mi atención, aunque la mayoría de las charlas se centraron en que el gran cambio no está en lo digital, sino en la gente y en cómo el cambio las afecta. Entre las destacadas para mi, fue la u Hayley Granston de la marca Beano que habló sobre el impacto de la transformación digital en los niños entre 6 y 12 años y cómo trabajan para entender qué es lo que demandan los niños y como influencian los hábitos de consumo de algunas marcas muy importantes.

Otra charla que me gustó mucho por el contenido de la misma fue la de Ricard Fuertes que acaba de hacerse cargo del equipo de desarrollo de software de TFGM explicando los desafíos de la movilidad en Manchester y como la ciudad debe dar respuesta a los requerimientos de transporte actuales y futuros entre ellos, la continua ampliación del Tram y la digitalización de las más de 30 lineas de Buses que gestionan privados externos a la organización. 

Luego del evento me reuní con Paul Caine, quien luego de su paso por TrustIV, empresa colega que se dedicaba a QA igual que Crowdar, acaba de incorporarse como colaborador al equipo de Crowdar como business development. 

Terminé mi semana en Manchester y fui a Leicester a visitar a mi familia. Pase unos días agradables en su casa, y haciendo oficina móvil en The Waterside Inn,  donde aproveché algunos días soleados para trabajar al aire libre. 

Para no relajarme mucho, el miércoles fui a Birmingham a reunirme nuevamente con Paul, para definir los próximos pasos de su incorporación a Crowdar.

Termino estas notas en el avión de viaje a Buenos Aires, donde la semana entrante nos reunimos con Martín Casamayor, responsable de la empresa en Chile, para revisar los nuevos proyectos que están por delante de aquí a fin de año, que parecen prometedores y planificar en conjunto con los directores de Argentina, Pablo Zuccarino y Cecilia Benassi el último trimestre del año. 

Crowdar supports Argentesting 2019

This year Crowdar will be supporting again Argentesting 2019 as every year since 2017.  Our aim is to support testing communities in all the countries that Crowdar operates. Providing tools, knowledge and experience.

We hope this movement grows more and more every year, and we’ll be participating as a team.

Photos from the event

Lippia Test Automation is live!

Lippia components

Lippia  Automation Framework is the first multi-platform (web, mobile, windows app), container-based test automation platform. Is the first of its kind framework that combines the best open source tools to create a solid, scalable (cloud and onpremise) solution saving thousand of coding hours.
Created by devops and test automation engineers to provide a single solution to solve test automation needs.

 

“After 1 year of development learning from our customer needs and based on tech industry trends we´re very proud to launch Lippia. Lippia is the first step in our roadmap to build a set of successful solutions to support development teams”.  Javier Re, CEO.

A quick look at Lippia Container-base Architecture shows how the docker containers technology support Lippia with different configurations for each type of application,.

Soon you will be able to download binaries to test Lippia in your own environment.

To know more about Lippia please visit https://lippia.io or contact us at lippia@crowdaronline.com

TestBash Manchester 2017

This year we expanded our frontiers. We supported last week the amazing event TestBash Manchester, organised by The Ministry of Testing community. Sponsoring this kind of events is part of our commitment with Testing Communities where Crowdar operates as a leading company in Testing Services.

Javier Re, our CEO joined the Workshops Day and OpenCamp events. “I increasing my learning of new trends, and techniques to improve the offering  that Crowdar can provide to the Market. Sharing time with the community is critical to design better testing services . We’ll continue supporting this kind of events.”

A special big “Thank you” to Richard Bradshaw for his warm welcome to Crowdar as first time sponsor.

Check the event in our twitter moment

 

Crowdar en Argentesting 2017

Este año nuevamente estuvimos acompañando una vez más a la comunidad de Testing de Argentina, como sponsor Gold de Argentesting 2017.  Esta vez fuimos sponsor Gold, y tuvimos nuestro propio Stand donde Pablo Zuccarino, nuestro Gerente de Operaciones, participó del mismo.

Seguimos colaborando con las comunidades de Testing en las regiones donde operamos.

Conocenos más:  en crowdar.com.ar

We are in Manchester – see us at local events

 

A year ago, Crowdar participated in the London Technology Week. Our CEO Javier Re spoke to the UKTI team and promised to be operating in the UK in 2017.

Since then, we have been endorsed by Gartner, Tech North and Prolific North. We have joined major events such as Innovate UK and Digital Revolution and fell in love with Manchester. Now we are proud to have a branch here – we simply couldn’t be happier to move to this vibrant city.

 

See us around – we regularly attend national and local conferences and workshops. Over the past few months we’ve been to the massive IP EXPO conference, Startup Stories by Manchester Digital, a pitching masterclass by Manchester Business Growth Hub, the inspiring Glug Manchester nights and Code Computerlove workshops. Get in touch to find out where we are headed next.