Nuestro segundo QATalks, es para Aurelio Gandarillas, una eminencia en el mundo del testing y la calidad del software.
Actualmente es Quality Expert en MTP y fue ganador de la mejor ponencia de ExpoQA 2018.
Para nosotr@s es un grandísimo honor el poder haber realizado esta entrevista a Aurelio, para QA Lovers Community. Desde aquí, le damos las gracias y esperamos que sea la primera colaboración de muchas.
1. A lo largo de tu extensa carrera, ¿cómo ha cambiado el panorama de testing y QA hasta actualmente?
Hay dos factores que han marcado la diferencia en la evolución del testing en los últimos años, el primero es la automatización y el segundo la especialización del tester.
Es curioso como existiendo las técnicas del testing desde hace más de 40 años ha sido en los últimos 10 años cuando ha habido una gran evolución del testing en España.
En los años 80 y 90 no existía conciencia por las técnicas y la estrategia de prueba, al menos en el entorno del desarrollo que yo conocía. Se desarrollaba el software y se hacían pruebas funcionales basadas en la experiencia de cada persona, equipo o empresa. En esos tiempos no existía el rol del tester y era el equipo de desarrollo era quien pensaba y diseñaba las pruebas. También eran tiempos donde el software tenía una tecnología más simple y una utilización más limitada. Los productos tenían ciclos de vida de años y se trabajaba con la calidad en el largo plazo. Obviamente no es la situación que conocemos como adecuada, pero el mercado permitía desarrollar así.
Para mí la aparición del rol del tester ha sido en el siglo 21 concretamente en los últimos 15 años, aunque fuera de España quizás se tuvo convivencia de la necesidad de este rol mucho antes, en la segunda mitad de los años 90. En esa segunda mitad de los años 90, aparecen referencias, publicaciones, estándares como ISTQB, paradigmas como la orientación a objetos y marcos de referencia como Extreme Programming o TDD. Todas ellas con lo que considero un denominador común, desarrollar software que tenga viabilidad económica para ser probado. Es decir, se tomaba conciencia de la importancia del testing en un desarrollo software como mecanismo para asegurar que el software aportaba valor al negocio que lo usa y no le causa problemas.
Pero el siglo 21, y concretamente en los 10 últimos años, el software tiene una relevancia extremadamente alta e incluso su presencia es crítica para los negocios. Hay empresas que son lo que son, por que existe un software que las hace viables. El impacto del software en nuestra sociedad actual es sencillamente demoledor. Hoy podemos realizar infinidad de gestiones desde cualquier lugar del mundo y realizar actividades que hace pocos años eran sencillamente inimaginables sin determinadas aplicaciones.
Pero precisamente ese incremento exponencial de la dependencia del software que afecta a personas, empresas y sociedad debe alertarnos de la necesidad de valorar qué efectos tiene un software que funciona mal y cómo podemos evitar el daño producido. Ya no estamos hablando de la incomodidad de un programa que nos deja "tirados". Estamos hablando de la continuidad de los negocios, así como el bienestar y la integridad de las personas.
Este es el área que yo considero como central en el rol del tester profesional.
A pesar de este evolución del software he conocido muchos proyectos de hace menos de 15 años donde no existía el rol del tester ni se le consideraba necesario. Incluso en algunas ocasiones se veía como una actividad temporal y mínima dentro del proyecto de desarrollo
En estos días y debido principalmente a la facilidad de comunicación, la existencia de eventos y comunidades como la de QAlovers, creo que se tiene mejor conciencia del rol del tester. Es raro que existan proyectos de desarrollo software donde el tester no esté desde el inicio de manera permanente. Pero aún se necesitan más y mayores cambios en el testing.
2. Creo que tienes una visión diferente de lo que es QA o Quality Assurance en el mundo de la calidad software ¿me lo podrías explicar?
Esta idea viene de mis primeros estudios universitarios como Ingeniero Industrial en Electrónica en los años 80 y que está fuertemente reforzada por la actividad que realizo en MTP, la empresa para la que trabajo desde hace 15 años, así como de los contenidos de estándares y certificaciones en materia de Testing y Calidad de Software
Para mí, existen tres grandes áreas de actividad en materia de Calidad:
3. A día de hoy, a nivel “acogida” de perfiles de testing en las empresas ¿lo ves mejor o seguimos estancados en el pasado?Creo que el nivel de acogida del tester dentro de los proyectos y la de las empresas ha mejorado significativamente en los últimos años. Recuerdo tiempos donde el tester se veía como algo molesto e incluso como una actividad no deseada. Queda algún "reducto" donde ocurre, pero, por suerte, es algo anecdótico.
Hoy en día prácticamente ninguna empresa con un proyecto de desarrollo de producto y sobre todo desarrollo software se plantea un equipo sin que existan la actividad de testing.
También detecto un incremento en la madurez de los proyectos, donde se está sustituyendo el clásico "lo pruebo al final", por una actividad de testing mucho más integrada con el desarrollo y aplicada en todo el ciclo de vida de desarrollo software. esto ha sido un cambio fundamental en los últimos 10 o 15 años, pero en lo que hay mucho trabajo por delante, según me cuentan mis alumnos :-)
También la percepción del rol del tester ha cambiado y yo creo que principalmente en los últimos 5 o 6 años. Al inicio del milenio, el tester era más reactivo y su actividad principal la realizaba al final de la construcción del producto principalmente de manera manual.
Hoy en día la labor del tester está progresivamente cambiando hacia la prevención, es decir el tester aparece al principio del proyecto con el foco de prevenir tanto como sea posible la inyección de defectos durante el proceso y de detectarlos lo antes posible. Sin embargo, a mi modo de ver, este cambio es mucho más lento de lo que el desarrollo software actual necesita.
La aplicación de enfoques de desarrollo agile y la automatización, están provocando que el tester se incorpore como uno más del equipo de desarrollo, aunque queda mucho trabajo por realizar para llegar al objetivo de que sea habitual que el tester esté equiparado al resto del equipo de desarrollo.
4. Como Quality Expert en MTP, ¿cómo ves el futuro próximo en la compañía?, ¿Qué tecnologías se asentarán y se usarán en los proyectos?
Bueno se habla mucho del futuro del testing sobre todo en conferencias, seminarios y artículos, pero creo que antes de hablar de ese futuro deberíamos terminar de afianzar nuestro presente. Hoy siguen existiendo proyectos donde el software y las pruebas siguen atascados en modelos con rentabilidad inadecuada.
Una de estas ideas que considero que deben cambiar es que aun se piensa que las pruebas es cosa sólo para los testers. El testing es responsabilidad de todo el equipo y el desarrollador es uno de los roles que más testing deben hacer. También el negocio debe implicarse en el testing y en la calidad software, obviamente contará con el apoyo de los especialistas, pero la calidad del producto es un problema del negocio.
También me gustaría que, en un futuro muy cercano, el equipo de desarrollo vea el testing como una fabulosa herramienta para que el desarrollador crezca profesionalmente y mejore su productividad. Es habitual en algunos equipos desarrollo pensar que el testing es un freno, una pérdida de tiempo, cuando en realidad se ha demostrado que una buena arquitectura de software y una buena estrategia de este testing son los mejores aceleradores del ciclo de desarrollo software. ¿cómo demostrar esto? muy sencillo, solo hay que analizar propuestas como scrum, enfoques agiles, Extreme Programming o TDD. Sin embargo, el testing para desarrolladores sería objeto posiblemente de otro debate y bastante largo así que ya tenemos materia para otra ocasión.
En cualquier caso y tratando de responder a tu pregunta, el futuro del testing pasa por una elevadísima automatización. No se trata solo de automatizar las pruebas, el diseño de los casos de prueba o incluso la estrategia de las pruebas. El tester va a tener que ser conocedor de todo tipo de herramientas y tecnologías de automatización de pruebas y del proceso de desarrollo porque van a formar parte de su día a día y debe incorporar dichas herramientas a su actividad.
Casi todos los tester, conocen lo que significa la automatización de pruebas, pero no todos conocen el testing basado en modelos o propuestas que donde los diseños de los casos de prueba vienen de especificaciones. Quizás algunos puedan conocer prácticas como BDD o Gherkin como lenguaje para automatizar casos de prueba partir de funcionalidades de negocio o del lenguaje natural. Pero este tipo de aplicaciones van a ir más allá y en el futuro existirán herramientas que permiten obtener los casos de prueba automatizados directamente de especificaciones modelos de negocio y de comportamientos del sistema. Estas herramientas aún están en proceso de creación y de optimización, pero el ritmo de crecimiento tecnológico es elevadísimo y posiblemente muy pocos años esto pase a ser nuestras herramientas.
Y por último en la automatización del proceso de desarrollo, bien por aplicación de propuestas como DevOps u otro tipo de propuestas que puedan aparecer en el en el futuro, van a generar unos procesos de construcción de Software donde la cantidad de datos generada va a ser increíble. Es decir, el proceso de desarrollo software va a tener su propio Big Data ahí es donde la inteligencia artificial, los sistemas expertos y las herramientas de análisis de datos van a poder ayudar al tester y a los responsables de calidad en los mecanismos para poder hacer las mejoras tanto del proceso como del producto. Probablemente el tester se convierta en lo que realmente debería ser, prevención de calidad (Quality Assurance) debido a todas estas mejoras.
Podría indicarte referencias de cómo en MTP, hace 10 o 15 años, hablábamos, aplicábamos algunas de estas propuestas. pero no hubo mercado suficientemente maduro para aplicarlas y quizás hoy en día el mercado tenga que madurar más para que ese posible futuro sea una realidad. Como decía al principio de esta pregunta, hay que tener la vista en el futuro, pero nuestro presente requiere aún de mucho trabajo.
5. ¿Soléis usar algún tipo de metodología en concreto o adaptáis según proyecto o cliente? ¿con cuál sientes que QA ha encajado mejor?
MTP ha apostado desde hace muchos años por las propuestas de ISTQB que ya tiene más de 20 años de vigencia y en los últimos 15 años por modelos de gobierno de la calidad como TMMi. En base a estas propuestas y nuestra experiencia damos cobertura a las tres áreas que he mencionado antes; QC, QA y QM.
Existen otros modelos, aunque no muchos más, pero yo creo que estas dos propuestas son claves en el mundo de la calidad software sobre todo cuando se hace un enfoque a la prevención
Nuestros modelos y servicios siempre han sido adaptables. Es imposible crear una propuesta metodológica, un proceso o una herramienta que sirva sin modificación para cualquier tipo de negocio, cualquier tipo de cliente, o incluso para cualquier tipo de proyecto. Si algo nos ha caracterizado ha sido la flexibilidad y la adaptabilidad.
Precisamente adaptabilidad es lo que yo considero como la adecuada traducción de la palabra inglesa Agile, tan vigente en la actualidad. Creo que la adaptabilidad ha caracterizado siempre MTP, por tanto, en mi opinión, pienso que MTP lleva 20 años siendo ágil, aunque quizás el mundo de la agilidad haya entrado con fuerza en los últimos 5 años en España.
En todos nuestros proyectos y clientes hay una fase inicial de diseño del servicio y en esa fase de diseño se analizan las necesidades, así como las casuísticas del cliente y del producto para ofrecer una adecuada estrategia de servicio en base a su mercado, su producto, su presupuesto y su nivel de madurez. Obviamente, esa adaptación es una actividad permanente durante todo el ciclo de vida del proyecto o del servicio.
Nuestra forma de trabajar está inspirada en muchas propuestas metodológicas, normas, buenas prácticas, enfoques, marcos de referencia. Digamos que creamos nuestro estilo, pero desde sólidas bases de conocimiento.
6. ¿Qué ramas o caminos, basados en la calidad, te gustan más? ¿eres de los que cacharrean a nivel más técnico o te gusta más la rama procedimental y de gestión?
¡Bueno a mí lo que más me gusta es no trabajar! Obviamente, es una broma…(risas).
Bueno para mí, el trabajo es una actividad que, si tuvieses la oportunidad, no harías pero que obviamente la desarrollas porque necesitas un medio de vida. Aquellas personas que pueden desarrollar una actividad que les apasiona, que les gusta y encima obtener ese medio de vida necesario, yo los considero auténticos afortunados.
Curiosamente en la profesión de testing es donde más personas me he encontrado con esta condición, gente que les apasiona su trabajo y que se consideran felices al realizarla.
En cuanto a lo que a mí me gusta, la verdad es que tengo la sensación de no he tenido una carrera profesional planifica, sino que han sido las circunstancias de los proyectos en los que he estado los que me han ido llevando a realizar todo tipo de actividades. Cada vez que ha aparecido una oportunidad interesante, he ido a por ella.
Creo que si tuviese que definir que es lo que más me gusta de mi profesión lo definiría con una palabra, crear. Realmente la creación o la realización de un producto, un proceso, una actividad, algo que antes no estaba hecho y que de alguna manera crea una innovación, un proceso o producto nuevo, es lo que más me atrae. La rutina, desde luego, es una de las cosas que peor llevo. Alguien podría pensar que con esta vocación es difícil poder trabajar en el mundo del testing. Pues creo que no.
Creo que la labor del tester, su labor principal, es innovar en pruebas. Quiero decir que se puede ser tester y estar continuamente creando casos de prueba, estrategias, desarrollando herramientas, automatizando, creando mecanismos de validación nuevos en el producto. Para mí realmente ese es el verdadero rol del tester, una combinación de estratega e innovación en casos de prueba, aunque por desgracia no es muy habitual esta actividad. Por tanto, veo muy difícil que aplicando lo que yo entiendo por tester uno pueda caer en la rutina o en el aburrimiento.
Otra actividad que me gusta realizar son el estudio y aplicación de metodologías, normas, marcos de referencia, buenas prácticas y, especialmente, los enfoques ágiles. Realmente muchas de las "novedades" que descubrimos actualmente llevan años, o incluso décadas, creadas. Lo que realmente veo que tiene un enorme valor es la forma tan sencilla, eficiente e incluso divertida de aplicarse en la actualidad. Es sencillamente apasionante analizar propuestas, ya veteranas como Scrum, o propuestas más actuales de escalado ágil, comparándolas con metodologías del siglo 20.
7. El año pasado, fuiste el ganador de la mejor ponencia en ExpoQA, a lo largo de todos estos años, ¿cómo has visto la evolución de los contenidos que se pueden ver los eventos? ¿estamos hacía caminos demasiado técnicos?
Respecto a los eventos, yo creo que miran hacia el futuro, hacia la innovación, hacia elementos nuevos, y es necesario, positivo y lógico que tengamos este tipo de visión a medio y largo plazo para que el mercado puede evolucionar.
Pero echo en falta más casos de éxito que marquen un camino real y útil a otros, así como casos de fracaso, es decir, errores que no deberíamos volver a cometer en el mundo del testing. No me gusta que el 100% de una presentación se centre en lo que una empresa es y en lo que puede ofrecer. Las presentaciones de hace 20 / 30 años eran de este segundo tipo, pero en la actualidad ya es muy habitual que pongan como condición para un evento hablar de experiencias útiles para otros.
Lo que me sorprende gratamente es que no solamente existe un evento de testing de manera anual. Existen varios eventos importantes en varias ciudades de España algunos de ellos de carácter internacional que en una de sus ediciones se ha celebrado en ciudades españolas. También me llama especialmente la atención como el colectivo de testers ha creado una comunidad con mayor crecimiento en madurez y tamaño, que en otros colectivos.
Sin embargo, el cambio que considero más significativo está en la evolución de las ponencias. Aunque se debería avanzar más, se pasado de ponencias centradas en las posibilidades de una compañía, a ponencias centradas en la aportación a un colectivo.
Otro aspecto interesante es el perfil y la media de edad de los ponentes. Me agrada ver cómo cada vez hay más profesionales que hablan de grandes experiencias en público con una edad relativamente joven.
Quizás, en unos años, desaparezca el típico formato de trasparencias y de comunicación unidireccional de un orador en pie hacia un público sentado. Parece algo difícil de imaginar, pero seguro que habrá cambios.
8. Para finalizar, ¿Vuelves a la carga este año en ExpoQA? ¿Puedes darnos un avance de lo que vas a tratar en tu ponencia?
Bueno eso de adelantar los secretos dicen que no es una buena práctica. Hay que guardarse unos cuantos ases en la manga. Intentaba ser una broma, pero es complejo trasmitir humor con un texto. Voy a tener que practicar más...(risas).
Puedo comentar lo que está publicado ahora mismo. Se trata de hablar de como la inteligencia artificial va a ayudar al tester. De hecho, creo que lo va a transformar.
La idea de la transformación digital la entiendo como ese cambio cultural y de mentalidad de las personas provocado porque ahora tenemos tecnologías que nos van a obligar a trabajar, pensar y realizar las tareas de otra manera. La tecnología no sólo nos permitirá hacer las mismas cosas de una manera más sencilla y rápida. Para mí el cambio fundamental es que hará innecesarias algunas de las tareas que hacemos actualmente y nos requerirá que hagamos otras nuevas. Esto puede dar un poco de vértigo, pero me temo que es imparable y la historia nos dice que con alta probabilidad es mejor para todos.
Vamos a una sociedad altamente tecnificada con ciclos de vida de productos y servicios cada vez más rápidos. Está alta tecnificación va a obligar al tester a una cualificación técnica muchísimo mayor de lo que estamos acostumbrados. Si la automatización de pruebas de alguna manera obligaba al tester a enfrentarse a la programación, la aplicación de un proceso de desarrollo software basado en DevOps le hace implicarse en los procesos de negocio y de desarrollo, en la tecnología, en la arquitectura y en la seguridad.
La inteligencia artificial realmente va a ser lo que decante al tester como estratega y profesional que previene los fallos. Esto no implica que debamos ser expertos en inteligencia artificial, sino asumir que formará parte de nuestra profesión. Por ejemplo, yo no sé construir una casa o un coche, pero soy perfectamente capaz de usarlos y saber sin son adecuados para mis necesidades. Muchas gracias.
Actualmente es Quality Expert en MTP y fue ganador de la mejor ponencia de ExpoQA 2018.
Para nosotr@s es un grandísimo honor el poder haber realizado esta entrevista a Aurelio, para QA Lovers Community. Desde aquí, le damos las gracias y esperamos que sea la primera colaboración de muchas.
1. A lo largo de tu extensa carrera, ¿cómo ha cambiado el panorama de testing y QA hasta actualmente?
Hay dos factores que han marcado la diferencia en la evolución del testing en los últimos años, el primero es la automatización y el segundo la especialización del tester.
Es curioso como existiendo las técnicas del testing desde hace más de 40 años ha sido en los últimos 10 años cuando ha habido una gran evolución del testing en España.
En los años 80 y 90 no existía conciencia por las técnicas y la estrategia de prueba, al menos en el entorno del desarrollo que yo conocía. Se desarrollaba el software y se hacían pruebas funcionales basadas en la experiencia de cada persona, equipo o empresa. En esos tiempos no existía el rol del tester y era el equipo de desarrollo era quien pensaba y diseñaba las pruebas. También eran tiempos donde el software tenía una tecnología más simple y una utilización más limitada. Los productos tenían ciclos de vida de años y se trabajaba con la calidad en el largo plazo. Obviamente no es la situación que conocemos como adecuada, pero el mercado permitía desarrollar así.
Para mí la aparición del rol del tester ha sido en el siglo 21 concretamente en los últimos 15 años, aunque fuera de España quizás se tuvo convivencia de la necesidad de este rol mucho antes, en la segunda mitad de los años 90. En esa segunda mitad de los años 90, aparecen referencias, publicaciones, estándares como ISTQB, paradigmas como la orientación a objetos y marcos de referencia como Extreme Programming o TDD. Todas ellas con lo que considero un denominador común, desarrollar software que tenga viabilidad económica para ser probado. Es decir, se tomaba conciencia de la importancia del testing en un desarrollo software como mecanismo para asegurar que el software aportaba valor al negocio que lo usa y no le causa problemas.
Pero el siglo 21, y concretamente en los 10 últimos años, el software tiene una relevancia extremadamente alta e incluso su presencia es crítica para los negocios. Hay empresas que son lo que son, por que existe un software que las hace viables. El impacto del software en nuestra sociedad actual es sencillamente demoledor. Hoy podemos realizar infinidad de gestiones desde cualquier lugar del mundo y realizar actividades que hace pocos años eran sencillamente inimaginables sin determinadas aplicaciones.
Pero precisamente ese incremento exponencial de la dependencia del software que afecta a personas, empresas y sociedad debe alertarnos de la necesidad de valorar qué efectos tiene un software que funciona mal y cómo podemos evitar el daño producido. Ya no estamos hablando de la incomodidad de un programa que nos deja "tirados". Estamos hablando de la continuidad de los negocios, así como el bienestar y la integridad de las personas.
Este es el área que yo considero como central en el rol del tester profesional.
A pesar de este evolución del software he conocido muchos proyectos de hace menos de 15 años donde no existía el rol del tester ni se le consideraba necesario. Incluso en algunas ocasiones se veía como una actividad temporal y mínima dentro del proyecto de desarrollo
En estos días y debido principalmente a la facilidad de comunicación, la existencia de eventos y comunidades como la de QAlovers, creo que se tiene mejor conciencia del rol del tester. Es raro que existan proyectos de desarrollo software donde el tester no esté desde el inicio de manera permanente. Pero aún se necesitan más y mayores cambios en el testing.
2. Creo que tienes una visión diferente de lo que es QA o Quality Assurance en el mundo de la calidad software ¿me lo podrías explicar?
Esta idea viene de mis primeros estudios universitarios como Ingeniero Industrial en Electrónica en los años 80 y que está fuertemente reforzada por la actividad que realizo en MTP, la empresa para la que trabajo desde hace 15 años, así como de los contenidos de estándares y certificaciones en materia de Testing y Calidad de Software
Para mí, existen tres grandes áreas de actividad en materia de Calidad:
- Detección del defecto o control de calidad (Quality Control / QC): El producto tiene una posible anomalía (error) y hay que tratar de evidenciarla, encontrarla y corregirla. Quizás, y de forma incorrecta, se asocia al tester sólo esta labor. En cualquier caso, lo fundamental de esta tarea es el testing temprano, es decir, que el tiempo entre la inyección del defecto y su detección sea lo antes posible (minutos o como mucho, horas).
- Prevención del defecto o aseguramiento de la calidad (Quality Assurance / QA): El defecto aún no se ha inyectado en el producto, pero se realizan tareas que minimizan que esto ocurra. La fuente de información de esta tarea son los errores ya cometidos (que curiosamente suelen ser detectados por las pruebas y las revisiones). Es decir, una adecuada aplicación de QA debería dar como resultado un proceso de desarrollo que cambia continuamente en base a la información facilitada por los testers. ¿Cuantos testers pueden decir que el proceso de desarrollo o la organización cambia por el resultado de su trabajo? Esto daría para un interesante debate.
- Gestión de la calidad (Quality Management): Esta área de actividad tiene como foco dotar al producto de la calidad adecuada al uso y optimizar la organización para lograrlo. Es la capa más estratégica de la calidad y fuertemente vinculada al negocio. Existen metodologías, normas y buenas prácticas que describen su aplicación (ISO 9001, CMMi, TMMi, ISO 29119, Nivel expert de ISTQB, etc..) pero hoy su aplicación ha quedado desgraciadamente en un proceso testimonial. Me apasionan las metodologías, normas, framework y buenas prácticas. De hecho, tengo un trabajo de recopilación al respecto https://metodologia.es que algún día terminaré. Esta área daría para otro interesante debate
3. A día de hoy, a nivel “acogida” de perfiles de testing en las empresas ¿lo ves mejor o seguimos estancados en el pasado?Creo que el nivel de acogida del tester dentro de los proyectos y la de las empresas ha mejorado significativamente en los últimos años. Recuerdo tiempos donde el tester se veía como algo molesto e incluso como una actividad no deseada. Queda algún "reducto" donde ocurre, pero, por suerte, es algo anecdótico.
Hoy en día prácticamente ninguna empresa con un proyecto de desarrollo de producto y sobre todo desarrollo software se plantea un equipo sin que existan la actividad de testing.
También detecto un incremento en la madurez de los proyectos, donde se está sustituyendo el clásico "lo pruebo al final", por una actividad de testing mucho más integrada con el desarrollo y aplicada en todo el ciclo de vida de desarrollo software. esto ha sido un cambio fundamental en los últimos 10 o 15 años, pero en lo que hay mucho trabajo por delante, según me cuentan mis alumnos :-)
También la percepción del rol del tester ha cambiado y yo creo que principalmente en los últimos 5 o 6 años. Al inicio del milenio, el tester era más reactivo y su actividad principal la realizaba al final de la construcción del producto principalmente de manera manual.
Hoy en día la labor del tester está progresivamente cambiando hacia la prevención, es decir el tester aparece al principio del proyecto con el foco de prevenir tanto como sea posible la inyección de defectos durante el proceso y de detectarlos lo antes posible. Sin embargo, a mi modo de ver, este cambio es mucho más lento de lo que el desarrollo software actual necesita.
La aplicación de enfoques de desarrollo agile y la automatización, están provocando que el tester se incorpore como uno más del equipo de desarrollo, aunque queda mucho trabajo por realizar para llegar al objetivo de que sea habitual que el tester esté equiparado al resto del equipo de desarrollo.
4. Como Quality Expert en MTP, ¿cómo ves el futuro próximo en la compañía?, ¿Qué tecnologías se asentarán y se usarán en los proyectos?
Bueno se habla mucho del futuro del testing sobre todo en conferencias, seminarios y artículos, pero creo que antes de hablar de ese futuro deberíamos terminar de afianzar nuestro presente. Hoy siguen existiendo proyectos donde el software y las pruebas siguen atascados en modelos con rentabilidad inadecuada.
Una de estas ideas que considero que deben cambiar es que aun se piensa que las pruebas es cosa sólo para los testers. El testing es responsabilidad de todo el equipo y el desarrollador es uno de los roles que más testing deben hacer. También el negocio debe implicarse en el testing y en la calidad software, obviamente contará con el apoyo de los especialistas, pero la calidad del producto es un problema del negocio.
También me gustaría que, en un futuro muy cercano, el equipo de desarrollo vea el testing como una fabulosa herramienta para que el desarrollador crezca profesionalmente y mejore su productividad. Es habitual en algunos equipos desarrollo pensar que el testing es un freno, una pérdida de tiempo, cuando en realidad se ha demostrado que una buena arquitectura de software y una buena estrategia de este testing son los mejores aceleradores del ciclo de desarrollo software. ¿cómo demostrar esto? muy sencillo, solo hay que analizar propuestas como scrum, enfoques agiles, Extreme Programming o TDD. Sin embargo, el testing para desarrolladores sería objeto posiblemente de otro debate y bastante largo así que ya tenemos materia para otra ocasión.
En cualquier caso y tratando de responder a tu pregunta, el futuro del testing pasa por una elevadísima automatización. No se trata solo de automatizar las pruebas, el diseño de los casos de prueba o incluso la estrategia de las pruebas. El tester va a tener que ser conocedor de todo tipo de herramientas y tecnologías de automatización de pruebas y del proceso de desarrollo porque van a formar parte de su día a día y debe incorporar dichas herramientas a su actividad.
Casi todos los tester, conocen lo que significa la automatización de pruebas, pero no todos conocen el testing basado en modelos o propuestas que donde los diseños de los casos de prueba vienen de especificaciones. Quizás algunos puedan conocer prácticas como BDD o Gherkin como lenguaje para automatizar casos de prueba partir de funcionalidades de negocio o del lenguaje natural. Pero este tipo de aplicaciones van a ir más allá y en el futuro existirán herramientas que permiten obtener los casos de prueba automatizados directamente de especificaciones modelos de negocio y de comportamientos del sistema. Estas herramientas aún están en proceso de creación y de optimización, pero el ritmo de crecimiento tecnológico es elevadísimo y posiblemente muy pocos años esto pase a ser nuestras herramientas.
Y por último en la automatización del proceso de desarrollo, bien por aplicación de propuestas como DevOps u otro tipo de propuestas que puedan aparecer en el en el futuro, van a generar unos procesos de construcción de Software donde la cantidad de datos generada va a ser increíble. Es decir, el proceso de desarrollo software va a tener su propio Big Data ahí es donde la inteligencia artificial, los sistemas expertos y las herramientas de análisis de datos van a poder ayudar al tester y a los responsables de calidad en los mecanismos para poder hacer las mejoras tanto del proceso como del producto. Probablemente el tester se convierta en lo que realmente debería ser, prevención de calidad (Quality Assurance) debido a todas estas mejoras.
Podría indicarte referencias de cómo en MTP, hace 10 o 15 años, hablábamos, aplicábamos algunas de estas propuestas. pero no hubo mercado suficientemente maduro para aplicarlas y quizás hoy en día el mercado tenga que madurar más para que ese posible futuro sea una realidad. Como decía al principio de esta pregunta, hay que tener la vista en el futuro, pero nuestro presente requiere aún de mucho trabajo.
5. ¿Soléis usar algún tipo de metodología en concreto o adaptáis según proyecto o cliente? ¿con cuál sientes que QA ha encajado mejor?
MTP ha apostado desde hace muchos años por las propuestas de ISTQB que ya tiene más de 20 años de vigencia y en los últimos 15 años por modelos de gobierno de la calidad como TMMi. En base a estas propuestas y nuestra experiencia damos cobertura a las tres áreas que he mencionado antes; QC, QA y QM.
Existen otros modelos, aunque no muchos más, pero yo creo que estas dos propuestas son claves en el mundo de la calidad software sobre todo cuando se hace un enfoque a la prevención
Nuestros modelos y servicios siempre han sido adaptables. Es imposible crear una propuesta metodológica, un proceso o una herramienta que sirva sin modificación para cualquier tipo de negocio, cualquier tipo de cliente, o incluso para cualquier tipo de proyecto. Si algo nos ha caracterizado ha sido la flexibilidad y la adaptabilidad.
Precisamente adaptabilidad es lo que yo considero como la adecuada traducción de la palabra inglesa Agile, tan vigente en la actualidad. Creo que la adaptabilidad ha caracterizado siempre MTP, por tanto, en mi opinión, pienso que MTP lleva 20 años siendo ágil, aunque quizás el mundo de la agilidad haya entrado con fuerza en los últimos 5 años en España.
En todos nuestros proyectos y clientes hay una fase inicial de diseño del servicio y en esa fase de diseño se analizan las necesidades, así como las casuísticas del cliente y del producto para ofrecer una adecuada estrategia de servicio en base a su mercado, su producto, su presupuesto y su nivel de madurez. Obviamente, esa adaptación es una actividad permanente durante todo el ciclo de vida del proyecto o del servicio.
Nuestra forma de trabajar está inspirada en muchas propuestas metodológicas, normas, buenas prácticas, enfoques, marcos de referencia. Digamos que creamos nuestro estilo, pero desde sólidas bases de conocimiento.
6. ¿Qué ramas o caminos, basados en la calidad, te gustan más? ¿eres de los que cacharrean a nivel más técnico o te gusta más la rama procedimental y de gestión?
¡Bueno a mí lo que más me gusta es no trabajar! Obviamente, es una broma…(risas).
Bueno para mí, el trabajo es una actividad que, si tuvieses la oportunidad, no harías pero que obviamente la desarrollas porque necesitas un medio de vida. Aquellas personas que pueden desarrollar una actividad que les apasiona, que les gusta y encima obtener ese medio de vida necesario, yo los considero auténticos afortunados.
Curiosamente en la profesión de testing es donde más personas me he encontrado con esta condición, gente que les apasiona su trabajo y que se consideran felices al realizarla.
En cuanto a lo que a mí me gusta, la verdad es que tengo la sensación de no he tenido una carrera profesional planifica, sino que han sido las circunstancias de los proyectos en los que he estado los que me han ido llevando a realizar todo tipo de actividades. Cada vez que ha aparecido una oportunidad interesante, he ido a por ella.
Creo que si tuviese que definir que es lo que más me gusta de mi profesión lo definiría con una palabra, crear. Realmente la creación o la realización de un producto, un proceso, una actividad, algo que antes no estaba hecho y que de alguna manera crea una innovación, un proceso o producto nuevo, es lo que más me atrae. La rutina, desde luego, es una de las cosas que peor llevo. Alguien podría pensar que con esta vocación es difícil poder trabajar en el mundo del testing. Pues creo que no.
Creo que la labor del tester, su labor principal, es innovar en pruebas. Quiero decir que se puede ser tester y estar continuamente creando casos de prueba, estrategias, desarrollando herramientas, automatizando, creando mecanismos de validación nuevos en el producto. Para mí realmente ese es el verdadero rol del tester, una combinación de estratega e innovación en casos de prueba, aunque por desgracia no es muy habitual esta actividad. Por tanto, veo muy difícil que aplicando lo que yo entiendo por tester uno pueda caer en la rutina o en el aburrimiento.
Otra actividad que me gusta realizar son el estudio y aplicación de metodologías, normas, marcos de referencia, buenas prácticas y, especialmente, los enfoques ágiles. Realmente muchas de las "novedades" que descubrimos actualmente llevan años, o incluso décadas, creadas. Lo que realmente veo que tiene un enorme valor es la forma tan sencilla, eficiente e incluso divertida de aplicarse en la actualidad. Es sencillamente apasionante analizar propuestas, ya veteranas como Scrum, o propuestas más actuales de escalado ágil, comparándolas con metodologías del siglo 20.
7. El año pasado, fuiste el ganador de la mejor ponencia en ExpoQA, a lo largo de todos estos años, ¿cómo has visto la evolución de los contenidos que se pueden ver los eventos? ¿estamos hacía caminos demasiado técnicos?
Respecto a los eventos, yo creo que miran hacia el futuro, hacia la innovación, hacia elementos nuevos, y es necesario, positivo y lógico que tengamos este tipo de visión a medio y largo plazo para que el mercado puede evolucionar.
Pero echo en falta más casos de éxito que marquen un camino real y útil a otros, así como casos de fracaso, es decir, errores que no deberíamos volver a cometer en el mundo del testing. No me gusta que el 100% de una presentación se centre en lo que una empresa es y en lo que puede ofrecer. Las presentaciones de hace 20 / 30 años eran de este segundo tipo, pero en la actualidad ya es muy habitual que pongan como condición para un evento hablar de experiencias útiles para otros.
Lo que me sorprende gratamente es que no solamente existe un evento de testing de manera anual. Existen varios eventos importantes en varias ciudades de España algunos de ellos de carácter internacional que en una de sus ediciones se ha celebrado en ciudades españolas. También me llama especialmente la atención como el colectivo de testers ha creado una comunidad con mayor crecimiento en madurez y tamaño, que en otros colectivos.
Sin embargo, el cambio que considero más significativo está en la evolución de las ponencias. Aunque se debería avanzar más, se pasado de ponencias centradas en las posibilidades de una compañía, a ponencias centradas en la aportación a un colectivo.
Otro aspecto interesante es el perfil y la media de edad de los ponentes. Me agrada ver cómo cada vez hay más profesionales que hablan de grandes experiencias en público con una edad relativamente joven.
Quizás, en unos años, desaparezca el típico formato de trasparencias y de comunicación unidireccional de un orador en pie hacia un público sentado. Parece algo difícil de imaginar, pero seguro que habrá cambios.
8. Para finalizar, ¿Vuelves a la carga este año en ExpoQA? ¿Puedes darnos un avance de lo que vas a tratar en tu ponencia?
Bueno eso de adelantar los secretos dicen que no es una buena práctica. Hay que guardarse unos cuantos ases en la manga. Intentaba ser una broma, pero es complejo trasmitir humor con un texto. Voy a tener que practicar más...(risas).
Puedo comentar lo que está publicado ahora mismo. Se trata de hablar de como la inteligencia artificial va a ayudar al tester. De hecho, creo que lo va a transformar.
La idea de la transformación digital la entiendo como ese cambio cultural y de mentalidad de las personas provocado porque ahora tenemos tecnologías que nos van a obligar a trabajar, pensar y realizar las tareas de otra manera. La tecnología no sólo nos permitirá hacer las mismas cosas de una manera más sencilla y rápida. Para mí el cambio fundamental es que hará innecesarias algunas de las tareas que hacemos actualmente y nos requerirá que hagamos otras nuevas. Esto puede dar un poco de vértigo, pero me temo que es imparable y la historia nos dice que con alta probabilidad es mejor para todos.
Vamos a una sociedad altamente tecnificada con ciclos de vida de productos y servicios cada vez más rápidos. Está alta tecnificación va a obligar al tester a una cualificación técnica muchísimo mayor de lo que estamos acostumbrados. Si la automatización de pruebas de alguna manera obligaba al tester a enfrentarse a la programación, la aplicación de un proceso de desarrollo software basado en DevOps le hace implicarse en los procesos de negocio y de desarrollo, en la tecnología, en la arquitectura y en la seguridad.
La inteligencia artificial realmente va a ser lo que decante al tester como estratega y profesional que previene los fallos. Esto no implica que debamos ser expertos en inteligencia artificial, sino asumir que formará parte de nuestra profesión. Por ejemplo, yo no sé construir una casa o un coche, pero soy perfectamente capaz de usarlos y saber sin son adecuados para mis necesidades. Muchas gracias.
Comentarios
Publicar un comentario