ENTREVISTA A JOSÉ VICENTE FAYOS, ANALISTA QA EN MINDDEN

«El diálogo es fundamental para el éxito en el desarrollo», José Vicente Fayos

21 julio 2023

¿Cuál es la función de un departamento de QA (Quality Assurance) y por qué es necesario incluirlo en un proyecto?

Todos hemos visto alguna vez por televisión o Internet a los muñecos dummies dentro de un coche chocando contra un obstáculo para verificar si saltan los airbags, o más recientemente, a laboratorios haciendo pruebas antes de sacar un medicamento o vacuna para frenar la Covid. Estos son dos ejemplos de tareas dentro de un departamento de QA, en las que se engloban muchas más, como el conocimiento del producto, la definición de test, la ejecución, el análisis, la automatización, el reporte, etc. En definitiva, son todas las actividades encaminadas para asegurar la fiabilidad y la calidad de un producto.

Si pensamos en las aplicaciones que usamos día a día para comprar algún producto, encargar comida, buscar un inmueble, consultar las redes sociales, hacer alguna gestión bancaria,… nos daremos cuenta que, siempre que podamos elegir, nos decantamos por la aplicación más fiable, segura y usable. Esto te hace diferenciarte de tu competidor al ofrecer fiabilidad en el uso del producto. En todas las aplicaciones o productos de éxito, hay un departamento de QA detrás encargado de anticipar y revisar que el producto sea satisfactorio y no presente errores para el usuario final.

 

En tu opinión, ¿cuál es el principal beneficio de tener un departamento de QA en una empresa? ¿Cómo contribuye al éxito general del producto o servicio?

Bajo mi punto de vista, la principal utilidad es la anticipación de futuros errores que, de darse en las últimas fases de producción, tendrían un coste monetario y reputacional mucho más grande que si se detectan en las fases iniciales.

La manera en que contribuimos un departamento de QA al éxito es, una vez se ha hecho un ejercicio de análisis del producto, aseguramos al máximo que todos los caminos y posibilidades que puedan impedir, dificultar o causar algún tipo de molestia al usuario final, queden detectadas y corregidas tan pronto como sea posible.

 

¿Cuáles son las principales responsabilidades de un ingeniero QA?

La definición clásica es que nos encargamos de planificar, diseñar, ejecutar, reportar todos los errores que se detectan en un producto, aunque personalmente, me gusta ir un poco más allá dentro de estas tareas. Me explico, en la fase de planificación, intentamos entender y dar nuestro punto vista a cualquier funcionalidad/tarea a nivel de caso de uso. En el diseño de pruebas, siempre en la medida de lo posible, ir un poco más allá de lo que está definido, probando algo que esté relacionado con lo que se está desarrollando. Además, si estamos en metodologías ágiles junto al Scrum Master, podemos ser las personas que se encarguen de dotar métodos verificables de calidad para que cada fase del desarrollo se cumpla de manera exitosa.

En definitiva, la principal responsabilidad es la de tener un rol protagonista dentro del flujo de desarrollo para purificar el producto y su implementación en producción.

 

¿Cómo sería un día habitual en tu puesto de trabajo? ¿Cuáles son las técnicas de pruebas de rendimiento que más pones en práctica?

En un día normal, lo que hacemos un equipo QA es entender las necesidades de aquellas funcionalidades que se va a implementar para diseñar todos los caminos posibles y verificar que todos los flujos quedan definidos en uno o varios casos de pruebas. Posteriormente, se ejecutan dichas pruebas y se reportan los errores encontrados con la persona que los ha desarrollado para que sean depurados. Además, aquellos casos de prueba que consideramos que están dentro del flujo principal, los seleccionamos para ser automatizados e incluidos dentro de las pruebas de regresión que se ejecutan antes de desplegar en producción. A estas funciones siempre se le añaden tareas para organizar prioridades de pruebas, implementación de la validación de la calidad del código, estimación de las tareas de QA dentro de las historias, validación de versiones de los microservicios o aplicaciones para ser desplegadas en producción, etc.

En cuanto a las pruebas de rendimiento, hacemos un estudio de aquellas funcionalidades que son sensibles a ser exigidas a nivel de número de usuarios, peticiones concurrentes o descargas simultaneas por tamaño archivo para, posteriormente, hacer un script que simule todas estas tareas. Una vez el script esta implementado, ejecutamos las pruebas que se estimen apropiadas. Las pruebas más comunes son las de simular una situación de un día normal de trabajo, simular un pico de trabajo muy alto para ver cómo lo gestiona el sistema, encontrar los límites de la aplicación para encontrar un punto de ruptura, revisar cómo afecta un cambio de tecnología a una funcionalidad, o bien, la del disaster recovery, que son las pruebas en las que se cae todo el sistema y verificamos cómo y de qué manera se recupera.

 

«Las atribuciones de un QA (…) no son solamente las de ejecutar, sino las de estimar, priorizar, diseñar y automatizar las pruebas. Es la persona encargada de la calidad del producto en todos los niveles del desarrollo.»

«Garantía de calidad es lo bueno que un producto es; y garantía de seguridad es lo poco expuesto que está ese mismo producto a ataques de seguridad.»

 

¿Qué diferencia un QA de un tester? ¿Y cuál es la diferencia entre la garantía de calidad y la garantía de seguridad del software?

La diferencia entre QA y tester es que un tester, que literalmente en castellano es probador, es justamente eso, una persona dedicada solo a probar y redactar los errores. Las atribuciones de un QA son más amplias, ya que no son solamente las de ejecutar, sino las de estimar, priorizar, diseñar y automatizar las pruebas.

Como hemos comentado antes, es la persona encargada de la calidad del producto en todos los niveles del desarrollo.

Respecto a la segunda pregunta, podemos considerar que garantía de calidad es lo bueno que un producto es; y garantía de seguridad es lo poco expuesto que está ese mismo producto a ataques de seguridad. En ambos casos, es imprescindible tener un buen plan de pruebas para cubrir los estándares de calidad definidos en cada equipo.

 

¿A qué retos de garantía de calidad te sueles enfrentar habitualmente? ¿Y cómo afrontas los imprevistos?

En la actualidad, cada día hay más herramientas que son implementadas en los productos de software, esto provoca que tengamos que estar en constante actualización para poder conocer, manejar y ejecutar las pruebas. Desde QA, la colaboración con los compañeros de desarrollo es constante porque son ellos quienes conocen y nos ayudan a implementar estas herramientas para garantizar la correcta ejecución de las pruebas.

Respecto a los imprevistos, la flexibilidad y el diálogo es la clave para sortearlos porque, por ejemplo, algunas veces pasa que al estudiar una funcionalidad se diseñan unos casos de pruebas que al ejecutarlos no tienen sentido y, tras unas consultas, te das cuenta que no aportan al conjunto final. También sucede al revés, que algo tenga mayor impacto al previsto inicialmente. En este caso lo que hacemos es reforzar las pruebas para asegurar esa parte.

 

¿Qué metodologías o enfoques de aseguramiento de calidad prefieres utilizar en tus proyectos?

En mi vida laboral, he trabajado tanto en waterfall como en metodologías ágiles y son dos caminos diferentes para un mismo fin. En estos últimos años, estamos trabajando en Agile y, desde mi punto de vista, es la manera más efectiva de llegar a ese fin. En esta metodología, el departamento QA es una parte integrada desde el minuto cero en el equipo de desarrollo y planificación. Esto hace que entendamos la necesidad del usuario, la implementación requerida y los flujos principales de aquello que se desarrolla. En cambio, en waterfall, el departamento de QA es una fase separada del desarrollo que no se acopla a las fases iniciales de un producto.

En cuanto a la metodología Agile, también es importante saber separar el esfuerzo en el desarrollo de una funcionalidad, del esfuerzo que se debe invertir en las pruebas de esa misma funcionalidad. Es decir, cabe la posibilidad de que implementar una funcionalidad sea añadir solamente unas pocas líneas de código, pero que eso implica diseñar y ejecutar un número elevado de pruebas. También, puede suceder el caso contrario. Por lo que hay que saber mantener la perspectiva de QA al margen del esfuerzo de desarrollo.

¿Por qué crees que son efectivos?

Como comentaba en la respuesta anterior, para mí el diálogo es fundamental para el éxito en el desarrollo. Cuando se comparten inquietudes o en la confrontación de ideas, se unifican criterios y se logra consensuar un camino para lograr la efectividad del producto y la satisfacción del usuario final. 

 

¿Cómo te aseguras mantener un equilibrio entre la eficiencia y la calidad en tu trabajo? ¿Has tenido que tomar decisiones difíciles en este sentido?

Como QA es básico plantear unas pruebas que, conociendo el alcance de la funcionalidad, te dejen tranquilo una vez las hayas validado. Por lo que es importante mantener ese equilibrio entre la confianza de las pruebas validadas y el contexto de la funcionalidad requerida con el tiempo disponible. Para lograr este punto, en ocasiones es posible simultanear pruebas, ya que en algunas pruebas se necesita que pasen ciertos procesos que tardan horas, o bien, encuentras errores bloqueantes en los que su resolución no va a ser inmediata.

En cuanto a las decisiones difíciles, ¡por supuesto que hemos tenido que tomar decisiones complicadas! Como por ejemplo: mantener un no-OK a pesar de las presiones para desplegar en producción o revisar cierta aplicación donde había habido un refactoring y no funcionaba nada. En todas estas situaciones, es importante siempre no perder la perspectiva y mantener tu criterio como QA, conservando siempre el buen talante y la búsqueda de soluciones efectivas.

 

Sabemos que la automatización es una parte importante del QA. ¿Cuáles son algunas de las herramientas de automatización que utilizáis? ¿Cuáles son sus ventajas y desventajas?

Algunas de las herramientas más populares dentro de la automatización son: Cypress, Selenium, Jmeter, Postman, Newman, Ranorex,… Hay una gran cantidad de ellas, por lo que es importante invertir tiempo en un estudio previo para seleccionar la herramienta de automatización que mejor se adapte a las características del producto que quieras probar.

Las ventajas de automatizar ganan por goleada a las desventajas. En el lado positivo, sería la reducción de tiempos en ejecutar casos de pruebas repetitivos y complejos de manera desasistida, facilitando la detección de errores y el despliegue de software. Esto genera una reducción de costes y agiliza la mejora de un producto. En la parte no tan positiva, podemos considerar que la inversión de tiempo inicialmente es superior a la de las pruebas manuales. Este tiempo se ve compensado cuando se integran esos casos de prueba en la automatización y queda ejecutado de manera no asistida más de una vez.

 

Cuéntame sobre un proyecto o producto en el que hayas trabajado y cómo tu aportación de QA contribuyó a su éxito o mejora.

Hay muchos ejemplos porque en mi vida laboral he probado desde documentos de texto, call centers, apps. para móviles, aplicaciones webs y de escritorio, caídas de sistemas enteros, API’s,… hasta microservicios, es decir, casi todo lo que sea software.

Alguno de los ejemplos más claros es cuando en una aplicativo se está decidiendo si se cambia de una tecnología a otra y lo que se hace es ejecutar una prueba de carga antes y después de desplegarse para verificar si ha habido una mejora o no en términos de rendimiento.

Otro ejemplo es que en un aplicativo que se usa para hacer “login” dentro de otro sistema, verificamos el número máximo de usuarios que puede acceder simultáneamente.

A nivel exclusivamente funcional, el actual proyecto donde estoy colaborando se ha vuelto a hacer de cero y, hoy en día, presenta muchas más funcionalidades, visualmente es más atractivo, presenta un número elevado de mejoras y, sobre todo, aquí está la parte que nos atañe exclusivamente a los QA, tiene una alta eficiencia funcional.

 

¿Consideras que el trabajo en equipo es fundamental para llevar a cabo las funciones? ¿Qué medidas tomas para garantizar que el equipo de desarrollo y otros departamentos comprendan la importancia de la calidad y cumplan con los estándares establecidos?

Desde mi punto de vista, es la base del éxito en cualquier actividad ya sea laboral o no. La frase que dijo en su día Alfredo di Stefano, “ningún jugador es tan bueno como todos juntos” me parece que lo resume bastante bien y se puede aplicar a los equipos de software.

Por esto, la comunicación cara a cara en tiempos del trabajo en remoto exige usar numerosas herramientas que faciliten la comunicación directa e inmediata. Es la manera más efectiva de dialogar, contrastar posturas y llegar a acuerdos para establecer los estándares dentro de un equipo. También lo es para empatizar y conseguir una relación agradable y cercana con los compañeros. No olvidemos que en el trabajo estás muchas horas al día y es importante tener un ambiente fluido, positivo y agradable.

 

¿Cómo te mantienes al tanto de las últimas tendencias y avances en el campo de la aseguración de calidad? ¿Hay alguna fuente de información o comunidad en línea que encuentres especialmente útil? 

La verdad que trabajar en un equipo tan dinámico de desarrollo hace que estés en constante actualización de herramientas y utilidades que se pueden aplicar a las pruebas de software.

Lo que hacemos es, entre compañeros de equipo y compañeros QA’s de diferentes equipos, organizar reuniones para ponernos al día de las diferentes herramientas que van surgiendo, así como pequeños trainings para saber cómo poder utilizarlas.

Por ejemplo, en la reunión más reciente, hemos abordado cómo poder utilizar una IA como ChatGPT para implementar casi cualquier tipo de test.

 

Como profesional con experiencia en este campo, ¿qué aconsejarías a los jóvenes que están interesados en ser ingeniero QA?

La mayoría de los compañeros QA con los que he colaborado en mi vida laboral han sido previamente programadores de software o tenían conocimientos de programación. Esto te ayuda a tener una visión un poco más global de las funcionalidades y facilita la implementación de los casos manuales a automáticos. Por lo que, bajo mi punto de vista, no es necesario haber tenido experiencia programando, pero sí es muy aconsejable.

Me gustaría animar a la gente joven para que se decida a ser QA, ya que es una profesión que te posiciona en un lugar dentro del equipo de desarrollo donde puedes tener una visión tan técnica como de negocio. Por este motivo, te permite un desarrollo muy amplio de tus capacidades, ya sea orientándote a un nivel más técnico o a un nivel más de gestión.

Mi experiencia: yo empecé casi por casualidad y he aprendido tanto como he querido, llevando mi carrera laboral a donde he querido en función de mis prioridades. Por lo que, si te gusta un poco enterarte de todo, eres de los que te gusta comunicar y disfrutas depurando errores, ¡esta puede ser sin duda la profesión que te haga feliz!