Hace unos años se hizo popular el rol de SDET (Software Development Engineer in Test). En el último tiempo también fue así con el rol de DevOps, orientado a la agilidad y a aspectos relacionados a desarrollo y calidad, pero con foco en operaciones (aunque vale aclarar que DevOps no es un rol, es una cultura, o quizá un conjunto de prácticas, pero de igual manera se hizo popular el “rol de DevOps”). Hoy, esta nueva corriente del QE es la que siento que más nos identifica.
El QA como ya conté en un post anterior, es el que asegura la calidad. También encontré por algún lado que QA refiere a quality analyst (analista en calidad) lo cual me cierra bastante más que asegurador de la calidad. De todos modos, se asocia ese rol con el tester funcional, que generalmente no tiene conocimientos en programación.
El QE no es un desarrollador que se enfoca en las pruebas (como el SDET), tampoco es alguien que enfoca sus tareas en desarrollo y operaciones, ni tampoco es alguien que asegura la calidad (como un QA). El QE es alguien que aplica ingeniería a distintas partes del proceso de desarrollo de software en beneficio de la calidad. Entre otras cosas, sus conocimientos en operaciones (infraestructura, servidores, plataformas) le vendrán bien para las pruebas de seguridad, performance, para integrar chequeos en un esquema de CI/CD, etc. Por otro lado, es importante que tenga manejo de automatización en distintos niveles como para que sea capaz de automatizar a nivel de API, a nivel de UI o a nivel de protocolo. Y también es fundamental que tenga sensibilidad por la calidad, esa que típicamente tienen los buenos testers. Veo imprescindible que un tester que se dedica a las pruebas de performance también sepa de Selenium, así como de definir una estrategia de pruebas funcionales o definir un criterio de aceptación de una historia de usuario. Digamos que un buen nombre para esto podría ser full stack tester (como el de la imagen de arriba, a 6 manos manejándolo todo).
¿Qué es lo que hace al QE tan relevante en estos tiempos?
Por un lado creo que es impulsado por las metodologías ágiles en cierta forma, y asociado a esto la idea de shift left testing. Entonces, el tester se tiene que involucrar en tareas tempranas del desarrollo, cuando aún no hay un producto completo quizá.
Los cambios tecnológicos no dejan de lado al tester y la ingeniería de calidad. Está claro que un tester estará mejor preparado para trabajar con los equipos de hoy día si es capaz de revisar código, analizar componentes, automatizar pruebas, manejarse con Jenkins y otras herramientas del estilo, así como con ambientes contenerizados como en Docker. No hay duda que hace falta cada vez más un perfil más técnico del tester.
El agilismo también influye en este cambio de rol por el motivo que los equipos no suelen estar formados por más de 9 integrantes (two-pizza-teams), y para ser autosuficientes, es necesario que menos personas concentren más conocimientos y responsabilidades. Quizá en algunas empresas luego se tenga equipos especializados, o incluso se tercericen algunas tareas, pero el éxito de esa tercerización será mayor si se cuenta con alguien en el equipo que pueda gestionar con conocimientos las tareas que se están delegando.
Actividades de un QE
Intentemos listar las actividades que puede llegar a estar bajo el cargo de un QE (seguro que esta lista se puede ampliar según el producto que se esté desarrollando, el tamaño de empresa, contexto, etc.):
- Definir plan y estrategia de calidad: qué hacer y qué no de acuerdo a los objetivos y riesgos asociados al contexto. Cómo hacerlo, con qué herramientas, de acuerdo a las restricciones de presupuesto, etc.
- Revisiones de código: entender, sugerir mejoras, utilizar SonarQube y entender las mejoras propuestas, poder hacer un plan de acción en base a un reporte de análisis de código y deuda técnica.
- Pruebas funcionales: deberá poder probar un sistema con un ojo crítico, en busca de bugs. Existen muchas técnicas de diseño de casos de prueba, y para poder organizarse y planificarse adecuadamente deberá manejar el testing exploratorio con confianza.
- Reportar incidentes: el objetivo de las pruebas no es solo encontrar bugs, más que eso es lograr que se resuelvan. Para esto, es fundamental tener habilidades para reportar adecuadamente los incidentes.
- Automatización de pruebas funcionales en distintos niveles: quizá no incluiría las pruebas unitarias ya que esas (para mí) son para el desarrollador, pero sí podría realizar revisiones periódicas de las pruebas unitarias y sugerir nuevos casos a probar, analizar la cobertura, definir si las pruebas tienen el nivel adecuado. Automatizar a nivel de API (REST, SOAP), a nivel de UI con herramientas como Selenium. Preparar las pruebas con un enfoque BDD con Cucumber o alguna herramienta similar. Deberá poder definir una estrategia de pruebas automatizadas, y espero que para eso se base en la pirámide de Cohn.
- Probar la performance: esto implica poder automatizar a nivel de protocolo así como analizar datos de la monitorización de distintos componentes, buscando cuellos de botella y oportunidades de mejora.
- Probar la seguridad: utilizar distintas herramientas y técnicas para control de acceso, hacking etico, etc. Al igual que las pruebas de performance, se requiere conocimiento bien específico, de las tecnologías y plataformas utilizadas.
- Entender y manejar el git flow: es fundamental que las pruebas estén alineadas con el desarrollo, y un punto de contacto muy relevante es la forma en la que se manejan las versiones del código, los distintos branches y asociado a esto, los distintos ambientes. El código de pruebas deberá ser tratado como parte del código del sistema, y para eso se deberán utilizar las mismas herramientas que un desarrollador y la misma metodología de gestión de versiones.
- Utilizar entornos de Integración Continua: todos los chequeos que se automaticen se quedrán tener en un entorno de pruebas CI/CD como Jenkins o similar, para que se ejecuten frecuentemente. El QE deberá manejar todos los artefactos de prueba, me animo a decir que será más usuario de Jenkins que los propios desarrolladores.
- Hablar en términos de negocio: mencioné muchos aspectos técnicos, pero la sensibilidad de un tester muchas veces está en la visión global, y la visión orientada al negocio. No hay que perder de vista que todo el trabajo de calidad que se hace es para que el negocio prospere, así que esta visión es tan importante como los conocimientos técnicos que hay que tener para manejar todas esas herramientas que nombré antes.
Seguro que me faltan varias. Si te animás, comentá la que te parezca que debería incluir en esta lista.
Cerrando
Cuando digo que me siento identificado es porque es lo que me ha tocado en mi rol en Abstracta. Si bien me inicié en informática como tester de performance en el 2005, he participado en distintos roles en proyectos de testing funcional, testing automatizado, seguridad, usabilidad, revisión de código, y por suerte cada vez más últimamente en proyectos en los que apoyamos a construir un esquema de Continuous Integration/Continuous Delivery.
Yo creo, desde mi humilde opinión, que esto es lo que todo tester debería apuntar a formarse, ya que es lo que más se está buscando, por ahora, al menos en el norte, pero acá por el sur, siempre se valorará más a quien tenga la visión más completa de calidad por más que sus tareas inicialmente se restrinjan a cierta área.
Para cerrar, una frase que me quedó grabada de Oscar Mullín, en su charla en Agiles2015 acá en Montevideo:
Es irrelevante la diferencia entre testing y desarrollo en cuanto a responsabilidad, pero no en cuanto a roles.
