Blog › Tutoriales

Cómo escribir los pasos para reproducir un bug (2026)

🔧 Tutoriales · 8 min de lectura · 9 de octubre de 2026
Por qué «no consigo reproducirlo» casi siempre es un problema de los pasos 5 reglas para unos pasos que funcionan ¿Qué nivel de detalle deben tener los pasos? 5 ejemplos completos Ejemplo 1: inicio de sesión y autenticación (5 pasos) Ejemplo 2: pago y cupones (6 pasos) Ejemplo 3: táctil en móvil (5 pasos) Ejemplo 4: API y datos (4 pasos) Ejemplo 5: bug intermitente (con probabilidad y timing) 7 errores que invalidan tus pasos Checklist antes de enviar FAQ Los pasos los escribes tú; las evidencias pueden ser automáticas Lecturas recomendadas

Por qué «no consigo reproducirlo» casi siempre es un problema de los pasos

Unos buenos pasos para reproducir = un punto de partida claro + una acción por paso + datos reales + lo que observaste en cada paso. Si alguien puede leerlos en voz alta y llegar a la misma pantalla, son suficientemente buenos. Abajo tienes 5 reglas, un test de nivel de detalle, 5 ejemplos completos (incluido cómo redactar un bug intermitente) y una checklist antes de enviar.

Cuando un desarrollador responde «no consigo reproducirlo», rara vez es falta de voluntad. Falta algo en los pasos, y normalmente es una de estas tres cosas:

  • Falta el punto de partida: sin requisitos previos escritos. Tú estabas con una cuenta enterprise, el desarrollador usó una personal — dos rutas de código distintas.
  • Las acciones se fusionaron: un paso dice «rellenar el formulario y enviar», pero el bug ocurre en el autoguardado entre rellenar y enviar.
  • Faltan los datos: descripciones genéricas en lugar de valores reales — y el bug solo aparece cuando el correo contiene un +.

    • En una frase: los pasos no son un registro para ti, son una ruta para otra persona.

    5 reglas para unos pasos que funcionan

  • Enuncia el punto de partida: estado de sesión, estado de los datos y URL de entrada van en los requisitos previos, no metidos en el paso 1.
  • Una acción por paso: cada número hace exactamente una cosa, para que se pueda verificar una a una.
  • Usa datos reales: escribe user+test@x.com, no «una dirección de correo».
  • Anota lo que observas (recomendado): tras los pasos clave, añade «aquí la página muestra X», para que el desarrollador vea dónde empieza a desviarse.
  • Pon el entorno en su campo, o decláralo en la primera línea: navegador, sistema operativo, dispositivo y ancho de viewport — omitir uno puede hacer fallar la reproducción.

    • ¿Qué nivel de detalle deben tener los pasos?

    Nivel Ejemplo Problema
    Demasiado grueso «Abrir el checkout, borrar un artículo, el contador está mal» Tres acciones en una frase: nadie sabe dónde falla
    El adecuado «1. Ir a /cart 2. Hacer clic en Eliminar junto al producto 3. Mirar el contador de la cabecera» Una acción por paso, cada una verificable
    Demasiado fino «1. Mover el puntero sobre el botón 2. Pulsar el botón izquierdo 3. Soltarlo» Acciones físicas troceadas: más difícil de leer, no más fácil

    El test: al terminar, hazte dos preguntas. ① ¿Otra persona llega a la misma pantalla sin mirar mi captura? ② ¿Puede un desarrollador decidir en dos minutos si es front, API o datos? Dos «sí» significan que el nivel de detalle es correcto.

    5 ejemplos completos

    Ejemplo 1: inicio de sesión y autenticación (5 pasos)

    Requisitos previos: cuenta test@example.com ya registrada y activa. Entorno: Chrome 120 / macOS 14 / escritorio / 1920×1080 / ventana de incógnito.

  • Abrir https://app.example.com/login
  • Introducir test@example.com con la contraseña correcta
  • Introducir tres veces seguidas un captcha de imagen incorrecto
  • En el cuarto intento, introducir un captcha válido y hacer clic en «Iniciar sesión»
  • Observar el mensaje que aparece

    • Esperado: un mensaje «captcha incorrecto, inténtalo de nuevo», sin bloquear la cuenta. Real: muestra «cuenta bloqueada, vuelve a intentarlo en 24 horas» — aunque el captcha era correcto.

    Ejemplo 2: pago y cupones (6 pasos)

    Requisitos previos: 2 artículos en el carrito por un total de 1.299 €; la cuenta es de tipo enterprise. Entorno: Chrome 120 / Windows 11 / escritorio / 1440×900 / cuenta enterprise.

  • Abrir /cart y confirmar que el total es 1.299 €
  • Hacer clic en «Ir al pago»
  • Introducir el cupón SAVE100 en el campo correspondiente (caducó hace tres días)
  • Hacer clic en «Aplicar»
  • Observar el aviso de la parte superior y el estado del carrito
  • Recargar la página y volver a observar

    • Esperado: un aviso «cupón caducado», con el carrito intacto. Real: muestra «cupón aplicado» y descuenta 100 €; en el momento de pulsar «Aplicar», los dos artículos desaparecen del carrito.

    Ejemplo 3: táctil en móvil (5 pasos)

    Requisitos previos: sesión iniciada, 1 artículo en el carrito. Entorno: iPhone 14 / iOS 17.2 / Safari / viewport 390×844.

  • Abrir https://shop.example.com/cart
  • Desplazarse hasta el formulario de dirección al final de la página
  • Tocar el campo «Nombre del destinatario» para abrir el teclado
  • Mirar el botón «Confirmar pedido» sobre el teclado
  • Intentar tocar ese botón

    • Esperado: el botón se desplaza por encima del teclado y sigue siendo pulsable. Real: el teclado tapa cerca del 60% del botón y los toques en esa zona no hacen nada.

    Ejemplo 4: API y datos (4 pasos)

    Requisitos previos: token del entorno de pruebas emitido; la base tiene 12.400 pedidos, de los que 12 coinciden con la palabra clave. Entorno: https://api-test.example.com / curl 8.x.

  • GET /api/orders/export?month=2026-08 con la cabecera Authorization: Bearer <token>
  • Esperar la respuesta
  • Observar el código HTTP y el cuerpo de la respuesta
  • Reintentar con month=2026-08-01~2026-08-07

    • Esperado: 200 con un ID de tarea de exportación, o 202 si la tarea quedó en cola. Real: 504 (timeout de pasarela); con el rango reducido devuelve 200, así que el umbral depende del volumen de datos.

    Ejemplo 5: bug intermitente (con probabilidad y timing)

    Requisitos previos: cuenta sin saldo; la tarjeta de prueba está asociada al usuario de pruebas. Entorno: Chrome 120 / macOS 14 / red limitada a 3G.

  • Abrir /checkout y rellenar los datos de pago
  • Abrir DevTools y poner el panel Network en limitación 3G
  • Hacer doble clic rápido en «Confirmar pago» (intervalo de unos 300ms)
  • Observar la lista de pedidos y el registro de pagos

    • Esperado: se crea un único pedido; los clics repetidos deben deduplicarse en el cliente o bloquearse por idempotencia en la API. Real: en 3 de cada 10 intentos se crearon dos pedidos (condiciones: intervalo <500ms y latencia >1s). Se adjuntan la grabación del panel Network y los IDs de las dos llamadas POST /api/orders.

    Cómo redactar un bug intermitente:

    • Da una probabilidad, no la palabra «intermitente»: «3 de cada 10 intentos» es cien veces más útil.
    • Da el timing o el umbral: «intervalo <500ms», «latencia >1s» — estas condiciones suelen ser la pista de la causa raíz.
    • Da el tipo de evidencia: la grabación de pantalla y los logs de consola son la única prueba duradera que un bug intermitente puede llevar consigo.

    7 errores que invalidan tus pasos

  • Empezar por «abrir la página de inicio»: la navegación es relleno, los cinco primeros pasos son ruido.
  • Varias acciones en un paso: «rellenar el formulario y enviar» — imposible localizar el fallo.
  • Descripciones genéricas: «introducir el usuario y la contraseña correctos», cuando esos valores exactos son la variable clave.
  • Faltan requisitos previos de datos: cuántos artículos en el carrito, qué tipo de cuenta, si ya hubo un reembolso.
  • Jerga interna: «pasar por el flujo antiguo», «usar una cuenta plan B» — indescifrable para un colaborador externo.
  • Resultados esperados colados en los pasos: «en el paso 3 debería aparecer un diálogo» — eso va en su propio campo.
  • Suposiciones dentro de los pasos: «el paso 4 falla porque la caché está obsoleta» — las hipótesis van en notas, marcadas como «sospecha».

    • Checklist antes de enviar

    • ¿Están escritos los requisitos previos (estado de sesión + estado de datos)?
    • ¿El primer paso es una acción de negocio, no «abrir un navegador»?
    • ¿Exactamente una acción por número?
    • ¿Valores reales en lugar de genéricos?
    • ¿Se anota la observación tras los pasos clave?
    • ¿Resultado esperado y real separados?
    • ¿En bugs intermitentes se indica probabilidad y timing?

    FAQ

    ¿Cuántos pasos debería tener una reproducción?

    Normalmente de 3 a 8. Menos de 3 suele significar requisitos previos ausentes; más de 8 casi siempre se puede recortar — mueve la navegación a los requisitos previos y deja solo las acciones que desencadenan el problema.

    ¿El entorno va en los pasos o en su propio campo?

    En su propio campo. Dentro de los pasos rompe el ritmo de lectura y no se puede filtrar. Si el formato no tiene campo de entorno (por ejemplo un correo), decláralo en una línea al inicio: «Entorno: Chrome 120 / macOS 14 / 1920×1080».

    ¿Hay que incluir acciones irrelevantes como «pulsar Atrás» o «cerrar el diálogo»?

    Solo si forman parte de las condiciones de reproducción. Haz la prueba: elimina el paso, ¿sigue ocurriendo el bug? Si sigue, quítalo; si no, debe quedarse.

    ¿Cómo escribo los pasos de un bug que yo mismo no consigo reproducir?

    Escribe tres cosas con honestidad: ① las condiciones que probaste (qué intentos funcionaron y cuáles no); ② la mejor evidencia disponible (grabación, logs de consola, peticiones de red); ③ las correlaciones observadas («solo cuando la red va lenta»). Márcalo como «condiciones de reproducción sin confirmar» en el título o las notas, en lugar de hacerlo pasar por un bug determinista.

    ¿Cuál es la diferencia entre pasos para reproducir y casos de prueba?

    Un caso de prueba es una checklist diseñada de antemano — cubre caminos normales, límites y excepciones buscando cobertura. Los pasos para reproducir son una ruta registrada a posteriori, cuyo único fin es repetir el problema de forma fiable. Se retroalimentan, pero los objetivos difieren — para redactar casos de prueba, consulta plantilla de casos de prueba con ejemplos.

    Los pasos los escribes tú; las evidencias pueden ser automáticas

    Los pasos tienen que venir de quien hizo clic: solo tú sabes qué hiciste. Pero el entorno y las evidencias que los acompañan pueden rellenarse solos:

    • Grabación de pantalla: graba la pestaña actual con un clic y recorta el clip, para que incluso un bug intermitente lleve evidencia reproducible.
    • Datos de diagnóstico: se recogen logs de consola en nivel error y peticiones de red fallidas (HTTP ≥ 400), con anonimización de parámetros sensibles.
    • Contexto técnico automático: URL, navegador, sistema operativo, resolución y viewport se rellenan por ti.
    • Capturas anotadas: selecciona una zona y añade flechas, cajas y texto para fijar el fallo.
    • Compartir o sincronizar: genera un enlace que se abre sin registrarse, o envía el informe a Feishu Bitable o a un webhook genérico.

    Lecturas recomendadas

    #steps to reproduce #bug reporting #QA #tutorial
    Compartir

    Artículos relacionados