Testers técnicos? Testers mejores!

Testers técnicos? Testers mejores!

Así a simple vista, parce que esta notícia (“Recruiters’ advice to testers – get technical!”) y este super-post de Toni Robres (“Tienen que saber programar los testers?”) van de lo mismo, de que ahora toca que los testers sean más técnicos y demás…

Pues no.

Para empezar, el primer artículo no debería llamarse Recruiters’ advice to testers… sino más bien Recruiters’ threat to testers… Porque todo el articulo en si mismo parece diseñado para meter el miedo en el cuerpo de los testers, algo así como…

Si no aprendes a programar, vendrá el hombre-agile-del-saco y te comerá.

Tomémonoslo con calma, que esto es serio. Si tuviera que resumir mi lectura del post de Toni en una frase sería algo así como un consejo, algo más como…

Tester, aprende a programar, que te puede ir bien.

Y humildemente me permito añadirle…

Tester de software, aprende cosas sobre software,
que te puede ir (muy) bien.

Cuidado que no es lo mismo que la amenaza de antes por parte de los recruiters. Se trata de hacer mejor nuestro trabajo. El saber no ocupa lugar, si aprendes cómo se hace el software, seguro que le puedes sacar partido a la hora de testearlo, y esto no tiene nada que ver con el advenimiento del agilismo, tiene que ver con si te interesa profundizar en lo que haces, para saber más y hacerlo mejor y con mayor eficiencia.

Sujeto A: pues yo no quiero saber más, ni hacer mejor mi trabajo.

Sujeto B: ok, pues yo no te quiero en mi equipo.

Más claro no lo puedo decir. Y además me ha salido un interludio teatral que vale para cualquier trabajo en equipo.

Aprender a programar puede venir bien, pero también tener nociones de HTML, bases de datos, aplicaciones web, algo de seguridad… Dependerá de a lo que se dedique la empresa en la que trabajas y/o hacia donde quieras dirigir tu carrera. Pero “get technical” así porque sí, porque lo dicen en el sector y si no prepárate, pues no, porque no es un requisito para TODOS los trabajos relacionados con el testing.

Y ojo, que yo no soy un “tester técnico” (sin saber muy bien qué es eso) pero sí que sé “cosas”, “cosas” que he ido aprendiendo a medida que las he ido necesitando o que las he descubierto y me han gustado, y ahora me facilitan la vida, y si me facilitan la vida, pues quiero saber más y quiero que me la faciliten más. Y en este deseo en forma de saco meto también las ganas y la necesidad de mejorar en la parte del negocio, que también ayuda a testear mejor: quiénes son tus usuarios, cómo usan las aplicaciones, cuál es el origen de los requerimientos…

Además, es que con esto hay que ir con cuidado, porque en España tenemos una obsesión por poner ofertas de trabajo que piden un montón de cosas porque es lo que toca, aunque luego no tenga nada que ver con lo que se tiene que hacer. Entonces, para terminar, lanzo una advertencia con mi tono más duro:

Recruiters del mundo, no vale incorporar por defecto a partir de ahora conocimientos técnicos en las ofertas de trabajo de y sobre testing, o me enfado.

Y yo cuando me enfado… Pues eso, que me enfado. 😐

Anuncios

12 comentarios en “Testers técnicos? Testers mejores!

  1. Totalmente de acuerdo contigo Mauri. En todo.

    Lo primero, al ver las ofertas que publican últimamente… vale que cuantas más herramientas para hacer tu trabajo, mejor, que si tienes conocimientos técnicos y/o de programación, mejor (aunque para mi ni imprescindibles), pero de ahí a que tengas que saber 3 y hasta 4 lenguajes de programación… mi pregunta es… para qué?

    Yo defiendo que no hace falta saber programar ni ser un gurú (o friki) tecnológico para ser un tester, un buen tester. Claro está, dependiendo de que tipo de pruebas realices… (y esto responde a mi pregunta anterior, para qué?). Si haces pruebas automáticas, por narices necesitar saber programar si quieres hacer una buenas pruebas y no te limitas a hacer click en una herramienta. Lo mismo pasa si haces pruebas de carga (quizá algo menos) y ya ni hablamos si haces pruebas de retrospección de código o de caja blanca.

    Pero por favor, que alguien me de motivos coherentes para que los testers funcionales (de caja negra o como quieran llamarlos) necesiten saber programar. Necesitan, sobre todo, que les guste su trabajo. Les motive a la hora de hacerlo bien y avanzar y sobre todo, ver más allá. Allá donde no ven los programadores incluso donde los responsables de negocio ven borroso. Claramente, necesitas tener unos conocimientos. Con todos mis respetos, no puede hacer el mismo trabajo una persona que ha orientado sus estudios a la hostelería que otra que los ha orientado a la informática, de la misma manera que yo no puedo hacer una paella para 6 con los mismo resultados, eficiencia y eficacia que alguien formado para ello.

    Pero, si se prueba funcionalidad, se prueba que la aplicación hace lo que debe y que sobre todo, lo que el cliente quiere (y para lo que se ha especificado), que más me da saber programar en Phyton, en C++ o en Java? Es más, que más me da en que está programado? A ver, no hay que ser radical y como digo, cuantos más conocimientos técnicos, más te ayudarán a hacer tu trabajo y sobre todo, a llegar a un nivel de excelencia cada vez mayor. Si hay que probar un página web que está hecha en html5, pues me ayudarán a saber que sobre todo tengo que hacer pruebas de compatibilidad de navegadores y prestar atención a versiones de IE inferiores a la 8.

    Un tester tiene que encontrar errores, depurarlos y detallarlos hasta tal punto que cuando un desarrollador lo lea o se le explique, sepa dónde está el error y cómo corregirlo. Incluso si esos conocimientos técnicos ayudan para “abrir” los ojos al desarrollador o hacérselo ver de una forma más clara, olé, pero un tester no tiene que arreglar ese error. Lo primero, no es su función. Lo segundo, si tiene que ser su función, dejaría de ser tester y pasaría a ser desarrollador y por consiguiente, entraríamos en el mismo bucle defendido por todos de “nadie ve sus propios errores de una forma tan clara como se ven desde fuera”.

    Yo llevo 12 años en el mundo de la calidad, QA, testeo o como lo quieran llamar dependiendo de la época, fecha o temporada (todo va por modas…). No se programar, lo reconozco. Sé que es un IF, un FOR, como funcionan… pero no señores, no se programar. Si tengo que hacer el “Hola mundo”, me llevaría tiempo, sobre todo por las labores de investigación, que se me antojan arduas. Llevo 12 años sin tirar una sola línea de código, curiosamente desde que acabe de estudiar. Curiosamente, desde que orienté mi carrera laboral al mundo de las pruebas. No sé si será mi fin o estaré cavando mi propia tumba, pero de momento, la experiencia me dice que no es así. Y sobre todo, NO quiero programar. Si quisiera programar, no sería tester. Al menos funcional.

    El otro día asistí a una charla coloquio aquí en Madrid en la que uno de los 2 ponentes, era Toni Robles. Me he quedado un poco perplejo, puesto que una persona del publico sugirió eso mismo, que los testers deben o tendrán que tender a desaparecer porque tienen que orientarse más a la programación. Toni no defendía eso. Sí unos conocimientos técnicos (y cuantos más mejor), pero siempre separando el desarrollo del QA. La charla trataba sobre los logros en sus proyectos gracias al agilismo. Sinceramente, yo no los ví. Pero eso lo podemos discutir en otro hilo, discutir sobre los “grandes beneficios” del agilismo.

    En resumen, para ser un buen tester, lo primero, te tiene que gustar. Tiene que motivarte la labor, tener el gusanillo y no quemarte (ni que te quemen). Hay que tener una base de conocimientos, que va creciendo con la experiencia y sobre todo, orientar ese crecimiento correctamente. Saber programar, dependiendo de la labor y tipos de pruebas que haga. Las ofertas publicadas… mal, mal, mal.

    Siento el chorrazo, que más que comentario parece una entrada en tu blog, pero como a ti, me cabrea muchísimo este tema (como creo que ha quedado claro).

    Un saludo

    • Arthur, fantástico como siempre. Gracias por la sinceridad y por la extensión (en serio).

      De todo, me quedo con la idea de “no hay que ser radicales”, pero en general. Los posicionamientos extremos (“mesiánicos” como dice Ramón, mi amigo, mentor y jefe) tienden a no ser buenos y a no dejarnos ver la foto de las cosas en su totalidad. Eso es lo que me gustaría que pasara en términos de recruitment, que los “ponedores” de ofertas entendieran bien qué es el testing y qué cosas puede contener antes de requerir como imprescindibles grandes exageraciones técnicas y de negocio, que las hay.

      Saludos, espero leerte pronto!

  2. Gracias a ti por darnos la oportunidad de hablar, incluso largo y profundo, sobre estos temas.

    Ya sabes, es que me pongo a explicar lo que pienso de forma tan detallada y…. jajajaja (deformación profesional).

    Un saludo!

  3. Estimados Mauri y Arthur, un placer haber leído el artículo y sus comentarios, me reí mucho además de hacerme reflexionar de igual o más manera.

    Vengo siguiendo los artículos de este blog, e incluso algunos de ellos lo he publicado en mi blog y en el grupo de discusión que administro en linkedin para generar difusión y debate acerca de esta problemática.

    También leí el artículo de Antonio Robres Turon porque es miembro de mi grupo de discusión en linkedin y este tema generó un buen debate entre sus miembros.

    Les dejo algunos de los comentarios que publicaron sus miembros:

    //
    “Antonio, algo similar me sucedía cuando daba seminarios sobre testing. Por supuesto que un tester tiene que tener conocimientos básicos de programación, al menos saber SQL y algún lenguaje de scripting como Bash o el Shell de Windows.

    Estoy de acuerdo en los puntos del blog y agrego otros:

    Automatización: Testers, no soñar con herramientas milagrosas, por más caras que sean, siempre hay que programar.Interfáz por línea de comando, API o servicio web:

    Hay sistemas completos que carecen de GUI, ¿qué hace el tester?.

    Técnicas: Lastécnicas de diseño de caja blanca requieren saber como funciona el código fuente o la estructura de los componentes. Si bien esto se le atribuye a los desarrolladores, generalmente estos no las conocen o no las entienden y puede que un tester tenga que colaborar en el diseño de las pruebas o incluso diseñarlas e implementarlas el mismo.

    Hay más beneficios, pero estos son los más importantes a mi criterio.”
    //

    //

    Estimados: Entiendo que si tienen conocimientos programación (es mas deberían haber programado por al menos 1 año) y muy productivo para conocer como piensa el programador y situarse frente a distintos escenarios para entender que esta sucediendo y por donde podría estar el problema, desde el punto de vista funcional y de lógica. También me paso que en una presentación comente algo parecido y tampoco les gusto a los participantes. Trabajo con un equipo donde hay informáticos y funcionales no informáticos, y les puedo asegurar que ven los temas en forma diferente.”
    //

    //
    “En mi opinión no es obligatorio programar, pero si es un plus a favor tener algún conocimiento básico, aunque sea de lógica, después depende también en que organización se va a desempeñar, si es una organización madura el desempeño es mucho mas fácil, al desarrolla la tarea, todos los sectores acompañan al proceso, en empresas inmaduras se complica la tarea, no todos hablan el mismo idioma, me refiero de la tarea a realizar, las ideas son poco claras, y por ende la tarea será un fiel reflejo de la empresa, quizás arman un sector de testing sin antes haber echo un estudio o análisis previo de que es lo que se quiere realizar, y como “escuchan” que existe un testing automático apuestan a eso por que la creencia es que eso los va a salvar de los errores y defectos que están teniendo en el proceso, y además todo va a ser mas rápido, con lo cual, el resultado es algo complejo, sin objetivos claros, gente con poca adaptación y que ademas al momento de pedir información un tanto mas amplia no sepan que es lo que se les esta pidiendo, obviamente la documentación brilla por su ausencia.
    “//

    En fin, al igual que Arthur, tampoco se programar ni lo quiero hacer, y me siento muy bien, pero bue, es todo un tema éste que hay que seguir de cerca para ver como se va actualizando (o mutando)

    Si quieren, dsp les paso la dirección del grupo para que puedan unirse si gustan, y así no solo estar al tanto de otras opiniones sino además de participar de debates, y hasta incluso, generarlos.

    Gracias por todo y sigamos discutiendo acerca de nuestra actividad
    Un gran saludo desde Argentina (Buenos Aires)

    • Gustavo, encantado de conocerte al fin! Yo también sigo testingBaires desde la distancia, me alegra saludarte y que hayas disfrutado del post a la par de que estés de acuerdo.

      Por favor, por supuesto, deja la dirección del grupo de discusión que administras para que este humilde blog pueda ayudar a la difusión del mismo.

      Un saludo desde Barcelona!

  4. Buenas!

    Efectivamente y como ya viste Arthur, yo me desmarco del radicalismo que algunas personas del público sugerían. Pero aun así creo que es importante como crecimiento personal y profesional (y siempre lo he indicado como sugerencia) que la gente se adentre un poco más en su mundo profesional incluyendo la programación y sobretodo la parte de diseño de software (incluyendo DBs, web o lo que sea necesario para tu proyecto).

    Voy a poner un ejemplo muy claro… imaginate que te quieres comprar una casa, y contratas a una persona para que evalué una casa y que te diga si esta bien o no. Esa persona que evalua hace un tests de caja negra (es decir, mira que la distribución este correcta, que tenga luz, que no haya problemas visibles…) y te dice, oye la casa esta perfecta! Un chollo vamos! Tu le haces caso, y compras la casa.

    Dos años más tarde descubres que la casa tiene un problema de estructura o que tiene aluminosis… y te preguntas… como puede ser? si me dijeron que estaba perfecta! Si contrate a alguien para que me dijera si estaba bien?

    Este mismo ejemplo se puede asignar a nuestra disciplina, por supuesto que nuestra baza fuerte ha de ser el testing puro, pero también es importante conocer el interior de la estructura aunque sea de forma básica, ya que nuestro trabaja se basa en eso… ingeniería de software. Es por eso que defiendo siempre que debemos tener una base de ingeniería, algo que nos permita ser algo más que puros usuarios. No nos hemos de hacer unos expertos en programación, para eso ya estan los programadores, pero si entender su trabajo desde su óptica también porque al fin y al cabo es lo que hemos de validar.

    Yo sinceramente no soy un portento programando… es más siempre he dicho que no quería dedicarme a programar, porque no me motiva hacerlo 8 horas al día, aunque si que me gusta investigar, ver como se hacen las cosas, ver porque funcionan, y ese es el motivo por el que me gusta aprender algunas cosas de programación. Lo hago porque tengo esa curiosidad, y esa motivación y creo que es una buena skill y la valoro.

    Yo cuando busco a alguien no descarto a nadie por no saber programar, o por no saber una tecnología. Todo eso se aprende… lo que quiero es ver la actitud y predisposición de aprender lo que sea necesario para el proyecto.

    No se si me he explicado bien, pero espero haberos aclarado cual es mi postura :p

  5. Añadir otro ejemplo muy claro… justamente en ti Mauri… tu dices que no eres un tester tecnico, pero eres una persona que se ha movido, que se miro de realizar una introducción a Ruby, que esta realizando el Code Year… esa es la actitud que hay que buscar, más que alguien que ya sea un experto en ello! :p

    Luego me pagas el jamon por haberte dado publicidad :p

    • Gracias Toni por tus comentarios y por clarificar tu postura tan didácticamente. Por otro lado, lo del jamón lo dejamos en tablas, que el primero en publicitar al otro en este post he sido yo 😛

      Nos vemos pronto!

  6. Hola Mauri, Toni,

    Toni, gracias por la aclaración. Perfecto. Por eso dije en mi comentario que me quedé un poco perplejo, porque estuve el miércoles en Madrid y presencié la discusión con la parte más radical del público.

    Yo entiendo que haya que tener una base y tener nociones, pero sigo defendiendo que no es imprescindible. Al igual que si un tester sabe de programación, no tiene que arreglar el bug, porque lo más seguro que luego no detecte el que haya podido cometer. Si me parece fundamental el ayudar al desarrollador a detectar y solucionarlo, pero creo que con el conocimiento de la aplicación y una base, puede ser suficiente.

    Y también defiendo que hay tester para todo, es decir, para automatizar claramente no hay que tener bases, hay que saber. Y saber bien, para hacer unos tests perfectos (o casi perfectos). Y no quiero entrar en el debate de “expertos” o “especialistas”, que también trajo (y trae) cola ;).

    Un placer hablar con vosotros sobre el tema y compartir impresiones e ideas.

    Saludos a todos

  7. Perdón, un inciso con el ejemplo de la casa, Toni:

    Tienes razón, que la persona que prueba la luz y el agua y te dijo que todo está correcto no te dijo que tenía aluminosis… pero es que tampoco podría decírtelo, tendrías que haber recurrido a la otra persona para que examine el resto: cimientos, materiales…

    Digamos que tus pruebas de la casa se han quedado cojas. Me refiero a que hay gente que cumple determinadas funciones.

    Quizá la persona que hubiera detectado la aluminosis podría haber certificado que la luz funciona al darle al interruptor y que sale agua al abrir el grifo, pero seguramente no hubiera visto que al pulsar el interruptor 10 veces habría empezado a fallar, o que si abre todos los grifos a la vez de uno deja de salir agua por falta de presión…

    Un saludo y gracias de nuevo!

  8. Pingback: [Encuesta - Resultados] Demuestra tus asunciones! | Testing funcional

  9. Pingback: Verano para autodidactas | Testing funcional

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s