La Keynote con la que arrancó el segundo día de ExpoQA 2018 corrió a cargo de Sereta Gamba con: Siete formas comprobadas de arruinar tu automatización de pruebas.

Seretta le dió la vuelta a una charla convencional. En vez de explicar buenas prácticas, explicó métodos infalibles con los que seguro que destrozas la automatización de tus tests; las posibles «defensas» ante estos métodos (es decir las buenas prácticas) y las contramedidas (a menudo excusas) más habituales contra estas defensas. Didáctica y bastante divertida.

Seretta Gamba

No me voy a enrollar con cada uno de los métodos ya que están bien explicados en TestAutomationPatterns.org, pero aquí están los que expuso:

  • Guillotime methods:
    • Fire Atlas
    • Impossible Goals
    • Change Tool
  • Boiled Frog methods:
    • Primitive program practices
    • Manual approach
    • Feigted Support
    • Ever increase maintance

Me llevo como tarea para el trabajo identificar si tenemos alguno de estos patrones y buscar soluciones (¡misión cumplida!).

La siguiente charla que me interesaba fue Guía del tester para manejar prejuicios, a cargo de Lina Zubyte.

Comenzó explicando que un prejuicio es un error sistemático en la forma de pensar sobre algo. Pero… ¿cómo puede afectar a los testers tener prejuicios en el día a día? Primero una pequeña clasificación:

  • Pensamiento de grupo: aunque la mayoría del equipo piense que las cosas deben ser de determinada manera, esto no tiene por qué ser cierto.
  • Falacia del coste incurrido: es difícil abandonar cosas en las que ya hemos invertido.
  • Prejuicio de datos: los datos de pruebas influyen en el resultado.
  • Prejuicio de resultado: si funcionó antes, no tiene por qué funcionar en el futuro.
  • Prejuicio de confirmación: el creador de una idea no siempre tiene la razón.

Lina Zubyte

Pero, ¿cómo trabajar con esto? Lo primero es admitir que tenemos prejuicios. Nos recomienda hacer el test “Project Implicit” de la Universidad de Hardvard para identificarlos. Pedir feedback y escucharlo. Cuestionarte a ti mismo y los procesos.

Nos explicó tres técnicas :

  • Systems 1 & 2. El cerebro tiene dos sistemas para tomar decisiones, uno intuitivo y rápido, y otro reflexivo y lento. Es malo tomar decisiones rápidamente bajo presión; si estas decisiones necesitan más reflexión, hay que tomarse el tiempo necesario.
  • Ladder of inference. Es el proceso mental que seguimos hasta tomar una decisión, descrito como una serie de escalones.
  • Rule of three. Si no puedes pensar en tres maneras en las que una solución puede fallar, es que no has entendido bien el problema.

En la parte de  cómo tratar con gente con prejuicios,  da tres consejos:

  • Preguntar, ser paciente y compartir conocimientos y hechos.
  • Romper ilusiones, no corazones
  • ¡Llevar galletas!

Al final de la charla relacionó el futuro con la ética y cómo los prejuicios afectan a la tecnología, en concreto a la Inteligencia Artificial. Como nota final me quedo con esta frase: “todos tenemos prejuicios, lo importante es conocerlos y saber gestionarlos«.

Otra charla que charla me interesó especialmente fue: Pruebas en el mundo de los cien microservicios: cuando la pirámide de pruebas se convierte en el reloj de arena, por Isabel Vilacides. Nos contó cómo están migrando de una aplicación monolítica a una arquitectura de microservicios. En este tipo de arquitectura los tests E2E son especialmente inestables y difíciles de ejecutar y mantener.

Isabel Vilacides

Detectaron que los tests de integración que utilizan mocks tienen un problema en sistemas de microservicios: están basados en suposiciones. Se hacen mocks de los cambios en las interfaces, y estos sistemas cambian mucho. Por ejemplo, tienes un microservicio que hace de productor y tres que hacen de consumidores. Si en algún momento cambias la API del productor, los tests de los consumidores seguirán en verde ya que se lanzan contra un mock, sin embargo, en tests E2E o en producción fallará.

Con este enfoque, se está poniendo la carga de controlar estos cambios en el desarrollador. La solución pasa por introducir los Consumer Driven Contract Testing con PACT. Establecen un «contrato» común para este conjunto de microservicios. Si cambia el API, los contract tests fallarán y se detectará el problema en una fase temprana. Resumiendo, este tipo de testing nos aporta:

  • Feedback rápido
  • Detección temprana
  • Facilitan la comunicación entre equipos que desarrollan diferentes microservicios

Continúa con esta frase “si las cosas se rompen, quieres ser el primero en enterarte”. Para conseguirlo necesitamos:

  • Verificaciones post-deploy
  • Health checks en producción
  • Monitorización:
    • Establecer límites conocidos
    • Medir
    • Alertas

Los despliegues los hacen en dos etapas, primero en un entorno que llaman producción interna, y si todo funciona bien, se pasa a producción. Pero, ¿qué pasa cuando las cosas van mal en producción? Pues quieres que afecten al mínimo número de usuarios. Para ello emplean:

Me pareció una charla muy práctica que seguro que puedo aplicar.

La siguiente ponencia fue la de Filipe Nuno Carlos con DevOps: ¿Cómo abordar los datos de prueba?. Comenzó la charla con una analogía entre una sierra manual y una motosierra. Indiscutiblemente la motosierra es más eficiente cortando leña. Pero, ¿y si el deposito de combustible es del tamaño de una taza de café? Probablemente pasaremos más tiempo rellenando el depósito que cortando leña.

Con este ejemplo Filipe nos muestra que se puede perder mucho tiempo inicializando datos para nuestros escenarios de test.

Creando la «Gold copy»

La forma “antigua” de gestión de datos de test sigue el patrón ‘copiar un subconjunto de datos de producción → enmascararlos → insertar datos en la BD de test’. Esto tiene una serie de problemas: es malo para la integración continua, no hay datos para escenarios negativos o escenarios futuros, poca cobertura, alto coste de infraestructura, es lento y propenso a errores.

Por ello nos propone esta receta:

  • En un primer momento se arranca con un subconjunto enmascarado de los datos de producción (como en el método anterior).
  • Se hacen perfiles de datos, se modelan y se mide la cobertura.
  • Se generan datos sintéticos hasta conseguir el ∼100% de cobertura.
  • Esta base de datos se denomina “Gold Copy”.
  • Con esta Gold Copy se preparan las BBDD de test.
  • En este punto se elimina la necesidad de datos de producción.

La segunda Keynote del día en esta ExpoQA 2018 fue a cargo de Alex Schladebeck y Huib Schoots con: Dejemos de hablar sobre Testing, comencemos a pensar en su valor.

Alex Schladebeck y Huib Schoots

Esta fue una presentación al alimón entre Huid y Alex. Comenzó poniendo de relieve que el testing no está siendo valorado por varias razones, entre otras, porque no sabemos transmitir qué es el testing. Así que proponen comenzar una revolución para cambiar las cosas. Toca hablar del valor que aporta el testing, de lo que produce y del rol que jugamos los testers. Dar una visión realista del estado del producto y ser crítico son aportaciones clave.

Algunos de los principios que proponen son:

  • Entregar información sobre el estado del producto.
  • Practicar el pensamiento crítico.
  • Facilitar las pruebas: liderar, capacitar, enseñar, apoyar.
  • Discutir sobre la testabilidad.
  • Explorar y experimentar.
  • Promover la eliminación de basura (trabajo innecesario).
  • Ayudar a acelerar al equipo.
  • Promover la mejora continua.
  • Fomentar la cultura de calidad.

¿Como pinta el futuro?

Me gustó mucho esta frase: “El propósito del testing es rellenar el hueco entre lo que sabemos y lo que necesitamos saber” (Risk Gap). Proponen que deberíamos hablar de la historia del producto, de los riesgos y del valor. En definitiva, revolucionar el modo en que contribuimos y comunicamos.

Para finalizar, asistí a la charla  El cuestionario de riesgo. Adam Knight nos mostró un experimento que se hizo en un paso a nivel sin barreras que cruzaba un bosque. Cuando los conductores se acercaban al paso a nivel reducían la velocidad para mirar si venía el tren. Cuando talaron los árboles cercanos al paso a nivel para que los conductores tuvieran más visibilidad, los conductores iban más rápido, asumiendo el mismo riesgo que antes. La conclusión es que la gente compensa los cambios para mantener un nivel constante del riesgo percibido (risk compensating).

Apuntó algunas pautas que influyen en nuestra percepción del riesgo, disminuyéndola, por ejemplo:

  • Múltiples riesgos diferentes vistos como un sólo riesgo.
  • Los posibles beneficios tienden a reducir la percepción del riesgo.

Para ilustrar cómo los testers y el negocio perciben los riesgos de forma muy diferente, nos mostró la Wave of Risk. Los testers percibimos más riesgo del real y negocio percibe mucho menos riesgo. Para salvar esta diferencia propone:

  • Contar historias.
  • Hablar una a una sobre las consecuencias negativas.
  • Involucrar a los testers en la visión del software.

Riesgo aceptable

Por último, nos presentó un ejemplo de cuestionario de riesgo basado en el mundo de las finanzas, pero aplicado al testing, para evaluar, identificar y preparar una estrategia de gestión de riesgos.

Y hasta aquí todo lo que dieron de sí las ponencias a las que asistí de ExpoQA 2018. ¡Hasta el año que viene!

También puedes leer en mi blog un resumen del primer día de ExpoQA 2018.