Consumer-driven contract testing con Spring Cloud Contract

Introducción

Como hemos comentado en entradas anteriores, la arquitectura en microservicos cada vez está ganando más fuerza, y esto supone un reto tanto para el desarrollo como para el testing. En el post vamos a hablar sobre Consumer-driven contract (CDC) testing y cómo podemos verificar que los microservicios trabajan correctamente y según lo esperado entre ellos.

Para ello, como siempre vamos a trabajar con un proyecto de ejemplo usando Spring Cloud Contract, que podréis descargar del repositorio de GitHub.

Consumer-driven contract (CDC) testing

Conociendo la arquitectura en microservicios sabemos que el mayor reto consiste en comprobar y validar la comunicación entre los distintos servicios y para ello las estrategias más comunes son ejecutar pruebas end-to-end o crear mocks de los servicios y lanzar pruebas de integración sobre ellos.

MicroservicesCon las pruebas end-to-end vamos a comprobar la comunicación entre los servicios simulando una experiencia más cercana a el entorno de producción. Primero debemos tener levantado todo el entorno (servicios, BBDD) lo que es costoso y dificulta la trazabilidad. Por otro lado, es fácil que los problemas de comunicación hagan que nuestras pruebas se ralenticen más de lo normal o que fallen. Las dependencia de tantos componentes debilitan nuestras pruebas.

Como hemos visto en un post anterior, mockear un servicio nos elimina los problemas anteriores. Por el contrario, puede que las pruebas contra el mock sean satisfactorias, pero en el entorno de producción la aplicación falle debido a un mal diseño de los mocks.

 

 

cdc testingCon Spring Cloud Contract diseñaremos los contratos de los servicios. El contracto sencillamente es la definición del comportamiento de nuestro servicio en base a una request. Con esa definición se van a generar teses a nivel de proyecto para validar los contratos, así como, se publicará el Stub en nuestro repositorio maven contra el que lanzaremos las pruebas de los clientes del servicio (como vemos en la imagen). No obstante, lo vamos a ver ahora y quedará mucho más claro.

Entre los beneficios que hemos visto, utilizar CDC testing con Spring Cloud Contract nos aporta:

  • Poder desarrollar nuestro servicio mediante metodología ATDD.
  • Una documentación actualizada y “honesta” de las APIs que conforman nuestro sistema.
  • Disponer de un mayor control de los clientes que consumen nuestros servicios. Debido a que sabremos quien realiza las pruebas contra los Stubs publicados.
  • Los contratos publicados siempre actualizados, debido que en el proceso de publicación se encuentra integrado en el proceso de “build”.

Entendiendo el proyecto de pruebas

 

project_services

El proyecto con el que vamos a trabajar consiste en un sistema de dos servicios. Inventory-service y Account-service.

Account-service expone una API que devuelve los datos de los usuarios e inventory-service expone una API que devuelve el inventario de un usuario vendedor.

Inventory-service consume account-service para obtener los datos del usuario de los items que va a devolver cuando le llamen, por lo que vamos a lanzar las pruebas sobre el Stub publicado de account-service.

Inventory-service publica su Stub para que cualquier cliente futuro pueda ejecutar las pruebas contra él. Así que vuestra imaginación puede volar y ayudaros a construir un nuevo servicio siguiendo los pasos del CDC 😛

 

Preparando el proyecto

Antes de ponernos a definir los primeros contratos vamos a ver que dependencias necesitamos en nuestro proyecto. Los ejemplos los vamos a ver del proyecto de account-service.

Dentro del build.gradle vamos a definir también en que directorio vamos a alojar los contratos, así como donde se guardarán las clases base de tests que utilizará para generar los teses de verificación de los contratos.

Definiendo los contratos

Siguiendo con account-service vamos a ver el contracto que hemos definido para devolver los datos de un usuario en base a su id, en /src/test/resources/contracts/ShouldReturnAccountById.groovy

Los contratos tienen una semantica muy clara y diferenciada. Vemos como definimos tanto la request que esperamos como la response que devolvemos para esa request.

Con este contracto estamos definiendo que para cuando llamen al endpoint: /account/[0-9]+ vamos a responder con un estado 200 y con un json que contien esos campos y datos.

Vemos que la url tiene un regex, por lo que un ejemplo de una llamada que la cumpla sería: /account/12345.

Es un contrato sencillo, y con esto tanto desarrollador (para comenzar el desarrollo) como el cliente (para consumirlo) ya sabrían cual sería el endpoint, así como los datos que tienen que mandar y los que van a recibir.

Podéis ver toda la información del DSL de los contratos en el siguiente enlace.

Si seguimos la metodología ATDD, sabemos que deberíamos hacer un desarrollo mínimo para poder lanzar los teses y que fallen e ir refactorizando hasta que los teses no fallen.

Veamos el paso de generar los contratos y publicar el Stub. Lanzando el comando generateContractTests va a autogenerar los teses de validación del contracto que hemos hablado anteriormente.


➜ account-service git:(master) ./gradlew generateContractTests
Starting a Gradle Daemon (subsequent builds will be faster)
:copyContracts
:generateContractTests

Y cuando lanzamos el comando install publicará en nuestro maven local (.m2) el Stub. Veámoslo:


➜ account-service git:(master) ./gradlew clean install
:clean
:compileJava
:compileGroovy NO-SOURCE
:processResources NO-SOURCE
:classes
:jar
:copyContracts
:generateClientStubs
:verifierStubsJar
:install

Si accedéis a .m2/repository/com/qajungle/account-service/0.0.1-SNAPSHOT podréis ver el Stub:

account-service-0.0.1-SNAPSHOT-stubs.jar

Desarrollando y ejecutando los teses

El cliente (inventory-service) consume account-service para obtener los datos del usuario del inventario. Veamos la clase de servicio y el gateway sobre el que tendremos que desarrollar el test:

/src/main/java/com/qajungle/services/InventoryService.java

/src/main/java/com/qajungle/gateway/AccountGateway.java

Como vemos AccountGateway.java es el encargado de realizar la llamada al API de account-service. Por lo que en este punto es donde tendremos que atacar contra el Stub publicado por el servicio. Veamos el test:

/src/test/java/com/qajungle/services/InventoryServiceTest.java

Lo más importante en este punto es ver que estamos atacando al Stub del servicio mediante el tag:


@AutoConfigureStubRunner(ids = "com.qajungle:account-service:+:stubs:8082", workOffline = true)

Si lanzamos el test del proyecto veremos que todo ha ido correctamente:


➜ inventory-service git:(master) ./gradlew -Dtest.single=InventoryService test
:compileJava
:compileGroovy NO-SOURCE
:processResources
:classes
:copyContracts
:generateContractTests
:compileTestJava
:compileTestGroovy
:processTestResources
:testClasses
:test

BUILD SUCCESSFUL

Cambiemos el contracto en account-service para comprobar que lanza contra el Stub. Por ejemplo cambiendo el valor de un campo.


➜ inventory-service git:(master) ✗ ./gradlew -Dtest.single=InventoryService test
:compileJava UP-TO-DATE
:compileGroovy NO-SOURCE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:copyContracts
:generateContractTests
:compileTestJava UP-TO-DATE
:compileTestGroovy
:processTestResources UP-TO-DATE
:testClasses
:test


com.qajungle.services.InventoryServiceTest > should_return_seller_information FAILED
org.junit.ComparisonFailure at InventoryServiceTest.java:28

org.junit.ComparisonFailure: expected:<“[aritz]”> but was:<“[fail]”>

El resultado es que el test fallará con un ComparisonFailure en este caso.

Conclusiones

El hacer uso de contract testing nos proporciona unos beneficios que no podemos encontrar en otras estrategias para el testing de servicios. Es muy importante sacar los valores que nos aporta ya no solo en no depender del entorno, de los teses E2E, si no de poder desarrollar mediante ATDD, disponer de una documentación fidedigna y llevar un mayor control de quien consume nuestros servicios.

A día de hoy solo he probado Spring Cloud Contract, pero me consta que existen otras herramientas como Pact, que espero probar en un futuro cercano. No obstante como habéis podido comprobar Spring Cloud Contract no es complejo de utilizar.

Charlando de testing con: Federico Toledo

Introducción

Si hay algo que me gusta y de lo que creo que aprendo es de hablar con los compañeros sobre el mundo del desarrollo y el testing. La mayor parte del conocimiento que tengo hoy en día es gracias a leer artículos y a discutir ideas.

Como creo que es mejor compartir, he decidido crear una nueva serie en el blog en la que colgaré “entrevistas” o “momentos de charla” sobre testing con otros compañeros. Mi idea es hablar sobre testing no solo con testers o QEs, si no con todos los roles implicados en el mundo del desarrollo. Conocer diferentes opiniones y puntos de vista que puedan hacer discutir y replantearme las cosas.

En el primer post de la serie “Charlando de testing con”  lo he decidido hacer con Federico Toledo, tras hablar varías veces con el y leer su libro creo que tiene una opinión muy interesante sobre el actual estado del testing, así como grandes ideas. No me gustaría adelantaros nada así que os presento la charla con Federico Toledo:

Entrevista

 

QA Jungle – Charlando de testing con Federico Toledo from QA Jungle on Vimeo.

Geb best practices, el antes y el después

foto3En la Greach (conferencia sobre groovy y grails de España) pude asistir a una charla títulada “Geb best practices” dada por Marcin Erdmann. En el post me gustaría tratar varios temas de los que se habló, compararlo a como desarrollo yo los proyectos a día de hoy, aplicar las buenas prácticas y ver el resultado.

Antes de pasar a la práctica tengo que decir que los proyectos que hablo en el “antes” estaban realizados sobre Geb 0.13.0 y ahora sobre 1.1.

Pódeis descargaros el proyecto de ejemplo desde mi repositorio de github. En el proyecto podéis ver todos los ejemplos que tratamos en el post.

Uso del “at checks”

foto3En Geb trabajamos con el page object pattern. El at check” es una “closure” definida a nivel de page que nos permite comprobar que nos encontramos en la página adecuada. ¿Cómo? Pues básicamente dentro del “at check” podemos realizar comprobaciones a nivel de página.

 

 

 

Antes

En algunos de mis proyectos uso el “at check” en cada cambio de página, es decir, cada vez que navegaba a otra página con el “to page” volvía a hacer un “at page” pensando que era necesario para realizar un cambio de contexto de page. En muchos casos el “at checker” únicamente devolvía true, por lo que aunque no se encontrará en la página siempre iba a ser correcto.

Después

Uso el “at check” únicamente para comprobar que me encuentro en la página que quiero estar. No lo útilizo como “cambio de contexto” de página ya que no es necesario si hago el “to page”.

Conclusión

En mi caso, haría un uso responsable de “at check”, es decir, no es necesario comprobar todas las páginas, si vamos a realizar acciones en la página y no nos encontramos en ella, nos va a saltar que no se encuentra el componente con el que queremos interactuar. Pero por otro lado, si hacemos uso del “at” vamos a saber que falla porque no se encuentra en la página o la página no ha cargado, y no porque el componente no se encuentra.

En el ejemplo podeís ver que yo lo he usado ya que testeo la navegación entre páginas.

Navegar a páginas

foto1

Lo común es navegar entre páginas y realizar las acciones y las comprobaciones que sean necesarias en nuestras pruebas funcionales. No siempre la url de un página es estática (ej.: /author/), si no que en muchas ocasiones necesitamos navegar a una url compuesta por elementos dinámicos (ej. /author/[ID]).

 

 

Antes

Para poder generar las url dinámicamente en base a los datos de entrada de un test hoy en día hago uso del “builder pattern”.

Sin entrar al detalle de como se contrulle un builder en groovy y explicandolo de una forma sencilla, únicamente paso los datos necesarios para construir la url al builder y una vez generada la seteo a la propiedad url de la página. Posteriormente navego a la página.
Después

Marcin comentó en la charla dos formas de poder navegar a una página construyendo la url dinámicamente, veamoslas.

La primera es con el uso del método de página “convertToPath“. El método puede recibir los parámetros que sean necesarios para construir la url.

Cuando hagamos uso del “to Page” añadirá el path construido por el método a la url estática de la página.

El otro ejemplo es el uso del método de página “getPageUrl”. Un poco más complejo. En este caso es necesario instanciar la página con los parámetros que espera la url.

Debemos hacer el “to Page” pasandole la nueva instancia de la página con los parámetros necesarios de la url en el constructor.

Conclusión

El hacer uso de un builder hace que tengamos que gestionar la lógica de la construcción de la url para cada página, y si no son muy “estandares” no será una tarea fácil.

Por otro lado hacer uso de “convertToPath” y “getPageUrl” nos permitirá mantener la responsabilidad de la construcción de la url en la propia página.

“Trackear” las páginas

foto3

Cuando hablamos de “trackear” las páginas, hablamos de capturarlas en una variable y utilizarlar sus elementos. Esto nos va aportar ciertas ventajas que vamos a ver con los ejemplos.

Antes

En todos mis proyectos lo común es navegar a la página en la que quiero e interactuar con los elementos directamente, esto hace que si la funcionalidad requiere de mucha interacción llegue un momento en que me pierda y no sepa si estoy interactuando con el elemento de una página u otro. Lo cierto es que puede llegar a ser poco legible.

El caso que presento no es el mejor ya que interactuamos con pocos elementos, pero imaginaos que hay más elementos e incluso elementos de otras páginas con el mismo nombre.

Después

Una buena practica es “capturar” la página y referenciar a los elementos a través de la variable. Veamos.

Conclusión

Capturar la página nos va a ayudar con la legibilidad de nuestros teses. En pruebas pequeñas igual no lo vemos algo muy útil, pero lo cierto es que es de gran ayuda.

Módulos

foto2

El uso de módulos nos permite reutilizar la definición del contenido de las páginas a través de varías páginas. Pero nos aportan mucho más valoro ocultar estructuras de componentes o interacciones complejas de los teses.

 

 

Antes / Después

En mi caso no hacía mucho uso de los módulos debido a que pensaba que los módulos únicamente servian para reutilizar contenido de las páginas, y no he tenído muchas ocasiones de utilizarlo. Pero saber que nos aportan mucho más que la reutilización aporta mayor valor.

Veamos un ejemplo de uso los módulos.

Por supuesto en la charla se tocaron más conceptos y buenas prácticas que comentaremos más adelante.

 

¿Un QA puede ser también developer?

Assert QA == Developer


¿Es un QA un developer?
Me gusta hablar con la gente. Me gusta compartir opiniones. Me gusta debatir. Tras varias conversaciones con compañeros de trabajo, de los que he podido obtener de una forma u otra feedback de lo que creen que es el trabajo de un QA Engineer, me he propuesto a escribir un post que ayude a romper ciertas barreras mentales en el trabajo que creemos que hace un ingeniero de calidad y ver si en realidad es un developer.

Ingeniería de la calidad del software

La realidad es que poca gente conoce lo que es la ingeniería de la calidad. No es algo conocido, no es algo que llame la atención cuando decides estudiar informática, es la realidad.

Cuando un desarrollador habla de un QA, no piensa que desarrolle, no lo trata como un desarrollador. Es más, muchos piensan que los QAs son desarrolladores frustrados, y no es cierto.

¿Porque cuesta tanto ver la ingeniería QA como una rama de la ingeniería del software, del desarrollo?

Cuando se piensa únicamente desarrollamos pruebas se está muy equivocado. La calidad del software no solo se garantiza con teses.

Desarrollamos teses, ¡por supuesto que sí! Y en muchas ocasiones la lógica que implementamos en el test puede ser más compleja que el código o la funcionabilidad que probamos. Y si… sabemos lo que son los patrones… es más, los aplicamos.

Para garantizar que el software cumple con los requisitos de calidad exigidos los QAs deben diseñar y aplicar las estrategias de calidad necesarias. Y muy seguramente en esas estrategias se implementen diferentes proyectos, desde automatización de pruebas hasta proyectos más complejos, y adivinad, muchos de ellos habrá que desarrollarlos.

Automatización de pruebas

Automatizar pruebas funcionales no siempre significa automatizar el comportamiento de una funcionalidad mediante UI testing. En muchas ocasiones se requiere hacer pruebas funcionales a nivel de API, o probar funcionalidades cross-aplicación y cross-dispotivo.

Aquí os dejo los enlaces a la presentación y explicación de cómo Uber realiza pruebas cross-aplicación y cross-dispotivo para probar sus aplicaciones mediante Octopus.

POST:
https://eng.uber.com/rescued-by-octopus/
SLIDE:
https://docs.google.com/presentation/d/1vYXhkvgLKun72Ix91LQDDWZQdcY5VOBqKVvI1Y6riYo/pub?slide=id.gd8d657045_0_0

VIDEO:
https://www.youtube.com/watch?v=p6gsssppeT0

Para mi es importante entender que un QA no es una persona dedicada únicamente a automatizar pruebas o a realizar testing. Es un ingeniero capaz de desarrollar las herramientas necesarias que ayuden a garantizar la calidad de la aplicación.

Lo que significa que un QA es un desarrollador especializado en la calidad.

Sí, somos un equipo

Una de las cosas que me dijeron era que si el que desarrollaba la tarea hacia bien su trabajo no tenía por qué meter bugs, y ya que sabía lo que estaba desarrollando y donde afectaba él podría hacer las pruebas, por lo tanto, los QAs sobraban.

Bueno, en un mundo perfecto donde el desarrollador está encantado de probar todo lo que hace, y donde el tiempo de entrega no existe, en el que nunca se equivoca, puede ser…¡pues tampoco! Que te diga coca cola o Samsung que no hacen control de calidad de sus productos… igual sus móviles explotarían.

Es necesario desarrollar estrategias y proyectos que garanticen la calidad de nuestras aplicaciones, equipar al equipo de desarrollo con las herramientas suficientes para hacer código de calidad, para agilizar su desarrollo.

Cada equipo somos piezas del desarrollo. Desarrollo, DevOps, Producto, QA etc.

Conclusiones

Antes de ser QA fuí desarrollador, y hoy en día sigo desarrollando casi al mismo nivel que antes, salvo que antes funcionalidades de una aplicación, y ahora herramientas que garantizan su calidad. ¿Qué diferencia hay?

Los QAs también somos desarrolladores, es la realidad, y primero nos lo tenemos que creer nosotros para que los demás se lo crean.

 

 

 

 

Estrategia Prevention & Reaction – Parte III

Introducción

En el segundo capitulo vimos cómo aplicábamos la estrategia Prevention & Reaction en tiempo de producción. En el último post de la serie, vamos a ver un ejemplo de organización de equipos QA que garantizan la estrategia en todas sus fases y contextos.

Equipos de trabajo

stategy teams

Para poder garantizar la calidad del software siguiendo la estrategia se crea una estructura grupal en la que cada grupo de trabajo se dedica o toma la responsabilidad de áreas concretas de la calidad del software.

La importancia de la estructura grupal planteada reside en la necesidad de cohesión de los grupos de trabajo, debido a que las tareas realizadas por un equipo son necesarias para otro.

Esto genera la posibilidad de disponer de personas multidisciplinares, es decir, personas que puedan participar en distintos grupo de trabajo a la vez, o permitir la rotación grupal.

La imagen muestra la cohesión de la que estamos hablando, así como la cobertura de cada grupo.

De forma general, se puede apreciar que el grupo strategy  abarca los demás grupos, debido a que sus decisiones afectan a todos los grupos.

Otro ejemplo es el equipo de Testing, el cual abarca las células de desarrollo dado que tiene que dar servicio y soporte de testing.

Vamos a ver la responsabilidad de cada grupo.

Equipo de estrategia

De forma general, el equipo de estrategia debe procurar mantener la estrategia y tomar decisiones importantes sobre la misma, debiendo corregir el rumbo cuando no se siga el camino previsto.

Las responsabilidades más importantes son:

  1. Diseñar la estrategia: Este equipo debe tener siempre presentes las necesidades en cuanto a la calidad del software se refiere y desarrollar una estrategia de calidad que las cubra.
  2. Definir KPIs: Los KPIs servirán para ver si la estrategia sigue el buen camino. En el caso de que los KPIs nos muestren indicios de que no se cumplen los objetivos preestablecidos, se podrán tomar decisiones con antelación para así poder pivotar la estrategia.
  3. Integrar la calidad en el CI: Hemos visto en las diferentes fases que la estrategia requiere estar presente en el flujo de la integración continua; es, precisamente, el equipo de estrategia el que deberá garantizarlo.

Equipo de datos

Durante el análisis que hemos hecho de la estrategia, hemos recalcado la importancia de obtener los datos de los resultados de las pruebas, de los datos de producción y de disponer de un sistema de predicción de bugs.

Las responsabilidades más importantes son:

  1. Obtención de datos de pruebas: Se deberán desarrollar las herramientas necesarias para obtener los datos de los resultados de las pruebas. Como hemos ido diciendo durante la serie de posts, los datos obtenidos nos servirán para alimentar la heurística del sistema de predicción de bugs, así como para mantener un histórico de resultados.
  2. Obtención de datos de producción: Los datos de producción van a servirnos para disponer de datos objetivos que nos ayuden a crear un mapa de calor de acciones, o bien como datos de entrada para las pruebas. Si nos fijamos en los logs de producción, podremos localizar trazas de errores y adelantarnos a solucionarlos o a reportarlos.
  3. Obtención de datos para KPIs: Los KPIs son indicadores o métricas que nos aportan conocimiento del estado de las acciones que estamos realizando. Mediante los KPIs seremos capaces de detectar defectos en nuestra estrategia o, por el contrario, ver el éxito de la misma. El equipo de datos debe desarrollar las herramientas necesarias para poder obtenerlos.
  4. Análisis y reporte de los datos: El análisis de los datos es de las acciones más importantes que debe realizar el equipo, dado que los resultados de los análisis son decisivos para la estrategia.

El equipo de datos tiene que trabajar estrechamente con los demás equipos de QA, debido a que va a necesitar extraer datos de todas las pruebas, así como de los resultados de la validación de las RCs o de la gestión de bugs. Estos datos serán analizados junto con el equipo de estrategia.

Equipo de automatización

El equipo de automatización deberá desarrollar los proyectos o herramientas necesarias para la ejecución de las pruebas automáticas. Los proyectos no tienen por qué ser únicamente desarrollo de pruebas automáticas; el equipo de automatización también se encargará de desarrollar los frameworks necesarios para el desarrollo de las mismas.

Las responsabilidades más importantes son:

  1. Framework de desarrollo de pruebas: Para muchos casos es necesario desarrollar, adaptar o mejorar un framework de testing. El equipo de automatización tiene que proveer ese framework a los equipos que desarrollen pruebas automáticas, ya sean ellos mismos o los desarrolladores.
  2. Desarrollo de pruebas funcionales: A pesar de que los desarrolladores implementen pruebas funcionales de sus tareas, es posible que el equipo de automatización necesite realizar unas pruebas automáticas de más alto nivel. Dentro de estas pruebas, se pueden listar también pruebas E2E, API, Mobile etc.

Es necesario que el equipo de automatización trabaje estrechamente con los departamentos de producto y de desarrollo, debido a que las pruebas que se desarrollen van a depender mucho de las conversaciones entre los diferentes departamentos.

Equipo de Rendimiento y Seguridad

El rendimiento y la seguridad de nuestra aplicación son unos de los valores más importantes que tenemos que garantizar, pero no siempre son los más sencillos. El equipo de rendimiento y seguridad se deberá encargar de desarrollar las pruebas necesarias que garanticen la calidad de ambos aspectos.

Las responsabilidades más importantes son:

  1. Pruebas de rendimiento: Disponer de una suite de pruebas de rendimiento (pruebas de carga, estrés, estabilidad, etc.).
  2. Pruebas de seguridad: A pesar de que los desarrolladores implementen pruebas funcionales de sus tareas, el equipo de automatización es posible que necesite realizar unas pruebas automáticas de más alto nivel. Dentro de estas pruebas, se pueden listar también pruebas E2E, API, Mobile etc.

El equipo de rendimiento y seguridad debe trabajar estrechamente con el departamento de sistemas o sysop, debido a que sus pruebas van a tener impacto en los entornos y en la aplicación.

Equipo de Testing

Dentro de las tareas más importantes se encuentra el validar o rechazar la RC y para ello es necesario que el equipo de testing realice las pruebas correspondientes. Por otro lado, el tratamiento de bugs y las pruebas bajo demanda también son tareas del equipo de testing.

Las responsabilidades más importantes son:

  1. Validación de RCs: Sacar la RC adelante es la finalidad de todos (desarrolladores, sys, QA, producto etc.), por lo que es la tarea más importante del equipo de testing. En caso de que en tiempo de RC en la fase de prevención todo haya ido bien, en fase de reacción los testers deberán buscar cualquier fallo crítico y, en caso de localizarlo, rechazar la RC.
  2. Pruebas bajo demanda: En ocasiones es necesario realizar pruebas bajo demanda sobre una tarea en concreto. Se suele hacer cuando la tarea es compleja o crítica. De esta forma, nos podremos asegurar que no vamos a meter fallos en la RC.
  3. Diseño de casos de prueba: Sin casos de pruebas no se sabe qué probar. El equipo de testing deberá diseñar los casos de prueba necesarios para la validación de la RC, o para el testing bajo demanda.
  4. Tratamiento de bugs: Cuando en producción se localiza un fallo o un bug es necesario reportarlo. El equipo de testing tiene que reproducirlo y aportar la información necesaria al equipo de desarrollo para que lo solucionen. Un aspecto, en mi opinión, importante y a veces olvidado es que disponer del conocimiento suficiente para entender el código de la aplicación ayudará al tester a obtener más información del error. De este modo, el desarrollador invertirá menos tiempo en solucionarlo.

El equipo de testing tendrá que trabajar estrechamente con el equipo de producto y desarrollo para obtener la información necesaria que permita preparar los casos de prueba frente a posibles bugs.

Conclusión final

Durante la serie de posts, hemos visto en qué se basa la estrategia de “Prevention & Reaction”. Es una estrategia teórica, basada en mi experiencia como QA, en lo que he aprendido estos años y en cómo hoy en día enfocaría el trabajo para garantizar la calidad en un entorno de desarrollo ágil.

La finalidad de la estrategia es garantizar la calidad desde una etapa temprana. Su base principal son los datos y el análisis de los mismos, pero también puede ser su punto débil, debido a que al comienzo de la implementación de la estrategia no disponemos de los datos suficientes. No obstante, como suele ocurrir, su punto débil también es su punto fuerte.

A medida que dispongamos de más datos, la heurística de nuestro sistema de predicción de bugs será mejor y, por lo tanto, nos ayudará a reducir el riesgo de dejar pasar fallos a producción.

Estrategia Prevention & Reaction – Parte II

Introducción

En el capitulo anterior vimos en qué se basaba la estrategia de Prevention & Reaction y cómo la aplicábamos en tiempo de RC. En esta segunda parte vamos a ver qué es el tiempo de producción y qué herramientas de calidad utilizamos para poder aplicar la estrategia Prevention & Reaction.

Tiempo de Producción

production time

Denominamos tiempo de producción al estado en que la release ha llegado a desplegarse en los entornos de producción. El software ya se encuentra disponible para que los usuarios lo utilicen, por lo que los errores que hayamos dejado pasar en tiempo de RC serán detectables por los usuarios. Las herramientas de calidad que actúan en tiempo de producción nos ayudarán a prevenir esta situación.

Prevención en tiempo de Producción

Prevention in production time
Las herramientas de prevención en tiempo de producción tratan de obtener información del estado y de las acciones de los usuarios y así poder utilizarlas en tiempo de RC. La información que obtengamos del entorno de producción nos servirá para adelantarnos a problemas aún no descubiertos por los usuarios, así como servirnos de datos para nuestras pruebas previas.

La información principal que obtendremos de producción es la siguiente:

  1. Trazas de errores: Lo que nos permitirá detectar bugs antes de que los usuarios sean conscientes, o proveernos de información para solucionar los fallos.
  2. Acciones de usuario: Hay ocasiones en las que los usuarios realizan acciones que no son contempladas por el equipo QA; con esta información podremos obtener mapas de calor de acciones y ajustar y mejorar nuestros casos de prueba.
  3. Datos de entrada: Obtener datos de entrada reales para nuestras pruebas puede ayudarnos a aumentar de alguna forma nuestra cobertura.

 

Como se puede observar, las herramientas que se plantean intentan obtener información para ayudar a las fases anteriores de la estrategia y así minimizar el riesgo de inserción de bugs en RCs futuras.

Reacción en tiempo de Producción

reaction in production
Cuando el software se encuentra en producción es probable que el usuario reporte bugs o, en el peor de los casos, que sea necesario tratar un fallo bloqueante que requiera de un hotfix. Las estrategias en tiempo de producción intentan manejar estas situaciones.

Bien es cierto que el tratamiento de bugs y el protocolo de actuación frente a la necesidad de realizar un hotfix es muy personal a la empresa, pero  lo que aquí intento mostrar es una estrategia básica del tratamiento de un caso de hotfix.

Aparte de las dos etapas clave de desarrollo de la solución y posterior fase de pruebas por parte del equipo de QA, es muy importante recabar la información necesaria para alimentar la heurística del sistema de predicción de bugs del que hablamos en el capítulo anterior, así como para hacer análisis y retrospectivas.

Conclusiones y adelanto

El capítulo aporta puntos bastante importantes en cuanto a las estrategias que seguimos en el tiempo de producción. Cuando la aplicación se encuentra en producción, los usuarios se toparán con los errores a no ser que podamos prevenirlos mediante la información que vamos obteniendo a lo largo del proceso.

Debemos disponer de un protocolo para tratar los errores bloqueantes: el protocolo debe ser lo suficientemente eficaz para que el impacto, tanto para el usuario como para el negocio, sea mínimo. Esto se traduce en un protocolo que nos aporte garantías en cuanto a la validez de la solución, así como rapidez en el desarrollo de la misma. Estos errores nos deben ser de ayuda para prevenir errores futuros.

La mayor fuerza estratégica de Prevention & Reaction la encontramos en tiempo de RC, ya que un error en producción es una muestra de que la estrategia no se está aplicando correctamente. No obstante, no debemos darle menos importancia al tiempo en producción ya que nos aporta una gran información con la que podremos mejorar nuestras pruebas.

En el próximo y último capitulo veremos como aplicar la estrategia mediante grupos de trabajo.

Estrategia Prevention & Reaction – Parte I

Introducción

Con las metodologías ágiles, el software se encuentra en un desarrollo continuo, de una forma iterativa e incremental, de forma que la mayoría de empresas despliegan diariamente una o más versiones de su aplicación.

Este hecho provoca que las estrategias de aseguramiento de la calidad (de ahora en adelante QA) deban adaptarse, dado que únicamente cubrían las necesidades de las metodologías tradicionales.

Actualmente existen empresas que implementan metodologías ágiles sin la necesidad de perfiles de calidad, siendo los desarrolladores quienes la aplican, mediante el desarrollo de pruebas unitarias y de integración. Esto es debido a que los equipos de calidad pueden demorar o ser un bloqueo en dichas iteraciones de desarrollo.

Tras en análisis anterior se me ocurrió como trabajo personal desarrollar una estrategia que aplicara esa idea. La estrategia “prevención y reacción” pretende adaptarse a las metodologías y equipos ágiles garantizando la calidad del software, tanto en fases de desarrollo como en fases posteriores y puesta en producción.

Contextos de prevención y reacción

El término de prevención se refiere a evitar la inserción de bugs en el desarrollo; por el contrario, el término de reacción se refiere a la actuación de localizar los fallos y al tratamiento en caso de hacerlo.

Diferenciamos dos contextos o tiempos diferentes en los que operan las estrategias tanto de prevención como las de reacción: Tiempo de la release candidata (en ahora en adelante RC) y tiempo de producción.

Tiempo de RC

rc_time_contexts

Llamamos tiempo de RC al estado en la que la release no ha sido desplegada en producción. Comienza en la toma de requisitos del desarrollo hasta la fase de pruebas de la RC.

Prevención en tiempo de RC

strategies
Las estrategias de prevención en tiempo de RC tratan de evitar la inserción de bugs o errores en la RC, de tal forma que la RC llegue a la fase de pruebas lo menos impactada posible.

Las estrategias operan fundamentalmente en tres fases del desarrollo de la RC:

  • Fase de diseño: En la fase de diseño, el equipo de calidad debe obtener información de los criterios de aceptación por parte del equipo de producto. Se podría obtener en fase de requerimientos pero es probable que en la fase de diseño estén más definidos, por lo que aquella (la fase de requerimientos) sigue siendo una etapa temprana.
  • Fase de desarrollo: Implementación de un sistema de predicción de bugs. Nos garantizará una información objetiva de los riesgos de los desarrollos realizados en la RC, puntos conflictivos y propensos a fallo. Mediante un sistema de predicción se pueden focalizar las pruebas con mayor precisión y así reducir el tiempo de ejecución de las mismas.
  • Fase de pruebas: Antes de generar la RC (la cual se enviará a pruebas finales) es necesario que pase  pruebas de análisis estático, unitarias, integración y funcionales. El equipo de desarrollo será el encargado de desarrollarlas. La petición finalizará  una vez esté el desarrollo junto con las pruebas. Se realizarán pruebas bajo demanda por parte del equipo de calidad. Todos los resultados se analizarán y se utilizarán para el sistema de prevención y futuras retrospectivas.

Aplicación estrategias

La imagen muestra una forma de aplicar las estrategias de prevención en tiempo de RC.

  1. Se desarrolla la petición junto con las pruebas por parte del equipo de desarrollo. El sistema de predicción obtiene los datos de los cambios realizados.
  2. Se ejecutan las pruebas desarrolladas unitarias y de integración. Los resultados se almacenan para un posterior análisis. Esos datos servirán para alimentar la heurística del sistema de predicción de bugs.
  3. Se despliega la petición en un nuevo entorno.
  4. Se ejecutan las pruebas funcionales. Los resultados se almacenan tanto para el análisis como para el sistema de predicción.

Reacción en tiempo de RC

Reaction in RC time

Las estrategias de reacción en tiempo de RC tratan principalmente de localizar los errores que se nos han “pasado” en la fase de prevención. Dado que la RC ya ha sido generada, los errores ya se encuentran ella, por lo que es tiempo de reaccionar y localizarlos.

Es bien cierto que en esta fase se implementan estrategias o acciones que garantizan la calidad de la aplicación que en la fase anterior no se podrían aplicar.

Como se puede ver, la intención no es solo asegurar la calidad desde un aspecto funcional, si no que intentamos realizar pruebas que garanticen el rendimiento y la seguridad de la aplicación.

reacción rc

La imagen muestra una forma de aplicar las estrategias de reacción en tiempo de RC.

  1. Se despliega la RC en un entorno de pruebas.
  2. Se ejecutan las pruebas de calidad. (Funcionales, UAT, security, performance…) Los resultados se almacenan para un análisis posterior y como heurística del sistema de predicción de bug.
  3. Se acepta o rechaza la RC.

La fase de reacción en tiempo de RC es la última antes del despliegue en producción, lo que significa que localizar un bug en producción que se ha insertado en la RC es un caso de fracaso.

Conclusiones y adelanto

Hemos visto cómo aplicar la calidad del software en tiempo de RC en dos contextos diferentes: Preventivo y reactivo.

Entender los dos contextos nos ayudará a conocer las diferentes estrategias que aplicamos y saber el porqué. Garantizaremos la calidad del software desde etapas tempranas y focalizaremos la mayoría de nuestros esfuerzos a generar RCs validas. De esta forma ahorraremos tiempos en el testing, dado que centralizamos las pruebas y en el desarrollo, dado que minimizamos la aparición de bugs.

En esta fase es muy importante la obtención de los datos. Los resultados de las pruebas sirven para realizar retrospectivas que ayuden a valorar el éxito de la aplicación de nuestra estrategia de calidad, debido a que si en la fase de pruebas no encontramos fallos que posteriormente se encuentran en producción deberemos tomar medidas. En el caso de los datos de predicción, nos ayudarán a focalizar nuestras pruebas, por lo que tendremos más opciones de encontrar posibles fallos y reduciremos nuestro tiempo de testing.

En el próximo post de la serie analizaremos los contextos de prevención y reacción en tiempo de producción. Veremos cómo los datos de producción nos pueden ser de gran ayuda para adelantarnos a fallos y cómo nos servirán para objetivizar nuestras pruebas.

Testing de microservicios – Estrategias

Introducción

Cada vez va cogiendo más fuerza el desarrollo usando arquitectura de microservicios por lo que el mundo de la calidad de software ha necesitado de nuevas estrategias. En este post hablaremos diferentes estrategias que se utilizan para garantizar la calidad de los microservicios.

Breve introducción a los microservicios

La arquitectura en microservicios busca desarrollar una aplicación dividiéndola en pequeños servicios (cada uno con su lógica de negocio) que corren de forma autónoma y que se comunican entre sí. Pero, ¿Que beneficios e inconvenientes nos aporta frente a la arquitectura monolítica?

microservicios

Como se puede apreciar en la imagen, una arquitectura monolítica es divida en varios servicios creando así una arquitectura de microservicios, donde cada servicio se comunica entre sí aportando la funcionalidad que ofrecía en su arquitectura monolítica.

 

BENEFICIOS

  • Cada microservicio es independiente por lo que su despliegue y desarrollo también, un cambio en uno no afecta en los demás.
  • La comunicación se  realiza mediante su interfaz pública (API) por lo que el lenguaje de desarrollo de los microservicios es independiente.
  • Mayor gestión de la escalabilidad, podemos escalar solo los microservicios que reciban más carga.

INCONVENIENTES

No todo son beneficios y es que la arquitectura en microservicios también nos aporta ciertos inconvenientes y retos, muchos de ellos debido a la introducción del concepto de sistemas distribuidos.

  • En el caso que una aplicación se componga de muchos microservicios es necesaria una mayor coordinación en los despliegues.
  • Será necesario una buena monitorización debido a que nos basamos en una arquitectura con un flujo muy dependiente de la comunicación. Un error en un punto del flujo tiene que ser rápidamente reconocible.
  • Garantizar la consistencia de los datos es un punto a tener en cuenta.
  • La saturación de la red puede afectar gravemente en el rendimiento de nuestra aplicación.
  • Las estrategias de calidad son mucho más complejas que en sistemas monolíticos debido a que no solo tendremos que testear los microservicios de forma independiente si no la funcionalidad en el flujo de los datos.

Estrategias de testing 

Como hemos dicho en la introducción, el mundo de la calidad del software ha tenido que aplicar nuevas estrategias de calidad para el reto que supone garantizar la calidad de las aplicaciones con arquitectura de microservicios.

En mi opinión el reto no se encuentra en el testing individual de cada microservicio, si no, en la integración y en la garantía de la consistencia de los datos. En comparación con los sistemas monolíticos, en una arquitectura por microservicios o distribuida el QA/Tester va a necesitar de un mayor conocimiento de la arquitectura y del flujo existente, debido a que es necesario controlar y verificar la información en todos los puntos de comunicación así como la funcionalidad de todos los microservicios.

La estrategia principal o las pruebas que se realizan son las siguientes (teniendo en cuenta que la estrategia es muy dependiente del proyecto que nos encontremos):

  • Tests unitarios: Como en todo proyecto ya sea monolítico o no, son necesarias pruebas unitarias. Mediante las pruebas unitarias comprobaremos la funcionalidad de los métodos o módulos de código que creamos necesarios.
  • Tests de integración: Los teses unitarios prueban los componentes de forma aislada por lo que también necesitamos probar el comportamiento entre los métodos. Debemos tener en cuenta que solo probaremos el comportamiento de los métodos de cada aplicación de forma aislada (de cada microservicio), por lo que las llamadas entre microservicios las mockearemos.
  • Tests de contratos o de API: La arquitectura de los microservicios depende de la comunicación entre los diferentes servicios. Cada microservicio presenta una API que consumen los demás microservicios, cuando la diseñamos estamos definiendo un “contrato”. Debemos realizar los diferentes tests a las APIs de los microservicios para garantizar que se mantiene el “contrato”.
  • Tests E2E: E2E (end-to-end) o teses funcionales tratan de garantizar la calidad de nuestra aplicación sin la necesidad de mockear  ningún método o llamada. Un test recorrerá la funcionalidad entre todos los microservicios que requiera. Debemos tener en cuenta que son susceptibles a fallar por motivos agenos a la funcionalidad (problemas de red, perdida de datos etc.). En el caso de los microservicios se recomiendan seguir unas reglas que nos ayudarán a reducir el esfuerzo de nuestros teses:
    • Dado que las pruebas E2E son difíciles de mantener, debemos intentar centrarnos en probar solo las funcionalidades más importantes, probando las demás en teses unitarios o de integración.
    • El uso de WebDrivers como selenium para probar las funcionalidades de usuario tiene un coste grande en cuanto a mantenimiento por lo que la mayoría de las acciones del usuario podemos hacerlas simulando las llamadas a la API.
    • Debemos intentar mantener un entorno limpio para cada ejecución dado que las pruebas son muy dependientes de los datos y pruebas anteriores pueden desestimar el resultado de los teses.

Referencias

  1.  http://testdetective.com/microservices-testing/
  2. http://www.sczyh30.com/vertx-blueprint-microservice/index.html

Explorando el “Exploratory Testing”

Introducción

 

Después de leer en varios blogs entradas sobre “exploratory testing” y como ha evolucionado desde 1.0, 1.5, 2.0 y 3.0 me he propuesto hacer un pequeño artículo para ayudar a valorar su importancia más allá de la teoría y ver su practicidad.
No voy a entrar a hablar sobre la evolución del testing exploratorio dado que James Bach ya lo explica de forma bastante detallada en en su artículo.

Exploratory testing

 

El ET (exploratory testing) sigue siendo una parte importante en la garantía de la calidad de nuestro software, a la que en menor o mayor medida no damos tanta importancia. La mayor importancia en los test exploratorios y clave para su éxito son sus bases o sus características:

  • Aprendizaje de la aplicación
  • Diseño de tests
  • Ejecución de tests

Resultado de imagen de exploratory testingEl QA deberá garantizarlas de forma simultanea a medida que va probando la aplicación, es decir, va diseñando las pruebas y ejecutándolas al tiempo que va adquiriendo conocimientos de la aplicación.

Esto puede generar disparidad de opiniones dado que al tester se le puede exigir un conocimiento del funcionamiento de la aplicación para poder validar las diferentes funcionalidades que la componen. Pero debemos ir un paso más adelante.  No estamos hablando de basar la calidad de la aplicación en este tipo de teses, si no de hacer uso de ellos para potenciar las habilidades de los testers y la búsqueda de bugs.

Algunos podréis estar de acuerdo conmigo, en el hecho de que cuando realizamos pruebas sobre una nueva funcionalidad o una nueva aplicación nuestra atención es mayor (menos comodidad, menos monotonía, desconocimiento de la funcionalidad etc), esto suele generar mejores resultados en cuanto a encontrar bugs.

Y como hemos podido observar la herramienta más importante para este tipo de test son las skills o las capacidades del tester en cuestión. Es importante disponer de la capacidad de pensar o diseñar los casos de prueba a medida que se avanza en las pruebas, discernir lo que es importante probar durante la sesión de pruebas, localizar los criterios de aceptación, en resumen, disponer de cierta experiencia e imaginación para el testing.

No obstante la experiencia se gana a medida que se hacen pruebas, por lo que es una muy buena herramienta para que los testers ganen y mejoren sus habilidades.

Experiencia y opinión

 

En el tiempo que llevo como QA lo cierto es que tengo más experiencia en la automatización de pruebas funcionales o manuales que exploratorias por lo que he dispuesto de un test plan (ya sea heredado o diseñado por mi) para desarrollar o ejecutar las pruebas.

Ahora cumpliré casi 10 meses en la empresa actual y realizamos  tanto automatización como pruebas manuales. Durante mi proceso de aprendizaje de la aplicación enfoque una gran parte del tiempo y del esfuerzo para realizar pruebas exploratorias lo que me ha llevado a tener un amplio conocimiento de la aplicación y a encontrar bugs que se salían del circuito “básico” de de pruebas. Hoy en día a pesar de que tenga interiorizado ese conocimiento y realice pruebas basadas en un test plan (que intento actualizar) suelo buscar un hueco para realizar pruebas exploratorias y sorprendentemente siempre suelo encontrar algún bug.

Siempre hay que tener en cuenta la situación o la estrategia del aseguramiento de la calidad de la empresa, pero como opinión personal creo que es importante implementar en la estrategia de calidad unas horas por recurso para que se realicen pruebas exploratorias. Esto va a ayudar a encontrar más fallos en la aplicación y sobre todo a mejorar las habilidades del tester.

Bibliografía

  1. http://www.satisfice.com/blog/archives/1509

 

Predicción de bugs, mito o realidad!

Introducción

Desde hace tiempo me produce bastante curiosidad el hecho de que puedan existir sistemas o algoritmos que nos puedan ayudar a “predecir” la existencia de bugs en nuestro software. Así leído puede parecer idílico e incluso algo difícil de creer dado que de base ya podemos pensar que hay muchos factores que pueden afectar a la inserción de un bug en nuestro código.

Para la predicción de bugs necesitaríamos una cantidad de datos importantes respecto al código, cambios realizados en la release, histórico de bugs. Y con todo ese caldo de datos…pum… magia?

Para que veáis que no solo puede afectar la parte técnica como curiosidad os dejo este enlace a un post que sobre todo es curioso.

Así que me he puesto a investigar un poco y ver la realidad y sobre todo los beneficios que nos puede aportar.

Algoritmo de predicción de bugs – FixCache

Existen varios algoritmos en lo que a la predicción de bugs respecta pero en este artículo me gustaría centrarme en el algoritmo FixCache y realizar una comparativa en artículos posteriores.

Actualmente existen dos tipos de estrategias para la predicción de bugs:

  1. Basados en las métricas de calidad como lineas de código (LOC) y la complejidad ciclomática.
  2. Basados en el control de cambios e histórico del repositorio.
fixcache_ratevstime
Imagen 1: Hit rate vs time for projects

FixCache entraría en el segundo grupo, dado que se sirve del repositorio de código para analizar los cambios y así predecir los posibles bugs.

En la imagen 1 vemos un ejemplo de la tasa de éxito del algoritmo FixCache sobre cuatro aplicaciones diferentes.

El algoritmo trabaja observando los cambios realizados en los ficheros o los métodos y utiliza tres heurísticas para añadir los ficheros a la “caché”:

 

 

 

  • Nuevos ficheros de código o modificados los cuales pueden contener bugs.
  • Ficheros que actualmente contienen bugs son propensos a contener más bugs (Aquí entra la teoría del “defect clustering”)
  • Ficheros que han sido modificados para solucionar algún bug son propensos a contener otros bugs.

Como hemos indicado para crear la “caché” de datos se sirve del repositorio de software, donde identificará los cambios realizados en los ficheros mediante los commits  al proyecto comparándolo con su propia base de datos o caché.

La gestión del caché es importante, normalmente cacheando un 10% de los ficheros del repositorio al finalizar el periodo de análisis. Es importante determinar si la caché está completa para remover los ficheros que no vayan a formar parte de posteriores análisis, para ello se pueden implementar varias políticas de reemplazo (parecido a las de la gestión de memoria caché de nuestro sistema):

  • El fichero menos utilizado recientemente (LRU).
  • El fichero que menos cambios ha tenido .
  • El fichero que menos bugs ha tenido históricamente.
  • El fichero que menos autores de cambios tenga.

Sería interesante ver que política de reemplazo da mejores resultados, lo cierto es que la más utilizada es LRU, me imagino que por su baja complejidad de gestión respecto a los demás.

Practicidad del sistema de predicción de bugs

Ya hemos visto un ejemplo de algoritmo que se basa en los cambios en los ficheros del repositorio pero,  ¿Que utilidad podemos darle al uso de un algoritmo de predicción de bugs?

En un sistema de CI (continuous integration) donde se aplique la metodología ágil, donde se realizan cambios a diario en el código y donde la intención es realizar despliegues a producción continuamente puede ser una muy buena opción para ayudar al equipo de QA en sus pruebas. Pongamos varios ejemplos:

  • Lanzar pruebas de regresión automáticas de aquellas funcionalidades o aquellos ficheros que el algoritmo detecte con riesgo de bugs en cada RC (release candidate).
  • Crear un “semaforo” que identifique las zonas de riesgo de la RC y así focalizar las pruebas o reforzarlas para prevenir bugs.
  • Mantener un histórico de ficheros conflictivos que puede ser utilizado a modo informativo por QA, desarrolladores etc.

Conclusiones

Depende de nuestro sistema de CI y la finalidad puede que nos sea más o menos viable implantar un sistema de predicción de bugs, lo cierto es que no muchas empresas disponen de ello (que se sepa) y puede ser interesante únicamente en los casos que se realicen cambios en nuestro código continuamente.

Bibliografía

  1. https://users.soe.ucsc.edu/~ejw/dissertations/AdaptiveBugPrediction_SungKim_Thesis.pdf
  2. http://static.googleusercontent.com/media/research.google.com/es//pubs/archive/41145.pdf
  3. http://www.mysmu.edu/faculty/davidlo/papers/csmr13-reopened.pdf
  4. https://users.soe.ucsc.edu/~supertri/docs/msr2011-final.pdf
  5. http://www.softwaretestingclub.com/profiles/blogs/defect-clustering-pesticide-paradox
  6. http://www.malavida.com/es/noticias/control-biometrico-para-predecir-errores-de-codigo-en-programacion-006101