No todos los bugs son iguales. No es lo mismo que un formulario de contacto no funcione de ninguna manera — eso bloquea completamente al usuario — que que permita enviar más caracteres de los permitidos. Uno es crítico y el otro es menor. Saber clasificarlos bien es una de las habilidades más importantes de un QA Engineer.
En este artículo te explico todos los tipos de bugs que existen, cómo clasificarlos y ejemplos reales de cada uno.
Por qué es importante clasificar los bugs
Cuando encuentras un bug tienes que tomar decisiones rápidas: ¿para el desarrollo? ¿se puede lanzar igual? ¿quién lo resuelve primero?
Sin una clasificación clara, el equipo pierde tiempo debatiendo la importancia de cada bug. Con una clasificación bien definida, todo el mundo sabe exactamente qué hacer con cada defecto.
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.
Ejemplos: un botón de login que no responde, un filtro de búsqueda que no devuelve resultados correctos, un formulario que no envía los datos al servidor.
Bugs de interfaz
Problemas visuales que afectan a la experiencia del usuario pero no necesariamente al funcionamiento.
Ejemplos: texto cortado en un botón, imágenes que no cargan, elementos que se superponen en móvil, colores incorrectos en un estado activo.
Bugs de rendimiento
La aplicación funciona pero de forma lenta o consumiendo demasiados recursos.
Ejemplos: una página que tarda 8 segundos en cargar, un proceso que consume toda la memoria del dispositivo, una búsqueda que tarda 30 segundos en devolver resultados.
Bugs de seguridad
Vulnerabilidades que pueden ser explotadas por atacantes. Son los más críticos desde el punto de vista del negocio.
Ejemplos: inyección SQL, exposición de datos sensibles en la URL, autenticación que se puede saltarse, acceso a recursos de otros usuarios.
Bugs de compatibilidad
El software funciona en un entorno pero falla en otro.
Ejemplos: una web que funciona en Chrome pero se rompe en Safari, una app que falla en Android 10 pero funciona en Android 13, un formulario que se muestra mal en pantallas pequeñas.
Bugs de regresión
Una funcionalidad que funcionaba correctamente deja de hacerlo después de un cambio en el código.
Ejemplos: el login dejó de funcionar después de un cambio en el módulo de usuarios, el carrito se vacía solo después de actualizar la pasarela de pago.
Bugs de lógica
El código se ejecuta sin errores pero el resultado es incorrecto.
Ejemplos: un descuento del 10% que se aplica como 10€ fijos, un sistema de puntos que suma en lugar de restar, una fecha de vencimiento que se calcula mal.
Bugs de usabilidad
La funcionalidad técnicamente funciona pero es confusa o difícil de usar para el usuario.
Ejemplos: un mensaje de error que no explica qué ha fallado, un proceso de registro con demasiados pasos innecesarios, un botón importante que está en un lugar poco visible.
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.
Crítica (Blocker)
El sistema no funciona o hay pérdida de datos. Nadie puede trabajar hasta que se resuelva.
Ejemplo: el proceso de pago falla completamente y ningún usuario puede comprar.
Alta
Una funcionalidad importante no funciona pero el sistema puede seguir operando de alguna forma.
Ejemplo: el filtro de búsqueda no funciona pero los usuarios pueden navegar por categorías.
Media
Una funcionalidad funciona pero de forma incorrecta o degradada.
Ejemplo: el formulario de contacto envía el mensaje pero no manda la confirmación por email al usuario.
Baja
Problemas menores que no afectan a la funcionalidad principal.
Ejemplo: un texto con una errata, un icono desalineado, un mensaje de error con redacción confusa.
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 usan 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:
Primero se detecta — por el QA, por un usuario o por un sistema automatizado. Luego se reporta en Jira con toda la información necesaria. El equipo lo analiza y asigna severidad y prioridad. El desarrollador lo corrige. El QA verifica que la corrección funciona. Finalmente se cierra.
Si quieres saber cómo reportar bugs correctamente en Jira 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.
Las herramientas de IA como el AI Test Case Generator ayudan a generar casos de prueba que cubren más escenarios y reducen la probabilidad de que los bugs pasen desapercibidos.
Si quieres saber más sobre qué es un bug y cómo funciona puedes leer qué es un bug en programación. Y si necesitas ayuda para implementar una estrategia de testing en tu proyecto puedes ver mis servicios en fatimaqa.com.