Encontrar un defecto es importante, pero reportarlo bien es igual de importante. Un defecto mal reportado puede generar dudas, pérdida de tiempo, discusiones innecesarias o correcciones incorrectas.
Un buen reporte debe permitir que otra persona entienda qué ocurrió, dónde ocurrió, cómo reproducirlo, qué se esperaba y qué evidencia existe. El objetivo no es culpar a nadie, sino aportar información clara para analizar y corregir el problema.
En este tema veremos qué información mínima debe tener un reporte de defecto y cómo escribirlo con claridad.
Un reporte de defecto es el registro de una diferencia entre el comportamiento esperado y el comportamiento obtenido del sistema. También puede llamarse incidencia, ticket, bug report o issue, según la herramienta y el equipo.
El reporte sirve para:
Un reporte claro reduce el tiempo entre detectar un problema y corregirlo.
Un reporte de defecto debería incluir, como mínimo:
No todos los defectos necesitan la misma extensión, pero omitir datos clave dificulta el análisis.
El título debe permitir entender el problema rápidamente. Debe ser específico, no genérico.
Títulos poco útiles:
Títulos más claros:
Un buen título describe el síntoma principal y, si es posible, la condición donde ocurre.
La descripción amplía el título y explica el contexto. Debe ser breve y objetiva.
Ejemplo:
La descripción no debe incluir suposiciones sin evidencia. Si no conocemos la causa, no conviene escribir "el backend está mal" o "la base de datos falla". Es mejor describir lo observado.
El ambiente y la versión son fundamentales para reproducir el defecto.
Información útil:
Un defecto puede ocurrir solo en un ambiente, navegador, versión o configuración. Sin esa información, reproducirlo será más difícil.
Las precondiciones explican qué debe estar preparado antes de seguir los pasos.
Ejemplos:
Si las precondiciones no se indican, otra persona puede ejecutar los pasos con datos distintos y no reproducir el problema.
Los pasos deben ser concretos, ordenados y reproducibles. Deben permitir que otra persona llegue al mismo resultado.
Ejemplo:
Evitemos pasos vagos como "hacer login mal" o "probar con datos incorrectos". La precisión ahorra tiempo.
El resultado esperado describe qué debería ocurrir si el sistema se comportara correctamente.
Ejemplo:
El resultado esperado debe basarse en requisitos, criterios de aceptación, reglas de negocio o comportamiento acordado. Si no está claro, conviene indicarlo como duda o solicitar aclaración.
El resultado obtenido describe lo que ocurrió realmente durante la prueba.
Ejemplo:
Debe ser objetivo. No conviene escribir "el sistema se volvió loco" o "falló todo". Es mejor registrar el comportamiento observable.
La evidencia respalda el reporte y ayuda al análisis.
Puede incluir:
La evidencia debe mostrar lo relevante. Una captura sin contexto o un video muy largo puede ser menos útil que una evidencia breve y precisa.
La severidad describe qué tan grave es el defecto desde el punto de vista técnico o funcional. Aunque el tema siguiente profundizará severidad y prioridad, un reporte puede incluir una estimación inicial del impacto.
Ejemplos:
La severidad ayuda a priorizar el análisis, pero puede ajustarse después de discutirlo con el equipo.
| Título | El sistema muestra error 500 al ingresar contraseña incorrecta. |
|---|---|
| Ambiente | QA - versión 2.4.0 - Chrome 123. |
| Precondición | Existe un usuario activo con correo usuario.activo@correo.com. |
| Pasos | Abrir login, ingresar usuario.activo@correo.com, ingresar contraseña incorrecta Test12345 y presionar Ingresar. |
| Resultado esperado | El sistema debe rechazar el acceso y mostrar "Correo o contraseña incorrectos". |
| Resultado obtenido | El sistema muestra pantalla de error interno con código 500. |
| Evidencia | Captura adjunta y log del navegador. |
| Impacto inicial | Alto: afecta manejo de error en inicio de sesión. |
Reporte pobre:
Problemas:
Reporte claro:
La segunda versión permite entender y reproducir el problema con mucha más facilidad.
Un defecto intermitente ocurre solo algunas veces. Son difíciles de analizar, pero igual deben reportarse con la mayor información posible.
Conviene registrar:
No poder reproducir siempre no significa que el problema no exista. Pero el reporte debe ser honesto sobre la frecuencia observada.
Antes de registrar un defecto, conviene revisar si ya existe uno similar. Los defectos duplicados pueden generar trabajo extra y confusión.
Si encontramos uno parecido, podemos:
A veces dos síntomas parecidos tienen causas distintas. No conviene cerrar como duplicado sin revisar con criterio.
El reporte debe ser objetivo y respetuoso. El testing busca mejorar el producto, no señalar culpables.
Evitar frases como:
Preferir frases objetivas:
La claridad técnica y el respeto mejoran la colaboración.
Los defectos suelen registrarse en herramientas de seguimiento. Algunas organizaciones usan sistemas como Jira, Azure DevOps, GitHub Issues, GitLab Issues, Trello u otras plataformas internas.
Más allá de la herramienta, lo importante es que el reporte permita:
La herramienta ayuda, pero no reemplaza la claridad del contenido.
Al reportar defectos, algunos errores frecuentes son:
Estos errores hacen que el defecto tarde más en analizarse y corregirse.
Para reportar defectos con claridad conviene:
Reportar defectos con claridad es una habilidad fundamental en testing. Un reporte bien escrito acelera el análisis, reduce preguntas innecesarias y ayuda a corregir el problema correcto.
El objetivo del reporte no es demostrar que algo está mal, sino comunicar información útil para mejorar el producto. Cuanto más claro sea el defecto, más fácil será reproducirlo, priorizarlo y resolverlo.
En el próximo tema estudiaremos severidad, prioridad y ciclo de vida de un defecto, para comprender cómo se gestiona un reporte desde que se crea hasta que se cierra.