En estos días seguí de cerca una discusión en Twitter súper interesante sobre esta pregunta, si el testing mejora la calidad, ayuda a mejorar la calidad, o simplemente da información para que otros mejoren la calidad.
I’ve never liked the characterisation that a tester doesn’t actually improve quality, they provide information that can be used to improve quality. It’s too much of a hands off, not my problem, abdication of responsibility attitude and it has never reflected the way I work.
— Gregory Paciga (@GregPaciga) October 13, 2019
Simplificando, se queja de eso que muchas veces se dice (yo mismo lo he dicho en charlas o cursos) que el testing no mejora la calidad realmente, sino que el objetivo es dar información que puede ser usada para mejorar la calidad. Es como lavarse las manos, sacarse la responsabilidad y pasársela a otro (a los desarrolladores, al PM, al CEO, etc.).
En este sentido, y de acuerdo con mucho de lo que dijeron varios en la cadena de twits, me encantó lo que dijo Mónica Wodzislawsky del CES recientemente en su charla en JIS.uy:
“El mejor tester no es el que encuentra mas bugs, sino el que logra que mas bugs sean arreglados”. Lo dijo Mónica Wodzislawski en el https://t.co/fLIJb5TDVz y estoy 100% de acuerdo.
— Enrique Almeida (@ealmeida) October 4, 2019
Update: encontré que esta frase originalmente es de Cem Kaner: “The best tester isn’t the one who finds the most bugs or embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.”
Más ahora en este mundo de desarrollo ágil, donde todos somos responsables de la calidad, somos también parte de las decisiones que se toman en el equipo, en qué poner foco, en si liberar o no una funcionalidad, en cómo estamos resolviendo las cosas, etc.
Hace un tiempo habíamos estado filosofando al respecto con Gabriel Montero (de Peregrinus) cuando preparábamos la charla para el Argentesting del 2018, al repasar la famosa definición de testing de Cem Kaner “Testing is an Empirical technical investigation done to provide stakeholders, information about quality of a product or a service.”
Esa definición dice que una vez que el servicio o producto está hecho hay que probarlo y dar información. En aquel entonces lo que discutíamos con Gabriel era sobre que el testing debería tener otro foco, no solo detectar y reportar errores, sino prevenirlos.
De ahí que tiene sentido que el testing participe desde el día cero, ya que ahí en las reuniones de definición de requisitos (user stories, casos de uso, etc) el tester hará preguntas pensando en cómo va a probar eso luego, entonces el desarrollador ya está pensando en cómo solucionar los posibles problemas que puede tener, con lo cual seguramente se eviten muchos de ellos. Eso es más económico que esperar a que alguien detecte, reporte, se corrija y se verifique.
Además hay otro problema con la definición, proveer información nos deja por fuera de las decisiones, nos quita la responsabilidad. Debemos tener un rol más activo y aportar en la calidad y asumir la responsabilidad, junto al resto del equipo, de la calidad del producto. Entonces, no se trata de obtener información para que un desarrollador haga lo que quiera con eso, o que un Project Manager decida si salir en producción o no, en el mundo actual nosotros tenemos el objetivo, responsabilidad y participación en esas decisiones, así que eso debería estar reflejado en la definición de testing.
Yo pienso que todo el equipo mejora la calidad final del producto y el testing es fundamental para no tener errores de funcionalidad a la hora que un cliente comience a utilizar dicho producto.