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

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

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

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.

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.

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.