Trabajar con bugs es una competencia clave para cualquier especialista QA. Entender qué es un bug, su ciclo de vida, cómo documentarlo y rastrearlo adecuadamente forma la base del testing profesional. En esta guía completa, examinaremos todos los aspectos del trabajo con defectos de software.

Qué es un Bug: Definición y Tipología

Definición de Bug

Bug (Defecto, Issue) es una desviación del comportamiento real del programa del resultado esperado descrito en requisitos, especificaciones o lógica de sentido común.

Definición formal de ISTQB: Un defecto es una imperfección o deficiencia en un producto de trabajo donde no cumple con sus requisitos o especificaciones.

Tipos de Bugs

1. Bugs funcionales — violaciones de funcionalidad de aplicación:

  • Característica no funciona en absoluto
  • Característica funciona incorrectamente
  • Característica no funciona según especificación
  • Funcionalidad declarada falta

Ejemplo: Botón “Agregar al Carrito” no agrega artículo sino redirige a página principal.

2. Bugs UI/UX — problemas de interfaz:

  • Discordancias con mockups de diseño
  • Problemas de alineación, espaciado, fuentes
  • Elementos de interfaz no funcionales
  • Mala adaptabilidad
  • Problemas de esquema de color, contraste

Ejemplo: En dispositivos móviles, el texto se desborda de los límites de pantalla, botones se superponen.

3. Bugs lógicos — errores de lógica de negocio:

  • Cálculos incorrectos
  • Manejo erróneo de condiciones
  • Errores de fórmulas
  • Violaciones de reglas de negocio

Ejemplo: Durante checkout, se aplica descuento del 20% en lugar del 10% declarado, llevando a pérdidas de empresa.

4. Bugs de rendimiento — problemas de velocidad y recursos:

  • Carga lenta de páginas
  • Alto consumo de CPU/memoria
  • Fugas de memoria
  • Ejecución larga de consultas

Ejemplo: Página de catálogo carga 15 segundos en lugar de 2 segundos requeridos.

5. Bugs de seguridad — vulnerabilidades que amenazan datos:

Ejemplo: Endpoint de API devuelve todos los datos de usuario sin verificación de derechos de acceso.

6. Bugs de compatibilidad — problemas específicos de plataforma:

  • No funciona en navegador específico
  • Problemas iOS/Android
  • Incompatibilidades de versión de SO
  • Conflictos con otro software

Ejemplo: Aplicación se bloquea en iOS 14 pero funciona en iOS 15+.

7. Bugs de localización — problemas de traducción:

  • Cadenas no traducidas
  • Truncamiento de texto en otro idioma
  • Formatos incorrectos de fecha, número, moneda
  • Discordancias culturales

Ejemplo: Aplicación muestra fechas en formato MM/DD/YYYY para todas las regiones, incluida Europa donde DD/MM/YYYY es estándar.

Ciclo de Vida del Bug

Un bug pasa por varias etapas desde descubrimiento hasta cierre. Entender el ciclo de vida es críticamente importante para gestión efectiva de defectos.

Ciclo de Vida Clásico del Bug

1. New (Nuevo)

  • Tester descubrió y documentó bug
  • Bug aún no ha sido revisado por equipo
  • Esperando triage

2. Open / Assigned (Abierto / Asignado)

  • Bug pasó triage
  • Reconocido como defecto válido
  • Asignado a desarrollador para corrección
  • Prioridad y severity establecidos

3. In Progress (En Progreso)

  • Desarrollador comenzó a trabajar en corrección
  • Bug está en desarrollo activo
  • Puede requerir información adicional

4. Fixed (Corregido)

  • Desarrollador completó corrección
  • Código comiteado y mergeado
  • Bug listo para verificación de tester
  • Build/versión donde se corrigió está especificada

5. Pending Retest (Esperando Reprueba)

  • Corrección desplegada en entorno de prueba
  • Esperando verificación de tester
  • Puede ser incluido en candidato de release

6. Retest (Reprueba)

  • Tester verificando activamente corrección
  • Reprueba de escenario original
  • Verificación de áreas adyacentes (regresión)

7. Verified / Closed (Verificado / Cerrado)

  • Tester confirmó que bug está corregido
  • Funcionalidad funciona correctamente
  • No se identificaron efectos secundarios
  • Bug cerrado

Estados Alternativos

Rejected / Invalid (Rechazado / Inválido)

  • Comportamiento coincide con requisitos
  • Problema no reproducible
  • Es una tarea, no un bug
  • Duplicado de bug existente

Cannot Reproduce (No se Puede Reproducir)

  • Desarrollador no puede reproducir problema
  • Requiere información adicional del tester
  • Puede ser específico del entorno

Deferred / Postponed (Diferido / Pospuesto)

  • Bug reconocido como válido pero corrección pospuesta
  • No crítico para release actual
  • Se corregirá en versiones futuras
  • Agregado al backlog

Won’t Fix (No se Corregirá)

  • Corrección demasiado costosa
  • Afecta caso extremadamente raro
  • Funcionalidad obsoleta será eliminada
  • Negocio decidió no invertir en corrección

Reopened (Reabierto)

  • Bug no fue completamente corregido
  • Problema se manifiesta en otros escenarios
  • Regresión después de otro cambio
  • Regresa al desarrollador

Diagrama de Ciclo de Vida

New → Open/Assigned → In Progress → Fixed → Retest → Verified/Closed
  ↓         ↓              ↓           ↓        ↓
  └→ Rejected              └→ Cannot Reproduce  └→ Reopened → (vuelta a In Progress)
            ↓
            └→ Deferred/Won't Fix

Clasificación de Bugs: Severity y Priority

La clasificación adecuada de bugs es crítica para gestión efectiva de defectos y priorización del trabajo del equipo.

Severity (Severidad) — Impacto Técnico

Severity mide el impacto técnico del bug en el sistema. Es una característica objetiva.

Critical / Blocker (Crítico / Bloqueador)

  • Aplicación se bloquea o completamente no disponible
  • Pérdida o corrupción de datos
  • Brecha de seguridad crítica
  • Bloquea continuación de testing
  • Hace funcionalidad principal no disponible

Ejemplos:

  • Usuarios no pueden iniciar sesión en sistema
  • Durante checkout, dinero se cobra dos veces
  • Base de datos de producción eliminada en cierta acción
  • SQL (como se discute en Security Testing for QA: A Practical Guide) injection permite acceso a datos de todos los usuarios

Major / High (Mayor / Alto)

  • Funcionalidad significativa funciona incorrectamente
  • Existe workaround pero inconveniente
  • Afecta mayoría de usuarios
  • Desviación significativa de requisitos

Ejemplos:

  • Búsqueda no funciona, pero usuarios pueden encontrar productos a través de categorías
  • Notificaciones por email no se envían
  • Exportación a PDF no funciona
  • Validación de formularios pasa datos incorrectos

Medium / Normal (Medio / Normal)

  • Funcionalidad funciona pero con defectos
  • Desviación menor de requisitos
  • Afecta pequeño grupo de usuarios
  • Existe workaround simple

Ejemplos:

  • Botón tiene color incorrecto
  • Errores tipográficos en textos
  • Problemas menores de alineación UI
  • Campos no críticos no se guardan

Low / Minor (Bajo / Menor)

  • Problemas cosméticos
  • No afecta funcionalidad
  • Casos extremadamente raros
  • Problemas en áreas no importantes

Ejemplos:

  • Margen incorrecto en pie de página
  • Advertencias de consola en DevTools
  • Tooltip aparece con ligero retraso
  • Visualización incorrecta en navegador obsoleto

Priority (Prioridad) — Importancia de Negocio

Priority mide urgencia de corrección desde perspectiva de negocio. Es una característica subjetiva que depende del contexto.

P1 / Urgent (Urgente)

  • Necesita corrección inmediata
  • Bloquea release
  • Crítico para negocio
  • Puede requerir hotfix

P2 / High (Alto)

  • Debe corregirse en release actual
  • Importante para escenario principal de usuario
  • Afecta métricas clave

P3 / Medium (Medio)

  • Debe corregirse en próximos releases
  • Agregado al backlog
  • Se corrige cuando hay recursos disponibles

P4 / Low (Bajo)

  • Nice to have
  • Se corrige cuando hay tiempo libre
  • Puede nunca corregirse

Matriz Severity vs Priority

Severity ↓ / Priority →P1 UrgentP2 HighP3 MediumP4 Low
CriticalApp caída antes de Black FridayBase de datos se bloquea en escenario raro--
MajorPago no funcionaExportación de reportes rotaAPI lento-
MediumError tipográfico en nombre de campañaFiltros funcionan incorrectamenteBug UI en página interna-
Low-Color de marca inexactoMargen incorrectoAdvertencia de consola

Importante entender:

  • High Severity + Low Priority: Bug crítico en característica que casi nadie usa
  • Low Severity + High Priority: Error tipográfico en nombre de CEO en página principal
  • Severity determinado por equipo técnico, Priority por equipo de producto y negocio

Cómo Reportar Bugs Correctamente: Mejores Prácticas

La calidad del reporte de bug afecta directamente la velocidad de corrección. Mal reporte de bug = tiempo desperdiciado del equipo.

Elementos Obligatorios del Reporte de Bug

1. Título Breve pero Informativo (Summary)

❌ Malo:

  • “No funciona”
  • “Bug en página de inicio de sesión”
  • “Problema con botón”

✅ Bueno:

  • “Login button does not respond on iOS Safari 15.2”
  • “Payment form accepts expired credit cards”
  • “Dashboard crashes when loading >1000 records”

Fórmula: [Área] Qué no funciona bajo qué condiciones

2. Entorno (Environment)

  • Sistema Operativo: Windows 11, macOS 14.2, iOS 17.1
  • Navegador y versión: Chrome 120.0.6099, Safari 17.2
  • Versión de aplicación: 2.5.3 (build 456)
  • URL: https://app.example.com/dashboard
  • Tipo de dispositivo: iPhone 15 Pro, Desktop 1920x1080
  • Condiciones de red: WiFi, 4G, Modo offline

3. Pasos para Reproducir (Steps to Reproduce)

Instrucción paso a paso detallada:

Prerequisites:
- User logged in as admin
- At least 5 products in cart

Steps:
1. Navigate to https://app.example.com/cart
2. Click "Apply Coupon" button
3. Enter coupon code "SAVE20"
4. Click "Apply"
5. Click "Proceed to Checkout"

Expected Result:
- Coupon discount 20% applied
- Total price reduced by 20%
- User redirected to checkout page

Actual Result:
- Coupon appears applied in UI
- Total price NOT reduced
- Error in console: "calculateDiscount is not defined"
- User CAN proceed to checkout with wrong price

Reglas de Oro para Steps to Reproduce:

  • Escribir desde perspectiva de usuario, no asumir contexto
  • Cada paso debe ser específico y ejecutable
  • Especificar datos exactos (no “ingresar email”, sino “ingresar test@example.com”)
  • Incluir prerequisitos
  • Numerar pasos

4. Resultado Esperado y Real

Siempre especificar AMBOS:

  • Expected Result: qué debería suceder según requisitos
  • Actual Result: qué sucede realmente

5. Severity y Priority

Indicar razonablemente con explicación (especialmente si es alto severity/priority).

6. Adjuntos (Attachments)

  • Screenshots — obligatorio para bugs UI
  • Video — para escenarios complejos, bloqueos, animaciones
  • Logs — consola del navegador, logs del servidor, logs móviles
  • Network traces — para bugs de API/red
  • Crash dumps — para bloqueos de aplicación

Herramientas:

  • Loom, CloudApp — para grabación de pantalla
  • Chrome DevTools — para logs de red/consola
  • Postman — para solicitudes API

7. Información Adicional

  • Frequency: Always / Sometimes / Rarely
  • Workaround: si hay forma de evitar problema
  • Related issues: enlaces a bugs relacionados
  • Impact: evaluación de impacto en usuario/negocio

Checklist de Reporte de Bug de Calidad

  • ✅ Título breve e informativo
  • ✅ Información completa de entorno
  • ✅ Pasos de reproducción detallados
  • ✅ Resultados esperado y real claramente separados
  • ✅ Severity y Priority justificados
  • ✅ Screenshots/video/logs adjuntos
  • ✅ Verificado que bug no es duplicado
  • ✅ Bug se reproduce consistentemente
  • ✅ Pasos innecesarios eliminados (escenario de reproducción mínimo)

Errores Comunes al Reportar

❌ Múltiples bugs en un reporte

  • Un bug = un reporte. No combine múltiples problemas.

❌ Descripciones subjetivas

  • No escriba “se ve extraño”, “funciona lento”
  • Escriba específicamente: “la carga toma 8 segundos en lugar de 2 requeridos”

❌ Falta de datos de reproducción

  • “Bug al ingresar email” — ¿qué email? ¿qué campo? ¿qué página?

❌ Tono emocional

  • “Bug terrible”, “Cómo pudo esto llegar a release”
  • Sea profesional y objetivo

❌ No verificar relevancia

  • Verifique que bug aún se reproduce antes de reportar

Ejemplos de Bugs Críticos de la Práctica Real

Estudiar ejemplos reales ayuda a entender la importancia del testing de calidad.

1. Therac-25 (1985-1987) — Acelerador Médico

Qué sucedió: Máquina de radioterapia Therac-25 tenía un bug en sistema de control que entregaba dosis letales de radiación bajo secuencias específicas de acciones del operador.

Causa técnica:

  • Race condition en software
  • Sin hardware safety interlocks (solo confiaba en software)
  • Manejo pobre de errores — sistema mostraba mensaje críptico “Malfunction 54”

Consecuencias:

  • 6 pacientes murieron
  • Múltiples víctimas de sobredosis
  • Demandas de millones de dólares
  • Detención completa de uso de dispositivo

Lección para QA:

  • Sistemas críticos de seguridad requieren testing especialmente minucioso
  • Importancia de mensajes de error claros
  • Redundancia Hardware + Software en sistemas críticos
  • No se pueden ignorar race conditions

2. Ariane 5 (1996) — Cohete de $370M

Qué sucedió: Primer lanzamiento de Ariane 5 terminó en autodestrucción 37 segundos después del despegue.

Causa técnica:

  • Integer overflow en sistema de navegación
  • Código fue reutilizado de Ariane 4
  • Velocidad de Ariane 5 era mayor, causando overflow al convertir float de 64-bit a integer de 16-bit
  • Manejo de excepciones llevó a apagado de ambos sistemas redundantes simultáneamente

Consecuencias:

  • Pérdida de $370 millones
  • 4 satélites científicos destruidos
  • Programa retrasado por años

Lección para QA:

  • Debe probarse en condiciones reales, no solo según especificaciones antiguas
  • Reutilización de código requiere testing de regresión con nuevos parámetros
  • Cálculos críticos necesitan verificación de valores límite
  • Sistemas redundantes no deberían fallar simultáneamente

3. Knight Capital (2012) — $440M en 45 Minutos

Qué sucedió: Actualización de software de trading llevó a que sistema enviara millones de órdenes comerciales erróneas.

Causa técnica:

  • Al desplegar nuevo código en 8 servidores, un servidor no fue actualizado
  • En servidor no actualizado, función antigua no utilizada se activó
  • Esta función comenzó a comprar acciones a precio alto y vender a bajo en volúmenes enormes
  • Error notado después de 45 minutos

Consecuencias:

  • $440 millones de pérdidas
  • Empresa en quiebra y comprada
  • Multas de SEC $12 millones

Lección para QA:

  • Importancia crítica de despliegue completo en todos los servidores
  • Smoke tests después de cada despliegue
  • Monitoreo y alertas en tiempo real
  • Disponibilidad de kill switch para sistemas críticos
  • Testing en entorno similar a producción

4. Toyota (2009-2011) — Aceleración No Intencionada

Qué sucedió: Automóviles Toyota aceleraban inesperadamente sin presionar pedal de gas.

Causa técnica (parcialmente confirmada):

  • Stack overflow en sistema de control de acelerador electrónico
  • Asignación de memoria insuficiente
  • Código pobre: variables globales, código espagueti, verificaciones de error insuficientes
  • Posibles bit flips por rayos cósmicos (no es broma)

Consecuencias:

  • 89 muertes (reclamadas)
  • Recall de 9+ millones de vehículos
  • $3+ mil millones en multas y acuerdos
  • Daño masivo de reputación

Lección para QA:

  • Software automotriz requiere estándares más estrictos (ISO 26262)
  • Importancia de calidad de código en sistemas embebidos
  • Testing de interferencia electromagnética
  • Hardware-in-the-Loop (HIL) testing obligatorio
  • Análisis estático de código y revisiones de código críticas

5. GitHub (2012) — Eliminación de Todos los Repositorios

Qué sucedió: Bug en sistema de respaldo podría llevar a eliminación de base de datos de producción.

Causa técnica:

  • Script que debía eliminar archivos de /tmp/ recibió variable vacía
  • Resultado fue rm -rf / en lugar de rm -rf /tmp/backups/
  • Afortunadamente, descubierto en sistema de prueba antes de producción

Consecuencias:

  • Ninguna (descubierto antes de producción)
  • Pero fue llamada de atención para industria

Lección para QA:

  • Siempre validar variables para valores vacíos antes de operaciones destructivas
  • Testing de procedimientos de respaldo/recuperación
  • Nunca ejecutar rm -rf con variables sin validación
  • Modo dry-run para scripts críticos
  • Revisión de código para código de infraestructura

6. AWS S3 Outage (2017) — Error Tipográfico Costó Miles de Millones

Qué sucedió: Empleado de AWS ejecutó comando para eliminar pequeño número de servidores pero accidentalmente eliminó muchos más, llevando a caída de S3 de 4 horas.

Causa técnica:

  • Error humano en entrada de comando
  • Sin protección contra eliminación masiva accidental
  • Proceso de recuperación tomó varias horas

Consecuencias:

  • Millones de sitios no disponibles
  • Pérdidas estimadas en $150+ millones para toda economía de internet
  • Amazon perdió cerca de $3-4 millones

Lección para QA:

  • Incluso ingenieros experimentados cometen errores
  • Operaciones críticas deben requerir confirmación
  • Estrategia de rollback debe ser rápida
  • Testing de procedimientos de recuperación ante desastres

Mejores Prácticas para Trabajo con Bugs en Equipo

1. Bug Triage

Reuniones regulares (usualmente daily o varias veces por semana) para:

  • Revisión de nuevos bugs
  • Validación y priorización
  • Designación de asignados
  • Eliminación de duplicados

Participantes: QA Lead, Dev Lead, Product Manager

2. Bug Metrics

Rastrear métricas:

  • Bug detection rate — cuántos bugs se encuentran
  • Bug fixing rate — cuántos se corrigen
  • Bug leakage — cuántos llegan a producción
  • Reopen rate — cuántos bugs se reabren
  • Average time to fix — tiempo promedio de corrección

3. Root Cause Analysis (RCA)

Para bugs críticos, realizar RCA:

  • ¿Por qué ocurrió bug?
  • ¿Por qué no fue descubierto antes?
  • ¿Qué procesos necesitan mejora?
  • ¿Cómo prevenir bugs similares?

4. Prevención de Regresión

  • Agregar pruebas automatizadas para cada bug significativo
  • Mantener suite de pruebas de regresión
  • Realizar análisis de impacto para cambios

5. Comunicación

  • Usar tono profesional
  • Enfocarse en problema, no en personas
  • No culpar ("¿quién escribió este código?")
  • Proponer constructivamente soluciones

Conclusión

Trabajar con bugs es arte y ciencia simultáneamente. Reporte de bug de calidad ahorra tiempo de todo el equipo, acelera correcciones y mejora calidad del producto.

Conclusiones Clave:

  1. Bug es cualquier desviación del comportamiento esperado, ya sea funcionalidad, UI o rendimiento.

  2. Entender ciclo de vida ayuda a rastrear efectivamente estado y no perder defectos.

  3. Severity y Priority son cosas diferentes. Primero es técnico, segundo es de negocio. Aprenda a distinguirlos.

  4. Calidad de reporte de bug es críticamente importante. Mal reporte = tiempo desperdiciado del equipo = corrección lenta = más bugs en producción.

  5. Estudie ejemplos reales de bugs críticos. Historia enseña, errores cuestan caro, lección no tiene precio.

  6. Trabajo con bugs es proceso de equipo. Testers, desarrolladores, gerentes — todos deben interactuar efectivamente.

Recuerde: cada bug encontrado y documentado adecuadamente es un problema que los usuarios no verán. Es inversión en calidad del producto y reputación de la empresa.

Próximos pasos:

  • Estudie SDLC y STLC para entender dónde encaja testing en desarrollo
  • Revise principios de testing para comprensión más profunda
  • Practique escritura de reportes de bugs en proyectos reales o de entrenamiento