Valencia AfterTest '19 - Resumen del evento

Hace unas semanas, tres de nuestros colaboradores, fueron a Valencia al After Test celebrado allí.

Los afortunados fueron Belén Montes, Jorge León y Estefanía Fernández Muñoz. Estuvieron repartidos por varias sesiones y nos traen un magnífico resumen de lo que allí se habló y de, lo que son, las nuevas tendencias de testing que hay en este momento.

Los damos las gracias por la colaboración, por el pedazo de resumen que han realizado y por el entusiasmo que le ponen a todo, ¡¡sois unos grandes #QALovers!!

Por un lado, Estefanía estuvo en las siguientes sesiones:



Isabel Evans - Track 2 - 11:45 - 13:15 | UX y testing de usabilidad. 'Shift left' para UX



La master class de Isabel fue bastante inspiradora en cuanto a cosas a tener en cuenta a la hora de probar un producto basándonos en el UX y en lo que va a pensar en usuario final sobre ella.

Isabel nos habló de varios puntos importantes: 


Conceptos:


  • ¿Qué significa para nosotros la calidad? Debíamos pensar qué es calidad para nosotros y compartir lo que pensábamos en grupo. ¿Cómo definimos calidad?, ¿Podemos dar algún ejemplo?, ¿Está el grupo de personas con las que has hablado de acuerdo contigo?

  • ¿Qué es la experiencia de usuario?, ¿Que pensamos que es? Cómo la pregunta anterior la comentamos en voz alta. Tenemos que tener en cuenta que UX no es solo la interfaz y la usabilidad, que hay muchas cosas más.

  • Calidad al usar un producto: ¿Cómo medimos eso?, ¿Cómo probamos eso? Debemos tener en cuenta que para probar algo tenemos que verlo no sólo con la cabeza, sino con el corazón y el alma.




Introducción a los procesos de UX:


  • ¿Cómo sabemos qué personas van a usar el producto y cuál es su contexto? Tenemos que identificar QUIÉN lo va a usar, POR QUÉ, PARA QUÉ lo va a utilizar e identificar sus emociones.

  • ¿Cómo identificamos atributos de calidad? Tenemos varias capas: las capas de UX, la de calidad en el uso y la de calidad del producto.

  • ¿Cómo definimos las US y los criterios de aceptación para el UX? Tenemos que escribir historias ricas (Rich Stories) con detalles, específicas, contractuales, simples...

  • ¿Cómo hacemos unas buenas iteraciones en el diseño? Mediante la empatía y experimentando. Nos preguntaremos: ¿quién? ¿Por qué? ¿Dónde? ¿Cuándo? ¿Cómo? Para dar respuesta a estas preguntas.

  • ¿Cómo hacemos una review de UX y tomamos en cuenta las observaciones? Mediante prototipos y test de usabilidad.


Fue una clase muy inspiradora y más filosófica de lo que esperaba, pero me sirvió mucho para mejorar los conceptos que tenía sobre UX y aplicarlos en mi día a día en pruebas.

Seretta Gamba - Track 2 - 14:30-16:00 | Automatización de prueba. Lecciones para los automatizadores de pruebas

Para mi la master class de Seretta fue una de las más interesantes de todo el evento. La clase que impartió se centró en lecciones y buenas prácticas para las personas que se dedican (o nos dedicamos) a automatizar pruebas, sobre todo centrándonos en dos partes:

•    Problemas más habituales que se tienen a la hora de automatizar pruebas.
•    Formas o enfoques para solucionar estos problemas.

Para ilustrar todo esto utilizamos una wiki que ha desarrollado Seretta junto a Dorothy Graham y donde se recogen todos estos patrones y enfoques. La URL de la wiki es: https://testautomationpatterns.org/wiki/index.php/Main_Page.

En la master class, Seretta nos hizo hacer algunos ejercicios para entender cómo utilizar esta wiki:

Ejercicio 1:

Vimos el ejemplo de Nancy Naive: https://testautomationpatterns.org/wiki/index.php/Nancy_Naive

El caso que se expone es el siguiente:

•    Nancy es una persona que no ha realizado automatización anteriormente.
•    Su empresa compra una herramienta para la automatización de pruebas (de la que tiene una demo) y que principalmente se basa en grabar acciones y auto-genera test automáticos.
•    Mediante esta herramienta, Nancy tiene que automatizar toda la suite manual de regresión que tiene actualmente.
•    Después de la demo comienza a grabar test y la primera ejecución funcionan perfectamente.
•    En las siguientes ejecuciones se da cuenta de que, al introducir nuevos desarrollos, los test que ya tenía grabados no le funcionan y tarda más en volver a grabar de nuevo los casos de prueba para pasarlos de forma automática que hacerlo manualmente.
•    Para analizar el problema de Nancy, debemos ir al Test Automatizo Issues Mind Map: (https://testautomationpatterns.org/wiki/index.php/Test_Automation_Issues_Mind_Map) y enumerar los que encontramos y que se puedan ajustar a este caso.

Algunos de los problemas que podemos encontrar son:

•    Execution issues: flaky test, inefficient execution.
•    Design issues: brittle scripts.
•    Management issues: inadequate support, inadequate team, limited experience, no previous test automation. 



Ejercicio 2:

Vimos el ejemplo de Ursula Unfocused: https://testautomationpatterns.org/wiki/index.php/Ursula_Unfocused

El caso que se expone es el siguiente:



  • Úrsula ha empezado a automatizar recientemente.

  • Tiene background de desarrollador a con lo cual está muy contenta de empezar.

  • Está utilizando buenos principios de automatización para crear la base del proyecto de pruebas automatizadas.

  • Tiene problemas en decidir qué test debe automatizar.

  • Empezó automatizando aquellos que se ejecutaban más, y algunos smokes.

  • Después comenzó a hacer test que le resultaban fáciles y le hacían avanzar de forma rápida.

  • Después de pasar un tiempo automatizando y mejorando la suite automática, ha tenido quejas de que hay partes importantes de la aplicación sin test automáticos y deben seguir ejecutando muchas pruebas manuales.

  • Para analizar el problema de Ursula tenemos que ir al Test Automation Patterns Mind Map (https://testautomationpatterns.org/wiki/index.php/Test_Automation_Patterns_Mind_Map) y enumerar los que encontramos y que se pueden ajustar a este caso.


Algunos de los patrones que podemos encontrar son:

•    Design: Abstraction levels, automate good test.
•    Process: ask for help, automate what’s needed, good programming practices, lazy automator, learn from mistakes.
•    Management: mix approaches, prefer familiar solutions, set clear goals.

Ejercicio 3:

Vimos el ejemplo de Iván Indispensible: https://testautomationpatterns.org/wiki/index.php/Ivan_Indispensible

El caso que se expone es el siguiente:

•    Iván es un arquitecto de test que ha creado el proyecto de automatización de pruebas de su empresa actual.
•    El proyecto está bien estructurado (ya que Iván tiene background de desarrollador) y no tiene casi duplicación.
•    Los scripts están bien estructurados y diseñados para ejecutar las pruebas de la forma más eficiente.
•    La automatización de pruebas es un éxito en la empresa y cada día hay más automatización.
•    La empresa de Iván se ha unificado con otra y ésta quiere aplicar el mismo principio de automatización que ha hecho Iván en su organización.
•    La nueva compañía ha asignado a Ramesh a realizar este proceso.
•    El problema es que Iván no ha documentado nada de todo el proceso que ha seguido y Ramesh está teniendo problemas para arrancar y comprender todo lo que hay montado.
•    Iván considera que documentar todo este proceso era una pérdida de tiempo porque él era la única persona que automatiza, pero ahora que Ramesh se ha unido piensa que quizás debería haber hecho las cosas de una forma diferente.
•    Para analizar el problema de Iván iremos a Diagnostic (https://testautomationpatterns.org/wiki/index.php/Diagnostic) y veremos qué diagnóstico le daremos al problema de Iván.

Alguno de los diagnósticos que pensamos para Iván son:

•    ¿Está Iván poco satisfecho con su automatización actual? En la parte de funcionalidad no porque él lo ha estructurado bien, pero a la hora de explicarlo a alguien nuevo está bastante descontento con cómo lo ha gestionado.
•    ¿Ha empezado hace poco el proceso de automatización? No, y ahora tienen que volver atrás y documentar el proceso para ayudar a Ramesh a entenderlo y aplicarlo.
•    ¿Te has unido a un equipo de automatización sin experiencia? En este caso Ramesh se ha unido a un equipo con experiencia, pero él no la tiene.
•    ¿Conoces ya cuáles son tus problemas? No, Iván los empezó a conocer cuando llegó Ramesh, hasta entonces pensaba que su solución era inmejorable.

Después de estos ejercicios Seretta siguió explicando las técnicas que están en la wiki más detalladamente y para terminar hizo un sorteo de su libro: “A Journey throught Test Automation Patterns” (https://www.amazon.com/Journey-through-Test-Automation-Patterns/dp/1727504887)

Fue una de las master class que más me gustó y de la que más disfruté, de hecho al final de la clase me quedé hablando con Seretta haciéndole varias preguntas sobre todo lo que había hablado. Sin duda, repetiré en alguna de las que dé.

Por otro lado, Jorge, estuvo en las siguientes sesiones:



Track 3_ES-Testing en el siglo XXI
Ponente: Alex Soto


 
De las Master Class más interesantes de la Test Academy de Valencia.
Alex Soto nos desmitificó un tema tabú en el testing, las pruebas en producción.
Todos sabemos que lo ideal en el mundo QA, es probar en un entorno lo más parecido al que van a utilizar los usuarios finales y que mejor que hacer dichas pruebas en el propio entorno productivo.







Nos explicó la metodología de trabajo para poder probar en este entorno, ir liberando releases para que sean testadas solo por ciertos usuarios en nodos concretos.
Esta redirección del tráfico se realizaría con la herramienta ISTIO:
https://istio.io/

Esta sería una pirámide tipo



Nos explicó terminología muy de modo actualmente como Canary release, chaos testing, Blue/Green Deployment o Shadowing Traffic.

Esta metodología de trabajo la usan grandes empresas como Facebook, Google o Netflix



Track 4_ES-API REST testing – Automatización e integración continua
Ponente: Rodrigo Jiménez



Master Class muy interesante en la que Rodrigo nos explicó su metodología de trabajo y herramientas utilizadas para realizar pruebas sobre Apis.
Lo mejor de todo, con un alto de porcentaje de herramienta open source y conocidas por tod@s:



•    Jenkins
•    Jmeter
•    Testlink
•    Jira



Si, si, habéis leído bien Jmeter para realizar pruebas funcionales de API.
Gracias a unos scripts de integración realizados en Python consigue relacionar todas estas herramientas en el proceso de integración continua de su empresa.



El flujo sería:



•    Definición de pruebas en Testlink con campos personalizados.
•    Desarrollo de los test en Jmeter con una nomenclatura especial para poder enlazarlos con los casos de prueba de Testlink.
•    En Jenkins se ejecutan las pruebas.
•    Con scripts desarrollados por el mismo en Python consigue que los resultados de las pruebas de Jmeter se generen en formato Tap. Esto hace que los resultados se vean de forma más claro que los que se obtienen por defecto en Jmeter
•    Gracias a los plugin de Jenkins y a otros scripts en Python consigue:







  • Obtener unos resultados muy limpios y claros de las pruebas

  • Que dichos resultados se vuelquen a Testlink.

  • Y que si existen pruebas falladas automáticamente se creen defectos en Jira.





Y para finalizar, Belén estuvo en las siguientes:



Albert Tort - Track 1 - 09:50 - 11:20 | Inteligencia artificial. Bots, spiders y modelos cognitivos: Las claves de la automatización en el testing con inteligencia artificial


Con esta Master Class, dio comienzo el Track en español del Test Academy de Valencia.

Durante este Track, se trataron conceptos como “Narrow AI”, donde se busca que la máquina sea buena en una tarea concreta, y “General AI”, que engloba aquella que pretende emular la gran mayoría de las capacidades humanas.

Respecto a Bots, spiders y modelos cognitivos, Albert Tort mostró por qué era necesario incluir estas herramientas en nuestro día a día.
Uno de los ejemplos fue hacer buscar a los asistentes un enlace roto en una página web. Estos, tardaron una media de un minuto o minuto y medio en encontrar alguno tras haber revisado 12-14 enlaces mientras que un spider, en ese mismo tiempo, fue capaz de analizar decenas de enlaces y reportar todos aquellos que no se encontraban operativos.

Albert Tort presentó un tema a la orden del día, haciendo partícipes a los testers reunidos del avance de la tecnología y el testing en este sector, a la vez que captó la atención de todos los asistentes con encuestas que mostraban resultados en vivo y lo difícil que puede ser tomar una decisión para una IA y también para las personas.

Tanja Vos - Track 2 - 11:45 - 13:15 | Pruebas visuales. TESTAR, ¡deja que la herramienta aprenda cómo probarlo!

Tanja Vos, profesora asociada en la Universidad Politécnica de Valencia, centró su Master Class en el testing de la Interfaz Gráfica de Usuario (GUI).

Comenzó poniendo en valor el GUI testing. Mostró la importancia de comprobar desde la Interfaz de un programa de ofimática hasta la Interfaz de máquinas tan delicadas como un monitor de constantes vitales en un hospital.

Tras esto, mostró la cantidad de casuísticas a tener en cuenta a la hora de realizar GUI testing y formuló la pregunta “¿Por qué no enseño a una máquina a hacerlo?”
Con esta premisa, presentó la herramienta TESTAR (https://testar.org/) que permite realizar GUI testing en aplicaciones de escritorio, web y móvil.
Es una herramienta de interfaz sencilla y bastante intuitiva que tiene unas cuantas acciones configuradas pero que, al ser de código abierto, permite adaptarla a las necesidades que se tenga en cada proyecto.

Actualmente, la versión de escritorio está más desarrollada, debido a las necesidades que tienen por parte de uno de los clientes, y buscan crear una comunidad que vaya alimentando esta herramienta.
Además, Tanja comentó que estaría encantada de ayudar a cualquiera que quisiese colaborar en el desarrollo de la herramienta facilitando su número de teléfono (690 917 971) para cualquier consulta.

Personalmente, esta Master Class me fascinó por el abanico de posibilidades que puede ofrecer la herramienta con una pequeña inversión de tiempo en la parte de aplicaciones móviles.

0 Comentarios