Testers vs Developers: Round 1
Advertencia: cualquier parecido del título con la realidad es mera coincidencia.
Durante años se ha tenido la creencia de que los testers (ingenieros de pruebas de software) y los developers (desarrolladores de software, programadores) no se llevan bien… y quizá en la práctica sea del todo cierto.
También se han tenido las creencias de que los testers son personas que no hacen nada (menospreciándolos), que su trabajo es fácil, que su trabajo es inútil, que no saben programar o que se la pasan fastidiando a los developers en su trabajo.
Y, por el lado de los developers, siempre se ha creído que son personas egocéntricas y poco proactivas, que no tienen imaginación, que lo ven todo cuadrado, que no piensan en el cliente y que se fastidian cuando les demuestran sus errores.
Todo lo anterior es parte de los tabús que tenemos los ingenieros en sistemas computacionales acerca de ambas especialidades.
Pues bien, en un ambiente muy entretenido, el pasado 3 de septiembre de 2018, se llevó a cabo el primer meet-up (encuentro) denominado Testers vs Developers: Round 1, en Guadalajara (Jalisco). Tres developers y tres testers debatieron y compartieron sus experiencias en el área de desarrollo de software; además, respondieron preguntas del público presente y algunas planteadas por el moderador.
Debo admitir que el equipo de testers estaba muy bien preparado y que el equipo de developers era demasiado pasivo —no porque actualmente sea tester significa que les tenga mayor simpatía a los de mi bando, pero la evidencia es clara—. Sin embargo, las respuestas dadas por ambos equipos fueron muy constructivas.
Se habló acerca de los mitos que existen entre ambas profesiones y su mutua enemistad, sobre quién tiene la culpa (o a quién echársela) cuando el flujo de trabajo no fluye como debería o cuando el producto no cumple con las especificaciones del cliente, qué rol es innecesario, quién es quien tiene mayor carga de trabajo y quién gana (o debería ganar) más.
Sobre estos diferentes puntos que se trataron, hubo uno que, quizá, sea el más importante de todos: ¿a quién se le echa, o debe echar, la culpa?
 |
| Foto: Mutuo. |
En palabras de Francisco Valdovines (Sr. QA y PM en Agave Lab): «La culpa es del equipo, no solamente de una sola persona». Y esto es muy cierto. Si el producto en desarrollo no está cubriendo los requerimientos que el cliente solicita, significa que algo anda mal, y no es cosa de una sola persona.
Es cierto, muchas veces el cliente no sabe lo que quiere y pide nuevos cambios a mitad de los sprints (esfuerzos finales)… o, de plano, a veces quiere que se rehaga todo. Pero si el equipo no define bien con el cliente cuál será el alcance del proyecto, las estimaciones del tiempo, la cantidad de gente requerida para desarrollar y probar, costos, etcétera, entonces la culpa es compartida.
El cliente también es partícipe de esta culpa cuando no define lo que (realmente) necesita. Dedebmos hacerle notar, de la manera más amable y diplomática, que no siempre tiene la razón.
 |
| Foto: Mutuo. |
Implícitamente, Francisco habló sobre soft skills (habilidades blandas) en este punto. Reconocer con humildad que nos hemos equivocado nos ayuda como developers y testers, a mejorar en nuestro trabajo y nuestras relaciones humanas. Aceptar nuestros errores es bueno, aunque muchas veces nos cueste vencer el orgullo.
Preguntarnos cuál rol es mejor sería completamente inútil. Desde mi punto de vista, ambos roles son indispensables para el desarrollo de software. Y claro, también lo son los DevOps, y Supports (ingenieros de soporte), Tech Leads (líderes técnicos), Team Leads (líderes de equipo), Project Managers (administradores de proyecto), SCRUM Masters (maestros SCRUM), la persona que realiza el aseo del lugar, etcétera.
Influyen también mucho el lugar de trabajo, cómo se administran los proyectos, el edificio y sus inmuebles, el equipo físico y humano de trabajo, las prestaciones salariales, los benefits & perks (beneficios y ventajas), el tipo de proyectos y clientes que tiene la empresa, el career path (plan de carrera), el crecimiento profesional, etcétera.
 |
| Foto: Mutuo. |
En resumen, son especialidades no excluyentes, pues se necesita de alguien para desarrollar el producto que el cliente requiere y de otro más para validar y certificar que lo desarrollado cumpla con los requerimientos del cliente.
Por cierto, estén al pendiente de mi próxima serie de entrevistas sobre ingeniería de software: entrevistaré a un developer y a un tester, quienes compartirán su percepción y experiencia acerca de este maravilloso mundo del desarrollo de software.
Y, si están buscando trabajo como developer o tester, siéntanse libres de mandarme su currículum a armando.cifuentes@itexico.net.
Comentarios
Publicar un comentario