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!

Anuncios

9 comentarios en “De casos de test a mapas mentales: una experiencia personal

  1. Pues me ha gustado tu enfoque. Tengo curiosidad de como guardas los resultados de la ejecución de pruebas, así como la forma de integrar Xmind en la documentación.

    Yo he usado Xmind para las features más gordas que he testeado y es una herramienta estupenda. Pero para el flow diario de features más pequeñas no he terminado de ver la manera de integrar los mindmaps resultantes con el proceso de testeo que sigo.

    Mauri, si por casualidad vienes un día por Valencia, me gustaría quedar y charlar un buen rato.

    • Gracias por tu comentario Jokin!

      Las dos cosas que comentas son puntos que tenemos que trabajar un poco más en nuestro enfoque actual. Una posibilidad de almacenar resultados de ejecución es usar los mencionados “low tech dashboards” y tener una herramienta potente de bug-tracking que te permita localizar issues por proyecto, completado con (quizás) un histórico de testing realizado por proyecto, a alto nivel incluso, indicando funcionalidades, módulos, etc. revisados y a qué nivel de profundidad (si eso se puede indicar 😉 ). Estas dos últimas son nuestra versión actual, con la primera mencionada a medio camino de ser realidad.

      Sobre la integración con la documentación, de momento guardamos los documentos versionados en un repo de documentos, asociados con la versión / proyecto en los que nacen. También depende de lo que necesites aquí, si no tienes que reutilizar ni rendir cuentas documentadas al bit de lo que haces, tanto la integración documental como el almacenado de resultados se aligera bastante y puedes gestionarlo como creas, y más si te basas en testing exploratorio, siempre listo para reinventarse.

      Da la casualidad que voy a ir a Valencia un fin de semana en Abril… Hablamos? 🙂

      Saludos!

      Mauri

  2. Hola,

    Tengo una pregunta o más bien un deseo oculto. (jeje) me suena mucho la idea de hacer los test exploratorios desde un mapa mental es mucho más organizado y tan complejo/fácil que uno quiera diseñarlo.

    Pero es que yo sueño en continious intergration constantemente. Y seria fantastico poder hacer un mapa mental antes de empezar los Scrums para poder hacer test peor la pregunta es:

    Como pensarias tu que se podria conectar mantis, (para el bug tracking)
    Selenium para los smokes automáticos (conectados ojala cada suit a un User case)
    Y jira para las funcionalidades nuevas que van saliendo dentro del scrum??

    Desde Bogotá Con cariño

    Beto Hernández

    • Hombre, pues la conexión de Selenium con Mantis no creo que sea ningún secreto, entiendo que te refieres a que si Selenium falla abra un bug automáticamente en Mantis, cosa que me parece bien pero que para que sea realmente eficiente requiere que estés seguro de que todo lo que hace Selenium esté actualizado y funcionando, cosa que es bastante difícil en la práctica…

      Lo que no veo (o no entiendo) es qué pretendes y para qué la integración con Jira, cómo usas o pretendes usarlo?

      Saludos!

      Mauri

  3. Hola Mauri,

    Es que Mantis en últimas NO es un levantador de requerimientos. Es donde el desarrollador va a ver que le toca hacer es más como yo veo JIRA es como donde se puede acomodar los requerimientos por sprint, las tareas de un sprint y la ejecución de las mismas.

    Pero mantis no es un organizador de requerimientos sino un big tracker. Seria estupendo si Selenium encuentra un error (en un smoke test digamos) automáticamente levanta un bug en mantis (con el código que está roto) Pero ese Bug en mantis debe ir si o si relacionado con un test case que a su ves va relacionado a un requerimiento. y esa lista de requerimientos esta en JIRA.

    (si me entiendes a donde quiero llegar maomenos son muchos clicks y muchas cosas abiertas )

    ( Mira, fíjate en esta herramienta a ver que tal te parece http://www.thoughtworks-studios.com/mingle-agile-project-management) MINGLE

    From Bogotà With love

    Beto

    • Ahora te sigo, y por qué separar bug-tracking y requerimientos cuando Jira puede con ambos? En mi proyecto actual los gestionamos conjuntamente, tal vez te interese este plugin de Jira, para la gestión de requerimientos, historias, sprints, epics y demás parafernalia agile: http://www.atlassian.com/software/greenhopper/overview

      Más allá de esto, suena genial, un sistema así dejaría mucho tiempo a los testers para explorar, especializarse y proporcionar información de alto valor añadido!

  4. excelente aporte!! llegue aca buscando una herramienta de gestion de pruebas mejor que la que estamos usando(testlink) y la verdad que tu aporte como que me cambio las prioridades…. la verdad que mantener trazabilidad entre las historias/requerimientos de jira, los casos de prueba en testlink, los bugs cargados en jira, hacer los planes de ejecucion para verificacion de bugs en test link atados a las historias , todo bien trazadito para que la gente de auditoria de iso no ponga el grito en el cielo, y encima cumplir con un cliente ultra exigente(por no decir paranoico) con las fechas de entrega….. es un terrible e interminable dolor de cabeza…… aveces pareciera que a nadie le importa realmente la calidad del producto…..

    • Fantástico! Me alegro mucho de ser útil 🙂

      Las trazabilidades y auditorías esconden muchas veces el miedo a lo desconocido: programar es construir, es fácil ver si algo está hecho o no (el cómo es otro tema…) pero testear es algo muy distinto, no es conocido ni visible a simple vista, y por ello se cae en el recuento de test cases y en la generación de reportes infinitos cuya única finalidad es la de existir y dar tranquilidad a otros por su existencia.

      Jerry Weinberg defiende “it doesn’t have to be this way”. Si tú crees que puedes mantener / mejorar la calidad del producto de un modo menos rígido y más resultón… Pues ve a por ello! La comunicación, visibilidad y transparencia te pueden ayudar y acompañar en tu camino al triunfo.

      Suerte!

      — Mauri

  5. Si te sirve de ayuda, yo ese proceso lo he vivido totalmente solo en un equipo de QA de 1 persona, con un equipo de desarrollo de casi 50 personas -.- si, muy equilibrado…

    Al final, a día de hoy, uso

    * Como gestor de testcases, Testlink 1.9.14

    * Herramienta propia desarrollada en Java para la ejecucion de testcases:
    url: https://github.com/netzulo/ntzXagobah/
    – Integracion con testlink
    – logger propio
    – Selenium REMOTE a través de un grid
    – Selenium LOCAL , siempre que tengas instalado el navegador que quieras usar
    – Test-NG , este es el nucleo de ejecucion de testcases

    * Como gestor de ejecuciones: Jenkins
    – En esta web puedo configurar crones de ejecucion sobre ficheros .bat o .sh, por lo que solo tengo que parametrizar mi aplicacion para que ejecute a partir de keywords ( que pueden estar configuradas en testlink
    ) los testcases a través de Test-NG , con el objetivo de recuperar resultados

    * Como gestor de bugs : Redmine
    – Se configura el acceso a las APIs
    – Se configurar el XML en testlink para interconectar ambos

    Y ahora…. un ejemplo

    Estoy de vacaciones, pero me llaman del departamento de desarrollo que han sacado una version nueva y que no se atreven a subirla sin que les de un okey desde QA.

    1. Abro jenkins, seleccion una carpeta de proyecto
    2. eligo una zona de ejecucion del proyecto( relacionado directamente como testsuites en testlink )
    3. le doy al RUN
    4. YA ESTA

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s