Test Case Management
QACasos de prueba, suites y paquetes reutilizables, conectados a cada petición y a cada pipeline de CI, con trazabilidad completa del requisito al defecto.
Varios servidores: $399
- Redmine
- 5.0 y posteriores, 6.x, 7.x
- Informes
- 12, con CSV y Excel
- Permisos
- 18, por rol de proyecto
- CI/CD
- API REST, autenticación con clave de API
- Idiomas
- 50 archivos de idioma
- Tipos de petición
- Los tuyos, sin cambios
Casos de prueba reutilizables
Suites y paquetes
Ejecuciones inmutables
Correspondencia con la automatización
API REST para CI/CD
Paneles e informes
Una sola cadena, del requisito al defecto que produjo
Nada en la cadena es una copia. Una petición apunta a los casos de prueba que la validan, cada ciclo añade una ejecución y una ejecución fallida apunta al error que originó. Sigue los enlaces en cualquier sentido y llegarás a registros reales de Redmine.
1. Petición
Una funcionalidad, historia o requisito en el tipo de petición que ya uses. El plugin no añade ningún tipo propio.
2. Caso de prueba
Asignado uno a uno o mediante un paquete. El mismo caso, por ejemplo TC-41, puede servir a tantas peticiones como haga falta.
3. Plan y ciclo
Un plan (TP-2) fija el alcance de una versión; un ciclo (TR-5) es una sesión sobre un build.
4. Ejecución
Correcto, fallido, bloqueado u omitido, con build, commit, entorno, resultados por paso y capturas. Nunca se edita después.
5. Defecto
Una petición normal de Redmine enlazada desde el fallo, creada a mano o automáticamente cuando falla una prueba.
Las reglas que mantienen unida la cadena
Referencias TC-, TB-, TP-, TR- y DS- con los prefijos que elijas, ejecuciones ancladas a la versión del caso que se ejecutó y una regla opcional que impide cerrar una petición hasta que se superen sus pruebas.
Todo el flujo de trabajo, capturado en un Redmine 6.1 en funcionamiento
Son pantallas reales del plugin con el tema predeterminado de Redmine. El proyecto, las personas y los resultados son datos de demostración de una tienda online ficticia llamada Harbor Storefront.
Escribir: una biblioteca de casos de prueba reutilizables
Busca y filtra por módulo, estado, automatización y etiquetas. Cada caso tiene pasos estructurados, un rastro de revisión y su propio historial de versiones.
Planificar: paquetes, planes de versión y datos de prueba
Los paquetes reúnen casos para reutilizarlos. Un plan une paquetes, peticiones, testers y una versión de Redmine. Los conjuntos de datos alimentan un mismo caso con muchas filas.
Ejecutar: las pruebas se hacen en la petición y en el ciclo
Desarrolladores y testers trabajan donde ya están. Cada resultado es una ejecución nueva, así que el historial es el registro de auditoría.
Decidir: informes que responden a «¿podemos publicar?»
Doce informes, todos con CSV, Excel e impresión. Dos de ellos están pensados para la conversación sobre la versión.
A tu manera: importación, notificaciones y ajustes
Cómo se ven treinta días de pruebas en los informes
Las cifras siguientes salen directamente del proyecto de demostración de las capturas, leídas en los propios informes del plugin: 70 casos de prueba y 1242 ejecuciones entre el 9 de septiembre y el 8 de octubre de 2026. Muestran lo que mide el plugin. No son benchmarks ni resultados de clientes.
| Medida | Valor | Detalle |
|---|---|---|
| Casos de prueba | 70 | 61 aprobados, 5 en revisión |
| Ejecuciones | 1,242 | 856 automatizadas, 386 manuales |
| Tasa de éxito | 87.8% | Objetivo: 90 % |
| Cobertura de automatización | 60% | 42 de 70 casos |
| Defectos originados por fallos | 5 | Vinculados a la ejecución fallida |
| Entorno | Ejecuciones | Correcto | Fallido | Bloqueado | Omitido | Tasa de éxito |
|---|---|---|---|---|---|---|
| QA | 700 | 610 | 47 | 29 | 14 | 87.1% |
| Staging | 344 | 307 | 20 | 10 | 7 | 89.2% |
| DEV | 162 | 142 | 12 | 5 | 3 | 87.7% |
| UAT | 36 | 31 | 3 | 1 | 1 | 86.1% |
| Módulo | Casos | Ejecuciones | Correctos | Tasa de éxito |
|---|---|---|---|---|
| API | 5 | 129 | 123 | 95.3% |
| Catálogo | 8 | 118 | 112 | 94.9% |
| Notificaciones | 5 | 99 | 93 | 93.9% |
| Administración | 6 | 62 | 56 | 90.3% |
| Búsqueda | 6 | 143 | 128 | 89.5% |
| Autenticación | 10 | 193 | 172 | 89.1% |
| Checkout | 8 | 131 | 114 | 87.0% |
| Pedidos | 6 | 89 | 73 | 82.0% |
| Carrito | 8 | 143 | 116 | 81.1% |
| Pagos | 8 | 135 | 103 | 76.3% |
Dentro de Redmine, las mismas cifras aparecen en el cuadro de mando (anillo de tasa de éxito, distribución de resultados, tendencia a 14 días, cobertura por módulo y por componente) y en los informes tabulares, todos con exportación a CSV y Excel.
Construido sobre una regla: un caso de prueba nunca se duplica
Casos de prueba reutilizables
Título, precondiciones, pasos estructurados con resultados esperados, módulo, componente, prioridad, severidad, tipo y etiquetas. Clona, edita en bloque, importa y exporta.
Versiones que protegen el historial
Editar un caso que ya se ha ejecutado crea una versión nueva. Las ejecuciones antiguas siguen apuntando a los pasos que realmente se ejecutaron.
Revisión y aprobación
Borrador, en revisión, aprobado, obsoleto. Cada decisión queda registrada con revisor, fecha y comentario, y se notifica al autor.
Paquetes, planes y ciclos
Los paquetes agrupan casos para reutilizarlos. Los planes delimitan una versión o un sprint sobre una versión de Redmine. Los ciclos registran una sesión sobre un build.
Un panel de pruebas en cada petición
Casos asignados, últimos resultados, tasa de éxito, defectos vinculados y registro en un clic, en los tipos de petición que elijas.
Ejecuciones que puedes auditar
Cada ejecución añade un registro con resultado, modo, entorno, build, commit, duración, resultados por paso, log y capturas. Nada se sobrescribe.
Pruebas basadas en datos
Conjuntos de datos reutilizables con columnas con nombre. Asócialos a casos o a paquetes enteros y registra qué fila usó cada ejecución.
Correspondencia con la automatización y CI/CD
Asocia un caso a un framework y a un identificador que tu runner entienda, y deja que el pipeline obtenga qué ejecutar y suba los resultados.
Cuadro de mando y doce informes
Un cuadro de mando que cada usuario compone con ocho widgets, más informes de preparación, cobertura, tendencia, entornos, defectos y seguimiento.
Cuatro ciclos de vida breves, todos visibles en la página
| Registro | Recorrido principal | Otros estados |
|---|---|---|
| Caso de prueba | Borrador → En revisión → Aprobado | Cambios solicitados, Obsoleto |
| Plan de pruebas | Borrador → Activo → Completado | Archivado |
| Ciclo de pruebas | Planificado → En curso → Completado | Interrumpido |
| Resultado de ejecución | Correcto, Fallido, Bloqueado u Omitido | No ejecutado. Cada resultado se registra como manual o automatizado. |
Tu pipeline pregunta qué ejecutar y luego informa del resultado
La API REST está bajo /testcases/api/v1 y se autentica con una clave de API normal de Redmine. Cualquier cosa capaz de enviar una petición HTTP puede usarla. Una guía incluida en el plugin recorre la configuración con tus propias URL ya rellenadas.
| Método | Endpoint | Finalidad |
|---|---|---|
| GET | /issues/:id/testing | Qué ejecutar para una petición |
| POST | /executions/upload | Resultados de un build para una petición |
| POST | /executions/bulk_upload | Resultados de varias peticiones o builds |
| POST | /test_runs | Crear un ciclo para este build |
| POST | /test_runs/:id/results | Enviar resultados a un ciclo |
| GET | /test_cases | Listar, crear y actualizar casos |
| GET | /test_plans | Listar, crear y actualizar planes |
| GET | /issues/:id/coverage | Cobertura de pruebas de una petición |
| GET | /reports/:name | Cualquier informe en JSON |
| GET | /dashboard | Métricas agregadas |
Subir los resultados de un build
Envía por POST a /executions/upload el id de la petición, el número de build, el SHA del commit, el entorno y una lista de resultados. Los resultados se emparejan con los casos por identificador de automatización, id del caso o referencia, y cada uno se convierte en una ejecución nueva. Los nombres de resultado se normalizan, de modo que passed, failure e ignored de tu runner acaban donde deben, y un resultado fallido enviado con create_defect genera un error vinculado.
Dieciocho permisos en un solo módulo de proyecto
Pruebas es un módulo de proyecto estándar de Redmine. Actívalo donde hagas pruebas y da a cada rol solo lo que necesita. Las pestañas del menú siguen los permisos.
| Rol | Permisos habituales | Qué hace |
|---|---|---|
| Responsable de QA | manage_test_cases, approve_test_cases, manage_test_bundles, manage_test_plans, assign_test_bundles | Se encarga de la biblioteca, aprueba casos y crea paquetes y planes de versión |
| Tester | view_test_cases, execute_tests, manage_test_runs, manage_test_data | Ejecuta pruebas, registra resultados y mantiene los datos de prueba |
| Ingeniero de automatización | manage_test_automation, view_test_executions | Asocia casos a frameworks e identificadores |
| Desarrollador | view_test_cases, view_test_executions, view_test_runs | Ve qué se ha probado en una petición y por qué falló |
| Jefe de proyecto | view_test_reports, view_test_plans | Consulta los informes de preparación, cobertura y seguimiento |
| Cuenta de servicio de CI | upload_test_results | Sube resultados con su clave de API, nada más |
| Administrador | admin_testing_settings, manage_test_environments | Prefijos, entornos, objetivos y la regla de cierre |
Funciona donde ya funciona tu Redmine
| Entorno | Estado | Notas |
|---|---|---|
| Redmine 7.x | Compatible | |
| Redmine 6.1 | Compatible | Versión objetivo del desarrollo, sobre Rails 7.2 y Ruby 3.4. Las capturas de esta página son de la 6.1.2. |
| Redmine 6.0 | Compatible | |
| Redmine 5.x | Compatible | 5.0 es la versión mínima que declara el plugin |
| MySQL 8 | Compatible | Usado para el desarrollo y para la demo de esta página |
| Tipos de petición | Los tuyos | Funciona con cualquier configuración de tipos de petición. Limita el panel de pruebas a los tipos que elijas o déjalo en todos. |
| Gems adicionales | Una, opcional | roo, solo para importar archivos .xlsx y .xls |
Instalación en tres pasos
Requiere acceso por shell y poder ejecutar tareas rake. Haz siempre una copia de seguridad antes de instalar un plugin.
cd /opt/redmine # unpack so the folder is plugins/redmine_testcases bundle install
RAILS_ENV=production bin/rails redmine:plugins:migrate NAME=redmine_testcases
# Project → Settings → Modules → Test Case Management # Administration → Roles and permissions → grant the testing permissions # Testing → Settings → environments, pass-rate target, trackers
RAILS_ENV=production bin/rails redmine:plugins:migrate NAME=redmine_testcases VERSION=0
¿Añade sus propios tipos de petición para requisitos, historias o errores?
¿Qué pasa con los resultados antiguos cuando alguien edita un caso de prueba?
¿Puede una prueba fallida impedir que se cierre una petición?
¿Con qué sistemas de CI funciona?
¿Pueden los fallos crear errores automáticamente?
¿Podemos traer casos de prueba desde una hoja de cálculo?
¿Son reales las cifras de esta página?
Precios
Un servidor
Una instancia de Redmine · usuarios ilimitados · 12 meses de actualizaciones.
Varios servidores
Servidores de Redmine ilimitados · usuarios ilimitados · 12 meses de actualizaciones.
¿Necesita una solución de Redmine a medida?
¿Busca una función que nuestros plugins aún no ofrecen?
RedmineKit desarrolla plugins de Redmine a medida, personaliza plugins existentes, automatiza flujos de trabajo, integra herramientas de terceros y crea soluciones adaptadas a su empresa.
Cuéntenos lo que necesita. Revisaremos sus requisitos y le propondremos una solución adecuada con un coste y un plazo estimados.