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. :-|
5 años de TRAC, 8 horas de JIRA
La empresa en la que trabajo, netquest, está en pleno proceso de cambio. La compañía ha mantenido un ritmo de crecimiento sostenido desde su fundación hace ya más de 10 años y, a parte de los retos comerciales y productivos a los que se ha ido enfrentando, también ha tenido que ir haciendo los deberes en lo que a organización interna se refiere, puesto que no es lo mismo gestionar la actividad de 5 personas (2003) a la de más de 50 personas repartidas en 5 ciudades y 4 países distintos (2011).
Sin ir más lejos, y ya entrando en materia, el ciclo del desarrollo de software ha venido funcionando con el TRAC como herramienta de bug-tracking. Hasta aquí, ningún problema, me gusta el TRAC, es un bug-tracker sencillo pero potente. Sin embargo, la tecnología de netquest tiene una característica que hace que algunos procesos sean algo distintos con el resto de empresas que fabrican software: las aplicaciones son de uso interno. Entonces, rápidamente, el TRAC se estableció también como la herramienta para que los usuarios registraran bugs, nuevas funcionalidades y propuestas de mejora.
Aquí ya empiezan las “hostilidades”, puesto que el bug-tracker está preparado y configurado para ser usado por miembros del equipo de desarrollo, en cambio el usuario final de las aplicaciones encuentra dificultades en la multiplicidad de campos presentes en el formulario y que no tienen sentido para él (cosas como Componente, Severity, Versión, Milestone… sin mencionar los campos predefinidos incorporados especialmente para el desarrollo de los proyectos).
Esto se puede superar con una buena documentación sobre cómo abrir buenos tickets (que así se llaman en el TRAC) y con la comprensión del usuario final (que debe cultivarse y mantenerse). Pero claro, la cosa se complica aún más si, dada la costumbre en el uso del bug-tracker, la herramienta se establece como la solución de helpdesk productivo de la compañía (aclaración: el ciclo productivo de netquest pasa por un uso intensivo de las aplicaciones desarrolladas en el área tecnológica por parte de los usuarios internos finales de las mismas), además este helpdesk ha ido evolucionando hacia un soporte de proyectos, tratando múltiples temas, no todos relacionados con las aplicaciones (por tanto, no competiendo todas ellas al departamento de desarrollo).
Total, que sin darnos cuenta (ejem…) tenemos un bug-tracker usado por toda la empresa para 3 cosas distintas:
- Gestión del ciclo de desarrollo tecnológico de las aplicaciones.
- Buzón de sugerencias de nuevas funcionalidades y mejoras, así como bugs encontrados en producción.
- Herramienta de helpdesk sobre aplicaciones y uso de las mismas en proyectos.
Esto, en términos prácticos, podemos verlo como 2 proyectos distintos, el desarrollo y mantenimiento de las aplicaciones (puntos 1 y 2 anteriores) y el helpdesk sobre el uso de las mismas y derivados. Cada uno de estos proyectos requiere sus campos, sus flujos, sus tareas, su funcionamiento, sus reports… El TRAC no puede proporcionar correctamente esa segmentación según su implementación inicial. Qué podemos hacer en este punto?
- Tirar de plugins y trac-hacks, para customizar la herramienta a nuestra medida.
- Desarrollar internamente los plugins necesarios, si lo anterior no fuera suficiente.
- Cambiar de herramienta (siempre hay que estar preparado para esto).
La primera se ha demostrado inútil según nuestras necesidades; la segunda requiere tiempo de desarrolladores (que dejan de dedicarlo a las aplicaciones correspondientes), cosa dificil de justificar. Solo nos queda la tercera. Si además añadimos a la equación que el ciclo la empresa necesita una renovación y mejora en sus procesos (implicando al bug-tracker o similar), apenas hay salida.
Total, que estamos evaluando la implantación de JIRA en la empresa.
Es muy difícil sacar tiempo para investigar o evaluar herramientas nuevas mientras tiras adelante tus tareas habituales. Lamentablemente solo he podido dedicar 8 horas de los 30 días de evaluación que hemos tenido, suerte que no era el único evaluador… 
Mi conclusión resumida es:
Wowwww.
Me explicaré, solo han sido 8 horas de inmersión, pero ni con 8 semanas te acabas todo lo que hay. JIRA es una herramienta enorme, sí sí, he dicho…
ENORME
Así de salida, creo que vamos sobrados con ella para hacer lo que queremos hacer y hacerlo tan bien que suponga un salto productivo de impacto, así como mejorar mucho en la eficiencia de la producción y el desarrollo.
En concreto, desde mi breve punto de vista, los aspectos que me han llevado a pensar así son:
1. Customización total, total de TODO:
Sea lo que sea lo que necesites, la interfície de la herramienta te lo permite hacer de manera sencilla, desde modificar los evidentes look & feel de la aplicación, proyectos, componentes, tipos de issues (que así se llaman en JIRA) hasta patrones de notificación en caso de modificaciones de issues, esquemas de permisos, nuevos campos de todos los tipos (textuales, menus de selección, checkboxes…), lo que necesites para customizar los formularios de apertura de nuevos issues. Ah, estos formularios pueden ser distintos según el tipo de issue que estés abriendo, también 
2. Herramienta diseñada para gestionar múltiples proyectos personalizados:
Esto nos va de perlas, puesto que era la principal deficiencia del TRAC. Además, JIRA no solo está pensado para gestionar distintos proyectos, sino que también permite gestionarlos de un modo distinto.
Los elementos que usan los proyectos (como los issues, los permisos, los usuarios y sus grupos, los flujos de issues…) se pueden customizar para cada uno de los proyectos. Por ejemplo, puedes tener un formulario muy simple para que los usuarios finales puedan registrar bugs encontrados durante el uso de las aplicaciones (dentro del proyecto de Helpdesk, por decir algo) y un formulario mucho más complejo y ajustado al ciclo de desarrollo para registrar bugs encontrados por el departamento de QA o los propios desarrolladores (dentro del proyecto de la aplicación X) y, si hubiera puntos de contacto entre proyectos (por ejemplo propuestas de mejora de aplicaciones logueadas en el proyecto de Helpdesk que debieran trasladarse al proyecto de desarrollo de la aplicación), los issues se pueden mover o clonar entre proyectos automáticamente y sin ningún problema.
Además, no solo JIRA está pensada para gestionar múltiples proyectos, sino que también está preparada para gestionar proyectos de todos los tipos, más allá del desarrollo tecnológico. Y eso, a la vista de la versatilidad ofrecida, se nota oiga. El gran ejemplo aquí son las sub-tasks, issues que están contenidos dentro de otros issues, como cuando una historia de usuario requiere distintas tareas de implementación, cada una de ellas con su estimación temporal de entrega, volumen de trabajo pendiente, etc.
3. Workflows, transitions y post functions
Rizando el rizo, el más difícil todavía. Además de customizar lo que quieras y añadirlo a los proyectos que tu quieras, en JIRA se puede configurar el flujo de los issues (workflow), sus estados y los movimientos de los mismos según el estado en el que se encuentran (transitions). Era necesario que así fuera, puesto que usar la aplicación para (por ejemplo) gestionar un ciclo de proyectos no tecnológico con el clásico flujo de bug-tracker reporter-developer-tester-closed no hubiera funcionado.
Workflow por defecto de JIRA (imagen sacada de la documentación oficial de Atlassian)
Pero lo mejor de este punto son las post functions, acciones que realiza la aplicación automáticamente dada una transition concreta. JIRA ofrece de salida un conjunto de post functions ya programadas (como actualizar campos del issue, disparar un mail al reporter original…) y permite al administrador programar las post functions que necesite para que sean disparadas en la ejecución de las transiciones. A partir de aquí, no hay límites, puedes montarte tu proyecto con tus componentes y tus flujos de trabajo, sin restricciones.
Además…
Por supuesto, todo viene con más documentación de la que pueda procesarse y guias, tutoriales para todos los niveles. Por otro lado, JIRA también ofrece soporte, obvio ya que es una herramienta de pago, y necesario, puesto que es fácil perderse en la enormidad y complejidad de la misma.
Para terminar, la usabilidad para el usuario es máxima, la navegación es sencilla, los links y el acceso a las acciones que necesitas en cada momento están en la pantalla en la que te encuentras cuando los necesitas (también con shortcuts!); puedes configurarte tu propio dashboard y compartirlo con otros usuarios, y un sinfín de etcéteras…
Lo único sería…
Si tuviera que decir algo que no haya visto claro sería la parte de reporting sobre issues. Así como en el TRAC, el reporting era sencillo y potente (configurable mediante UI, TracQuery language o el lenguaje de la DB que tuvieras debajo), JIRA viene de salida con un conjunto de reports establecidos y no queda claro que hay que hacer si quieres otros, no encuentro donde se configuran como administrador y en la documentación parece ser que debes referirte a un plugin que permite programar los reports en JAVA, pero tampoco queda demasiado claro.
En resumen:
Dada la customización, potencia, versatilidad y multidimensionalidad de JIRA, me inclino a pensar que es la herramienta que necesitamos en netquest en el momento presente, y no puedo esperar a que se implante para comprobarlo!!!
Lo que se esconde detrás de un máximo de caracteres
Es ideal que los QAs y los testers estén involucrados en la captura de requerimientos y su posterior conversión en especificaciones. El agilismo así lo defiende y yo lo comparto, puesto que permite reconocer y alertar sobre áreas de riesgo, detectar potenciales problemas futuros, conocer de antemano los detalles de la funcionalidad que va a venir, adelantar el diseño de las pruebas… Es ideal, pero no siempre es posible.
En esos casos, la documentación disponible es de cosas ya hechas; es decir, funcionalidad ya implementada. En esa documentación pueden faltar detalles de implementación o meta-conocimiento del que disfrutaríamos si hubiéramos estado involucrados desde en un principio.
Hay varias maneras de recuperar ese terreno perdido, la idea de “Show & Tell” de Darren McMillan me parece fantástica (por la que el desarrollador hace una “demo” de la funcionalidad al tester, antes de submitar el código al repositório). Otra manera es mediante el própio testing exploratorio, mediante la própia exploración de la funcionalidad, apretando las tuercas a cada frase, cada palabra, cada coma, de la especificación de lo testeado.
En cualquier caso, los objetivos son los mismos:
- Disponer del conocimiento máximo de las aplicaciones a testear
- En caso de que el objetivo anterior no se cumpla, hacer todo lo que esté en nuestra mano para conseguirlo
Este objetivo no es un fin en sí mismo, es un medio para hacer mejor nuestro trabajo. Por ejemplo, un caso real con el que me he encontrado esta misma semana: nueva funcionalidad para una aplicación, me puedo incorporar a testearla sin haber podido participar en su concepción, luego valido y re-valido todo lo que dice en la especificación que viene con la funcionalidad, y me encuentro con…
El campo XXX puede albergar un máximo de 256 caracteres.
“Eso habrá que verlo”, me digo. Y no era así, admitía 255, uno menos de lo esperado y especificado. En este punto, me podría haber parado, reportar el defecto y a otra cosa, pero en ello no ganaba conocimiento, luego me pregunté…
Y de dónde viene esta limitación?
Un dato así, a grandes rasgos, puede venir de…
- Exigencia expresa transmitida por el equipo de negocio
- Limitación técnica
- “Había que poner un máximo y no sabíamos cual”
Es fácil salir de dudas, preguntando al desarrollador responsable de la funcionalidad. En este caso, se trataba de (2): el límite viene del ancho de la columna de la base de datos que almacena el valor en el campo. Pero había un detalle, el campo es de tipo tinytext, cuyo ancho máximo es 255 caracteres y no 256, luego esto no es un defecto, es una errata en la documentación y ya está, puesto que no había problema por parte de negocio en que el campo tuviera una capacidad de 255 caracteres.
Learnings del caso concreto:
- Saber de donde viene el máximo establecido en el campo concreto
- Un defecto menos en el bugtracker, una errata corregida en la documentación
- Aprender que el tipo de dato tinytext en SQL admite hasta 255 caracteres, útil para futuras pruebas de esta y otras funcionalidades.
Admito que no es un aprendizaje enorme ni me va a arrojar luz sobre las grandes dudas del testing o de la humanidad, pero si de cada pequeño cambio en una funcionalidad sacamos un conocimiento así, al cabo de un tiempo estaremos bastante más cerca del conocimiento máximo de las aplicaciones que testeamos.
Steve Jobs, on hiring and recruitment…
If you want to hire great people and have them stay working for you, you have to let them make a lot of decisions and you have to be run by ideas, not hierarchy. The best ideas have to win, otherwise good people don’t stay.
