VLCTesting Valencia 2017

Reading time ~16 minutes

¿En serio? ¿Otro año? El tiempo vuela y creo que si está volando así de rápido es porque las cosas van muy bien 😄

La verdad es que quisiera haber publicado muchísimas cosas este año pero oye, parece que tengo que darle un toque a mi agenda para poder escribir nuevos posts. Este año he ido a conferencias súper interesantes como a la Test Academy de Barcelona y la European testing conference de Helsinki 😱

En fin, mientras me animo a contar esas vivencias, os cuento qué tal de nuevo en el VLC Testing, que esto para mi ya es un must.

Bien esta vez, comenzamos con una charla introductoria bastante relevante para el resto de las conferencias puesto que Javier LLacer nos introduce “Antes de pollo fui Gallo” en la que nos cuenta como, metido en el mundo del desarrollo y al principio de los tiempos, él creía que la calidad no tenía una importancia clara.

Le parecía raro tener a un tester desde el principio del desarrollo. Comenta que nacemos gallos con respeto a la calidad, porque pensamos que somos lo suficientemente buenos para llevarla innata con nosotros, pero eso es precisamente porque no la entendemos. Además es muy difícil implantar la calidad en una empresa que nunca ha tenido cuidado de ella.

Debemos acabar con los vicios que obvian la calidad y tomar buenos hábitos, metodologías, organización y desarrollo para que ni el producto ni el equipo tengan mala imagen. Hay que tener muy en cuenta que para tener calidad, ante todo debe haber buen ambiente en el equipo y fomentarlo.

Nos hizo recordar la diferencia que existe entre un jefe y un líder.

Además nos dio un toque con respecto al departamento comercial, que son los grandes olvidados y deberíamos sin embargo estar muy en contacto con ellos puesto que son los que establecen las expectativas del producto con los clientes. Al final, la cohesión es la que permite que el engranaje de la organización esté perfectamente engrasado.

Charlas (miércoles)

Control de la calidad del software en la Generalitat Valenciana (Amparo Belmont y Juan Carlos Egido)

No podemos ser inflexibles con la calidad. Ellos recorrieron todas las consellerías para ver qué métodos de trabajo se seguían, estructura etc. Vieron que todo era muy dispar, no había control de versiones y era muy difícil mantener la trazabilidad de las aplicaciones desplegadas. Además la gestión de esos proyectos se hace inmantenible puesto que existen grandes volúmenes de datos y aplicaciones.

Para implantar una metodología común crearon gvLOGOS. De esta manera se regula toda la problemática.

Finalmente concluyen afirmando que es muy difícil el cambio porque existe resistencia pero mientras se encuentren alineados con los usuarios, la calidad estará presente.

Ágil por necesidad (Silvia Jiménez)

Nos cuenta la experiencia de su equipo con uno de sus clientes. Les pidieron crear una factoría donde crear componentes y por otro lado se certificaran los productos. En el pasado lo que manejaban en su empresa era el típico modelo “creo” > “certifico” > “despliego” hasta que se les presentó la posibilidad de hacer un cambio.

El cambio se basó en fijarse en el modelo del Lean Manufacturing, de tal manera que, en el mundo del software (Lean software development https://en.wikipedia.org/wiki/Lean_software_development), llegues a estructurar proyectos de desarrollo de un modo ágil.

Fue así como pasaron de tener una factoría con el antiguo modelo, a tener dos en las que todo el proceso de desarrollo, test y despliegue estaban totalmente engrasados.

Lecciones aprendidas:

Estrategia de test guiada por contexto (Tomislav)

Nos compara el testing con los caballos, ¿qué tendrá que ver? Pues mucho, porque nos comenta que su coach de equitación le ha enseñado lecciones que encajan perfectamente con el mundo del testing.

“Sabes montar ese día, a esa hora y con ese caballo en particular”

Y es que todo depende del contexto, no podemos decir que ya sabemos testear algo simplemente porque ya hicimos algo parecido alguna vez.

Por eso debemos en nuestra estrategia de testeo debemos pensar en:

  1. Para quién estamos testando
  2. Qué aspectos de calidad tenemos que tener en cuenta
  3. Dónde lo vamos a testear
  4. Cómo lo vamos a testear

Y basar todo ello en estas tres máximas: experimentar, aprender y compartir.

Muy buena compañero

Orquestación y calidad en el ciclo de vida de los microservicios (Aurelio Pérez)

Nos presenta el problema y la solución en su arquitectura. Nos introduce la diferencia entre la arquitectura monolítica y la orientada a microservicios.

Ellos implantaron un orquestador de aplicaciones que se pone por encima de los Jenkins y tiene su propio ciclo de estados. Teniendo esto, el resto de aplicaciones mapean su estado actual con los estados de este orquestador para que sepa en qué momento la aplicación en cuestión podría ser desplegada.

Además siguen ciertas reglas como:

  1. Cada equipo es quien decide y define las dependencias de su microservicio

  2. La descripción de los pipelines debe ser para todos la misma

  3. No es facil que todos los micro servicios tengan las mismas fases y por eso cada uno tiene su propio .json que mapea sus fases con las del orquestador

Aplicación profesional del esquema de certificación ISTQB (Aurelio Gandarillas)

Ya todos conocemos esta certificación. Este año apuestan por difundir este conocimiento a todos los profesionales informáticos desde que se estudia la carrera.

Tropezar con la misma piedra vale, pero hacerte amigo de la piedra nunca (Domingo Gaitero)

Nos muestra de nuevo la realidad de que la calidad y el testeo caen una y otra vez en los mismos errores y hay que luchar por lo contrario para evitar la tristeza y desmotivación de los trabajadores.

  • Testear al final del ciclo de vida del software
  • El testeo no lleva tiempo
  • No se tiene en cuenta que el testing es rigurosidad
  • El testeo está subestimado

Hacia el testing ágil: 5 errores que vas a cometer y podrías evitar (Pedro Sebastián)

Nos cuenta qué problemas podemos encontrarnos en agile:

  1. Ver el testing como algo aislado y no un trabajo en equipo
  2. Ultradetallar la actividad de testeo
  3. Automatizar todo y no tener una estrategia
  4. Sobrevalorar las capacidades técnicas, hay que saber que el conocimiento suma pero que la actitud multiplica
  5. Adaptar agile desde el modelo waterfall

Agile testing en Goldcar (Juan Antonio Ruzafa)

Esta empresa de alquiler de coches tiene un equipo técnico detrás muy interesante. Desde el principio han defendido la idea de “todos somos testers” y “una historia no está terminada sino está probada”.

Me gusta la idea de que piensan para cada User Story, si debe llevar su correspondiente sub tarea de testing exploratorio y/o automatización.

Tienen además un DSL desarrollado para comunicarse con negocio a nivel de tests.

Además han desarrollado métricas que les permiten ver el estado del negocio y su trabajo como son la diferencia entre bugs reportados por clientes vs bugs encontrados en user stories, recuento de tests etc

Para finalizar, apuntan que su siguiente paso es meterse con docker.

Testing de API para alcanzar la calidad (Jesús Heras)

Nos cuenta cómo testea API con rest-assured y valida los servicios api rest en Java y siguiendo la filosofía BDD.

Los test siguen el esquema Given When Then y sus aserciones los matchers de hamcrest.

No pruebes, simula. Cómo Cabify usa IA en su proceso de testing (Juan Enrique Sanchez)

Nos comenta cómo aproximaron el testing de varias maneras puesto que, en Cabify, se tiene la app del conductor y la del pasajero.

Un primer approach fue utilizar appium a bajo nivel para tener tanto iOS como Android sincronizados contra un mismo test, tras esto probaron con microservicios algo que acabó siendo poco determinista y muy inseguro y finalmente han probado a simular utilizando la inteligencia artificial.

Con esta aproximación ya no se hacen tests sino que se le indica al agente qué tareas debe realizar (programadas de antemano) y el resultado no es binario, sino que una tarea puede no ejecutarse, puede aparecer un error, un fallo etc

Muy interesante todo lo que nos comenta.

Cierre

La jornada cerró con premios como suele ocurrir y la verdad es que me gusta mucho la organización y que promuevan este tipo eventos.

Noche

Por la noche alojamos el evento de Trobatest en nuestra oficina de Flywire y ¡tela la de gente que vino!

Unimos a unos y otros profesionales que buscaban testers y jugamos para que todo el mundo tuviera la oportunidad de conocer al resto.

Nada más que añadir, una comunidad espectacular ;)

Talleres (jueves)

A los que yo he asistido:

Introducción al testing exploratorio, Heurísticas de testing y Pensamiento lateral (Claudia Badell)

Claudia nos explica súper bien el testing exploratorio.

La estrategia de pruebas a seguir aquí sería la suma del aprendizaje, diseño y ejecución de pruebas. Tienes libertad personal de qué probar pero la responsabilidad de administrar tu tiempo para que la búsqueda de información sea productiva.

El testing exploratorio es útil para obtener resultados rápidamente, detectar defectos en lugares que no esperábamos y aprender más del producto.

No es improvisar.

El testing exploratorio basado en sesiones te permite organizar el trabajo. Esto es, establecer una misión para la sesión (general o específica), ver el área de cobertura, analizar las tareas, dejar traza de los datos utilizados, mindmaps y notas y elegir una buena herramienta de reporting.

Claudia nos recomienda leer el libro “Explore it!” Porque contiene muchas heurísticas de testing que pueden ayudarnos en la tarea del testing exploratorio.

Docker y Docker compose, caso práctico (Vicente Pons Martinez)

Mi compañero de Flywire, Vicente, nos cuenta todos los secretos de docker compose. Este taller ha sido sobre todo práctico.

No estaría mal que vinierais por la oficina a una hacknight o testnight para pillarlo por banda y preguntarle más 😉

Servicios Rest y Gherkin y cómo combinarlos (Auxi Carlos Alberola)

Ella nos cuenta como empezaron en un proyecto con una máquina de estados, con muchos roles. Lo primero que hizo para ver cómo probarlo de una manera óptima, estudió bien el proyecto, la arquitectura, analizó las herramientas disponibles para hacer esas pruebas y finalmente priorizó las pruebas que debía hacer.

Con relación a las herramientas: SOAPUI, Gherkin y REST ASSURED (más orientada a BDD)

  • El lenguaje Gherkin es para definir los requisitos que después probarás. Defines a alto nivel y por debajo cucumber te hace esa traducción a un lenguaje de programación. Así roles como los analistas que están más en contacto con el cliente pueden diseñar pruebas.

  • SoapUI sirve para simular código de servicios web de forma rápida, sirve tanto para REST como para SOAP. Además te permite hacer pruebas de carga. (Y nos muestra cómo funciona la herramienta, cosa que me hace volver a 2 años atrás en mis inicios como tester… las ventanas siguen siendo independientes y estando sueltas por el escritorio… qué loco todo… xD) es una herramienta potente, eso sí.

  • Rest Assured sirve para simplificar la construcción de los test sobre una API REST.

Parece que utilizar REST ASSURED + Gherkin es una buena apuesta.

Performance is happiness (Almudena Vivanco)

Vamos a medir la satisfacción del usuario. Y con ello vamos a optimizar reduciendo el número de recursos críticos para acortar el critical path de nuestro producto.

A tener en cuenta: tiempo de respuesta, animation, idle y load.

Importante, conocer WebPagetest.org, que es free, no es una herramienta de carga, es para ver si tú como cliente te frustras o no con el producto. (Libro recomendado: WebPageTest) No es un Jmeter, no nos permite conocer el estado del servicio ni una auditoría de código. Es una herramienta de rendimiento a nivel de browser para analizar los tiempos de visualización y renderización para comprobar cuál es la experiencia de los usuarios.

Nos permite hacer emulación de dispositivos móviles y simulación de red. Hay que tener en cuenta la latencia a la hora de hacer las pruebas y así saber si tenemos que evitar la frustración miedos y estrés ciertos usuarios. Hacemos la prueba con nuestra web, flywire.com Desde Korea y China Te devuelve la “nota” de la prueba que ha hecho. Debemos intentar comprimir al máximo las imágenes que servimos, contenidos que sean estáticos etc (como comentan en el libro las 40 golden rules for performance)

Para nuestro test: Hace dos ejecuciones, una sin cache y otra con. El primer tiempo de carga del primer byte son 3 segundos. Estamos usando el keep alive, nos chiva que usamos gzip en los recursos, nos dice en qué podemos mejorar, sobre todo en esos dominios que no son nuestros, te genera un video de cómo se ha visto la web desde allí… vamos que está genial.

Tips:

  • Tenemos que tener en cuenta el front-end porque se ve muy afectado según el dispositivo que lo cargue.
  • Siempre hay que hacer el peor caso, el de todos los usuarios son nuevos
  • Hacer más veces el mismo test para comparar (con y sin cache)
  • Document complete vs onLoad
  • Evitar muchas conexiones porque consume recursos en el cliente, para evitar tener un SPOF (single point of failure, cuando dependemos de un tercero y lo tenemos en medio de nuestra carga, por lo que hay que ponerlos al final, puedes forzar un dominio a dar timeout) y bloqueos
  • Revisar cuánto tarda el código impuesto por analytics, clicks, hot jack…
  • Mirar en el waterfall del test cuántos Kb tiene el html inicial, en qué segundo comienza el evento render, cuántos socket connections hay hacia un host concreto…

Ahora entramos nosotros como testers para ver qué tenemos que medir. Podemos hacer comparaciones con la competencia y utilizar otras herramientas para ver qué podemos mejorar:

  • sitespeed.io
  • cssanalyzer.com
  • jscompress.com
  • compressor.io
  • unused-css.com

Conclusión

Estoy viendo que, a nivel local, la comunidad relacionada con el testing y con la calidad está creciendo y se hace eco cada vez más, eso sí, todavía veo que se cuentan historias que podrían haber sucedido hace perfectamente 10 años, vamos, que quedan empresas que no apuestan mucho por ella o que directamente se niegan e impiden que sus trabajadores la implanten como es debido.

Me gusta cómo ha crecido este ciclo de conferencias pero me gustaría aún más empezar a escuchar menos sobre esa lucha para implantar la calidad y más temas de nuevas prácticas y mecánicas de trabajo que nos hagan mejorar como profesionales.

En fin, no prometo volver pronto, pero sí prometo que lo intentaré 😂 ¡a cuidarse!

Read More

TestBash San Francisco 2018

![](http://emerrefe.github.io/qa-blog/images/TestBash_San_Francisco_2018_Best_Test_West_DOJO_EVENT_BANNER.png)Bueno bueno, os vengo a con...… Continue reading

TestNight JMeter 2018

Published on January 18, 2018

VLCTesting Valencia 2016

Published on November 11, 2016