Los tests automáticos tienen sentimientos

…y no solo sentimientos, también pueden tener bugs. Incluso peor, pueden fallar ocasionalmente (flaky tests en anglosajón) y ello puede llevar a ponerlos en cuarentena en la ejecución de los builds bajo el lema “ya arreglaremos los tests más tarde”, un “más tarde” que no llega nunca, perdiendo cobertura de pruebas lenta y dolorosamente.

Ignorar temporalmente tests que fallan a veces para conseguir un “green build” es válido, pero no arreglar o eliminar esos tests que no son de confianza no lo es. Con esta idea en mente escribí esta carta en nombre de un test ignorado, publicada en el blog de desarrollo de Atlassian.

Espero que te guste 🙂

De testers y code reviews

Hola, me llamo Mauri y yo también he ignorado las revisiones de código con la excusa de que son “terreno de los desarrolladores”.

¡Pero ya no! Desde que trabajo en Atlassian que me he dado cuenta que, para que la calidad escale con el desarrollo, hay que invertir esfuerzos en la prevención por delante del control o la mitigación, y un buen lugar para prevenir son las revisiones de código, que acostumbran a ocurrir antes de cualquier testing hands-on.

STASH13_PRactivity

Y no quiero oir a nadie diciendo cosas del estilo “pero yo no soy desarrollador” o “es que no sé leer código”, porque no hace falta ser un developercon213añosdeexperiencia para mirarse una revisión de código. Además, leer código es más fácil de lo que aparenta, y las revisiones de código son un buen lugar por donde empezar, ya que los cambios estan asociados a una funcionalidad o bugfix, de tal manera que el código se puede vincular fácilmente a su objetivo.

Listado de 5 cosas al azar que te interesan, como tester, de las revisión de código:

  1. Mayor conocimiento de los sistemas y aplicaciones: como tester más funcional, seguro que ya te conoces todos los recovecos de la interfaz de usuario, ¿por qué no ampliar ese conocimiento con nociones del funcionamiento de la cara interna de las aplicaciones?
  2. Inspiración para futuras fases de pruebas: dependencias inesperadas, secciones complejas, condicionales gigantes, dudas sin resolver expresadas en los comentarios… Este tipo de cosas son pistas invaluables para exprimir las aplicaciones durante la fase de pruebas. Este conocimiento, bien usado y con práctica, hace que el testing sea como jugar al Trivial Pursuit consultando la Wikipedia.
  3. Mejores tests automáticos: el input de un tester en las pruebas automatizadas que vengan con el código (tests unitários, de integración o de lo que sea) puede ser muy útil para que las nuevas funcionalidades nazcan con una cobertura exhaustiva e útil, más allá de los happy paths.
  4. Se cazan bugs también! Que sí, que sí, que se puede! Y no solo bugs, también comentarios confusos, errores de formato, secciones poco claras, tests unitarios que no testean nada… Las revisiones de código son el momento idóneo para corregir este tipo de problemas.
  5. Respeto: también puedes ganarte (más) el respeto de los desarrolladores con tu participación e interés en las revisiones de código, gracias a tus consejos y aportaciones en las mismas. Sabrás que estás por el buen camino cuando tu input sea solicitado en ellas o (todavía mejor) cuando algún desarrollador te pida consejo sobre qué casos de prueba automatizar ¡en la fase de codificación!

Estas son las mías, pero hay muchas más razones por las que, como tester, puede ser interesante participar en las revisiones de código. ¿Cuáles son las tuyas? ¡Cuéntamelo en los comentarios!

Verano para autodidactas

Tras terminar el semestre universitario (por si alguien no lo sabe, estoy estudiando el Grado en Ingenieria Informática en la UOC) empieza el mejor periodo del año para los autodidactas: el Verano! Una estación donde solamente hay que trabajar (o ni eso, si tienes vacaciones) y se abre casi un trimestre para estudiar, investigar y aprender lo que uno quiera!

Personalmente, me gusta marcarme unos objetivos claros para no caer en la dispersión y agotar el tiempo sin haber hecho nada concreto. Tener unos objetivos y un plazo claros también te ayuda a ser consciente de tus progresos y del grado de esfuerzo necesario en cada momento. Así pues, mis objetivos en este verano para autodidactas 2013 son los siguientes:

Reflexionando mucho sobre este tema quiero realizar las siguientes tareas para mejorar mi profundidad técnica en lo que al testing se refiere:

Realizar el curso “Technical web testing 101” → Completed!

Fantástico curso para entender las diferencias entre testing técnico y testing de la superfície. Gratuito, breve pero intenso, on-line, con un profesor de nivel como Alan Richardson (The Evil Tester) y repleto de información, este curso (alojado en la plataforma de aprendizaje on-line Udemy) es ideal para principiantes y testers cero-técnicos con interés en barnizar su trabajo con una capa de mayor profundidad técnica a la hora de testear aplicaciones web. Es un curso de básicos con muchos punteros a información, recursos, herramientas, trucos y demás material para investigar por cuenta própia, con una filosofía muy del DIY, de conocer las herramientas que tienes a tu disposición (especialmente los navegadores y los proxies HTTP) y de encontrar la motivación dentro de uno mismo para investigar y preguntar hasta entender todo aquello que desconocemos, olvidándonos de la frontera entre lo que es técnico o no, lo que es testing y lo que no, en pro del conocimiento.

Os dejo el link del curso, en inglés (of course) → https://www.udemy.com/technical-web-testing-101/

Completar el track de jQuery en Codecademy → In progress

En mi dominio, tener nociones de HTML, CSS, JavaScript y jQuery es esencial, por ello me valgo de la fantástica plataforma  codecademy para alimentar esos conocimientos. En concreto ahora estoy en plena track de jQuery, el último que me falta, a terminar muy en breve, como puedes ver en mi perfil.

Adquirir nociones de Java → To start

Siempre he querido tener nociones de lenguajes de programación, y en mi trabajo disecciono diáriamente aplicaciones basadas en Java, así que ¿por qué no profundizar en este lenguaje? Para ello, cuento con este libro electrónico (también de Alan Richardson) llamado Java for testers, que parece un muy buen punto de partida para el nivel que quiero alcanzar (que no es el de ser un superdesarrollador, más bien el de entender los fundamentos para poder jugar con ellos).

Por otro lado, hace tiempo que quiero investigar sobre las posibles especializaciones dentro del testing (usabilidad, rendimiento, seguridad…) y aprovecharé este verano para…

Profundizar en el testing de seguridad → To start

Unas nociones superbásicas de este tema apasionante ya se tocan en el curso de “Technical web testing 101” del que ya os he hablado antes, y para profundizar más, tomaré este otro curso también en Udemy: Whitehat hacking and penetration testing, a ver cómo evoluciona!

Para terminar, y pensando en la charla que daré en la próxima edición de la conferencia QA&TEST 2013, quiero…

Mejorar mi inglés hablado! → In progress

Para ello, me he apuntado a un grupo de conversación en inglés que hay en mi barrio, un día cada dos semanas, para quitarle el óxido a esta habilidad cuya precisión depende totalmente del nivel de práctica que lleves encima.

Este es mi plan, y el tuyo? Qué te vas a auto-enseñar durante este verano? Cuéntamelo en los comentarios 😉

Reportar defectos ES comunicarse!

The Testing Planet ha publicado un texto mío sobre el bug-reporting y como encajarlo dentro de nuestra estrategia de comunicación como testers para con el resto del mundo. Aquí lo tienes: http://www.ministryoftesting.com/2013/06/dude-pen/

Image

En el artículo, propongo un nuevo mnemotécnico para pulir nuestros reportes de defectos: DUDE, PEN!. Un buen defect report es (como mínimo y en inglés):

  • Direct
  • Unique
  • Documented
  • Entire
  • Prioritised
  • Easy to find
  • Neutral

Espero que te guste! Me dejas tu opinión en los comentarios? 😉

Trucos de Selenium IDE – Intro, recording, waiting

Trucos de Selenium IDE – Intro, recording, waiting

Hasta ahora, Selenium IDE me ha salvado mi vida de tester suficientes veces como para decidir lo siguiente:

  1. Profundizar en esta herramienta esencial para los testers, con la intención de entender propiamente qué es, qué es lo que he estado haciendo con Selenium IDE, cómo puedo sacar mayor beneficio de la misma, etc.
  2. Difundir la palabra sobre esta herramienta (a veces) minusvalorada, defendiendo su honor y ayudando y animando a otros a profundizar, aprender e inspirarse de ella.

Qué mejor manera de hacer esto que blogear? Así que he desarrollado una pequeña serie de posts sobre Selenium IDE, explicando algunos trucos que hago servir, escribiendo porqué y cómo los uso, ya que… To blog is to learn!

Este primer post pretende introducir la serie, explicándonos qué es Selenium IDE y algunos conocimientos básicos sobre la misma. Allá vamos!

Qué es Selenium IDE?

Según SeleniumHQ (el site oficial del proyecto), Selenium IDE es un “add-on para Firefox que hace un sencillo Record-and-playback de interacciones con el navegador”. A partir de esta definición, concentrémonos en algunos conceptos:

  • IDE: IDE son las inciales de “Integrated Development Environment”, y esto quiere decir que estamos delante de una aplicación que nos ayudará a desarrollar utilidades relacionadas con el software.

  • Firefox: sí, Selenium IDE solamente está disponible para Firefox, así que no nos va a ayudar en la ejecución de cross-browser testing, pero es una herramienta ligera e inestimable para automatizar testing funcional de carácter general en navegador.

  • Add-on: un add-on para un navegador (también llamado una extensión del mismo) es un complemento instalable que añade funcionalidades o amplía las que tiene el navegador por defecto. Esto es lo que Selenium IDE nos ofrece, añade funcionalidades de record-and-playback de interacciones con el navegador a nuestro Firefox.

  • Record-and-playback: esto quedaría mejor com record and/or playback. Puedes grabar o no, pero en lo que estamos interesados es en el playback, en la reproducción, porque es lo que realmente nos porporciona capacidades automatizadoras, la reproducción de…

  • Interacciones con el navegador: este es el tema, esto es lo que Selenium IDE hace fantásticamente. Con este add-on podemos grabar, generar, gestionar y ejecutar interacciones von el navegador, simulando los clicks, selecciones, movimientos, escritura… de un usuario real en páginas web y su contenido.

Pues, para resumir esta sección con palabras sencillas, Selenium IDE es un pequeño complemento para nuestro navegador Firefox que nos permite simular interacciones de usuario vía navegador en páginas web. Con él, seremos capaces, entre otras cosas, de ejecutar testing funcional automatizado en navegador web.

Cuándo es Selenium IDE una buena elección para testing automático?

Con Selenium IDE podemos almacenar y organizar casos de test y suites, así que es posible tener una suite de suites automatizada a ejecutar con esta herramienta. Selenium IDE es potente (más de lo que parece), pero limitada; es una gran herramienta para casos de test sencillos pero no tan apropiada para casos más complejos (con muchas ramas, condicionales, casos y demás). Además, tal y como hemos dicho antes, sólo funciona con Firefox, así que si se necesita una herramienta para cubrir casos más complejos y/o funcionando en distintos navegadores, es mejor echarle un vistazo a Selenium Webdriver o Watir. Hay herramientas comerciales que también podrán satisfacer estas necesidades.

Personalmente, yo la uso para ejecutar testing automático ligero, para repetir tareas tediosas pero simples durante una iteración o proyecto, pero sin el objetivo de almacenar o mantener esta automatización; haciendo esto, las pruebas se pueden desarrollar más rápido (aunque seguramente de forma sub-óptima), pero muy efectivas para el coste que implican. Además, Selenium IDE es un fantástico “facilitador” de testing no automático, ya que te puede ayudar en ejecutar rápida y robóticamente pasos tediosos y largos que dejan tu aplicación web lista para ser testeada, en un estado que  sea aburrido de conseguir. Automatizando el camino hasta este punto no estarás cansado ni enfadado, pero sí listo para ejecutar tu mejor testing en él! 🙂

El recording como inicio fácil…

La manera más fácil de empezar un caso de test con Selenium IDE es ejecutarlo manualmente con el botón de grabado a “on”; lamentablemente, hay muchas cosas que se escaparán de este grabado (eventos en background, esperas implicitas que ejecutamos como humanos sin darnos cuenta, cosas así). Por ejemplo, vamos a grabar una simple búsqueda en un motor de búsquedas, buscaremos el término “Software Testing” y veremos si luego aparece un link a la página de la Wikipedia sobre Software Testing en los resultados. Este es el código que obtengo tras grabar esto con Selenium IDE: 

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
clickAndWait id=search_button_homepage
verifyElementPresent link=More at Wikipedia

Este test se puede reproducir sin ninguno de los problemas antes mencionados, ya que el grabado de Selenium IDE es suficientemente listo como para convertir mi gesto de “click” en el botón de búsqueda en un comando “clickAndWait”. La referencia implícita (esta pestaña se encuentra en la consola del IDE) de este comando dice…

clickAndWait(locator)

Generated from click(locator)

Arguments:

     * locator – an element locator

Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad. 

Así que, virtualmente, el ejemplo anterior se corresponde al siguiente…

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
waitForPageToLoad 30000
verifyElementPresent link=More at Wikipedia

…donde el 30000 es simplemente un número arbitrário de milisegundos para llamar a un timeout una vez se hayan superado y la página no se haya cargado aún. El comando “clickAndWait” usa el timeout por defecto especificado en el menú “Options” del IDE, mientras que en “click” + “waitForPageToLoad” tenemos que especificarlo manualmente, luego puede ser mayor o menor que el timeout por defecto.

Podemos alcanzar algo similar usando el comando “pause” del siguiente modo: 

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
pause 30000
verifyElementPresent link=More at Wikipedia

Ejecutando este trozo de código podemos ver que la ejecución de este test SIEMPRE se espera 30 segundos (30000 milisegundos), sin importar si la página se cargó hace 20 segundos, cosa que suena mucho menos eficiente que las anteriores versiones. El tema es que necesitamos que se haga algo justo después de accionar el botón que nos asegure que la página (o recurso, o botón…) se haya cargado antes de seguir en nuestras comprobaciones, puesto que si tuviéramos el siguiente caso de test…

open http://duckduckgo.com/
type id=search_form_input_homepage Software Testing
click id=search_button_homepage
verifyElementPresent link=More at Wikipedia

…nuestro test seguramente fallaría ejecutándolo a la máxima velocidad, ya que le estamos diciendo a Selenium IDE que verifique justo después de hacer click, cuando resulta que este click provoca la carga de una página nueva, entonces verificar inmediatamente cosas sin esperar a que la página esté completamente cargada nos llevará fácilmente a que Selenium IDE verifique algo que todavía no puede encontrar, retornando un mensaje…

[error] false

…en la pestaña de log de la consola del IDE mientras ejecutaba el comando “verifyElementPresent”, puesto que cuando Selenium IDE está ejecutando este comando no hay link a la Wikipedia en la página (ya que esta no se ha cargado completamente todavía).

Final learnings

Grabar la ejecución de nuestros test cases nos ayudará a definir su esqueleto. Una vez hayamos hecho esto, conviene hacer debugging sobre los mismos (los breakpoints y las ejecuciones paso a paso nos ayudarán con ello) haciéndolos suficientemente robustos como para ser ejecutados a la máxima velocidad sin problemas, sin importar si la red de la oficina parece más lenta de lo normal.

Gracias por leer hasta el final y… nos vemos en el siguiente post de esta serie sobre Selenium IDE!

De casos de test a mapas mentales: una experiencia personal

De casos de test a mapas mentales: una experiencia personal

La mecha que prendió este post fue este comentario en una de mis entradas de análisis de herramientas de test case management, preguntando por el resultado de la investigación en este tema realizada al principio del año 2011. La búsqueda terminó al cabo de algunos meses, a medida que me iba dando cuenta de que una herramienta de este tipo no encajaba en mi contexto actual, pero nunca concluí la investigación oficialmente. No la estoy concluyendo ahora con este post, a lo mejor la retomo en el futuro, pero dos años después de sus inicios, el hecho es que hemos vivido y testeado adecuadamente sin casos de test ni herramientas de gestión de los mismos. Así es como lo hicimos.

Antes de empezar, no estoy intentando afirmar cuál es la mejor solución en este aspecto, esto es el relato de una experiencia personal solamente, un caso de estudio si queréis. Simplemente food for thought, cosas a considerar si os encontráis en esta situación. Espero os sirva de ayuda 🙂

Nuestro contexto

Intentaré resumir nuestro contexto en unas pocas líneas, contáctadme si no es suficiente para entender la situación:

  • 2 aplicaciones web-based
  • Ambas aplicaciones son maduras, con más de 3 años de existencia cada una
  • +500 casos de uso (y creciendo!), desde simples CRUD a grandes y complejos casos de integración de sistemas con interpretaciones condicionales y reglas de negocio implicadas
  • Un departamento de 2 testers, emparejado con un equipo de 4-5 developers superlistos
  • Un promedio de 2-3 releases al mes
  • Sin automatización disponible (en el momento de iniciar la investigación)

El primer número que me vino a la mente fue que necesitábamos una herramienta que gestionara como mínimo +500 casos de test (digamos, el happy path de cada uno de esos casos de uso), ergo se supone que tendremos que desarrollar esos +500 casos de test, y también se supone que tendremos que mantener esos +500 casos de test, sin reclutar nuevos compañeros ni reducir la velocidad de releases que defendemos.

No podíamos realizar esa inversión, nuestro foco hubiera pasado de testear a crear y mantener casos de test, con la sensación de que se trata de una tarea interminable, ya que hay casos de uso nuevos cada mes, más revisiones de los ya existentes, implicando nuevos casos de test a redactar y casos de test viejos a mantener, más en algún momento explorar los unhappy paths si teníamos tiempo.

Qué hacíamos mientrastanto?

Al principio de todo, 2 años antes de que esta búsqueda empezara, intentaba crear los casos de test en Excel al principio de la fase de testing (desarrollábamos bajo waterfall por aquél entonces) antes de testear efectivamente, de lo que aprendí lo siguiente:

  1. Los casos de test evolucionan mientras testeas, por ello tu manera de pensar y la herramienta que uses tiene que estar preparada para esto.
  2. El mantenimiento y la reutilización de los casos de test es un tema candente, difícil de gestionar en un entorno cambiante como el nuestro, por las razones antes mencionadas.

Con este enfoque, descubrí que invertía más tiempo creando, editando y adaptando a la situación actual mis casos de test en Excel que testeando efectivamente. Progresivamente, fui abandonando ideas; primero, abandoné la idea de reusar casos de test (con lo que el asunto del mantenimiento desapareció también); y después, abandoné la idea de preparar todo el conjunto de casos de test antes de empezar el testing, abrazando un diseño de testing y una ejecución más dinámicos. Estaba haciendo testing exploratorio sin saberlo, pero no me sentía cómodo con la idea de no tener documentación de test. Por esto último empecé la investigación de una herramienta de gestión de casos de test.

Y… Apareció el mind mapping!

Mientras investigaba herramientas concretas, intenté averiguar qué hacían otros profesionales en situaciones similares a la nuestra, y descubrí que el testing exploratorio era real y muy respetado por testers muy influyentes; y descubrí el mind-mapping también.  Inmediatamente cambié el uso de Excel y Notepad en mis actividades exploratorias extraoficiales para usar Xmind como herramienta de soporte para las mismas.

Tan buen punto empecé a hacer esto tuve un momento de esos de “cómo no había hecho esto antes!”, ya que los mapas mentales son la herramienta perfecta para desarrollar y ejecutar pruebas mientras testeas, evolucionando tus ideas de testing mientras testeas efectivamente, disfrutando con el proceso y reforzando la parte creativa del testing, cosa que también tiene su gracia. Además de esto, el uso de mapas mentales nos permitió desarrollar un “mapa mental de ideas de testing” al inicio de los proyectos e iteraciones y evolucionarlo a medida que estas avanzaban y profundizábamos en su contenido, compartiéndolo con el resto del equipo, tanto desarrolladores como stakeholders, creando una gran compilación de ideas de pruebas justo antes de empezar efectivamente a testar, y pudiendo evolucionar esta compilación mientras el testing tenía lugar.

La búsqueda de una herramienta de test case management finalizó de facto…

…en el momento que me pregunté ¿por qué iba a querer invertir esa cantidad de tiempo en documentar esos casos de test cuando estamos cumpliendo razonablemente bien sin ellos? Las primeras respuestas que me vinieron a la mente se referían a registros de ejecución de pruebas, cobertura y reutilización. Así que las analicé profundamente.

El tener registros de ejecución de casos de test no es razón suficiente para implementar una herramienta de gestión de casos de test, por lo que seguí profundizando en las otras respuestas.

Sobre cobertura… somos principiantes en testing exploratorio, así que me sentía inseguro de que nos dejáramos areas importantes sin testear con un enfoque tan dinámico, pero la idea de implementar una herramienta de gestión de casos de test no me era suficiente, preferí pensar en mejorar como testers exploratorios; además, alimentar esas herramientas nos hubiera quitado tiempo de testing efectivo, por lo que la coberturase vería afectada también. Por otro lado, qué cobertura te ofrece una herramienta de gestión de casos de test? La cobertura sobre los casos de test que has sido capaz de introducir en ella, cosa que es una manera sesgada de ver la cobertura. Me sentí más seguro haciendo crecer la cobertura en las áreas importantes a medida que íbamos testeando.

La reutilización ha sido un hito reciente para nosotros, decidiendo no reutilizar nada hasta ahora, recreando y revisando las ideas de pruebas a medida que lo hemos ido necesitando, afilando nuestros sentidos y habilidades exploratorias en cada iteración, aunque probablemente modifiquemos esta conclusión pronto.

Próximos pasos (algunos ya ejecutados)

Habiendo decidido oficialmente que hacíamos testing exploratorio con mapas mentales y siendo felices con ello, empezamos a iterar esta idea para mejorar nuestro desempeño. Cosas que ya hemos hecho al respecto:

  • Invertir tiempo en automatizar validation checks, para combinar nuestra óptica exploratoria profunda con cobertura general y ligera en términos de checking.
  • Documentar formalmente algunos casos de test para los casos de uso más críticos (hablamos de unos 5 o así), creando una mini test-suite a ser ejecutada en cada ciclo de testing, antes de la instalación de una nueva versión. Esta suite no se automatizará nunca, ya que requiere unos 15 minutos de ejecución y quiero los 7 sentidos de un tester pensante en ella, y un robot no me ofrece esa seguridad. Los smoke tests son documentados formalmente también. Estas son pruebas sencillas que demuestran que el testing exploratorio y el documentado formalmente pueden coexistir.

Cosas que espero hagamos en el futuro cercano:

  • Repensar el tema de la reutilización. Quizás podríamos desarrollar un mapa mental con checklists para empezar esa recopilación de ideas de pruebas con algo ya hecho, actualizando estos documentos a medida que los vamos usando, aceptando que tienen que ser actualizados antes de evolucionarlos, pero tomando ventaja del conocimiento y esfuerzo mental ya aplicado.
  • Desarrollar una especie de testing low-tech dashboard, basado en mapas mentales, con la intención de comunicar más fácilmente el estado del testing al equipo et altri.

Finale

Pues ya está. Un proceso de 4 años resumido en menos de 1500 palabras. Espero poder escribir algo más al respecto en los próximos 4 años, a ver si mejoramos en este interminable y fantástico asunto!

5 años de TRAC, 8 horas de JIRA

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:

  1. Gestión del ciclo de desarrollo tecnológico de las aplicaciones.
  2. Buzón de sugerencias de nuevas funcionalidades y mejoras, así como bugs encontrados en producción.
  3. 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.

JIRA logo

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.

JIRA Default Workflow

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!!!