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!

Australia, Sydney, Atlassian… y yo.

El pasado 28 de Enero fue mi primera jornada laboral como QA Engineer en la oficina central de Atlassian, en Sydney (Australia). Ha sido un proceso muy largo y complicado en muchos sentidos, aunque tampoco esperaba que entrar a formar parte de una de las empresas más punteras en el desarrollo de software del mundo fuera fácil… 😉

photo (6)

Estoy muy contento por haber llegado hasta aquí aunque, tras tres semanas trabajadas, puedo decir que el nivel es altísimo, así como el volumen de información, lo que implica que me voy a tener que poner las pilas a muchos niveles para estar a la altura de mis nuevos y nombrosos compañeros.

Seguiremos informando desde Down Under, saludos!

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

Xqual Xstudio

Xqual

Tenía muchas ganas de evaluar Xstudio. A simple vista apuntaba alto en lo que espero de una buena herramienta de gestión de casos de test, además de  ir apareciendo progresivamente en los foros y blogs (como comentaba ektwp en el post sobre Testlink) sobre temas de calidad como una herramienta a considerar en lo que a gestión de TCs se refiere.

Antes que nada, una consideración: Xstudio NO es una herramienta opensource. La herramienta en sí misma es gratuïta pero no de código abierto, distribuyendo bajo licencia LGPL algunos complementos como los launchers de tests automáticos o los templates de reports. El negocio de Xqual (empresa que distribuye la herramienta) proviene de la venta de servicios y complementos alrededor de la misma, en concreto soporte (con varios niveles de atención y tiempo de respuesta), formación, consulting y comercialización de plugins sobre el paquete básico (más reports, ampliación para lanzamiento y monitorización de pruebas de carga…).

La “comercialidad” detrás de Xstudio se nota al acceder a su site, mucho más cuidado y marketiniano que el de sus compañeras de código abierto. Solamente atendiendo a los features presentados en la página parece cumplir con los requisitos que exijo a este tipo de herramientas: gestión de TCs manuales, integración con tests automáticos mediante lanzadores (launchers) especificos de varios frameworks como Selenium, JUnit, AutoIT…, gestión de requerimientos, gestión de especificaciones, integración con herramientas de bugtracking… Una maravilla, oiga.

Después de dejarme llevar momentáneamente por la imaginación y perder la objetividad por unos minutos, me lanzo al vacío y me descargo la demo de la herramienta. Sí sí, he dicho “descargo”, porque XStudio es una herramienta de escritorio en JWS. La primera impresión de Xstudio vuelve a ser marketiniana, con una interfície mucho más visual y cuidada que las herramientas de código abierto, aunque rápidamente la emoción se torna confusión, y es que Xstudio va mucho más allá de la gestión de casos de test, se trata prácticamente de una herramienta de gestión del ciclo de vida de las aplicaciones (salvando la parte de código), ya que permite gestionar empresas, usuarios y calendario, SUTs, requerimientos, especificaciones, releases, tests, bugs, proyectos, sprints…

Esta visión maximalista impresiona, pero tiene dos grandes inconvenientes:

  1. Todas estas entidades están vinculadas entre sí (para crear usuarios debes crear compañías, para testear hay que crear campañas de test, para crear sprints hay que crear proyectos…), de tal manera que si el alcance de la herramienta es demasiado amplio para lo que se necesita, no es posible saltarse áreas para concentrarse en lo necesitado, hay que pasar por todo el ciclo.
  2. La usabilidad es mala. Me refiero en términos ámplios, la aplicación es difícil de entender y manejar. Puedo aceptar el punto anterior, pero solamente si este es aceptable, y no lo es.

Como agravante al punto 2 anterior, la documentación disponible es poca y demasiado simplista, no ayuda demasiado a hacer funcionar la aplicación correctamente (tal vez por eso una de las principales ofertas comerciales de la empresa sea el soporte a la herramienta).

Pero no todo son cosas malas, el área de diseño de tests es muy completa, permitiendo crear tests (equivalentes a test plans) con test cases dentro e incluso indicar dependencias entre tests. Además, la creación de un test case refleja realmente (por fin!) la complejidad de esta tarea: Xstudio permite crear casos de test de ejecución manual por pasos, con la posibilidad de indicar en cada paso los parámetros a usar y los checks a validar, estableciendo condicionalidades entre pasos, etcétera. Adicionalmente ofrece la funcionalidad de combinar por pares los diferentes parámetros de una funcionalidad, para optimizar los casos de test a diseñar / ejecutar; sin embargo, la ejecución de estos casos de test manuales no es por pasos, admitiendo un único resultado por ejecución de caso de test. Igualmente, hay tal vez un exceso de complejidad en este área (y en general en la herramienta), haciendo muy difícil llegar hasta el punto de ejecutar los casos de test (por ejemplo en mi investigación no lo conseguí, tuve que usar casos de test creados por otros usuarios de la demo compartida).

La ejecución de casos de test tiene otros puntos interesantes: el primero es la integración con tests automáticos, mediante lanzadores desarrollados para las aplicaciones robot más conocidas, tanto opensource como propietarias (QTP, Squish, Selenium, AutoIT, JUnit, PyUnit…). Además, repito, ofrece al usuario la posibilidad de desarrollar su propio lanzador que sirva para otra aplicación o librería. Este punto tampoco es de fácil comprobación en la demo, puesto que requiere instalarse un paquete de ficheros, aunque es un punto a favor poder incluir la ejecución de tests automáticos desde una misma herramienta, gestionando los resultados de manera conjunta. Otro aspecto interesante son las ejecuciones estructuradas en sesiones (llamadas “campañas” de testing), registrando la actividad del usuario durante las mismas. Por último, las ejecuciones permiten la creación de bugs en el área de bugtracking de la herramienta; pudiéndo integrarse la misma con herramientas de bugtracking más establecidas en el mercado como Jira, Mantis o Trac (la nuestra), aunque en ninguna parte indica como se vinculan estas herramientas en términos prácticos.

Para terminar con lo general y antes de pasar a la evaluación concreta, Xstudio consta con muchas áreas de reporting y estadísticas sobre las entidades que se van creando (especificaciones que cubren requerimientos, tests que cubren especificaciones, bugs encontrados en campañas…) que permiten mantener una visión concreta de la situación en un área determinada, lo que evita perderse entre tanta pestaña y objeto.

Puntuaciones concretas en los aspectos establecidos para evaluar:

  • Principalmente…
    • Creación, gestión y ejecución de test cases – OK (muy completa)
    • Creación, gestión y ejecución de test plans – KO (paga la complejidad y falta de documentación general, no es evidente)
    • Gestión de resultados de ejecuciones – OK (muchas áreas de reporting por defecto)
    • Vinculo entre test cases y use cases / user stories / requerimientos – OK (primera herramienta que separa requerimientos de especificaciones)
  • Más en segundo término…
    • Integración con la herramienta de bugtracking implantada en la empresa: Trac – KO (área de defects propia, será desarrollo a medida no documentado)
    • Gestión de recursos asociados a un test case – OK (se pueden adjuntar documentos a nivel general o en tests concretos)
    • Facilidad de instalación y mantenimiento como herramienta – KO (documentación casi inútil, el hecho de que se ofrezca soporte de pago parece decir que lo va a necesitar)
    • Gestión de N proyectos por M usuarios, idealmente con permisos distintos (creación, ejecución, consulta…) – OK (se puede gestionar hasta la dedicación y vacaciones de estos usuarios)
    • Ejecuciones iterativas sobre un mismo test plan – OK (mediante campañas de test)
  • Y en último lugar…
    • Integración con tests automáticos – OK
    • Test cases, test plans y resultados imprimibles / exportables – KO (no existe o no he sido capaz de encontrar nada parecido)

Siguiendo los criterios establecidos, esta evaluación se queda en un 8 sobre un máximo de 24, empatada con RTH. Me esperaba bastante más, qué decepción.

TC mgmt ratings - Xstudio

Comparativa de evaluación entre herramientas de gestión de test cases

Sigo buscando, mentiría si no dijera que  me empiezo a plantear considerar herramientas de pago para implantar la gestión de casos de test manuales y empezar a producir en este sentido. Sin desfallecer!