¿Hace falta que un Tester sepa programar?

Esta es otra afirmación que me ha sorprendido y mucho, y que he oido mucho hablar de ella durante mis muchos años de práctica. A ver. La técnica que suelen usar los bloggers normalmente es plantearlo como una pregunta. Pero en realidad, muchas veces ya se tiene la respuesta, y el post se limita a dar una avalancha de argumentos a favor de su postura. Vamos a intentar dar una vuelta a los argumentos a favor y en contra. Pero ¿porqué programar? ¿porqué no hablamos de otros conocimientos como: UML, arquitectura, lenguajes de programación, herramientas de desarrollo,  herramientas de testing, sistemas, análisis...? Me da la sensación de que esta afirmación viene siempre de gente con un fondo importante en programación, y que por  tanto da mucho valor a este rol (y no digo que no lo tenga), y que sin querer desprecia el resto de roles en el ámbito del desarrollo software.

Dando una vuelta por internet, me encuentro con argumentos a favor y en contra. Pero sorprendentemente, muchos más a favor. Vayamos viéndolos:

A favor:

• ¿Porqué no? He encontrado este argumento, y bueno...no se han roto la cabeza.
• Depende. Vale. Otro argumento bien fundamentado. No en serio, vamos a intentar profundizar sobre éste, ya que soy partidario de él parcialmente. Lo haremos durante el post.
• Todo ayuda. Ahí estoy de acuerdo. Cuanta más formación, mejor. Pero más bien la duda sería: ¿qué es mejor? ¿Que esté formado en programación y desarrollo (específico en lenguaje, en plataforma, en arquitectura...)? ¿O que esté formado en el negocio del cliente, que conozca su forma de trabajo, sus necesidades, su lenguaje específico? ¿Qué debe hacer realmente un tester?
• Para poderle explicar al programador dónde está el fallo, ya que el conocimiento de programación le puede hacer inferir qué problema tiene, y así le ayuda a corregirlos antes. Este argumento me sorprende y mucho. Salvo que el tester sea uno de los programadores, y conozca la arquitectura en detalle, es difícil (por no decir imposible), que el tester sepa qué y porqué falla algo. Estoy de acuerdo, que cuando con nuestra experiencia, los que hemos programado hacemos pruebas, podemos tener sospechas de porqué falla algo. Pero de ahí, a que realmente sea útil esa sospecha, es concedernos un criterio excesivo.
• Para poderle aportar al programador experiencia sobre cómo corregir sus fallos, de forma que su código sea más seguro y fiable. Esta también me ha sorprendido. Entonces qué queremos ¿testers o formadores? Esta es la visión típica de la persona que ha probado mucho, pero también ha programado mucho. Pues claro que tendrás experiencia en fallos/soluciones típicas. Pero es mucho más complicado que eso. Si estamos en un mantenimiento, no vamos a tener tiempo de tonterías: hay que resolver la incidencia para cumplir el ANS (Acuerdo de Nivel de Servicio). Y si no es un mantenimiento, si de verdad tenemos tiempo de ponernos a hablar y discutir con el programador todos y cada uno de los fallos encontrados....yo quiero trabajar en ese proyecto, y lo quiero YA. Aquí se mezclan churras con merinas. De acuerdo que programadores que han hecho mucho testing, son los más adecuados para transferir ese conocimiento. Pero eso no significa que el tester deba hacerlo, porque la forma de corregir los defectos puede depender de la arquitectura específica, y el tester no tiene porqué conocerla. De hecho, en la mayoría de los casos, lo que interesa es presentar un informe de resultados de defectos al cliente y/o al jefe de proyecto. La solución de los problemas, su prioridad, etc., dependerá de muchos factores (y no tiene porqué ser el criterio del tester, y mucho menos del programador).

En contra:

• No debe condicionarse al tester con el conocimiento interno de la aplicación. Las pruebas deben realizarse siguiendo las indicaciones del plan de pruebas. Ahora bien, si no hay plan de pruebas, no hay casos de pruebas, ni datos de prueba, ni resultados esperados…no necesitamos un tester que sepa programar. Necesitamos a Dios.
• El conocimiento de la aplicación (léase documentación, arquitectura, análisis, etc), puede estar obsoleto. Si defendemos las metodologías ágiles, es posible que el tester no cuente con documentación actualizada de “qué hay dentro”. Si aceptamos que esto sea así, ¿cómo vamos a exigirle que entienda algo que seguramente no le sirve? Dejémosle que pruebe lo que debe probar, y que no esté pensando en "lo que hay detrás".
• ¿Debe alguien que se prueba la ropa saber coser? ¿o hacer pantalones, o cortar telas…? ¿Deben los inspectores de calidad de un edificio saber poner ladrillos, etc? ¿Debe un técnico de ITV saber construir un coche? (puede que ni siquiera le haga falta saber conducir)
• Un tester debe ser objetivo. Su resultado es un informe de pruebas. Si su resultado son consejos a los programadores, tendremos a un arquitecto, analista o programador “power”, cuyo tiempo estaría mucho más aprovechado revisando la arquitectura y el código (o formando al equipo), que probando.
• A un programador difícilmente le puede aportar un resultado de pruebas del estilo: "yo creo que te falla la punta de la trócola cuando el cimborrio izquierdo recibe un valor trambostático". Si la conclusión del tester no es objetiva, acabaremos creando una cadena de opiniones que finalmente perviertan el resultado de la prueba, y por tanto, la invaliden. Al programador hay que darle algo objetivo: se da el fallo x cuando en la situación y meto el valor z. Esto es algo repetible y objetivo. Por ejemplo: no le puedo decir: "me parece que en algunos ordenadores el color de fondo es más claro". Sino que si soy un tester debo decir: "en las pruebas X, en el ordenador Z, el color de fondo se ve más claro".  

Yo creo que la conclusión sería ésta:

• Si el equipo y el proyecto son pequeños, no te queda otra: no es operativo tener un señor sólo para probar, a no ser que sea un recurso compartido entre proyectos. Aquí normalmente no es que haga falta, es que simplemente este tester tiene también otros roles.
• Si el proyecto es mediano o grande, se hace necesario un tester especializado en esa tarea. Y aquí es cuando es menos significativo que el tester sepa hacer otras tareas.
• Si sólo llevamos un proyecto en la empresa: aquí la visión es otra: necesitas alguien que haga el testing, pero que también te de soporte a más tareas. Además, es más fácil que el tester esté versado en el negocio del cliente, la arquitectura, etc, porque sólo hay 1.
• Si llevamos varios proyectos en la empresa: si el tester se comparte entre varios proyectos, es más difícil que esté puesto en el negocio, en la programación, la arquitectura...ya que pueden ser muy diferentes. Si el tester no se comparte entre varios proyectos, sino que hay uno por proyecto, entonces sí que es posible que aporte algo más.