No todos los bugs son iguales. No es lo mismo que el proceso de pago falle completamente — eso bloquea a todos los usuarios y hay que pararlo todo — que que un icono aparezca desalineado en una página secundaria. Uno es crítico y el otro puede esperar.
Saber clasificar los bugs bien es una de las habilidades más importantes de un QA Engineer. En este artículo te explico todos los tipos que existen, cómo clasificarlos por severidad y prioridad, y un ejemplo real de cada uno.
Clasificación por tipo de bug
Bugs funcionales
Son los más comunes. La aplicación no hace lo que debería según los requisitos.
| Ejemplo real | Impacto |
|---|---|
| Un botón de login que no responde | Bloquea el acceso de todos los usuarios |
| Un filtro de búsqueda que no devuelve resultados | El usuario no puede encontrar lo que busca |
| Un formulario que no envía los datos al servidor | Pérdida de información del usuario |
Bugs de interfaz
Problemas visuales que afectan a la experiencia del usuario pero no necesariamente al funcionamiento.
| Ejemplo real | Impacto |
|---|---|
| Texto cortado en un botón | Confusión sobre qué hace el botón |
| Imágenes que no cargan | Aspecto roto de la aplicación |
| Elementos superpuestos en móvil | Inutilizable en dispositivos pequeños |
| Colores incorrectos en estado activo | El usuario no sabe en qué estado está |
Bugs de rendimiento
La aplicación funciona pero de forma lenta o consumiendo demasiados recursos.
| Ejemplo real | Impacto |
|---|---|
| Una página que tarda 8 segundos en cargar | Abandono masivo de usuarios |
| Un proceso que consume toda la memoria | El dispositivo se congela |
| Una búsqueda que tarda 30 segundos | Experiencia de usuario inaceptable |
Bugs de seguridad
Vulnerabilidades que pueden ser explotadas por atacantes. Son los más críticos desde el punto de vista del negocio.
| Ejemplo real | Impacto |
|---|---|
| Inyección SQL en formulario de login | Acceso no autorizado a la base de datos |
| Datos sensibles expuestos en la URL | Robo de información de usuarios |
| Autenticación que se puede saltarse | Acceso a cuentas ajenas |
Bugs de compatibilidad
El software funciona en un entorno pero falla en otro.
| Ejemplo real | Impacto |
|---|---|
| Web que funciona en Chrome pero se rompe en Safari | Parte de los usuarios no puede usarla |
| App que falla en Android 10 pero no en Android 13 | Usuarios con versiones antiguas bloqueados |
| Formulario que se muestra mal en pantallas pequeñas | Inutilizable en móvil |
Bugs de regresión
Una funcionalidad que funcionaba correctamente deja de hacerlo después de un cambio en el código.
| Ejemplo real | Impacto |
|---|---|
| El login dejó de funcionar tras un cambio en el módulo de usuarios | Nadie puede entrar a la aplicación |
| El carrito se vacía solo tras actualizar la pasarela de pago | Pérdida de ventas |
Los bugs de regresión son especialmente frustrantes porque algo que ya estaba resuelto vuelve a fallar. Las pruebas de regresión automatizadas con Playwright existen precisamente para detectarlos antes de que lleguen a los usuarios.
Bugs de lógica
El código se ejecuta sin errores pero el resultado es incorrecto.
| Ejemplo real | Impacto |
|---|---|
| Un descuento del 10% que se aplica como 10€ fijos | Pérdida económica para el negocio |
| Un sistema de puntos que suma en lugar de restar | Datos incorrectos en la base de datos |
| Una fecha de vencimiento calculada mal | Contratos o accesos con plazos erróneos |
Bugs de usabilidad
La funcionalidad técnicamente funciona pero es confusa o difícil de usar.
| Ejemplo real | Impacto |
|---|---|
| Un mensaje de error que no explica qué ha fallado | El usuario no sabe qué hacer |
| Un proceso de registro con pasos innecesarios | Abandono del registro |
| Un botón importante poco visible | Funcionalidad que nadie usa |
Clasificación por severidad
La severidad describe el impacto técnico del bug en el sistema. Es independiente de la urgencia con la que hay que resolverlo.
| 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 funciona pero se puede navegar por categorías |
| Media | Una funcionalidad funciona pero de forma incorrecta o degradada | El formulario envía el mensaje pero no manda la confirmación por email |
| Baja | Problemas menores que no afectan a la funcionalidad principal | Un texto con una errata, un icono desalineado |
Clasificación por prioridad
La prioridad describe la urgencia con la que hay que resolver el bug desde el punto de vista del negocio.
Y aquí está la clave que mucha gente confunde: severidad y prioridad no son lo mismo.
Un bug puede tener severidad baja pero prioridad alta. Por ejemplo: una errata en el titular principal de la home — técnicamente es menor pero está en el sitio más visible de toda la web y hay que corregirlo hoy.
Y al revés: un bug puede tener severidad alta pero prioridad baja. Por ejemplo: un fallo en una funcionalidad que solo usa el 0,1% de los usuarios — es importante pero puede esperar.
| Severidad | Prioridad | Ejemplo |
|---|---|---|
| Alta | Alta | El login no funciona |
| Alta | Baja | Fallo en funcionalidad poco usada |
| Baja | Alta | Errata en el titular de la home |
| Baja | Baja | Icono desalineado en página secundaria |
El ciclo de vida de un bug
Un bug no aparece y desaparece de forma inmediata. Pasa por varias fases:
- Detección — por el QA, por un usuario o por un sistema automatizado
- Reporte — se documenta en Jira con toda la información necesaria
- Análisis — el equipo asigna severidad y prioridad
- Corrección — el desarrollador lo resuelve
- Verificación — el QA comprueba que la corrección funciona y no ha introducido nuevos bugs
- Cierre — el bug se cierra
Si quieres saber cómo documentar correctamente cada uno de estos pasos, puedes leer cómo reportar un bug en Jira paso a paso.
Cómo evitar que los bugs lleguen a producción
La mejor estrategia es detectarlos antes de que lleguen a los usuarios. Esto se consigue combinando pruebas manuales, automatización y una buena estrategia de testing desde las fases tempranas del desarrollo.
Aplicar el concepto de shift-left testing — incorporar el QA desde el principio del ciclo — reduce drásticamente el número de bugs que llegan a producción. Y herramientas como el AI Test Case Generator ayudan a cubrir más escenarios en menos tiempo.
Si necesitas ayuda para implementar una estrategia de testing en tu proyecto puedes ver mis servicios en fatimaqa.com.