El primer día de conferencias de ExpoQA 2018 (Madrid, 4-6 junio) arrancó con la Keynote «Testing para un mundo más seguro«, a cargo de Fiona Charles. El objetivo de la charla era concienciar sobre la necesidad del testing en un mundo en el que las vidas humanas dependen, cada vez más, del software: coches autónomos, dispositivos médicos, etc. Y analizó cómo adaptarnos a este tipo de testeo.

En su charla, Fiona proclama que necesitamos testers entrenados capaces de hacer las preguntas adecuadas, tener visión de la «big picture», con creatividad e imaginación para crear escenarios de posibles desastres, y pensamiento estratégico para usar los recursos de test de la forma más efectiva.

Modelo Cynefin

¿Y qué podemos hacer los tester? Aprender acerca de seguridad. Puso varios ejemplos de frameworks como STAMP, Safety II, SUBSAFE. Involucrarnos lo antes posible, y aquí citó a Nancy Leveson en Engineering for a Safer World: “Casi todos los accidentes serios en los que ha habido software involucrado en los últimos 20 años son debido a fallos en los requerimientos y no a errores de codificación«.

Entender los riesgos, asegurar la seguridad, desarrollar y testear sistemas resilientes, pensar a nivel de sistema y aprender a navegar en la complejidad, son otros de los puntos a tener en cuenta.

La siguiente charla a la que fui era Master Class: Testing en el siglo XXI, de Alex Soto, sólo me quedé a la primera parte, ya que se solapaba con otra que también me interesaba.  Comenzó explicando cómo ha ido evolucionando el testing clásico, hasta pasar a centrarse en cómo testear microservicios. Nos habló de cómo hacer virtualización de servicios con HoverFly, para probar y tener tests automatizados que dependan de servicios externos o de terceros, sin que estén realmente conectados.

Alex Soto

Otro de los puntos fue el de los Contract Tests (de esto también se habló en otras charlas y en los pasillos). Aquí se define un «contrato» entre los microservicios proveedores y consumidores, de forma que si alguno cambia la forma de comunicarse, el test falla. Alex nos puso un ejemplo con PACT. Alguna de las ventajas de este enfoque es que es automatizable, fiable y aporta detección temprana.

La mañana terminó con Santhosh Tuppad y ¿Por qué la seguridad del software ha empeorado? ¿Y qué podemos hacer al respecto? Comenzó dando un repaso al preocupante estado actual de la seguridad en blogs, sitios de ecommerce, hospitales, etc. En su opinión, las razones que han llevado a esta situación: falta de formación en seguridad, foco sólo en el testeo de la funcionalidad, programación no segura,…

Santhosh Tuppad, hacker y más.

Siguió con una demo en la que mostraba lo fácil que es acceder al panel de administrador de la web de un hospital, o cambiar la contraseña de administrador de un determinado servicio, simplemente modificando un JSON.

Y ¿qué podemos hacer los testers? Santhosh enumeró varias preguntas que podemos hacernos, resumo algunas:

  • ¿Qué base de datos usas?
  • ¿Estás usando un firewall? ¿Qué reglas tienes configuradas y por qué?
  • ¿Qué estas haciendo para prevenir ataques XSS?
  • ¿Estás usando las cabeceras seguras de HTTP?
  • ¿Qué visión tienes sobre la seguridad de software?

La segunda Keynote del día fue La evolución del rol de los testers de software en la era de DevOps, IoT, AI y UX de Baris Sarialioglu. Explicó la evolución del tester 1.0 a 2.0.  Es una evolución totalmente alineada con el enfoque de testing ágil, resumiendo: pasamos de poner el énfasis en prevenir bugs, en lugar de en detectarlos; testing constante frente a testing al final; responsabilidad de todo el equipo frente a sólo del tester.

Baris Sarialioglu

Sobre DevOps y testing comenzó hablando sobre algunas confusiones habituales sobre DevOps. Destacar una par de ellas que he oído por ahí:

  • DevOps es sacar software cada 5 minutos o hacer 10 despliegues al día -> No tiene por qué ser cierto para tu organización.
  • DevOps es automatizar -> DevOps no es algo que «construyes», es algo que «haces».

El testing pasa a ser una actividad colaborativa en la que participan tanto testers como desarrolladores y analistas de negocio.

Todo el equipo al testing

En el apartado de IoT & Testing  hay muchos retos por delante. Las líneas de código existente se multiplican por dos cada dos años, pero el número de defectos por línea se ha mantenido constante. IoT implica más test de hardware (RFID, NFC, Bluetooth, Wifi, etc..)

Después paso a hablarnos de la Inteligencia Artificial & Testing. Algunas de las áreas donde aplicar IA son:

  • Intelligent Monkey Testing: entrenar a una herramienta para descubrir y optimizar test cases
  • Test Oracles and Test Basis: para que la IA se capaz de explorar funcionalidad
  • Análisis de código
  • Análisis de defectos
  • Análisis de datos de test

Usos de la IA en testing

Por último, sobre UX & testing, me gustó una cita de Graham Greene: «La naturaleza humana no es blanca y negra, sino negra y gris«. Estableció un paralelismo en el que los tests de UX son la «zona gris» del testing, ya que probamos múltiples aspectos, no sólo la facilidad de uso, también la eficiencia, el proceso, o incluso cómo te hace sentir el producto. Esto hace que sea difícil de cuantificar.

La siguiente charla: Entregando buena calidad con trainees en el equipo,  Maja Schreiner nos explicó como incorporan al equipo  trainees muy jóvenes (15-16 años) en Swisscom. Hacen prácticas como parte de su currículo escolar. Su tarea principal es testing exploratorio. La calidad, proactividad, motivación, experiencia y reconocimiento son los problemas y riesgos que debe gestionar.

Calidad con trainees… sí, con Maja Schreiner

Para hacer un equipo exitoso, plantea cinco factores:

  • Herramientas de colaboración
  • Comunicación
  • Conocerse
  • Pair testing
  • Sesiones de testing conjuntas con todo el equipo

Al final, de lo que se trata es de construir habilidades de coaching, y nos recomiendó el libro “Coaching Competences” de Lisa Haneber. Finalmente nos dio algunos consejos, como preparar un plan de tareas semanal y tener feedback regular de los trainees. Nos dejó una frase “No seas su madre, déjalos equivocarse”.

ATDD: hacia la entrega continua de valor. Un caso real. En esta charla, Miguel Ángel Alonso, Jorge España y Javier Bel nos contaron cómo ING ha implantado una estrategia de ATDD en el proyecto RUBIK, una nueva plataforma bancaria en 5 países.

Resolviendo Rubik

Para empezar, cuentan con equipos autorganizados, divididos en tribus y squads. Desatacan que es vital contar con el compromiso de la gerencia para implantar esta forma de trabajo. Su modelo de ramas es sencillo, solo está master y las ramas de features. En la rama de feature se pasan las pruebas rápidas (tests unitarios, integración, aceptación) y en master se ejecutan las pruebas lentas (rendimiento, seguridad,…).

Ramas sin complicaciones

El concepto sobre el que gira su  enfoque es que “los criterios de aceptación deberían ser ejecutables” (Dan North). Se basan en JIRA y XRay, con los criterios de aceptación escritos en Gherkin, ligados a la historia en JIRA. Si el código no pasa los tests de aceptación, el botón de merge a master NO se habilita.

En total tienen cuatro quality gates para poder hacer el merge en master: Tests técnicos, Peer review, Acceptance Tests y Regresion tests.

Pasito a pasito…

En el apartado de lecciones aprendidas destacan:

  • Es clave el compromiso de la organización para adoptar este enfoque
  • Los tests y despliegues deben ser automáticos
  • Seguir las buenas prácticas de programación y test
  • Tener buenos datos para test
  • Utilización de los quality gates
  • La calidad comienza con la definición del producto, con definiciones declarativas

Y hasta aquí, lo que dio de si el primer día. Puedes seguir leyendo mi resumen del segundo día de ExpoQA 2018.