Un bug no es más que un error en el software. Puede ser un botón que no funciona, un cálculo incorrecto, una página que no carga o una funcionalidad que se comporta de forma inesperada. Lo que tienen en común todos los bugs es que el software no hace lo que debería hacer.
En este artículo te explico de dónde viene el término, qué diferencia hay entre bug, error y defecto, y cómo funciona el ciclo de vida de un bug desde que se detecta hasta que se cierra.
Por qué se llaman bugs
La historia del término viene de 1947, cuando la programadora Grace Hopper encontró una polilla real atrapada en un relé del ordenador Mark II que estaba causando un fallo en el sistema. La pegaron en el libro de registro con la nota «primer bug real encontrado». Desde entonces, el término se usa para referirse a cualquier error en el software.
Bug, error y defecto: ¿es lo mismo?
En el día a día del sector se usan de forma intercambiable, pero técnicamente no significan exactamente lo mismo.
| Término | Definición técnica | Ejemplo |
|---|---|---|
| Error | Acción humana que produce un resultado incorrecto | Un desarrollador malinterpreta un requisito |
| Defecto | Imperfección en el código que puede causar un fallo | El código resultante de ese malentendido |
| Bug | El fallo observable en el sistema cuando el defecto se ejecuta | El botón que no responde cuando el usuario hace clic |
En la práctica, cuando un QA dice «he encontrado un bug» se refiere al fallo observable. Lo que importa es que el software no hace lo que debería hacer.
Qué tipos de bugs existen
No todos los bugs son iguales. Existen bugs funcionales, de interfaz, de rendimiento, de seguridad, de compatibilidad, de regresión, de lógica y de usabilidad — cada uno con un impacto distinto en el sistema y en el usuario.
Si quieres conocer en detalle cada tipo con ejemplos reales y tablas de clasificación completas, puedes leer tipos de bugs en testing: clasificación completa con ejemplos.
Cómo se clasifica un bug
Cuando se encuentra un bug hay que clasificarlo en dos dimensiones antes de reportarlo:
Por severidad
El impacto técnico del bug en el sistema.
| Severidad | Descripción | Ejemplo |
|---|---|---|
| Crítica (Blocker) | El sistema no funciona o hay pérdida de datos | El proceso de pago falla completamente |
| Alta | Una funcionalidad importante no funciona pero el sistema sigue operando | El filtro de búsqueda no devuelve resultados |
| Media | Una funcionalidad funciona pero de forma incorrecta | El formulario envía el mensaje pero no manda la confirmación al usuario |
| Baja | Problemas menores que no afectan a la funcionalidad principal | Un texto con una errata, un icono desalineado |
Por prioridad
La urgencia con la que hay que corregirlo desde el punto de vista del negocio.
| Severidad | Prioridad | Ejemplo |
|---|---|---|
| Alta | Alta | El login no funciona |
| Alta | Baja | Fallo en funcionalidad que usa el 0,1% de usuarios |
| Baja | Alta | Errata en el titular principal de la home |
| Baja | Baja | Icono desalineado en página secundaria |
La confusión más habitual es pensar que severidad y prioridad son lo mismo. No lo son. Una errata en el titular de la home tiene severidad baja pero prioridad alta — está en el sitio más visible de toda la web y hay que corregirla hoy.
El ciclo de vida de un bug
Un bug no aparece y desaparece de forma inmediata. Pasa por varias fases desde que se detecta hasta que se cierra.
| Fase | Qué ocurre |
|---|---|
| Detección | El QA, un usuario o un sistema automatizado encuentra el fallo |
| Reporte | Se documenta con toda la información necesaria para reproducirlo |
| Análisis | El equipo asigna severidad y prioridad y decide quién lo resuelve |
| Corrección | El desarrollador trabaja en la solución |
| Verificación | El QA comprueba que la corrección funciona y no ha introducido nuevos bugs |
| Cierre | El bug se cierra definitivamente |
En algunos casos el bug se rechaza — porque no es un bug sino el comportamiento esperado, porque es un duplicado de otro ya reportado, o porque se decide no corregirlo por ahora.
Cómo evitar que los bugs lleguen a producción
La mejor forma de gestionar los bugs es evitar que lleguen a los usuarios. Aplicar el concepto de shift-left testing — incorporar el QA desde el principio del ciclo de desarrollo — reduce drásticamente el número de bugs que llegan a producción.
Si quieres saber cómo encaja el trabajo del QA en un equipo ágil, puedes leer cómo funciona el QA en Scrum.
Y si necesitas ayuda para implementar un proceso de QA que minimice los bugs en producción, puedes ver mis servicios en fatimaqa.com.