Un informe de defecto es una herramienta de comunicación, además de un registro del problema. Un buen informe ahorra tiempo: los desarrolladores pueden reproducirlo, los responsables comprenden su impacto y QA puede seguir la corrección y los riesgos relacionados.
Qué suele contener un informe
- →Un título claro que identifique el problema.
- →El entorno y las precondiciones relevantes.
- →Los pasos para reproducirlo.
- →Los resultados obtenidos y esperados.
- →Evidencias: capturas de pantalla, vídeos, registros, trazas de red, cuerpos de solicitudes o trazas de la pila.
Qué hace que un informe sea útil
- →El problema se entiende y se reproduce fácilmente.
- →Se distinguen los hechos de las interpretaciones.
- →Se explica el impacto en el usuario, el negocio o el sistema.
- →Los detalles irrelevantes no dificultan la toma de decisiones.
Errores frecuentes
- →Un título impreciso como «el botón no funciona».
- →Resultados esperados ausentes o demasiado abstractos.
- →Pasos que omiten condiciones esenciales y no permiten reproducir el defecto.
- →Una prioridad y una severidad basadas en la emoción, en lugar del riesgo.
Recomendación práctica
Escribe para alguien que desconoce el contexto de tus pruebas. Cuanto antes pueda identificar qué falló, cómo reproducirlo y por qué importa, mejor será el informe.
Ejemplo desarrollado: un informe de defecto reproducible
El siguiente es un ejemplo didáctico ficticio, no un defecto observado en un producto real. Supongamos que el requisito REG-04 admite un alias de entre 3 y 12 letras ASCII, ambos límites incluidos. La compilación del ejemplo rechaza incorrectamente los alias de exactamente 3 letras. Vincula los informes reales a un requisito aprobado y a una observación efectiva.
ID: DEMO-17
Título: El registro rechaza un apodo de 3 letras permitido por REG-04
Entorno: versión ficticia de formación 1.0; navegador y SO: registrar las versiones reales
Precondiciones: formulario de registro abierto; los demás campos contienen datos válidos
Pasos:
1. Introducir abc en el campo Apodo.
2. Mover el foco al siguiente campo.
3. Enviar el formulario.
Esperado: ningún error de longitud del apodo; el registro puede continuar.
Real en este escenario ficticio: "Minimum 4 characters"; el envío queda bloqueado.
Reproducibilidad: 3 de 3 intentos tras restablecer el formulario.
Impacto: no se puede registrar un apodo permitido.
Evidencias que recopilar: captura, ID de versión, marca de tiempo y solicitud/respuesta sin datos sensibles.
Requisito: REG-04.
Severidad / prioridad: acordarlas según las definiciones del equipo y el contexto de la entrega.El título identifica la acción, la entrada y la desviación. No supone que el problema sea responsabilidad del backend. Si solo se ha observado la interfaz, indícalo; examina la solicitud antes de atribuir la causa al servidor. Las capturas y los registros mencionados arriba son evidencias que deben recopilarse, no archivos adjuntos proporcionados por esta guía.
Plantilla de informe para copiar
Título:
Versión / entorno:
Requisito o fuente del comportamiento esperado:
Precondiciones y datos de prueba:
Pasos:
Resultado esperado:
Resultado real:
Reproducibilidad:
Impacto en el usuario:
Evidencias sin datos sensibles:
Incidencia / caso de prueba relacionado:Antes de enviarlo, pide a otra persona del equipo que siga únicamente los pasos registrados. Elimina las credenciales y los datos personales de las evidencias. Un informe que todavía no se puede reproducir también puede ser útil: indica qué se sabe, con qué frecuencia ocurrió y qué información falta.