Por qué el título importa más que el resto del informe
Un buen título de bug = dónde ocurrió + qué hiciste + qué salió mal + bajo qué condición se reproduce. Si esos cuatro datos caben en una línea, un desarrollador puede reproducir el fallo sin preguntarte nada. Esa es toda la diferencia entre un buen título y uno malo. Abajo tienes 40 ejemplos comparados, repartidos en siete escenarios — login, registro, pagos, móvil, APIs, rendimiento e interfaz — para reescribir tus propios bugs.
Los desarrolladores leen primero el título, siempre. Un título vago significa o una ronda extra de preguntas, o que el ticket se queda sin abrir. Peor aún: un mal título no se salva con un bloque de entorno excelente — nadie abre un ticket llamado «el botón está roto».
Un título se aprueba o se suspende por cuatro cosas: si es específico (nombra el componente o la página), si es observable (hechos, no «no funciona»), si lleva condiciones (navegador, dispositivo, tipo de cuenta, momento) y si permite juzgar el alcance (caída total o caso límite).
La fórmula de 4 partes para títulos de bug
[Componente/Página] + [Acción] + [Resultado inesperado] + [Condición]
Cómo rellenar cada parte:
- Componente: página de checkout / modal de login / lista de pedidos /
POST /api/orders - Acción: hacer clic, enviar, subir, cambiar de pestaña, escanear
- Resultado inesperado: no ocurre nada, devuelve 500, el importe tiene un dígito de más, el estado no se sincroniza, el texto se solapa
- Condición: Chrome 120, iOS 17.2, ancho <390px, solo cuentas enterprise, tras un timeout de red
Sentence case, el componente primero, sin etiquetas de prioridad. Es la convención que adopta la mayoría de los equipos — y la coherencia importa más que la convención que elijas.
1. Login y cuentas (7 ejemplos)
| Título débil | Título fuerte |
|---|---|
| El botón de inicio de sesión no funciona | Al hacer clic en «Iniciar sesión» en Chrome 120 no ocurre nada; la consola lanza TypeError: login is not a function |
| No llega el correo de restablecimiento | No llega el correo tras pulsar «He olvidado mi contraseña» con una dirección de Gmail (revisado el spam a los 30 minutos) |
| Redirección incorrecta tras el login | Un usuario estándar aterriza en /admin en lugar de /dashboard tras iniciar sesión; reproducible desde la v5.3 |
| El captcha falla siempre | Un captcha válido se rechaza con «Código no válido» — solo en ventanas privadas o de incógnito |
| La cuenta se bloquea | Tres contraseñas incorrectas bloquean la cuenta de forma permanente, pero el mensaje dice «vuelve a intentarlo en 24 horas» |
| La sesión no se invalida | Iniciar sesión en un segundo dispositivo no invalida la primera sesión, que sigue totalmente operativa |
| Falla el login por SSO | El callback de SSO devuelve «Invalid signature» desde la rotación del certificado del IdP |
Conclusión: en bugs de login, la condición (navegador, tipo de cuenta, incógnito) decide si alguien puede reproducirlo. No la omitas.
2. Registro y formularios (7 ejemplos)
| Título débil | Título fuerte |
|---|---|
| No puedo registrarme | El registro rechaza direcciones con «+» (p. ej. user+test@x.com) con «Formato de correo no válido» |
| La validación del teléfono no funciona | Un número completo de 11 dígitos sigue mostrando «Introduce un número de 11 dígitos» |
| El indicador de seguridad es erróneo | Una contraseña de 8 caracteres que ya incluye dígitos sigue mostrando «debe incluir un número» |
| El desplegable no responde | El desplegable «País» no se puede seleccionar con las flechas tras filtrar escribiendo 3 caracteres |
| El formulario se envía dos veces | Pulsar Enter en el formulario de registro lo envía dos veces y crea dos cuentas duplicadas |
| Campo obligatorio sin validar | El registro se completa sin marcar «Acepto los términos» y la cuenta se crea igualmente |
| Zona horaria por defecto incorrecta | La zona horaria aparece en UTC+0; los usuarios en UTC+8 deben cambiarla a mano en cada registro |
Conclusión: sustituye la descripción por valores de entrada concretos. Una cadena real vale más que diez frases de «la entrada no funciona».
3. Pagos y checkout (7 ejemplos)
| Título débil | Título fuerte |
|---|---|
| El pago falla | Un total de 129,99 € se muestra como 1.299,99 € (un dígito de más) en el checkout, y la pasarela hereda el importe erróneo |
| El cupón no funciona | Un cupón caducado sigue apareciendo como «válido»; al aplicarlo devuelve un 500 y vacía el carrito |
| El contador del carrito no se actualiza | El contador de la cabecera sigue mostrando «1» tras eliminar el último artículo, hasta recargar la página |
| Cobro duplicado | Reintentar el pago tras un timeout de red cobra dos veces el mismo pedido (pedido n.º 10231) |
| Los datos de facturación no se guardan | Los datos de facturación de la empresa se borran al retroceder un paso y volver al checkout |
| Estado de reembolso desincronizado | El pedido sigue mostrando «Pagado» en la vista del cliente aunque el reembolso ya se emitió (pedido n.º 10388) |
| Falta un método de pago | La opción de tarjeta no aparece en el checkout — solo en cuentas con el modelo de facturación antiguo |
Conclusión: si hay dinero o números de pedido de por medio, pon el número de pedido en el título. Reduce el triaje a la mitad.
4. Móvil y responsive (6 ejemplos)
| Título débil | Título fuerte |
|---|---|
| El diseño se rompe en móvil | El botón «Añadir al carrito» se solapa con el precio en iPhone 14 (iOS 17.2) por debajo de 390px de ancho |
| La página no hace scroll | Abrir un modal bloquea el scroll en móvil y sigue bloqueado tras cerrarlo |
| El teclado tapa el campo | El teclado de Android Chrome tapa el botón «Enviar», que no se puede pulsar |
| Diseño en horizontal roto | La barra de navegación se parte en iPad en horizontal (1024×768) y el logo se solapa con el menú |
| Las imágenes no cargan | Falta la imagen principal del producto en Safari iOS 16; la consola devuelve 403 (firma de CDN caducada) |
| Área táctil demasiado pequeña | Los botones de paginación en móvil tienen un área táctil de 12×12px, por debajo del mínimo de accesibilidad de 44px |
Conclusión: en móvil, «móvil» no es una condición. Escribe el modelo exacto, la versión de sistema y el ancho de viewport.
5. Datos, APIs y permisos (6 ejemplos)
| Título débil | Título fuerte |
|---|---|
| La exportación falla | Exportar más de 10.000 pedidos devuelve 504; la exportación por lotes sí funciona |
| Marcas de tiempo incorrectas | Las marcas de tiempo del informe van 8 horas atrasadas — solo en usuarios con zona horaria Asia/Shanghai |
| La búsqueda no devuelve nada | Buscar «iPhone» devuelve 0 resultados aunque existen 12 registros coincidentes en la base de datos |
| Filas duplicadas al paginar | La lista de pedidos repite las 3 últimas filas de la página 1 al inicio de la página 2 |
| Error al subir archivos | Subir un PNG de más de 5MB devuelve 413, pero la interfaz muestra «Subida completada» con el archivo vacío |
| Escalada de privilegios | Un rol de solo lectura puede llamar a DELETE /api/projects/12 y borrar un proyecto correctamente |
Conclusión: en bugs de API, pon el código HTTP, la ruta del endpoint o el umbral en el título. Es medio trabajo de depuración hecho de antemano.
6. Rendimiento y carga (3 ejemplos)
| Título débil | Título fuerte |
|---|---|
| La página va lenta | El LCP de la home es de 8,2s en 4G, causado por 2,1MB de JavaScript sin comprimir |
| Fuga de memoria | La memoria pasa de 120MB a 900MB tras cambiar de pestaña 20 veces, y la pestaña acaba cerrándose |
| La API va lenta | El P95 del endpoint de listado de productos es de 4,8s (base 300ms), solo en picos de ofertas |
Conclusión: un bug de rendimiento necesita un número y una referencia, o nadie podrá decidir si siquiera es un defecto.
7. Textos y detalles de interfaz (4 ejemplos)
| Título débil | Título fuerte |
|---|---|
| Faltas de ortografía en la página | «Confirmacion» debería ser «Confirmación» en la página de confirmación de pedido |
| Iconos inconsistentes | Dos de los cuatro iconos de la página de ajustes son de estilo lineal y dos de estilo relleno |
| Modo oscuro ilegible | En modo oscuro el texto del campo es #333 sobre fondo oscuro, prácticamente invisible |
| Mensaje de error inútil | Una subida fallida solo muestra «Operación fallida», sin causa ni indicación para reintentar |
Conclusión: en bugs de texto e interfaz, escribe «lo que pone → lo que debería poner». Es el tipo de bug con menor coste de revisión.
7 hábitos que empeoran los títulos
Cómo escribir según tu rol
| Rol | Cómo hacerlo |
|---|---|
| QA / tester | Fórmula completa de 4 partes, con todas las condiciones (navegador, dispositivo, cuenta, red) |
| Soporte u operaciones que escala | Síntoma visible para el usuario + ruta reproducible + captura; omite la causa si no la conoces y marca «pendiente de confirmación técnica» |
| Revisor de UAT | Ancla al criterio de aceptación: «Incumple AC-3: el estado del pedido no se actualiza en 5 segundos» |
| Product manager | Describe el impacto visible para priorizar, pero no sustituyas el síntoma técnico |
Cuando un título se traduce
| Título en idioma original | Título en español |
|---|---|
| 结算页删除最后一件商品后购物车角标未更新 | El contador del carrito no se actualiza tras eliminar el último artículo en el checkout |
| Android Chrome 键盘遮挡提交按钮，无法点击 | Android Chrome: el teclado tapa el botón Enviar y no se puede pulsar |
| 只读角色可删除项目（越权） | Un rol de solo lectura puede borrar proyectos (escalada de privilegios) |
Tres reglas cuando un título cambia de idioma: mantén los nombres de componentes en su idioma original si son nombres propios, traduce literalmente el resultado observable y no traduzcas nunca los mensajes de log ni los códigos de error. Una traza traducida es un bug irreproducible.
FAQ
¿Cuánto debe medir un título de bug? Unos 60 caracteres o 10 palabras como máximo, para que no se recorte en los listados. Si no cabe, o no has aislado el síntoma principal, o en realidad son dos bugs.
¿Debe incluir la prioridad o la severidad? No. La prioridad es un campo aparte que cambia con la planificación. Cuando cambia, el título queda mal — y ensucia la búsqueda.
¿Puedo escribir una suposición si no conozco la causa? «Posiblemente causado por X» es aceptable, pero nunca como conclusión cerrada. Justifícalo en el cuerpo del ticket, o desviarás el triaje.
¿Un bug en varios navegadores son varios tickets? Titula el síntoma principal y pon las diferencias de entorno en el campo de entorno o notas. Sepáralo solo si las rutas de corrección son realmente distintas, por ejemplo rutas de código separadas para iOS y Android.
¿Title Case o sentence case? Ambas valen, pero mantén la coherencia con tu backlog. Sin historial previo, sentence case se lee mejor y se escanea más rápido.
El título lo sigues escribiendo tú; el resto puede ser automático
Que quede claro: BugCapturer no escribe tu título — eso requiere tu criterio sobre lo que has visto. Pero los campos tediosos y fáciles de olvidar sí pueden rellenarse solos:
- Contexto técnico automático: URL, navegador, sistema operativo, resolución de pantalla y tamaño de viewport se capturan por ti, así que las condiciones del título ya no hay que copiarlas a mano.
- Datos de diagnóstico: se recogen los logs de consola de nivel error y las peticiones de red fallidas (HTTP ≥ 400), con anonimización automática de parámetros sensibles (tokens, contraseñas, claves de API).
- Capturas anotadas: arrastra para seleccionar la zona del problema y añade flechas, cajas y texto, para dejar fijado «dónde está mal» en la imagen.
- Grabación de pantalla: graba la pestaña actual y recorta el clip, para que el desarrollador reciba un vídeo de 12 segundos que puede verificar.
- Compartir o sincronizar en un clic: genera un enlace que colaboradores externos abren sin registrarse, o envía el informe a Feishu Bitable o a un webhook genérico.
Así solo tienes que acertar con esa única línea de título, y la herramienta rellena el resto.
Checklist descargable
Pégala junto a tu monitor y revísala antes de enviar:
- ¿Nombra el componente o la página?
- ¿Plantea un hecho observable en lugar de «no funciona»?
- ¿Incluye condiciones (navegador / dispositivo / cuenta / red / ancho)?
- ¿Lleva un dato verificable (código de estado, n.º de pedido, importe, duración, umbral)?
- ¿Describe exactamente un solo síntoma?
- ¿Se han eliminado la prioridad y cualquier suposición sin verificar?
- ¿Se queda por debajo de 60 caracteres o 10 palabras?
Si superas las siete, tus títulos se triarán antes que el 90% del backlog.
Lecturas recomendadas: plantilla de informe de bug (lista completa de campos y plantilla para copiar) · cómo reportar bugs con eficacia · plantilla de casos de prueba con ejemplos · Formato de informe de bug · Cómo escribir los pasos para reproducir