Un issue tracking system es el registro único donde cada problema, defecto y petición se anota, se asigna y se cierra — y se elige por cuatro cosas: cómo entran los tickets, cómo se mueven, quién puede verlos y cuánto cuesta con vuestro número de licencias.
Muchos equipos comparan listas de funcionalidades y seis meses después descubren que la herramienta está bien y lo que está roto es la puerta de entrada: los problemas llegan como mensajes de chat, capturas en una carpeta y «¿puedes mirar esto?». Nadie sabe cuántos quedan abiertos, y en el registro solo está lo que alguien se molestó en volver a escribir.
Esta guía cubre las dos mitades: los nueve criterios que de verdad deciden, y el paso de entrada que casi todas las páginas de comparación omiten.
Qué es realmente un issue tracking system
Un issue tracking system (también issue tracker, sistema de gestión de incidencias o, con un alcance más estrecho, bug tracking system o defect tracking system) hace cuatro cosas:
- Capturar: registrar un problema con detalle suficiente para que otra persona pueda actuar.
- Asignar: nombrar un responsable y hacer visible esa responsabilidad.
- Seguir: llevar un estado de nuevo a cerrado, con historial de quién cambió qué.
- Medir: responder cuántos hay abiertos, con qué antigüedad y dónde se acumulan.
Tableros, sprints, roadmaps, SLA y automatizaciones son capas encima. Si la captura y la medición son débiles, ningún diseño de tablero lo salva.
Issue tracking system vs bug tracker vs help desk
Los términos se solapan y los proveedores los usan con soltura. La diferencia práctica es el alcance:
| Sistema |
Alcance típico |
Quién suele llevarlo |
| Issue tracking system |
Todo lo que requiere una decisión: defectos, tareas, peticiones, dudas |
Producto o ingeniería |
| Bug tracker / defect tracker |
Solo defectos, normalmente ligados a un build o ciclo de pruebas |
QA |
| Help desk / service desk |
Peticiones entrantes de usuarios con compromisos de tiempo de respuesta |
Soporte o IT |
| Herramienta de test management |
Casos de prueba, ejecuciones y resultados, con defectos vinculados |
QA |
Elegid por alcance, no por categoría de proveedor. Un equipo que empieza con un bug tracker casi siempre necesita un issue tracking system en el año; uno que empieza con un service desk completo suele arrepentirse de la ceremonia.
Si buscas concretamente la vista del ciclo de vida del defecto — severidad, verificación, regresión — lee la comparativa de software de gestión de defectos. Esta página trata del registro general.
Los 9 criterios que deciden la elección
Ordénalos antes de abrir una prueba. El orden importa más que las respuestas.
| # |
Criterio |
Por qué determina el resultado |
Qué comprobar |
| 1 |
Entrada |
El registro vale lo que vale lo que entra en él |
¿Puede alguien no técnico enviar con un clic? ¿Llega el informe con captura, errores de Console, peticiones fallidas y navegador/OS/viewport? |
| 2 |
Flujo de trabajo |
Un flujo rígido se sortea; uno laxo esconde el estado |
¿Se añade un estado sin consultor? ¿Se registran las transiciones? |
| 3 |
Campos |
Severidad y prioridad no son el mismo campo |
¿Severity (impacto técnico) separada de priority (urgencia de negocio)? ¿Campos por proyecto? |
| 4 |
Detección de duplicados |
Los duplicados son la primera causa de bloqueo del triaje |
¿Búsqueda al escribir sobre título y URL de la página? ¿Fusión conservando historial? |
| 5 |
Integraciones de salida |
El registro debe llegar a donde la gente ya trabaja |
Chat (Slack / Teams), control de código, notas de versión y un webhook genérico para el resto |
| 6 |
Permisos |
Quien reporta desde fuera no debe ver vuestro backlog |
¿Rol de invitado limitado a sus propios tickets? ¿Visibilidad por proyecto? |
| 7 |
Medición |
Sin antigüedad de tickets no se gestiona la cola |
Abiertos por antigüedad, carga por responsable, tasa de reapertura, cycle time — exportables |
| 8 |
Coste con vuestras licencias |
La cuenta de licencias cambia la respuesta más que las funciones |
Precio a 5, 20 y 50 licencias; qué cuenta como licencia (¿lectores? ¿invitados? ¿quien reporta?) |
| 9 |
Salida |
Migraréis al menos una vez |
¿Exportación completa con adjuntos y comentarios? ¿API abierta? |
Una lista corta que ignore el criterio 1 se verá espléndida en la demo y fallará en la tercera semana.
9 issue tracking systems comparados (2026)
Los modelos de precio se describen por su forma, no con cifras exactas: las tarifas cambian y varían por región. Verifica los números actuales en cada proveedor.
| Herramienta |
Ideal para |
Los tickets entran por |
Modelo de precio |
Ojo con |
| Jira (Atlassian) |
Equipos que necesitan flujos configurables y ya viven en el ecosistema Atlassian |
Formularios, email, integraciones |
Plan gratuito y luego suscripción por licencia |
Deuda de configuración; pronto aparece un rol de administrador |
| Linear |
Equipos de producto que quieren velocidad y triaje con teclado |
Manual, Slack, integraciones |
Suscripción por licencia |
Deliberadamente opinionado; menos apto para colas no técnicas |
| GitHub Issues |
Trabajo ya pegado al repositorio |
Manual, plantillas, API |
Incluido en los planes de repositorio |
Débil en peticiones no técnicas y en informes entre repositorios |
| GitLab |
Equipos que quieren tickets, merge requests y CI en un sitio |
Manual, plantillas, API |
Suscripciones por niveles, opción autoalojada gratuita |
Funciones cortadas entre niveles |
| YouTrack (JetBrains) |
Equipos que quieren vistas por consultas y flujos propios |
Manual, email, integraciones |
Suscripción por licencia, gratis para equipos pequeños |
Interfaz densa; coste de adopción para quien no es técnico |
| Azure DevOps Boards |
Equipos de stack Microsoft con planes de prueba y pipelines |
Manual, pipelines, integraciones |
Suscripción por usuario |
Solo compensa si usas el resto de Azure DevOps |
| Bugzilla |
Proyectos longevos que necesitan una base de defectos probada y autoalojada |
Manual, email |
Gratis, código abierto |
Interfaz anticuada; informes vía extensiones |
| Redmine |
Equipos con administrador de sistemas que quieren módulos y control total |
Manual, email |
Gratis, código abierto |
Exceso de plugins; las actualizaciones son trabajo real |
| MantisBT |
Equipos pequeños que quieren un tracker simple y autoalojado |
Manual, email |
Gratis, código abierto |
Poca automatización y pocas integraciones modernas |
Ninguna es mala. El fallo es elegir por el motor de flujos y dejar la entrada al copiar y pegar.
El paso que casi ninguna selección hace: cómo entra el ticket
Todas las herramientas de la tabla suponen que el ticket ya está descrito. Y ahí se va el tiempo:
- un tester escribe «el botón de pago no hace nada» y el desarrollador hace tres preguntas antes de abrir DevTools;
- una captura duerme en un hilo de chat, separada de la URL y del navegador;
- el error de Console que lo explica todo nunca se capturó, porque quien reporta no sabe qué es la Console;
- el bug no se reproduce, se cierra como «en mi máquina funciona» y vuelve dos sprints después.
Compara lo que llega en cada caso:
| Qué necesita un arreglo |
Informe manual |
Informe con contexto automático |
| Dónde ocurrió |
«la página de pago, creo» |
URL y título exactos |
| Qué se pulsó |
Una frase en palabras de quien reporta |
Captura anotada señalando el elemento, con su selector |
| Qué está roto |
«no funciona» |
Errores de Console y peticiones de red fallidas, literalmente |
| Entorno |
«Chrome, ¿un Mac?» |
Navegador, OS, viewport, marca de tiempo |
| Quién puede reproducirlo |
Nadie, hasta que quien reporta tenga tiempo |
Cualquiera con el enlace, de inmediato |
Esa es justo la capa que cubre BugCapturer, y deliberadamente no es un tracker: los testers capturan con la extensión de navegador (captura, anotación, grabación de pestaña), los visitantes reportan con un Web SDK incrustado sin instalar nada, y cada informe lleva automáticamente contexto de Console y red. Los informes llegan a Slack, Microsoft Teams, Lark Bitable o tu propio webhook — la capa de entrada alimenta el tracker que elijas arriba en lugar de competir con él. El plan gratuito incluye una licencia, tres proyectos y una integración, con la captura de Console siempre incluida; el resto está en precios.
El reparto que funciona para la mayoría: el tracker decide, la capa de captura recoge. El tracker guarda estado, responsabilidad e historial; la capa de captura garantiza que cada elemento llegue completo.
Un proceso de selección en 60 minutos
Escribe la frase de entrada (10 min). «Un [rol] que reporta un [tipo de problema] debe poder enviarlo en menos de [N] clics, con [estos artefactos] adjuntos». Si dos proveedores no cumplen esa frase, quedan fuera.
Enumera tus tres colas reales (10 min). No hipotéticas: donde hoy se acumulan los problemas (chat de cliente, hoja de QA, email del cliente). Cada una necesita una vía de entrada.
Puntúa los nueve criterios (15 min). De 1 a 3 por criterio, con el doble de peso en entrada y medición. En empate suele decidir el criterio 9 (salida).
Pasa un ticket real por dos finalistas (15 min). Sin guion de demo: coge el bug más desordenado de ayer y envíalo de principio a fin. Cronometra y cuenta cuántas preguntas tiene que hacer el desarrollador.
Calcula 12 meses y 20 licencias (10 min). Incluye las horas de administración. Una herramienta autoalojada «gratis» con una hora semanal de mantenimiento no es gratis.
Cuánto cuesta de verdad
Tres números deciden la factura y solo el primero está en la página de precios:
- Licencias × meses. Vigila la definición de licencia. Si quien reporta desde fuera o quien solo lee consume licencias, la cifra real supera con creces la plantilla.
- Complementos de integración y automatización. Muchos planes «baratos» limitan automatizaciones, llamadas a la API o integraciones: justo lo que hace útil un tracker.
- Administración. Diseñar flujos, limpiar campos y fusionar duplicados es trabajo continuo. Reserva unas horas al mes o el registro se degrada.
Un plan gratuito es un estado final legítimo para un equipo pequeño, no solo una prueba. Si sois de una a cinco personas siguiendo defectos en unos pocos proyectos web, una herramienta de captura ligera más un canal de chat pueden sustituir por completo a un tracker — y lo mantendréis actualizado de verdad, que es la única métrica que importa.
Lista de migración
Cambiar de tracker es sobre todo un problema de adjuntos y comentarios, no de campos.
- Exporta todo: tickets, comentarios, adjuntos, seguidores e historial de estados.
- Mapea los estados a los del destino, no uno a uno: casi siempre necesitas menos de los que tienes.
- Decide qué hacer con los tickets cerrados de hace más de 12 meses antes de moverlos.
- Mantén el sistema antiguo en solo lectura al menos un trimestre; alguien necesitará un enlace.
- Reconecta las integraciones primero e invita después: el orden inverso genera una semana de notificaciones duplicadas.
- Haz doble entrada solo una semana y solo para P0/P1, luego corta.
- Tras el corte, comprueba que la entrada sigue funcionando: la forma más rápida de matar una migración es romper el botón de reportar.
Preguntas frecuentes
¿Jira es un issue tracking system?
Sí. Jira es un tracker configurable que además cubre planificación de proyecto y sprint. Es una opción sólida cuando importa la flexibilidad del flujo y alguien se hace cargo de la configuración.
¿Cuál es la diferencia entre issue tracking y bug tracking?
El bug tracking cubre solo defectos. El issue tracking cubre todo lo que exige una decisión — defectos, tareas, peticiones, dudas — siendo el defecto un tipo más. La mayoría de bug trackers acaban siendo issue tracking systems.
¿Un equipo pequeño necesita un issue tracking system?
De una a cinco personas pueden funcionar con un canal de chat, una herramienta de captura y una lista compartida, siempre que cada elemento tenga responsable y estado. En cuanto dos personas no saben qué se está arreglando ya, el tracker se paga solo.
¿No basta con una hoja de cálculo?
Para un proyecto pequeño y corto, una hoja es un registro legítimo. Se rompe cuando necesitas permisos, notificaciones, adjuntos e historial de cambios de estado: normalmente cuando entra el primer cliente externo.
¿Cuál es la configuración más barata que tiene sentido?
Capturar con una herramienta gratuita o barata que adjunte contexto de Console, red y entorno, y empujar los informes al canal de chat o al tracker que ya pagas. El coste es casi cero y la calidad del dato es mejor que la de una suite completa alimentada a copiar y pegar.
¿Cómo evitamos que los problemas lleguen como mensajes de chat?
Haz que enviar sea más rápido que escribir un mensaje: un clic, una captura anotada, entorno automático y un destino que el equipo ya lee. Si reportar tarda más que quejarse, la gente se queja.