SaveLink añade a SaveTest un registro de requisitos, comparación de ramas y planificación

SaveLink ha lanzado una actualización de SaveTest, su plataforma de gestión de pruebas. El anuncio se publicó el 8 de octubre de 2026 y destaca tres funciones clave: un registro de requisitos con matriz de trazabilidad, la comparación de ramas y la planificación de ejecuciones de prueba. La parte disponible del material no incluye métricas de rendimiento, número de clientes ni precios, así que la versión solo puede valorarse por su conjunto de funciones y por las tareas de los equipos de QA que pretende cubrir.

Qué incluye la versión

El cambio principal es la unión de requisitos y pruebas. Hasta ahora, este tipo de sistemas solía almacenar casos de prueba y resultados de ejecución, mientras que los requisitos vivían en el gestor de tareas o en documentos. Ahora el registro de requisitos está dentro de SaveTest, y la matriz muestra qué requisitos están cubiertos por pruebas y cuáles siguen sin verificar.

Contenido de la actualización según la descripción publicada:

• registro de requisitos dentro de la plataforma;
• matriz de trazabilidad: vínculo entre requisito, caso de prueba y resultado;
• comparación de ramas;
• planificación de ejecuciones de prueba;
• fecha del anuncio: 8 de octubre de 2026, fuente: CNews.

Para qué sirve la trazabilidad

La matriz de trazabilidad responde a la pregunta que los responsables de QA oyen antes de cada lanzamiento: qué hemos verificado exactamente y qué ha quedado sin cubrir. Si un requisito está vinculado a casos de prueba y a sus últimos resultados, el hueco se ve de inmediato, sin cotejar tablas a mano. En proyectos sujetos a auditoría, con requisitos regulatorios o con un ciclo de vida largo del producto, esa transparencia es especialmente importante: permite demostrar a los auditores cómo se ha comprobado cada requisito mediante una prueba.

También hay un efecto inverso. Es fácil detectar los casos de prueba que no están vinculados a ningún requisito. Se mantienen en el conjunto por costumbre y consumen tiempo de ejecución sin proteger nada concreto.

Ramas y planificación

La comparación de ramas resuelve un problema del desarrollo en paralelo. Cuando un producto evoluciona en varias líneas, por ejemplo la rama principal, la de lanzamiento y la de una funcionalidad grande, los conjuntos de pruebas se desincronizan. La herramienta de comparación permite ver en qué se diferencian las versiones y no perder cambios al fusionarlas. Los detalles de la implementación no se revelan en el fragmento disponible: no está claro si se comparan solo los casos de prueba o también los requisitos y los resultados.

La planificación de ejecuciones es una función más terrenal, pero es la que determina el trabajo diario. El calendario de ejecuciones, el reparto de pruebas entre responsables y compilaciones, la visibilidad de la carga del equipo: todo esto suele vivir en hojas de cálculo y chats. Llevarlo a la plataforma reduce la probabilidad de que se olvide una ejecución de regresión o de que se lance sobre una compilación equivocada.

Mercado y contexto

SaveTest llega a un mercado saturado. Compiten con él TestRail, Qase, Allure TestOps y Test IT, y cada uno ya tiene su propia versión de trazabilidad y planificación. Por eso, la diferenciación tendrá que venir de la profundidad de las integraciones y de la comodidad al trabajar con ramas. En un momento de adopción masiva de la IA en las pruebas, por ejemplo para generar casos de prueba a partir de requisitos, llama la atención otro dato: la parte disponible del anuncio no dice nada sobre funciones de IA. La versión apuesta por el proceso y la disciplina, no por la generación automática.

Qué comprobar antes de la implantación

Los equipos que estén valorando la actualización deberían aclarar con el proveedor varios puntos:

• cómo llegan los requisitos al registro: importación desde el gestor de tareas, API o entrada manual;
• si es posible sincronizar los estados de los requisitos con las tareas en Jira o herramientas similares;
• qué se compara exactamente al contrastar ramas y cómo se resuelven los conflictos;
• si existen informes de cobertura aptos para auditoría;
• qué opciones de despliegue hay: nube o infraestructura propia.

Para un piloto basta con tomar un producto con dos ramas activas y medir cuánto tiempo lleva preparar el informe de cobertura antes y después del cambio. Si la matriz se genera automáticamente y coincide con la realidad, la función se amortiza. Si los vínculos hay que mantenerlos a mano, no habrá ganancia.