[Debate] ¿Los testers deben saber hacer de todo en el mundo ágil? ¿Qué cualidades debe tener un tester en un equipo ágil?

Hoy me gustaría promover un debate sobre el perfil de tester, sobre qué debe hacer un tester en los equipos ágiles. Esta idea se me vino a la cabeza hace unos cuantos días, cuando unos compañeros de una empresa en la que paso bastantes días a la semana, vinieron de un curso para una certificación de tester ágil, y nos pusimos a hablar de los contenidos que trataron.

Un poco de contexto

Dejando de lado el tema certificación sí, o certificación no, lo cierto es que en los proyectos ágiles nos hemos dado cuenta de que el papel de tester tradicional, policía, que prueba al final del proceso no es suficiente, y para una mejor calidad tenemos que probar más a menudo y empezar desde las fases más tempranas del proyecto (recuerda que el testing es una de las cosas que influyen en la calidad del software, pero no la única Calidad del software es mucho más que el testing). Incluso en ciertas empresas y para ciertos productos, solo realizar testing funcional también se queda corto (recuerda que hay muchos tipos de pruebas ¿Pruebas de integración, funcionales, de carga…? ¡Qué jaleo! ¿Qué diferencias hay?).
Siendo conscientes de esto, cuando hablamos de testing ágil (¿Cómo enfoco el testing de forma ágil?) se le vuelva a dar importancia a temas como la automatización de pruebas, Integración Continua, testing exploratorio, ATDD, BDD, TDD (lado del desarrollador), pruebas unitarias (lado del desarrollador)…
En este punto salió la cuestión de: ¿es que un tester ahora tiene que saber todo eso? ¿tiene que saber hacer pruebas manuales funcionales, testing exploratorio, automatizar pruebas, implantar integración continua, BDD…? ¿así de golpe? ¿y tienen que estar dentro del equipo y ya no tiene que existir el rol de QA manager?
Para mí fue una conversación muy buena, con conclusiones muy interesantes, y lo mejor, diferentes visiones. No las digo porque espero que estos amigos participen y den su visión en el debate.
Pero la cosa no queda ahí. Si profundizamos más allá, la cuestión es que en ciertas empresas directamente no hay rol de tester, este papel lo asume desarrollo. ¿Es eso adecuado?

Abramos el debate

Por eso, testers, desarrolladores, QA managers, CEOs, CTOs, etc. os invito a dar vuestra opinión sobre los siguientes temas:
1 – ¿Debe existir alguien especializado en testing en un equipo ágil? ¿o solo con testing desde el lado de desarrollo?
2 – ¿Qué debe hacer un tester dentro de un equipo? ¿Y qué debe saber? ¿Debe saber y practicar BDD, ATDD, integración continua, testing exploratorio, automatizar pruebas…?
3 – ¿Sigue siendo necesario el rol de QA manager?

Mi opinión.

Así que para abrir el debate comenzaré yo dando mi opinión. Recalco opinión porque no quiero liar a nadie, lo que voy a decir no es un absoluto a seguir aceptado por la real academia de testers (si eso existiera xD), ni el mundo ágil, ni dicho en el libro X de testing ágil.
Para entenderme un poco tenéis que saber que mi perfil es un algo especial. Me gusta programar, vengo de desarrollo, y soy tester, pero más involucrada y especializada en integración continua y automatización de pruebas que en la parte manual. Además por otra parte también ayudo a las empresas con la agilidad, Scrum, procesos de desarrollo, calidad del software (proceso, producto y personas), etc. De ahí que no tenga una visión específicamente funcional del testing y es muy probable que mucha gente tenga una visión distinta a la mía.
Así que vamos allá con los puntos anteriores:
 
1 – ¿Debe existir alguien especializado en testing en un equipo ágil? ¿o solo con testing desde el lado de desarrollo?
Parece que en el concepto de los equipos ágiles, multifuncionales, nos hemos cargado los roles, el tester funcional, desarrollador backend, desarrollador frontend, administrador de base de datos (DBA)…
Yo soy partidaria de mantener roles, teniendo un sentimiento de igualdad dentro del equipo. Es decir, que un desarrollador backend no es más valioso que un tester, ni un DBA más valioso que el resto. Para mi un rol indica que alguien es un especialista en ese campo.
En un equipo multifuncional hay especialistas, pero eso no quita que la gente también tenga ciertos conocimientos sobre otros campos, sin llegar a ser especialistas (Un equipo ágil es aquel en el que todo el mundo sabe hacer de todo… ¿seguro?)
Por ello pienso que todo el mundo debería saber de calidad del software, todo el mundo debería contribuir a ella y haber cultura de testing.
Aunque los desarrolladores deben ser responsables de testing a nivel de unidades código (pruebas unitarias), para mí en aplicaciones grandes, críticas, esto es necesario, pero no suficiente. Necesito testing a distintos niveles de la aplicación, incluso una visión global, regresionar componentes afectados con los cambios de código, una buena estrategia de pruebas, etc. Tantas cosas más que para mí hacen indispensable un tester, o varios, como ya comentaré en el siguiente punto.
 
2 – ¿Qué debe hacer un tester dentro de un equipo? ¿Y qué debe saber? ¿Debe saber y practicar BDD, ATDD, integración continua, testing exploratorio, automatizar pruebas…?
Pienso que el concepto de calidad del producto software es muy amplio, y todavía no está muy bien acotado y definido. Para que te hagas una idea, la ISO 25000 establece que calidad del producto software abarca las siguientes características y subcaracterísticas a tener en cuenta:

Actualmente conseguir todo eso en un software me parece muy costoso a nivel de esfuerzo y dinero.
Así para mí el objetivo final es aportar el máximo valor al cliente con el software que desarrolles (el cliente puede ser externo, o puede ser interno a la empresa), por lo que las acciones de mi equipo deberían ir orientadas a darle valor al cliente.
En mi visión, de todas las características de calidad que hay, tenemos que pensar ¿qué es lo que le aporta valor al cliente? ¿qué es lo que necesito como empresa?
Por ejemplo, podría darse el caso que para un usuario de una web de compras calidad sea que el software a nivel funcional se adecúe a lo que él espera, que tenga una buena usabilidad y seguridad de que no le vayan a hackear la cuenta bancaria.
Pero a lo mejor para otro tipo de aplicación la seguridad no es un aspecto tan crítico. O incluso, para una empresa que desarrolla un producto y lo mantiene en el tiempo pueden ser necesarias la adecuación funcional y la mantenibilidad.
Para mí eso se debe reflejar en el desarrollo de software, en la prevención de riesgos y en la estrategia de pruebas. Es decir, detectar y reducir errores de seguridad, de mantenibilidad, usabilidad, etc. en cada caso.
Lo que quiero decir con esto es que sí se puede dar el caso de que por motivos de negocio y organización interna en una empresa sea necesario que:
– Se implante integración continua.
– Se automaticen pruebas.
– Se haga testing manual funcional (porque no es rentable automatizar pruebas de ciertas partes de la aplicación muy costosas técnicamente).
– Se hagan pruebas de carga y rendimiento.
– Se haga ATDD, BDD, para tomar mejor los requisitos del cliente y mejorar la comunicación en todo el equipo con los distintos perfiles.
¿Un solo tester tiene que ser especialista en todas estas áreas? Mi visión es que no. ¿Un desarrollador debe ser especialista en backend, frontend, dba, UX, seguridad, sistemas, etc.? Es imposible.
Creo que la calidad del software es algo tan amplio, tan poco tenido en cuenta, y el concepto de tester sigue muy poco especializado, o especializado solo en el área funcional.
Por eso, si se puede permitir y la empresa lo necesita (previo análisis de su negocio, requisitos, necesidades, etc.), sí veo necesario que haya especialistas en distintos campos de testing en un equipo, y que eso no les limite aprender o ejercer otras actividades.
Pero creo que no estamos preparados para esto. Antes de ello, es necesaria una concienciación sobre qué es calidad del software, por qué es importante, y qué es testing, para todos los roles, incluidos los testers.
 
3 – ¿Sigue siendo necesario el rol de QA manager?
Para mí sigue siendo necesario. Más que nada porque el día a día del equipo ágil no quite a los testers el objetivo general de testing a nivel de todos los equipos, coordinación entre todos, etc.
Además de que veo muy bien que haya una persona que se preocupe de que los testers puedan mejorar profesionalmente, promocionar, estén motivados, solucionar problemas, etc.
Para mí es ideal además, se hagan reuniones de coordinación interna de los perfiles de tester o QA de todos los equipos.
En este aspecto tengo una visión muy parecida a los conceptos de chapter y guild de Spotify.
—-
¿Tú que opinas? También puedes contradecir o comentar mis opiniones, para eso es un debate. ¡Espero tus respuestas! 🙂