La plantilla de reporte de bugs que ningún revisor rechaza

¿Qué es una plantilla de reporte de bugs?

Una plantilla de reporte de bugs nombra cada campo que un ticket necesita antes de que un ingeniero pueda actuar sobre él, desde el título hasta la línea de entorno, para que no haya que perseguir nada después de enviar el ticket. Cada campo responde una pregunta que un revisor tendría que hacer en un hilo de comentarios si no estuviera. Completa cada campo antes de enviar, y trata un campo vacío como motivo para que el ticket rebote.

¿Por qué existe el campo de título y qué lo hace útil?

El campo de título existe para que un revisor sepa qué está roto sin abrir el ticket, lo que decide si se toma en la siguiente ronda de triage o queda enterrado bajo otros cincuenta. Un título útil nombra la acción y el fallo juntos, como "Aplicar una tarjeta de regalo en el checkout muestra una página en blanco en lugar de un error", no un estado de ánimo como "el checkout está roto". Escribe el título al final, después de que los pasos y el resultado real estén claros, para que nombre el fallo real en lugar de una suposición.

¿Por qué existe el campo de pasos para reproducir?

El campo de pasos para reproducir existe para que una segunda persona pueda provocar el mismo fallo sin preguntarle nada más a quien reportó, convirtiendo una observación aislada en un caso de prueba repetible. Las acciones numeradas desde un punto de partida declarado son lo que separa un reporte con el que un ingeniero puede trabajar de un reporte que necesita una reunión de seguimiento. Pasos para reproducir explica cómo se ve un conjunto completo de pasos y por qué una precondición faltante es la razón más común por la que fallan.

¿Por qué la gravedad necesita su propio campo, separado de la prioridad?

La gravedad necesita su propio campo porque mide el daño técnico, mientras que la prioridad mide qué tan pronto alguien necesita arreglarlo, y las dos respuestas rara vez coinciden. Un bug de pagos que afecta a una sola cuenta un fin de semana es grave pero no urgente esta noche; una errata en la página de inicio es menor pero urgente antes de un lanzamiento. Gravedad vs. prioridad explica cómo alguien en el triage califica cada una sin que un número se filtre en el otro.

¿Qué debe ir en el campo de entorno?

El campo de entorno nombra el navegador y la versión, el sistema operativo, el tamaño de pantalla y si el fallo ocurrió en producción, staging o una build local, porque la misma secuencia de clics puede comportarse distinto en cualquiera de esos casos. Un revisor sin este campo no puede saber si un bug es universal o está ligado a una sola configuración, lo que significa que ni siquiera puede estimar a cuántos usuarios afecta. Copia la cadena de versión exacta de la página about del navegador en lugar de una suposición como "el Chrome más reciente".

¿Qué debe ir en los campos de resultado esperado y resultado real?

El campo de resultado esperado indica qué debía mostrar la interfaz, y el campo de resultado real indica exactamente qué apareció en su lugar, cada uno como una línea concreta, no como un párrafo compartido sobre cómo se sintió el bug. "Se esperaba el mensaje 'Código inválido', apareció una página en blanco sin salida en la consola" le da a un ingeniero algo con qué comparar; "el checkout no funciona" no. Escribe ambas líneas antes de escribir el título, ya que la discrepancia entre ellas es lo que el título tiene que nombrar.

¿Qué hace que un revisor rechace una entrega de plano?

Un revisor rechaza una entrega de plano cuando uno de los ocho campos anteriores está vacío, es vago o responde la pregunta equivocada, ya que quien hace el triage no puede calificar gravedad y prioridad en un reporte que no puede imaginar. La causa individual más común es una precondición faltante: los pasos parecen completos, pero nadie indica el estado de la cuenta o los datos existentes que los pasos suponen. La segunda causa más común es combinar el resultado esperado y el real en una sola oración, lo que oculta la discrepancia exacta que una corrección tiene que cerrar.

¿Cómo completa el session replay una plantilla de reporte de bugs automáticamente?

El session replay completa una plantilla de reporte de bugs automáticamente porque la grabación ya contiene las precondiciones, las acciones numeradas y el entorno que un reporte manual tendría que describir a mano. Flowsery adjunta la grabación, los pasos para reproducir y los detalles de entorno a cada issue en cuanto llega a Slack, Linear o Jira, así que quien reporta solo tiene que confirmar la gravedad en lugar de volver a escribir campos que la grabación ya responde. El mismo reporte de bug con session replay le muestra a un ingeniero el clic exacto que provocó el fallo, lo que completa el campo de resultado real sin que nadie escriba una descripción de ello.

Preguntas frecuentes

¿Qué campos necesita una plantilla mínima viable de reporte de bugs?

Una plantilla mínima viable necesita un título, precondiciones, pasos numerados para reproducir, resultado esperado, resultado real, gravedad, prioridad y entorno. Omite cualquiera de estos ocho y un revisor tiene que hacer una pregunta de seguimiento antes de hacer el triage del ticket, que es justo la demora que una plantilla existe para eliminar.

¿Pueden gravedad y prioridad compartir un campo en una plantilla de reporte de bugs?

Gravedad y prioridad no deberían compartir un campo, porque un bug puede ser grave sin ser urgente, como un bug de pagos que afecta a una cuenta un fin de semana, o urgente sin ser grave, como una errata en la página de inicio antes de un lanzamiento. Combinarlos en un campo obliga a quien reporta a adivinar qué respuesta representa el número.

¿Por qué los revisores rechazan reportes que tienen pasos pero no precondiciones?

Los revisores rechazan reportes con pasos pero sin precondiciones porque la misma secuencia de clics produce resultados distintos según el estado de la cuenta, los datos existentes o las acciones previas tomadas antes del paso uno. Sin un punto de partida declarado, un ingeniero tiene que reconstruir la precondición antes de siquiera intentar los pasos indicados.

¿Cuál es la diferencia entre el campo de entorno y el campo de resultado real?

El campo de entorno nombra dónde ocurrió el bug, como el navegador, el sistema operativo y la etapa de build, mientras que el campo de resultado real nombra qué pasó, como un mensaje de error o una pantalla en blanco. Un reporte puede indicar exactamente qué salió mal y aun así ser irreproducible si nunca dice qué navegador o entorno lo provocó.

¿La creación automática de tickets de bugs elimina la necesidad de una plantilla de reporte de bugs?

La creación automática de tickets de bugs elimina la necesidad de escribir los campos a mano, no la necesidad de los campos en sí. Flowsery adjunta la grabación, los pasos para reproducir y el entorno a cada issue automáticamente, así que quien reporta revisa y confirma los campos en lugar de volver a escribirlos de memoria.

¿Cuánto debería tardar en llenarse una plantilla de reporte de bugs?

Una plantilla de reporte de bugs debería tardar lo que se tarda en indicar ocho datos que un revisor necesita: título, precondiciones, pasos, resultado esperado, resultado real, gravedad, prioridad y entorno. Un reporte que tarda mucho más que eso rellena descripción en lugar de uno de esos datos; un reporte que tarda menos se saltó uno de ellos por completo.

¿Quién completa una plantilla de reporte de bugs, el reportero o el revisor?

El reportero completa cada campo al crear el ticket, nombrando el título, las precondiciones, los pasos, el resultado esperado y el real, la gravedad, la prioridad y el entorno. El revisor lee esa misma plantilla para comprobar que no falta nada antes de que el ticket llegue a un ingeniero, y lo devuelve en lugar de arreglarlo si algún campo está vacío. Cuando el session replay adjunta los pasos y el entorno automáticamente, la parte del reportero se reduce a confirmar la gravedad.

¿Qué pasa después de que un revisor rechaza un reporte de bug?

El ticket vuelve al reportero en lugar de avanzar hacia un ingeniero. El reportero tiene que completar lo que el revisor marcó, casi siempre una precondición faltante o un resultado esperado y real mezclados en una sola frase, antes de que el ticket vuelva a entrar en triage. Nadie puntúa gravedad ni prioridad en un reporte devuelto, porque un triador no puede calificar un bug que no puede imaginar.

¿Por qué no deberían el resultado esperado y el resultado real compartir una sola frase?

Juntarlos en una sola frase oculta justo el desajuste que una solución tiene que cerrar, y esa es la segunda causa más común de que un revisor rechace un reporte. Escritos como dos líneas separadas, como un mensaje esperado de 'Código inválido' frente a una pantalla en blanco real, un ingeniero puede identificar la brecha directamente en lugar de leer un párrafo sobre cómo se sintió el bug. El campo de título solo funciona una vez que ese desajuste está dicho con claridad, porque el título tiene que nombrar el fallo que describen esas dos líneas.

¿Importa el orden de los campos en una plantilla de reporte de bugs?

El orden importa porque cada campo depende del anterior: las precondiciones tienen que existir antes de los pasos que las asumen, y la gravedad se puntúa antes que la prioridad para que la urgencia tenga un daño al que referirse. El resultado esperado y el real se escriben antes que el título, ya que el desajuste entre esas dos líneas es lo que el título tiene que nombrar. Seguir ese orden es lo que hace que el título, el último campo, prácticamente se escriba solo.