El Tester… ¿debe saber programar?

Cuentan las leyendas que en la antigüedad el Testing era una fase que ocurría sólo al final del ciclo de vida, o del proyecto, una vez que desarrollo había terminado su trabajo. Por aquellos tiempos, ahora remotos, y a diferencia de los tiempos ágiles que ahora corren, Testing era una fase, no una tarea como sucede ahora, Testing iba al final, y no desde el principio, y casi en paralelo a desarrollo, como ahora; entonces Testing era un equipo externo, y no una actividad que ocurre dentro de ese equipo ágil multifuncional, donde el Tester forma parte del equipo; antaño Testing era una actividad ajena a la programación, y no como ahora que el Tester programa…. ¿cómo? ¿qué el Tester programa? </parrafo_con_ironias>
En el mundo del Testing Ágil hay bastante consenso en gran parte de lo que antes te contaba, salvo en una cosa… ¿el Tester debe/saber programar?
Hay consenso en que para entregar “prototipos potencialmente entregables” de forma rápida, al final de cada Sprint, los equipos necesitan automatizar pruebas (luego ya vendría el debate de cuánto automatizar). Y esto lleva a pensar que los Tester deben saber programar. Y aún más, si esto lo unes a la errónea interpretación que circula por ahí, casi imposible de implementar, por cierto, de que equipo multifuncional ágil significa que todo miembro del equipo debe saber hacer de todo (te recuerdo aquel post de Un equipo ágil es aquel en el que todo el mundo sabe hacer de todo… ¿seguro?).
Pero veamos que opina parte del mundo del Testing al respecto…
En 2012 Rob Lambert escribía un post del que te extraigo algunos párrafos:

Muchos sugieren que los Tester deben aprender a programar o de lo contrario serán reemplazados por una máquina (o por alguien que sepa programar).

Estoy de acuerdo en que aquellos Tester que únicamente “chequean” serán (y deben ser) reemplazados por máquinas que realizan la misma acción. Algunas de estas personas que “chequean”, podrían convertirse en grandes «Tester», dejando que las máquinas realicen el trabajo tedioso del “chequeo”.

Pero no creo que todos los Tester tengan que aprender a programar. Yo sé de un gran número que no lo hacen y hacen un trabajo excepcional en Testing. Dicho esto, creo que cada equipo de Testing debe tener la capacidad de codificar, con un programador de ayuda o un «Tester Técnico» como ayuda a la automatización, para profundizar y entender el producto.

Y, en parte, te he citado el anterior post porque James Bach (el del Testing exploratorio y el Lessons Learned in Software Testing: A Context-Driven Approach), respondía lo siguiente, añadiendo un comentario al mismo…

Los Tester NO necesitan saber programar. La idea de que los Terter tienen que saber programar viene de la ignorancia sobre el Testing, de confundir Testing con Chequeo. Viene también de la ignorancia sobre los diferentes tipos de Tester y de Testing.

Y decir a los Tester que necesitan a aprender a programar desalentará a gente brillante a convertirse en Tester.

También Elisabeth Hendrickson (autora de Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing) comentaba que no todos los Tester deben saber programar, sólo aquellos que se dediquen a la automatización de pruebas. Por ejemplo, aquellos Tester dedicados a las pruebas exploratorias, no tienen que saber programar.
Bueno, eso es lo que dicen los que saben, pero qué opina y dice “el pueblo”, el “día a día”, la cruda realidad. Bueno, para ello, me he dado una breve vuelta por algunos portales de empleo y he mirado qué piden las ofertas de trabajo para Tester. Y las ofertas de trabajo difieren bastante de aquello de que el Tester no debe saber programar, más si la oferta menciona en algún lado la palabra mágica “ági”. Véase…
Conocimientos que te puedes encontrar como requeridos en una oferta de Testing, además de los típicos de Testing, puedes encontrar cosas como, y copy pego literal: Refactoring, Android and IOS architecture, SQL, Pruebas Unitarias (sobre las que existe consenso que son responsabilidad de desarrollo), lenguajes de programación de todo tipo, etc.

Terminando…

Difícil una conclusión cerrada, pero si que parece que tenemos claro que el Tester no es un desarrollador, si bien es necesario – muy recomendable – se pide cada vez más que tenga conocimientos de programación (más aún si el puesto es para automatización de pruebas). Si bien, tampoco hay que olvidarlo, el desarrollador tampoco es un Tester, si bien es necesario – muy recomendable que tenga conocimientos de Testing.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “El Tester… ¿debe saber programar?”

  1. Buena reflexión, lo que pasa es que en parte ha venido este movimiento como reacción al hecho de que muchos egresados y egresadas de informatica iban al testing como una forma deliberada de escapar de lo tecnico.
    Tambien se ve al testing como una forma de pasar a tareas de analisis y luego a gestión…

  2. Es una pregunta con muchos años de historia, en la mi opinión es: DEPENDE !!!
    La clave está en confundir que existe un único perfil de tester y (como mínimo existen 2).
    Tal y como indica Google en su libro How Google Tests Software de James A. Whittaker o ISTQB en su programa de certificación en Testing, existen 2 grandes grupos de testers
    1.- El tester de caja negra o un tester que conoce el negocio y el usuario, así como lo que el software debe hacer y que no tiene porque saber construir el software que prueba. ¿Nosotros necesitamos saber programar una App para saber si es lo que buscamos? ¿necesitamos saber construir un coche para decir que es el adecuado? ¿Un piloto de pruebas debe saber construir un avión?
    2.- El tester de caja blanca o tester técnico que conoce el desarrollo y la tecnología y cuyo valor fundamental es enriquecer al equipo de desarrollo con enfoques y técnicas de testing que (por desgracia) los desarrolladores no solemos tener.
    En cualquier caso, separar el rol de tester y desarrollador de manera absoluta o, por el contrario, pensar que todos tenemos que ser desarrolladores y testers expertos, me parecen posiciones extremas que no son válidas para todos los casos (incluso no son válidas para la mayoría de casos)
    Sin embargo, considero «imprescindible» que un desarrollador sepa realizar testing en aquellos casos que ese rol no exista en el equipo de desarrollo.
    También considero «imprescindible» la labor de testing desde incluso antes de iniciar el proyecto de desarrollo. Como dice Javier, esto de que el Testing es una fase al final, es una vieja creencia, en mi opinión absolutamente errónea. Un tester profesional (de cualquiera de los dos grupos) puede explicar porque es así.

  3. Una vez aclarados estos conceptos (tester y automatización), entonces es muy probable que durante años hayamos cometido el error de referirnos a dos cosas diferentes con el mismo nombre. Indudablemente, debemos buscar como automatizar las pruebas (cuando así se requiera y sea conveniente)… Ahora, que lo haga el tester… pues eso ya es otra cosa.

  4. Como bien dice James Bach y también Michael Bolton, si las pruebas fueran automatizables, porque no hablamos tambien de automatizacion de la programacion o automatizacion de la gestion de proyectos?
    Se confunde Testing con Checking. Lo que se automatiza es el Chequeo, El testing es una actividad humana.
    Lease: http://www.satisfice.com/blog/archives/856

  5. En desarrollo ágil, un tester que no programe tiene dificil cabida.
    Como bien justifica Javier, los miembros del equipo ágil deben ser lo más multifuncionales posible. En algunos equipos lo serán más o menos, pero se me hace dificil imaginar un equipo ágil donde alguien no sepa programar. Principalmente por 2 motivos:
    1) Los equipos ágiles son pequeños. En un equipo de 4 personas, si no sabes programar, te puedes encontrar con muchos tiempos muertos sin tarea.
    2) La DoD: Definición de Hecho. En un equipo ágil, un miembro del equipo coge una tarea (normalmente historia de usuario) y se encarga de resolverla de acuerdo a la DoD. Esta DoD como mínimo incluirá que funcione! Y para saber que funciona habrá que probarla. Debe esperar el desarrollador a que el tester pruebe su implementación? Lo normal es que el desarrollador haya programado unos tests que prueben la resolución de la tarea (además de otras pruebas manuales que haya tenido que hacer).
    Esto no quita para que aunque el desarrollo sea ágil, haya una fase posterior a la entrega de validación de la versión entregada. En especial si son desarrollos para clientes. Es en esta fase donde veo que encaja perfectamente ese perfil (o quizás sería más un rol de un perfil) de tester de caja blanca que no sabe programar.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *