Un bug es la palabra informal para un defecto; un defecto es el término formal para cualquier falla en la que el software no cumple su requisito. Un issue es el término paraguas que cubre defectos, peticiones de funcionalidad, tareas y dudas. En la práctica describen lo mismo con distinto nivel de ceremonia — y lo que genera confusión es mezclarlos dentro de un mismo equipo. Las diferencias importan menos en la conversación y más en tres sitios: qué mides, qué prometes por contrato y qué le pides a quien reporta. Esta página propone una separación defendible, para ponerla en un glosario y dejar de discutirla.
La respuesta corta
| Término | Alcance | Dónde se ve |
|---|---|---|
| Bug | Palabra informal para defecto. Suele ser algo que antes funcionaba o que claramente debería funcionar | Dailies, chat, «hay un bug en el pago» |
| Defecto | Término formal: cualquier desviación entre comportamiento real y esperado, haya funcionado antes o no | Informes de QA, auditorías, contratos, métricas |
| Issue | Término paraguas: todo lo que exige una decisión — defecto, petición, tarea, duda | Trackers, IDs de ticket, notas de versión |
| Error | Una acción humana que produce un resultado incorrecto | Análisis de causa raíz, post-mortems |
| Fault | La instrucción o dato erróneo dentro del software que provoca el fallo | Discusión de ingeniería, estándares |
| Failure | El evento observable: el sistema no hace lo que debe | Revisiones de incidentes, monitorización |
La cadena: error, fault, failure
El modelo clásico, todavía usado en estándares y útil en post-mortems:Por qué «issue» es mejor palabra para tu tracker
Un tracker guarda más que defectos. Nombra el objeto issue — y mantén «bug» como palabra cotidiana — y tendrás un solo sitio para:- defectos (el comportamiento es incorrecto),
- peticiones de funcionalidad (el comportamiento falta a propósito),
- tareas (trabajo sin comportamiento asociado),
- dudas (no se espera cambio de código).
Donde la distinción gana dinero
1. Contratos y SLA. Un acuerdo que promete «defectos críticos corregidos en 24 horas» necesita una definición escrita de defecto y crítico. Sin ella, cada discusión es una negociación. «Bug» en un contrato suele ser demasiado vago para exigirlo. 2. Métricas. Densidad de defectos, tasa de fuga y tasa de reapertura solo significan algo si la población es estable. Si la mitad de tus «bugs» son peticiones, ningún número se sostiene. 3. Auditoría y cumplimiento. Los productos regulados suelen necesitar un registro de defecto trazable con severidad, verificación y evidencia de cierre. Es un artefacto formal: la palabra defecto señala esa formalidad.¿Bug o petición de funcionalidad?
La frontera que más discusiones genera:| Es un defecto si… | Es una petición si… |
|---|---|
| El comportamiento contradice un requisito escrito o el diseño documentado | No existe requisito y ese comportamiento nunca se prometió |
| Los usuarios no pueden completar una tarea que antes completaban | Pueden completarla, solo que no como preferirían |
| El estado del sistema se vuelve inconsistente o se pierden datos | El sistema es consistente; la salida simplemente no es la deseada |
| Afecta accesibilidad, seguridad o integridad de datos | Es una preferencia de maquetación, texto o flujo |
¿Bug o «error» (el mensaje en pantalla)?
Un mensaje de error en pantalla no es un defecto por sí mismo. «El formato del email no es válido» es comportamiento correcto. El defecto es cuando el mensaje está mal, falta, o aparece cuando no debe. Y el error de «Console error» se refiere a una excepción registrada por el runtime, que puede ser un defecto o no (muchos errores registrados son esperados y gestionados). Por eso un informe debe adjuntar la salida de Console como texto y no como captura: quien triaja necesita el texto, la pila y la frecuencia, no una imagen.Elige un vocabulario y escríbelo
La recomendación con la que la mayoría de equipos puede vivir:- Issue es el objeto del tracker. Todos los tipos viven debajo.
- Defecto es el tipo «comportamiento incorrecto» y la palabra de métricas, contratos e informes.
- Bug se queda como palabra hablada. Fuera de los dashboards.
- Error / Fault / Failure solo en análisis de causa raíz, en ese orden.
Qué implica para el informe
Se llame como se llame, los campos que necesita quien triaja son idénticos:- la página o endpoint exacto,
- qué se hizo, qué se esperaba y qué ocurrió,
- la evidencia: captura, errores de Console, peticiones fallidas,
- el entorno: navegador, OS, viewport, marca de tiempo.