Hace unos años, por falta de alternativas open-source, cuando se trataba de herramientas de gestión de pruebas siempre recomendábamos TestLink. Hace mucho que cambié de idea, y que creo que no es una herramienta que me transmita confianza como para llevar ahí toda la gestión del proceso de testing. Las últimas versiones han venido con issues muy graves y no han mejorado los puntos flojos de la herramienta. Ya en este post estuve contando de Redmine y Redcase, buscando alguna alternativa a Testlink.
Hemos evaluado en Abstracta varias alternativas. Hoy en día, a menos que el cliente tenga alguna elección hecha, o cuente con licencias de alguna herramienta, por lo general estamos utilizando lo que alguna vez dije que no era una buena práctica: planillas de cálculo. Hoy pienso que a falta de una buena herramienta, es mejor utilizar algo que todos sepan usar, sea fácil y flexible. Tal vez no tiene todas las funcionalidades que uno quisiera, pero si se usa con inteligencia, es posible gestionar en forma adecuada (y liviana) el proceso de pruebas. Por otra parte, creo que en entornos ágiles, esto se puede complementar muy bien con el propio tablero del equipo, y alguna herramienta para gestionar el conocimiento del producto y las ideas de pruebas, como son los mindmaps.
Algunas de las herramientas que hemos probado tienen alguna versión gratuita (como Leantesting), y otras son opensource. En particular en este post te comparto el análisis hecho por Mariela Cepero de Abstracta (quien tiene mucha experiencia en el uso de TestLink) sobre una herramienta opensource llamada Kiwi TCMS, la cual al principio parecía prometedora, pero creo que aún le falta trabajo para poder considerarla en nuestro contexto. Seguro que a muchos podrá servirle, y por eso compartimos el análisis, pero nosotros seguiremos por ahora con las herramientas provistas por el cliente, o con planillas de cálculo 🙂
Kiwi TCMS – Descripción y principales funcionalidades
Kiwi TCMS es una herramienta open source para la gestión del proceso de pruebas en proyectos de software. Entre sus funcionalidades se encuentra:
- Módulo de administración (definición de roles, permisos, productos, versiones, prioridades, clasificaciones, entre otros).
- Gestión de planes de prueba.
- Gestión de casos de prueba.
- Gestión de ejecuciones de pruebas.
- Ejecución de casos de prueba (permite indicar estatus, comentarios, y bugs).
- Integración con herramientas de gestión de incidentes como Jira, Bugzilla y otros.
- Seguimiento del progreso de las pruebas a través de resúmenes y reportes variados.
Instalación y soporte de la herramienta
Kiwi TCMS es una aplicación de código abierto, desarrollada en Pyhton y Django. Su código fuente está disponible en: https://github.com/kiwitcms/Kiwi
El último año ha tenido un desarrollo activo como se ve en la gráfica 1. Tiene 11 contribuidores activos y 56 issues abiertos.
Para esta evaluación, se utilizó una demo online disponible desde http://kiwitcms.org/ .El primer paso es registrarse con un usuario, contraseña y cuenta de correo, a la que se enviará un mail de confirmación y el link para acceder a la demo.
También desde la página oficial y desde la demo online, se puede acceder a la documentación de administración y uso de la herramienta.
En este link se muestran las instrucciones de instalación en producción.
En este link se muestran las instrucciones de instalación en un ambiente de desarrollo.
Primer contacto con la herramienta
Al iniciar sesión se muestra un menú superior y un espacio de trabajo donde se irán desplegando los contenidos del menú cuyas opciones son:
- Dashboard: Muestra una vista resumen de los planes de prueba activos y sus ejecuciones (con links para acceder a la información más detallada).
- Testing: Provee opciones para agregar planes de prueba y casos de prueba.
- Search: Provee opciones para buscar planes de prueba, casos de prueba y ejecuciones de pruebas. Además da una opción para búsqueda avanzada (por más criterios).
- Reporting: Provee opciones para reportes:
- Overall Reports: Muestra para todos los proyectos, el número de planes, ejecuciones y casos de prueba asociados.
- Custom Report: Se presenta una interfaz para buscar por diferentes criterios y como resultado de la búsqueda se muestran por build, el número de planes, ejecuciones y casos de prueba asociados, así como el porcentaje de casos en estado Passed y Failed.
- Testing Report: Se presenta una interfaz para buscar por diferentes criterios incluidos distintos tipos de reporte como: Por tester, Por prioridad de los casos de prueba, Por etiquetas, entre otros.
- Admin: Provee opciones para administración de diferentes recursos, por ejemplo:
- Submenu enviroment: permite gestionar grupos y propiedades.
- Submenú Everything else: permite gestionar clasificaciones, componentes, prioridades, productos y versiones (opciones que luego son utilizadas durante la creación de planes, casos o ejecuciones).
Flujo de trabajo
El plan de pruebas es la entidad contenedora de más alto nivel, seguidamente se deberán crear los casos de prueba asociados y luego las ejecuciones de pruebas, donde finalmente se registrarán los resultados del testing.
Gestión de planes de prueba: El primer paso es crear el plan de pruebas, el mismo debe estar asociado a un producto y versión del producto (que pueden configurarse con anterioridad o crearse desde esta interfaz). Además, se añaden otros datos como: tipo, id del padre, link, grupos de ambiente y documentos del plan (con posibilidad de escribir o adjuntar archivo).
Opciones relacionadas: Editar, Eliminar, Clonar, Deshabilitar, Imprimir, Enviar notificación por mail cuando se realicen acciones sobre el plan.
Gestión de casos de prueba: Accediendo al plan de pruebas, aparece un submenú donde se pueden gestionar los casos de prueba y ejecuciones del propio plan. Accediendo a Case/Write New case se muestra la pantalla de creación de casos de prueba. Se solicita la siguiente información: Sumario (único campo obligatorio), Productos, Componente, Si es manual o automatizado, Requerimiento, Script, Alias, Tester, Tiempo estimado, Prioridad, Argumento, Link de referencia, Etiqueta, Notas, Categoría, Configuración, Desglose, Acciones, Resultado esperado. Los casos de prueba se crean por defecto con Status “Proposed” y se listan en la opción Reviewing Case, siendo necesario cambiar a estado “Confirmed” para poder agregarlos a una ejecución de pruebas.
Opciones relacionadas: Editar, Eliminar, Clonar, Imprimir.
Gestión de ejecuciones de pruebas: También desde el plan de pruebas, es posible agregar las ejecuciones de pruebas, accediendo a Case/Run/New test run. Pueden crearse varias ejecuciones de pruebas en un mismo plan, por ejemplo, si se desean probar los mismos casos en diferentes ambientes, se aconseja crear una ejecución de prueba para cada una de ellas.
Ejecución de casos de prueba: Accediendo a la opción Runs, se muestra una lista de todas las ejecuciones creadas para el plan de pruebas, seleccionando una de ellas se listan los casos planificados para esa ejecución y opciones pare registrar status (IDLE, RUNNING, PAUSED, PASSED, FAILED, BLOCKED, ERROR, WAIVED), comentarios y bugs. En esta misma pantalla se va generando un resumen por status y % de ejecución. Accediendo al caso de prueba desde su ID y luego a la tab Case Runs, se podrá conocer la evolución del mismo en su diferentes ejecuciones.
Asociación de bugs: Como parte de las ejecuciones se permite agregar link a los incidentes reportados en alguna herramienta de Bug tracking, seleccionando la opción Bug/Add y luego indicando una de las herramientas activas y el identificador del Bug. Actualmente se integra con: GitHub, JIRA y Bugzilla. Otras integraciones pueden ser adicionadas de manera sencilla utilizando la interfaz: ADMIN -> Everything else -> Test cases -> Bug trackers. Cada bug tracker recibe un nombre, una breve descripción, URL, una expresión regular utilizada para validar el ID del bug, credenciales y tipo de integración.
Comparativa con Testlink
La siguiente tambla muestra una comparación con TestLink para las principales catacterísticas de los productos.
| Kiwi TCMS | TestLink | Comentarios relacionados a Kiwi TCMS | |
| Gestión de proyectos | No | Si | No cuenta con la división entre distintos proyectos. |
| Gestión de planes de prueba | Si | Si | Impresión sólo en pdf (limitando la edición del documento si se considera entregar al cliente). |
| Notificaciones vía mail ante cambios en planes y casos de prueba | Si | No | Configurable al momento de editar planes y casos de prueba. |
| Gestión de requerimientos | No | Si | No existe un módulo para gestionar requerimientos, se puede agregar textualmente en un campo en la edición del caso de prueba. |
| Gestión de casos de prueba | Si | Si | Se solicitan muchos datos de entrada. No se distinguen pasos de prueba, sino campos de texto donde el tester deberá ordenar los pasos como considere. Impresión sólo en pdf. |
| Ejecución de casos de prueba | Si | Si | Se puede registrar el status individualmente o en grupos (ventaja) Existen más estados. |
| Gestión de ambientes | Si | No | |
| Gestión de Plataformas | Si | ||
| Reportes | Si | Si | Los reportes no tienen opción de impresión. |
Errores encontrados durante la evaluación
Al momento de evaluar la herramienta me encontré con varios incidentes, en su mayoría reproducibles. Aquí paso una breve descripción de los mismos (no pretende ser un reporte de incidentes, solo una mención).
- La información se presenta usando idioma inglés y español indistintamente (en una misma pantalla se presentan opciones en uno y otro idioma).
- Al realizar varias acciones las páginas quedaron cargando y no se recuperaron, por ejemplo:
- Desde un plan de pruebas, seleccionar Case/Set Sort Number (colocar un número).
- Al acceder a la opción Show filter options y luego Filter Case (acá en realidad las opciones de búsqueda no están disponibles, sólo se muestra el label pero no se permite buscar).
- Al seleccionar la acción Default Testing desde plan de pruebas /cases.
- En la pantalla para agregar planes de prueba, se crea un plan de pruebas colocando en el campo versión (unspecified), se agregan los pasos y ejecuciones. Por otra parte se agrega una nueva versión desde la opción Admin/Ererything else/ versions. Si selecciono el plan para editarlo y coloco la nueva versión, me muestra una página de error 500 (esto sólo me ocurrió en el primer plan que creé).
- En la pantalla para agregar casos de prueba, si deseo agregar categorías me muestra página de error (403 Forbidden).
- En la pantalla para agregar una ejecución del plan de pruebas, si deseo agregar una Build me muestra página de error (403 Forbidden).
- En el Custom Report, filtro por Producto, entre los datos mostrados está la cantidad de ejecuciones, si doy clic sobre ese número esperando encontrar el detalle de esas ejecuciones, se muestra una pantalla con todas las ejecuciones registradas (de todos los productos), o sea que no se mantiene el filtro indicado en la primera búsqueda.
- Opción Change Log mostró segmentos de código (no identifiqué exactamente en qué caso de prueba me ocurrió, no ocurre siempre).
Conclusiones
Tal vez necesitaría más tiempo de análisis para identificar mejor sus potencialidades, pero hasta ahora no me convence mucho como alternativa a Testlink en el contexto en el que trabajamos en Abstracta. Algunas razones:
- No nos permite la distinción por proyectos. El plan de pruebas es la entidad contenedora de más alto nivel. Así, ¿cómo distingo entre los datos de un cliente y los de otro? O ¿cómo usarlo para un cliente que tiene distintos productos donde hay distintas personas involucradas en cada uno? El único workaround que se me ocurre es haciendo una instalación aparte para cada uno? Mirando la documentación se ve que se solicitó como requerimiento en diciembre 2017, sobre todo por la necesidad de poder personalizar campos por proyecto o cliente pero aún está abierto y no vi que tengan una fecha tentativa (dan como sugerencia a corto plazo reflejar el proyecto como un producto).
- Veo dificultades para la navegación (te permite ir adentrándote en determinadas pantallas pero el retorno no está muy claro, en ocasiones tuve que regresar al dashboard para retomar mi punto de partida).
- Es poco configurable, por ejemplo: se piden muchos datos para crear casos de prueba (y no hay posibilidad de adecuarlo a las necesidades de cada proyecto o producto), así como la posibilidad de ajustar los posibles estados de ejecución del caso de prueba (estos están reportados también, puede ser que se mejore a futuro).
- Aunque hay reportes interesantes, no vi posibilidad de exportar a csv o Word para poder editar o reutilizar datos de reportes para nuestros informes.
- La evolución de un caso de prueba (resultado del mismo por cada iteración) sólo lo puedo ver individualmente, no como en Testlink que veo para todo el plan los resultados de todas las ejecuciones (al menos no encontré dónde verlo).
