Cómo reportar un bug que el desarrollador sí quiera arreglar

La respuesta corta: un buen reporte de defecto se arregla rápido porque el desarrollador puede reproducirlo en su máquina sin adivinar nada. Necesita tres cosas para eso: los pasos exactos para provocar el fallo, lo que esperabas que pasara, y lo que pasó de verdad. Si tu reporte tiene esas tres, ya vale más que el 80% de los que llegan a un tablero. Si además le pones entorno, evidencia y una severidad honesta, acabas de ahorrarle media hora de ida y vuelta a alguien.

Hay un costo escondido en el "no funciona, arréglalo". El desarrollador lee eso, no puede reproducir, y te devuelve la pelota: "¿en qué navegador?", "¿qué usuario?", "¿me pasas captura?". Esa conversación puede durar dos días para un bug que se arreglaba en veinte minutos. El reporte no es papeleo: es el artefacto que decide si el defecto se cierra hoy o rebota una semana.

01 · el mínimo innegociableLos tres datos sin los que no hay reporte

Un reporte de defecto que no puede reproducirse es una anécdota, no un defecto. Por eso el estándar internacional de testing, la ISO/IEC/IEEE 29119, define el incident report con campos obligatorios, y en el centro están siempre los mismos tres: pasos para reproducir, resultado esperado y resultado obtenido. Ese trío es el corazón del oráculo: sin el "esperado", nadie sabe si lo que viste es un bug o el comportamiento correcto que tú no conocías.

Los pasos para reproducir se escriben numerados, desde un estado conocido, con datos concretos. No "inicié sesión y falló", sino "1. Entro a /login. 2. Uso el usuario demo@qirava.io. 3. Dejo la contraseña vacía. 4. Pulso Entrar". Cualquiera con esos pasos llega al mismo punto. Esa es la prueba de fuego: si tú no puedes reproducirlo dos veces seguidas siguiendo tus propios pasos, todavía no tienes un reporte, tienes una sospecha.

Sin "resultado esperado", nadie puede distinguir un defecto de una función que no entendiste.

El resultado esperado es el que más se olvida y el que más pelea evita. Di de dónde sale tu expectativa: la historia de usuario, la especificación, una regla de negocio, el sentido común documentado. "Esperaba que rechazara el envío con un mensaje de error" es una afirmación verificable. El resultado obtenido es lo que de verdad ocurrió, tal cual, sin interpretarlo: "la página quedó en blanco y la consola mostró un error 500".

02 · el contexto que ahorra la ida y vueltaEntorno, evidencia y un título que se entiende de un vistazo

El trío te da un reporte válido. El contexto te da un reporte que no rebota. Lo primero es el entorno: número de build o versión, navegador y sistema operativo, tipo de usuario o rol, y datos de prueba usados. La mitad de los "en mi máquina funciona" se resuelven aquí, porque el bug vivía en una versión, un navegador o un permiso que el desarrollador no estaba mirando.

Después va la evidencia. Una captura con la zona del error marcada, un video corto si el fallo es de secuencia, y sobre todo el log o el mensaje de error literal. Copia el texto del error, no lo parafrasees: ese stack trace suele apuntar a la línea exacta del código. Adjuntar el error real puede ser la diferencia entre un arreglo de diez minutos y una tarde de rastreo a ciegas.

Copia el mensaje de error literal. Ese texto suele ser el mapa que lleva a la línea culpable.

Un detalle que separa al que reporta bien: intenta aislar antes de enviar. ¿Pasa siempre o de vez en cuando? ¿Con cualquier usuario o solo con uno? ¿En una sola pantalla o en varias? Reducir el bug a sus condiciones mínimas es, en la práctica, la mitad del trabajo de depuración ya hecho. El desarrollador lo agradece porque le entregas el problema acotado, no el caos completo.

03 · severidad honesta y el tono que no quema puentesCómo clasificar sin inflar y sin culpar

La ISTQB distingue dos cosas que la gente mezcla: severidad es cuánto daña el defecto al sistema; prioridad es qué tan urgente es arreglarlo. No son lo mismo. Un error de ortografía en el logo de la home es severidad baja pero prioridad alta, porque lo ve todo el mundo. Un cálculo mal en un caso extremo que casi nadie toca puede ser severidad alta y prioridad baja. Separar ambas evita la guerra de "todo es crítico".

Y ahí está la tentación: inflar. Si marcas todo como bloqueante, en dos semanas nadie te cree y tus bloqueantes reales se pierden entre los falsos. La severidad honesta es un activo de confianza. Reporta el impacto real, con datos: "afecta a todos los usuarios que pagan con tarjeta", no "es urgentísimo". El dato convence; el adjetivo cansa.

Queda el tono, que es lo que decide si el desarrollador quiere ayudarte o se pone a la defensiva. Un reporte de defecto describe el comportamiento del software, no la incompetencia de una persona. "El formulario guarda el precio sin el impuesto" abre una conversación; "otra vez rompiste el checkout" la cierra. El defecto es contra el sistema, nunca contra quien lo escribió. Ese pequeño cambio de sujeto, del "tú" al "el sistema", es lo que mantiene al equipo del mismo lado de la mesa.

Junta todo y el reporte deja de ser una queja. Se vuelve un pequeño experimento reproducible: aquí están los pasos, esto esperaba, esto obtuve, en este entorno, con esta evidencia, y este es el daño real. Con eso en la mano, el desarrollador no adivina: reproduce, entiende y arregla. Y la próxima vez que abras un ticket, en lugar de rebotar, se cierra el mismo día. Esa es toda la diferencia entre reportar un bug y solo avisar que algo anda mal.