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!

QA&Test 2012

QA&Test 2012

Por segunda vez este año, he tenido la suerte de ganar una entrada gratis para la conferencia QA&TEST 2012 celebrada en Bilbao los días 17, 18 y 19 de Octubre. Quiero reiterar el tema de “la suerte”, porque ahora que hace menos de 72 horas que se ha terminado el evento puedo decir oficialmente (de nuevo) que ha sido una experiencia…

FANTÁSTICA!

Amantes del testing de España y de todo el mundo, sintámonos afortunados de tener en nuestro territorio un evento de orfebrería como éste, una auténtica delicatessen de conferencia.

Honestamente, el QA&TEST 2012 me ha robado el corazón, por muchas razones, por ejemplo:

  • El pequeño formato que defiende la organización. El total de asistentes entre ponentes y público roza las 100 personas y se organiza en 2 tracks simultáneos que van cambiando de temática durante la conferencia, esto hace que sea un evento en el que impera la…
  • Cercanía. Hay algo en el ambiente de esta conferencia que te hace sentirte bien, como en família, la calidez está por todas partes, de principio a fin, desde la organización hasta los…
  • Contenidos. Un poco de todo, tocando todos los palos, ponentes de todo tipo, ponencias muy concretas junto a otras más generales, rigurosidad en la selección y mucha información que requiere de una correcta…
  • Duración. 3 días de conferencia, suficientes para cubrir temas con holgura, sin que sea corto y estresante ni largo e injustificable, para tratar los temas con todo lujo de…
  • Detalles. La calidad está en los detalles, el trabajo se nota en los detalles. Las cosas, los eventos, no salen a la perfección si no hay mucho trabajo detrás y no se atiende a las pequeñas cosas, por ejemplo los cuadernos con los slides de las ponencias impresos, las comidas fantásticas en los que se podía catar lo mejor de la cocina Vasca, el banquete en la histórica sociedad bilbaina con una copa posterior pagada por la organización, y un largo etcétera.

En resumen, un 10 para la organización 🙂

Entrando más en profundidad en lo que al testing se refiere, el QA&TEST de Bilbao no tiene nada que envidiar al “cartel” más mediático de ponentes de su pariente lejana ExpoQA, como prueba de ello están las ponencias y keynotes de Lynn Mckee, Nancy Kelln, Derk-Jan De Grood, Jan Jaap Cannegieter, Julian Harty, Shmuel Gershon… Pero no depende todo de eso; sin presentaciones de “relleno”, todos los temas de la conferencia se tocaban con mucha profesionalidad y la variedad de las temáticas de los tracks (QA, management, el testing en sectores industriales, automatización, mobile, organización de equipos, nuevas técnicas…) permite que, en global (y seguro en particular), sea una conferencia interesante y de valor añadido para todos los asistentes con interés en el testeo de software, la calidad y relacionados.

Mesa redonda sobre el futuro del testing con Bryan Bakker, Jan Jaap Cannegieter y Lynn Mckee

Me quedo con toda la experiencia, con todas las ponencias y keynotes, con todas las charlas e interacciones, creo que he aprendido muchas cosas en esta conferencia y, para resumirlo en citas sin cansar al personal, sugiero que pensemos seriamente en las siguientes ideas, puesto que pueden cambiar nuestra visión de la profesión:

“El testing se puede llevar a cabo sin casos de test” @nkelln

“Puedes transformar tu organización” @lynn_mckee

“Concéntrate en aportar valor a la gente de business@derkjandegrood

“Puedes hacer más de lo que te crees capaz” @jjcannegieter

“Porque el futuro del testing está en nuestras manos” @mauri_edo

Nos vemos en el QA&TEST 2013!!!

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!

La fatiga del tester

Esta semana hemos subido a producción una nueva versión de una de las herramientas propietarias de Netquest que básicamente ha consistido en el rediseño casi total de una de las áreas tratadas por la aplicación. El proceso de testing ha sido largo, duro y difícil, y he sido presa de la fatiga por varios errores de apreciación realizados durante el proceso y que me juro que no voy a cometer nunca más:

  • Incorporación tardía al proyecto: esto es más grave como más tardía es la incorporación (obvio, no? ;-)) y como más grande es el proyecto. Testers y QAs del mundo, hay que encontrar tiempo para asistir a las reuniones de análisis de nuevos requerimientos o funcionalidades (o convocarlas nosotros mismos) para no “perder comba” de lo que sucede. El proceso de testing se pone en marcha más rápido y mejor si no nos coge “en frío” en lo que al contenido se refiere.
  • Desorganización en las pruebas manuales: no tengo los deberes hechos en lo que a organización y documentación de pruebas manuales se refiere. Aunque el rediseño de la herramienta implica casos de uso nuevos y eliminación de viejos (con el consiguiente efecto idéntico en los casos de test), aquellos casos que no han cambiado o que lo han hecho muy poco tienen que estar listos para ser ejecutados y la redacción de casos nuevos tiene que quedar almacenada para futuras situaciones similares. Es importante invertir el ciclo del trabajo y empezar a documentar el testing pensando en el reaprovechamiento futuro de los casos. Una buena herramienta de Test Case Management puede ser de vital importancia en este punto.
  • Falta de automatización en las funcionalidades básicas: de las dos herramientas desarrolladas por la empresa, en esta no tengo nada automatizado. Esto añade gran incertidumbre a aquellas situaciones donde el volumen de trabajo es difícil de asumir, ya que si falta tiempo para validar las nuevas funcionalidades, mejor ni pensar en las existentes. Como más funcionalidades básicas estén aseguradas por pruebas automáticas, más nos podremos concentrar en las funcionalidades nuevas y mejor dormiremos la noche antes de la subida a producción.
La fatiga del tester

Otros factores que contribuyen a que la fatiga haga mella en los testers pueden ser…

  • Procesos largos de pruebas: hacer pruebas es divertido, pero hacerlas bajo presión temporal y durante muchos días seguidos no lo es tanto. Me vuelvo a referir a los puntos anteriores: cuanto antes nos incorporemos al proceso, mejor organizados estemos y tengamos aseguradas las funcionalidades básicas mediante pruebas automáticas, más corta será la fase de (puramente) testing de un proyecto o una funcionalidad nueva.
  • Encontrar muchos errores o muy graves: encontrar errores es buena señal, porque serán corregidos antes de llegar a manos del usuario final; esto siempre es bueno. Lamentablemente, encontrar muchos errores alarga el final del proceso de testing (trasladar los errores a la herramienta de bugtracking correspondiente requiere tiempo e implica que además de validar las funcionalidades, habrá que validar que los errores se han arreglado). Además, encontrar errores graves puede ser algo frustrante, ya que estos errores acostumbran a ser bloqueantes, impidiendo proseguir con la validación de funcionalidades concretas, lo que añade mayor presión temporal a la situación.

Al final, la subida a producción fue bien y se hizo con seguridad, pero el proceso de testing ha requerido de demasiada “fuerza bruta” y las aplicaciones se han hecho demasiado grandes y complejas como para seguir con este planteamiento. Es hora de cambiar de planteamiento y subir el listón para entregar mejores versiones en menos tiempo y con el esfuerzo racionado y concentrado en aquellas áreas que lo requieran, sin perder fuelle en procesos intermedios.

RTH

RTH LogoSigo en busca y captura de una buena herramienta de management de test cases que implantar en mi departamento, para organizar todo el testing manual de las herramientas propietarias de Netquest. La siguiente en ser evaluada ha sido RTH (requirements and testing hub). Me decido a evaluarla por varias razones:

  1. En el número de Testing Experience de diciembre, había un artículo de Bruce Butler que hablaba maravillas de la misma.
  2. En el mismo número pero en otro artículo (este de Vinodh Velusamy) aparece como una de las 5 primeras herramientas de TC Management, según un debate-encuesta realizado en Linkedin al grupo de Software Testing & Quality Assurance.
  3. En el apartado de test management de opensourcetesting.org es la segunda herramienta de gestión de casos de test con mayor número de descargas (la primera es Testlink).

Según veo, hay dos proyectos en realidad, RTH y RTH Turbo, este segundo parece más potente según como lo describen pero al acceder al home del proyecto queda claro que es un proyecto inactivo, con una única versión de hace más de 3 años, nacido de la versión 1.2 de la aplicación original. No es muy alentadora esta situación (una herramienta de código abierto sin comunidad aparente y me figuro que sin soporte), por lo que sigo con la versión original del proyecto, a ver qué me ofrece.

RTH “a secas” tampoco presenta un mejor panorama, la última versión estable es de Abril del 2009, en el blog oficial de la herramienta hay un post de diciembre de ese mismo año avisando de la cercana inactividad del proyecto debido a que no hay desarrolladores en el equipo de gestión del mismo, por lo que no puede haber un roadmap definido al no tener certeza sobre cómo y cuándo se podrán hacer desarrollos; por otro lado, parece un proyecto bastante rocambolesco y descabezado, según su historia. Tampoco anima mucho a su adopción, pero vayamos a lo práctico…

El proyecto no goza de mucha documentación disponible, apenas un listado de funcionalidades y unas FAQ’s, no tiene un manual de usuario o de instalación como Testlink, pero se indica que requiere de PHP y MySQL. De lo que sí dispone es de una demo activa en http://rth.liedl.at/login.php, que también carece de menús de ayuda o similares. Jugando un poco con la demo, me encuentro con una herramienta parecida a Testlink aunque algo más rica en definición de casos de test. La creación/edición de un caso permite indicar pasos a ejecutar estableciendo la acción a llevar a cabo, los test inputs y el resultado esperado. Además se ofrecen muchos campos informativos para clasificar el caso de test donde proceda (no hay clasificación en árbol como en Testlink), aunque algunos de estos campos son de contenido aparentemente fijo (por ejemplo, el campo “Test type” muestra los valores “functional / regression / performance / smoke”); estos campos serían realmente útiles si fueran personalizables, pero no es el caso (o no parece serlo, pero no hay nada que indique lo contrario ni área de configuración adecuada). Sí se permite subir ficheros de soporte a los casos (aunque en la demo no pueda hacerlo funcionar) y marcar un test como “automático”, aunque sea mera clasificación.

Una funcionalidad curiosa es que RTH permite gestionar la elaboración y mantenimiento de los casos de test, marcándolos con un “estado” a escoger (nuevamente campo no configurable) entre estados como Work in progress, ready to review y similares. Además permite asignar los casos a alguien, estableciendo un calendario de fechas esperadas sobre acciones a realizar sobre los casos (completar, validar, revisar…). Parece una funcionalidad bastante útil en caso de que las aplicaciones experimenten cambios frecuentes o nuevos requerimientos que exigan modificar los casos de test que los cubran, sabiendo siempre si los casos ejecutados están actualizados, validados, pendientes de revisar, etc.

El área de requerimientos es bastante parecida a la de casos de test, con varios campos informativos de contenido fijo. La asociación de requerimientos a casos de test es bastante buena, permitiendo vincular N casos a M requerimientos sobre la cobertura del 100% del requerimiento funcional. A su vez, la aplicación ofrece una matriz de trazabilidad automática sobre esta información.

La gestión de los test sets (agrupación de casos de test a ejecutar ante una release) es buena, creando la mencionada release, luego un build y luego el test set propiamente. Lo que no es tan bueno es la selección de casos a incluir en un set; esto es debido a que la creación de casos de test no es jerárquica, luego se depende de la información proporcionada en los casos para poder filtrarlos y seleccionarlos manualmente como parte del set. En su defensa, un test set se puede copiar entre releases y entre builds, evitando tener que repetir la selección manual a cada ejecución del set.

La ejecución de casos dentro de un set es aceptable, en caso de tests manuales muestra los distintos pasos permitiendo indicar el resultado obtenido en cada paso y el status del mismo, además de indicar el status de la ejecución global del caso. Para tests automáticos se puede indicar el status de la ejecución global. Las ejecuciones permiten especificar los motivos de fallo o bloqueo en los distintos pasos, hacer comentarios, indicar el entorno en el que se han hecho las pruebas, notificar a usuarios de la ejecución, etc. Sin embargo, el área de reporting es un área general que queda desligada de las releases o builds, cosa que implica seleccionar los datos a tratar en cada ocasión. Tampoco queda muy claro si se pueden añadir reports personalizados a los pocos disponibles.

Por último, la gestión de usuarios y permisos es correcta, siendo configurable en todo lo necesario. Por otro lado, RTH dispone de un área propia para registrar bugs y defectos, lo que deja en un desarrollo a medida la integración de la herramienta con cualquier bugtracker.

En resumen, y para poder puntuar:

  • Principalmente…
    • Creación, gestión y ejecución de test cases – OK (mejor que Testlink en lo que a ejecución se refiere)
    • Creación, gestión y ejecución de test plans – KO (mala inclusión de casos en sets)
    • Gestión de resultados de ejecuciones – OK (justito, pero aceptable)
    • Vinculo entre test cases y use cases / user stories / requerimientos – OK
  • Más en segundo término…
    • Integración con la herramienta de bugtracking implantada en la empresa: TracKO (al tener un área de defects propia, quedaría como un desarrollo a medida)
    • Gestión de recursos asociados a un test case – OK
    • Facilidad de instalación y mantenimiento como herramienta – KO (muy poca información al respecto, proyecto casi inactivo)
    • Gestión de N proyectos por M usuarios, idealmente con permisos distintos (creación, ejecución, consulta…) – OK
    • Ejecuciones iterativas sobre un mismo test plan – OK (mediante builds dentro de una release)
  • Y en último lugar…
    • Integración con tests automáticos – OK
    • Test cases, test plans y resultados imprimibles / exportables – KO (solamente son exportables los casos de test, aunque el resultado no es demasiado bueno)

Siguiendo los criterios establecidos, esta evaluación se queda en un aceptable 8 sobre un máximo de 24.

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

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

En resumen, RTH me ha gustado más que Testlink, sin embargo la inactividad del proyecto me hace desconfiar de la herramienta como una apuesta de futuro. Necesitamos una solución lo más estable y mantenida posible, ya que ni el area de QA (que ahora mismo soy yo solamente) ni el area de desarrollo tienen recursos para gestionar/mantener herramientas que no sean las propietarias.

Seguimos buscando…

Testlink 1.7.3

Primera parada en la búsqueda de una herramienta de test case management para su implantación en los proyectos en los que trabajo: Testlink.

Cómo ya mencioné en el post que iniciaba esta búsqueda, la herramienta a escoger debe ser opensource por restricciones de presupuesto. Entonces, qué mejor que acudir a opensourcetesting.org y mirar qué tienen en la sección de testing tools, apartado test management? Pues, a fecha de hoy, aparecen 24 herramientas en el apartado, algunas de gestión de casos de test, otras no, algunas de nombre conocido, otras no. La más descargada según el “download data” disponible es Testlink (con más de 200.000 descargas), además de la referencia en el sector según he leido en varios lugares; pues ya puestos, mejor empecemos por el referente!

La evaluación que he hecho de Testlink ha consistido en dos “sesiones”, una de lectura de la documentación disponible sobre la aplicación en la página del proyecto (concretamente el manual de usuario y el manual de instalación) y otra sesión de jugar con la aplicación en la demo disponible. De la primera, debo reconocer que la impresión inicial fue algo negativa, debido a la falta de cuidado de los sites del proyecto (http://www.teamst.org y http://blog.testlink.org), con bastantes links importantes rotos (la demo del primer site, todas las páginas no iniciales del segundo) así como de la ausencia de un resumen de funcionalidades globales, no específicas de cada release. De esta dejadez deriva que haya tenido que trabajar con la versión 1.7.3 de la aplicación, cuando la última estable ha sido la 1.9.2, pero lo que no iba a hacer era montar un entorno con Apache, PHP y una DB en MySQL para hacer una prueba de concepto (tampoco tengo los recursos ni las capacidades para ello). Tras la segunda sesión, 100% práctica, procedo a emitir mi veredicto sobre la adecuación de la herramienta a las necesidades de nuestros proyectos y del equipo.

Testlink es un buena candidata en esta elección que estoy llevando a cabo. Sin haber tratado nunca con una herramienta de gestión de casos de test, lo que me esperaba de este tipo de aplicaciones lo he encontrado en ella; especialmente en lo que se refiere a gestión: permite gestionar varios proyectos con casos de test distintos, admite múltiples usuarios con roles definidos totalmente ad-hoc y con permisos configurables sobre tareas y proyectos, puede organizar los test cases en test suites y estas test suites en otras test suites hasta tener el nivel de anidamiento deseado, admite la creación de test plans (compuestos de las suites o casos deseados) para releases concretas, ejecutando o modificando estos planes (o su contendo) de modo iterativo mediante la creación de builds dentro de los mismos, capacidades más que suficientes de reporting… Sin embargo, me ha sorprendido lo poco orientada que está la aplicación hacia la creación de los test cases diseñados, con una interfaz demasiado simple, exigiendo HTML en las descripciones ya que si no después de visualizan mal, sin espacio para indicar los pasos del caso de test ni el resultado esperado de cada uno de estos pasos, con un espacio único para añadir adjuntos (en lugar de ser “por paso”)… Lo mismo sucede con la ejecución de los casos; de hecho, apenas puede llamarse ejecución sinó más bien marcado de ejecuciones de casos, puesto que consiste en mostrar los casos de test como si fueran a ser impresos en PDF añadiendo un par de campos para establecer el resultado de la ejecución (pass, fail, blocked, not run) y un campo para “notas adicionales”. Nuevamente se ignora el “paso a paso” en la ejecución, lo que dificulta mucho el trabajo si los casos de uso son complejos o tienen muchas partes.

Ciñiéndome a las necesidades expresadas en el post inicial de la búsqueda, mi valoración de Testlink es…

  • Principalmente…
    • Creación, gestión y ejecución de test cases – KO (gestión muy buena, creación y ejecución bastante pobre)
    • Creación, gestión y ejecución de test plans – OK (la creación y ejecución de planes es muy flexible y ajustada a la realidad del proceso)
    • Gestión de resultados de ejecuciones – OK (incluso hay más reporting del necesario)
    • Vinculo entre test cases y use cases / user stories / requerimientos – OK (la definición de requerimientos puede desactivarse “de sistema”, la asociación con casos o historias se puede ajustar en la creación de suites)
  • Más en segundo término…
    • Integración con la herramienta de bugtracking implantada en la empresa: TracKO (puede integrarse, pero exige atorgar permisos importantes al usuario anónimo, mientras que ahora este usuario no tiene permisos más que el de ver la página de login)
    • Gestión de recursos asociados a un test case – KO (un único campo attachment por test case, cuando sería preferible por pasos de ejecución)
    • Facilidad de instalación y mantenimiento como herramienta – KO (requerimientos exagerados en comparación con otras herramientas del mismo estilo, los upgrades tampoco parecen sencillos a juzgar por el manual de instalación de las versiones posteriores a la testeada)
    • Gestión de N proyectos por M usuarios, idealmente con permisos distintos (creación, ejecución, consulta…) – OK (incluso se pueden configurar roles totalmente nuevos)
    • Ejecuciones iterativas sobre un mismo test plan – OK (mediante la creacion de builds asociados a los planes, que pueden tener más o menos casos de test o versiónes más nuevas de los mismos)
  • Y en último lugar…
    • Integración con tests automáticos – KO (sin soporte específico)
    • Test cases, test plans y resultados imprimibles / exportables – OK

Si las valoraciones del primer apartado valen 3 y -3 (OK vs. KO), las del segundo valen 2 y -2 y las del tercero valen 1 y -1, sobre un total posible de 24 puntos máximos, según mi humilde opinión el ajuste de Testlink a mis necesidades es de un 4. Gráficamente…

Resultados de la evaluación de herramientas de gestión de TC - Testlink

Resultados de la evaluación de herramientas de gestión de TC – Testlink

Poco prometedor, el único atenuante es la “antiguedad” de la versión testeada (he leido que en las siguientes versiones pueden haberse dado mejoras en la ejecución / automatización). Iremos viendo qué ocurre con esta cruzada para encontrar una herramienta de gestión de TCs que se ajuste a las necesidades. Seguimos!