Alternativas a TestLink: Redmine + Redcase

Hace mucho que estoy buscando una alternativa opensource a Testlink como herramienta de test management. En este caso evalué un plugin de Redmine llamado Redcase, y acá dejo mis notas sobre esta evaluación. La conclusión fue que no me sirve, por muchos motivos no la recomiendo, pero dejo todo a la mano por si alguien más quiere probarla. Aprovecho para decir que en mi evaluación estoy también buscando flexibilidad con respecto al concepto de casos de prueba, ya que estoy cada vez más convencido que el enfoque tradicional de casos de prueba debería dejarse de lado, o al menos no considerarlo como la única o mejor alternativa (documentando detalladamente los pasos, resultados esperados, etc.). Entonces, también me gustaría conocer alguna alternativa que me facilite la gestión del testing exploratorio.

 

Instalación rápida para probar Redcase

Para probarlo fácilmente, teniendo Docker instalado (en mi caso, en Windows 10 home, uso Docker toolbox), se puede usar esta imagen. Para obtenerla y dejarla corriendo simplemente ejecutar el siguiente comando

docker run -d -p 3000:3000 dberchtold/redcase

Luego accedo a la URL dada por la IP del contenedor y el puerto 3000 en este caso, podemos acceder a una instalación nueva de Redmine con el plugin Redcase instalado, que en mi caso quedó en http://192.168.99.100:3000/ (la forma más fácil es acceder al Web preview en Kitematic, dentro del Docker toolbox).

El usuario y password del usuario administrador por defecto es admin/admin, y al acceder solicita cambiarlo.

Algunos tips para probar

La mejor documentación disponible se encuentra acá: https://bitbucket.org/bugzinga/redcase/wiki/Home

Primero hay que crear un proyecto.

Después, para crear test cases hay que hacerlo en la pestaña “Issues”, ya que los casos de prueba están implementados como issues en Redmine.

Luego en la pestaña test cases ahí se pueden organizar en suites y listas de ejecución.

Tuve el problema que no me cargaba prioridades en el combobox al intentar crear un test case (issue), y el campo es obligatorio. Para solucionarlo, tuve que ir a “administration” y ahí “enumerations” donde pude crear las prioridades que quería que se asignen. También es necesario crear al menos una versión para que así aparezcan las pestañas de “execution” y “report”.

Otra cosa importante, un caso de prueba por defecto se crea en estado “new”. Hay tres estados originalmente: new, in progress, obsolete. El estado “new” podría aplicarse para que alguien lo revise antes que se considere “in progress”, o sea, listo para usar. El tema es que solo cuando está “in progress” se puede asignar a una lista de ejecución (Execution suite).

Claramente en la pestaña “execution” es donde uno registra los resultados de ejecución de las pruebas, y en “report” se puede ver un reporte donde muestra un gráfico de torta según el avance por suite y por versión.

 

Limitaciones de Redcase

Las limitaciones más importantes que le encontré en una prueba muy rápida, las cuales ya me hicieron descartar el producto fueron:

Gestión de casos de prueba, ciclos de prueba, ejecución:

  • No tengo posibilidad de asignar casos de prueba a personas. Esto en mi caso creo que me sirve en la mayoría de las veces, pero en otros no, y creo que en muchos equipos esto es una limitación. Además, así no tengo la posibilidad de ver qué casos tengo asignados y de esos cuántos me faltan o cuántos ya completé.
  • No puedo guardar evidencias asociadas a la ejecución de un caso, solo puedo poner un comentario, no puedo asociar una imagen ni nada más.
  • No puedo ver un reporte que me muestre todas las suites, o todos los ambientes, o todas las listas de ejecución. Como se puede ver en la imagen del reporte arriba, creé tres ambientes de ejecución (por browsers, por ejemplificar) y no tengo forma de ver un reporte unificado, tengo que ver cada reporte para cada browser por separado.
  • No queda fácil para editar las listas de ejecución, y no se pueden borrar.
  • Como los test cases están implementados como issues, estos no están pensados para ser utilizados en distintos ciclos de prueba, están más pensados para que se creen, se trabajen y se cierren. Entonces, no puedo ejecutar un caso para una versión y fácilmente asignar para otra versión, ya que me lo muestra como ejecutado y eso queda confuso.
  • Por el mismo motivo, no queda simple vincular casos de prueba con issues.

Confianza del producto

  • No encuentro referencias de gente que lo use realmente.
  • Es un proyecto opensource, pero el repositorio de código no me queda claro cuál es. Si entro a Bitbucket me dice que migraron a Github, pero ahí no tienen actividad hace 2 años…

Conclusión

Si bien hay un montón de cosas que me gustan en Redmine, como tener la gestión de un proyecto con sus incidentes, features, wiki, documentos, noticias, incluso se puede instalar algún plugin como este o este para seguir una metodología ágil, no me terminó de convencer con respecto a gestionar los casos de prueba (o ideas de prueba, o sesiones de testing exploratorio) con el uso de Redcase.

Tendré que seguir buscando. Vos, ¿conocés y recomendás alguna herramienta de gestión de pruebas que sea opensource?

12 thoughts on “Alternativas a TestLink: Redmine + Redcase

  1. fabian says:

    Fede, que tal test case DB?
    https://github.com/msjit/testcasedb
    si bien tiene mas cosas que un test case mgmt tool, pinta bueno:
    http://www.testcasedb.com/features.php
    es Open MIT.

    1. Federico says:

      Sabés que esa es la única que por ahora tengo en el To-Do list para revisar… te aviso cuando la pruebe. Gracias!

  2. Ana Gallardo says:

    Hola, y qué versión de Redmine utilizaste para integrar RM con Testlink? yo intento integrar Redmine 2.4.2, pero según la documentación en RM, Testlink solo soporta integrarse con la versión Redmine 2.1.x, 2.0.x.

    Gracias.

    1. Federico says:

      Ana, qué tal?
      La verdad que no lo recuerdo 🙁 qué mal que no lo anoté.
      Ahora la verdad que estoy bastante dejado con Testlink (incluso estoy intentando dejar los casos de prueba de lado lo más posible… siempre depende del contexto si aportan o no, pero apuntamos a ser un poco más ágiles y no centrar todo en documentación detallada y exceso de gestión sobre eso).
      Saludos!

  3. Heison says:

    Tienes algún artículo sobre este tema de dejar los casos de prueba de lado?

    1. Federico says:

      Buenas!
      De herramientas, no recomiendo testlink, eso es lo más importante
      No hemos encontrado una open que esté buena
      Te re recomiendo la charla de Claudia en TestingUy sobre mindmaps y testing exploratorio
      Esto te puede servir de intro http://13.57.7.11/mindmaps-para-testing/
      Bach y Bolton tienen varios artículos sobre el tema también.

      1. Federico says:

        y la primera parte de esta charla que yo di http://13.57.7.11/charla-en-cordoba-argentina-testing-exploratorio-y-performance-en-mobile/
        es la única que creo q tengo grabada sobre este tema

  4. Pedro says:

    Hola, que herramienta gratuita para diseño, ejecución y reportes de prueba me recomiendas, diferente a testlink

  5. Federico says:

    Hola Pedro, qué tal?
    Nada ha cambiado desde que escribí el post, así que no tengo nada para recomendar
    Si sabés de algo avisame porfa 🙂

  6. Angel says:

    Ha cambiado tu opinión respecto a alguna? Tenemos redmine con redcase en mi organización y no es para nada usable. Estamos tentados de dar el salto a testlink… pero no estoy convenvcido y no sé como mantener la traza con redmine… y kiwi, no me convence el hecho de no poder meter requerimentos ni separar por proyectos.

    Me aconsejas algo?

  7. Federico says:

    Angel, qué tal?
    No he tenido ninguna experiencia que me haya hecho cambiar de opinión. Estuvimos intentando un poco con kiwi… pero no en un proyecto.
    No sé si ha salido alguna versión nueva de Testlink como para hacerme cambiar de opinión…
    No han considerado alguna que requiera pagar alguna licencia?

Leave a Reply

Your email address will not be published. Required fields are marked *