QA práctico: cómo documentar un bug reproducible con evidencia útil

QA práctico: cómo documentar un bug reproducible con evidencia útil

Un cliente agrega un producto al carrito, cambia la cantidad y continúa al checkout. Al volver a la pantalla anterior, el carrito muestra un importe distinto al esperado. El equipo de desarrollo recibe el aviso: “El total está mal”. Sin embargo, con esa información no puede saber qué datos usar, en qué entorno ocurrió ni cómo confirmar la corrección.

Un buen reporte de defecto transforma una observación en un caso verificable. En este artículo aprenderás a documentar un bug de forma accionable, utilizando un ejemplo ficticio de carrito de compras: qué incluir, cómo aportar evidencia, cómo justificar la severidad y cómo diferenciarla de la prioridad de negocio.

Qué debe resolver un reporte de defecto

Un reporte de bug debe permitir que otra persona pueda:

• Entender qué comportamiento es incorrecto.
• Reproducir el problema sin depender de quien lo descubrió.
• Comparar el resultado observado con el comportamiento esperado.
• Evaluar el impacto técnico y para el usuario.
• Confirmar la corrección mediante una nueva prueba.

La calidad del reporte no se mide por su extensión, sino por la información relevante que contiene. Un documento demasiado breve puede ser ambiguo; uno excesivamente largo puede ocultar los datos importantes entre detalles innecesarios.

Un reporte vago

Título: El carrito falla

El total se calcula mal cuando cambio la cantidad.
Revisar urgente.

Este reporte no indica qué producto se utilizó, cuál era la cantidad inicial, qué total se esperaba, qué total se observó ni en qué entorno ocurrió. Tampoco permite saber si el problema es constante o si existe alguna condición específica para reproducirlo.

Un reporte verificable

Título: El total del carrito no se actualiza al reducir la cantidad de un producto

Entorno:
- Aplicación web de pruebas
- Navegador: Chrome
- Usuario autenticado con una cuenta de prueba

Precondiciones:
- El producto “Auriculares inalámbricos” está disponible.
- El carrito está vacío.

Datos usados:
- Producto: Auriculares inalámbricos
- Precio unitario mostrado: $50
- Cantidad agregada: 2

Pasos para reproducir:
1. Iniciar sesión con una cuenta de prueba.
2. Agregar dos unidades del producto al carrito.
3. Abrir el carrito.
4. Confirmar que el subtotal mostrado es $100.
5. Reducir la cantidad a 1.
6. Observar el subtotal y el total del carrito.

Resultado esperado:
El subtotal y el total se actualizan a $50.

Resultado observado:
La cantidad cambia a 1, pero el subtotal permanece en $100
hasta recargar la página.

Severidad sugerida: Media.
El usuario puede continuar comprando, pero el importe mostrado
es incorrecto y puede provocar una decisión de compra equivocada.

La segunda versión contiene información suficiente para que QA, desarrollo y producto trabajen sobre el mismo problema. Además, separa los hechos observados de la interpretación sobre el impacto.

Cómo describir el entorno y las precondiciones

El entorno aporta el contexto necesario para determinar si el defecto depende del navegador, el dispositivo, una configuración, una versión de la aplicación o un tipo de usuario.

Información útil del entorno

• Aplicación o ambiente: desarrollo, pruebas, staging o producción.
• Tipo de dispositivo: escritorio, teléfono o tableta.
• Sistema operativo, cuando pueda influir en el problema.
• Navegador y versión, si el defecto ocurre en una aplicación web.
• Versión de la aplicación o identificador del build, si está disponible.
• Tipo de cuenta o rol utilizado.
• Configuraciones relevantes, como idioma o moneda.
• Estado inicial de los datos.

No es necesario completar todos estos campos en todos los casos. La regla práctica es incluir aquello que pueda cambiar el resultado o ayudar a repetirlo.

Precondiciones frente a pasos

Las precondiciones describen lo que debe estar preparado antes de comenzar la prueba. Por ejemplo, “el carrito está vacío” o “existe una cuenta de prueba con una dirección de envío válida”.

Los pasos para reproducir describen las acciones que llevan al defecto. Conviene escribir un paso por acción observable y evitar instrucciones ambiguas como “hacer el flujo normal” o “probar varias cantidades”.

En lugar de escribir “modificar el carrito”, es más útil indicar “reducir la cantidad del producto de 2 a 1 utilizando el control de decremento”. La precisión reduce las interpretaciones y facilita la repetición por parte de otra persona.

Cómo separar el resultado esperado del resultado observado

Esta separación es una de las partes más importantes del reporte. El resultado esperado representa la regla funcional o el comportamiento acordado. El resultado observado describe exactamente lo que ocurrió durante la prueba.

• Resultado esperado: después de reducir la cantidad a 1, el subtotal debe mostrar el precio de una unidad.
• Resultado observado: la cantidad visual cambia a 1, pero el subtotal conserva el importe correspondiente a 2 unidades hasta recargar la página.

Evita mezclar la causa supuesta con el resultado. Por ejemplo, “el frontend no actualiza el estado por un error en la API” puede ser una hipótesis, pero no necesariamente un hecho comprobado. Si no se verificaron las solicitudes de red o los logs, es mejor describir el comportamiento visible y registrar la hipótesis por separado.

Datos de prueba reproducibles

Los datos usados deben ser suficientemente específicos para repetir el caso, pero no deben exponer información real innecesaria. En el ejemplo del carrito, conviene indicar el producto, su precio mostrado, la cantidad y cualquier condición especial, como un cupón o una regla de envío.

Si el defecto depende de una combinación concreta, documenta esa combinación:

• Producto con descuento aplicado.
• Cantidad inicial y cantidad final.
• Código de cupón de prueba.
• País o moneda seleccionada.
• Estado del inventario o disponibilidad mostrada.

Cuando los datos cambian con frecuencia, puedes identificar el registro mediante un código de prueba o una descripción clara. No es recomendable copiar datos personales de clientes reales para hacer reproducible un caso.

Qué evidencia incluir y cómo proteger la privacidad

La evidencia debe ayudar a confirmar el defecto, no simplemente demostrar que se ejecutó una prueba. Una captura del carrito puede ser útil si muestra la cantidad, el subtotal y el total al mismo tiempo. En otros casos, un video corto puede mostrar la secuencia completa, especialmente cuando el problema desaparece después de recargar la página.

Evidencia pertinente

• Captura de pantalla del estado incorrecto.
• Video breve con los pasos relevantes.
• Registro de la solicitud y respuesta de una API, si es necesario para analizar el comportamiento.
• Mensaje de error visible para el usuario.
• Marca temporal y referencia del entorno.
• Logs filtrados alrededor del momento de la prueba.

La evidencia debe estar relacionada con el defecto. Adjuntar muchas capturas sin contexto puede dificultar el análisis. Añade una breve descripción, por ejemplo: “La captura muestra que la cantidad es 1, mientras el subtotal permanece en $100”.

Criterios de privacidad para capturas y logs

Antes de adjuntar evidencia, revisa si contiene información que no debería compartirse fuera del entorno autorizado. Elimina o enmascara:

• Nombres, correos electrónicos, teléfonos y direcciones reales.
• Números completos de tarjetas u otros datos financieros.
• Contraseñas, tokens, cookies y claves de API.
• Identificadores de sesión o encabezados de autenticación.
• Información de otros usuarios que no sea necesaria para el caso.
• Datos de negocio confidenciales que no aporten al diagnóstico.

Utiliza cuentas y datos sintéticos siempre que sea posible. En logs, comparte únicamente las líneas necesarias y aplica enmascaramiento antes de adjuntarlos. Si la herramienta de gestión de defectos tiene controles de acceso, confirma que la evidencia esté disponible solo para las personas que necesitan analizarla.

Cómo asignar severidad sin confundirla con prioridad

La severidad describe el impacto técnico o funcional del defecto. La prioridad indica qué tan pronto debería atenderse desde la perspectiva del negocio, del riesgo o de la planificación.

Ambas dimensiones pueden estar relacionadas, pero no significan lo mismo. Un error que bloquea todos los pagos suele tener alta severidad y alta prioridad. Sin embargo, también pueden existir combinaciones diferentes:

• Severidad alta, prioridad baja: una función crítica falla en una pantalla experimental que no está habilitada para usuarios.
• Severidad baja, prioridad alta: un texto legal incorrecto aparece en una campaña que se publicará en pocas horas.
• Severidad media, prioridad alta: el total del carrito se muestra incorrectamente durante una campaña comercial, aunque el pago todavía pueda completarse.
• Severidad baja, prioridad baja: un detalle visual menor en una sección poco utilizada.

Preguntas para justificar la severidad

• ¿El defecto impide completar una acción importante?
• ¿Puede provocar pérdida de datos o una operación incorrecta?
• ¿Afecta a todos los usuarios o solo a una condición específica?
• ¿Existe una alternativa para continuar?
• ¿El sistema muestra información incorrecta que pueda influir en una decisión?
• ¿El problema genera un riesgo de seguridad, privacidad o integridad de datos?

En el caso del carrito, una severidad media puede ser razonable si el usuario todavía puede continuar y el importe se corrige al recargar. La prioridad podría ser alta si el problema aparece en una etapa cercana al pago o durante una actividad comercial relevante. La asignación final debe seguir los criterios acordados por el equipo.

Plantilla reutilizable para reportar un bug

Puedes adaptar la siguiente plantilla a una herramienta de gestión de defectos, una hoja de cálculo o un laboratorio de práctica:

Título:
[Componente o acción] + [comportamiento incorrecto] + [condición relevante]

Entorno:
- Aplicación o ambiente:
- Dispositivo:
- Sistema operativo:
- Navegador y versión:
- Versión o build:
- Usuario o rol de prueba:
- Configuración relevante:

Precondiciones:
- 
- 

Datos usados:
- 
- 

Pasos para reproducir:
1.
2.
3.

Resultado esperado:
[Qué debería ocurrir según la regla o requisito.]

Resultado observado:
[Qué ocurrió realmente, incluyendo mensajes o valores visibles.]

Frecuencia:
[Siempre, intermitente o reproducido X de Y intentos.]

Evidencia:
- Captura, video, log o referencia:
- Descripción de lo que demuestra:

Severidad:
[Justificación breve del impacto técnico o funcional.]

Prioridad:
[Si corresponde, según el impacto para el negocio o el plan de trabajo.]

Notas:
[Hipótesis, casos relacionados o información pendiente de validar.]

El campo de frecuencia es especialmente útil cuando el defecto no ocurre siempre. “Intermitente” es menos informativo que “se reprodujo en 3 de 5 intentos siguiendo los mismos pasos”. Si no tienes suficientes ejecuciones para establecer una frecuencia, indícalo como observación pendiente.

Errores frecuentes al redactar reportes de defectos

• Usar títulos genéricos: “No funciona” no identifica el componente ni el comportamiento.
• Omitir datos: sin producto, usuario o configuración, el caso puede no repetirse.
• Combinar varios problemas: registra defectos separados salvo que compartan una causa o flujo claramente relacionado.
• Describir una hipótesis como un hecho: diferencia lo observado de la posible causa.
• Usar lenguaje subjetivo: reemplaza “la pantalla se ve horrible” por una descripción concreta del defecto visual.
• No indicar la frecuencia: el equipo necesita saber si el problema es constante o intermitente.
• Adjuntar evidencia con datos sensibles: revisa y enmascara capturas y logs antes de compartirlos.
• Marcar todo como crítico: la severidad debe justificarse con el impacto, no con la urgencia personal de quien reporta.

También conviene releer el reporte como si no conocieras el contexto. Si una persona del equipo puede seguir los pasos sin hacer preguntas básicas, el reporte está más cerca de ser accionable.

Conclusión: un bug útil es un bug que otra persona puede verificar

Documentar un defecto no consiste solo en informar que algo salió mal. Consiste en construir un caso reproducible con contexto, datos, pasos exactos, resultado esperado, resultado observado y evidencia pertinente. La severidad debe expresar el impacto del problema, mientras que la prioridad debe reflejar la urgencia del negocio o del equipo.

Como siguiente paso, descarga o adapta la plantilla y practica reportando un defecto verificable en una aplicación de prueba. Puedes utilizar un flujo de carrito, login, búsqueda o checkout y pedir a otra persona que intente reproducirlo únicamente con tu reporte. Si necesita información adicional, esa será una señal clara de qué puedes mejorar.

Este tipo de práctica forma parte del trabajo que se puede desarrollar en un laboratorio de QA, como QA Market Lab, y también constituye una base útil para prepararte para tareas reales de testing manual y para el curso QA Tester de Mentores Tech.