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!

Anuncios

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!

Status update

Por varias razones, el área de QA de Netquest (la empresa donde trabajo), vuelve ha quedar como una área unipersonal conmigo al frente. De la experiencia de trabajar en equipo extraigo una gran conclusión, que es la siguiente:

Incorporar y formar a un nuevo compañero es una tarea muy difícil sin tener el área organizada y con un roadmap claro y bien definido.

Entonces, antes de que volvamos a incorporar (inlcuso entrevistar) a una nueva persona en el área, quiero tener los deberes hechos: dibujar un buen plan, establecer unos objetivos concretos, trabajar para conseguirlos y tener unas líneas de acción desarrolladas e iniciadas para que la nueva incorporación tenga un “camino a seguir”. A su vez, tener el área bien organizada permite ahorrar tiempo en algunos aspectos, tiempo a dedicar en mejorar en otros aspectos de organización, alcanzar hitos del roadmap y formar a esa nueva persona en su nuevo puesto. Todo parecen virtudes, a conseguir con trabajo duro!

Mi principal meta con todo esto es conseguir la calidad total en las aplicaciones de Netquest y en sus procesos, idealmente sin dejarme la vida en ello. Según lo aprendido y siguiendo esta meta, los objetivos concretos son:

  1. Revisar, actualizar y completar las especificaciones de las herramientas que desarrollamos, esto es un prerrequisito para…
  2. Crear, actualizar y gestionar la batería de casos de test manuales que cubran las funcionalidades especificadas, para lo que necesito una buena herramienta de TC Management.
  3. Avanzar en la automatización, haciendo una primera inmersión en JUnit (framework que ya se usa en uno de los proyectos) y clarificando qué es conveniente automatizar y con qué herramientas.

Seguiremos informando al respecto…