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?

Leave a Reply

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