Una gran parte de los informes de errores que reciben los desarrolladores son solo una imagen y las palabras “está roto”. La captura hace la mitad del trabajo; la otra mitad depende de cómo se capturó, anotó y empaquetó. Esta guía es una plantilla práctica para que cada captura aporte todo lo que puede.

Qué contiene un buen informe basado en capturas

  1. El estado en sí: la pantalla real que muestra el problema, no una descripción de él.
  2. Un puntero: una flecha o un cuadro que señale el elemento exacto implicado.
  3. Metadatos de contexto: qué app y qué versión, qué sistema operativo e idealmente la resolución, para que el desarrollador pueda descartar fallos de renderizado propios del entorno.
  4. Pasos de reproducción: numerados, cortos y en orden. La captura es el paso N; el lector necesita los pasos 1 a N-1.
  5. Esperado vs. real: una línea para cada uno. “Esperado: el desplegable se mantiene abierto. Real: el desplegable se cierra al instante.”

Todo lo demás es opcional. Resiste el impulso de adjuntar cinco capturas cuando una captura bien anotada y tres pasos de reproducción cuentan toda la historia.

Capturar específicamente para un informe de errores

Captura el alcance adecuado

  • Región, no pantalla completa, en la mayoría de los casos. Un recorte ajustado alrededor del componente roto se lee más rápido en móvil y expone menos de tu entorno.
  • Pantalla completa solo cuando la posición importa, p. ej., un error de maquetación donde lo importante es la relación entre paneles.
  • Captura ambos estados en los errores de transición. Si hacer clic en X hace desaparecer Y, necesitas el antes y el después. Dos capturas pequeñas valen más que una ambigua.

Anota con intención

La guía de anotación cubre las herramientas a fondo; para un informe te bastan sobre todo estas:

Anotación Cuándo usarla
Flecha Un elemento concreto está mal. La opción por defecto.
Rectángulo Una región o contenedor se comporta mal (espaciado, desbordamiento, recorte).
Texto Números de paso en reproducciones de varios pasos; etiquetas de “esperado” y “real”.
Desenfoque Cualquier cosa sensible que no sea relevante para el error. Siempre.
Recortar Quitar el espacio vacío tras anotar para que la marca ocupe el encuadre.

Dos reglas generales:

  • Una flecha por captura. Si necesitas tres flechas, probablemente necesitas tres capturas.
  • Desenfoca antes de subir. Tokens, nombres de clientes y URLs internas se desenfocan en el editor antes de que la imagen salga de tu máquina. Qué método de tapado usar depende de lo que tenga que seguir siendo legible. No se puede deshacer un desenfoque después de compartir.

Incluye los metadatos que ayudan

Una página de compartición que muestra dimensiones, tamaño de archivo y fecha de captura te ahorra la ronda de preguntas de “¿a qué resolución estabas?”. Las páginas de compartición de Shotivo muestran ancho × alto, tamaño de archivo, fecha de creación y caducidad, así que pegar el enlace transmite ese contexto automáticamente.

En el propio cuerpo del informe, añade:

  • Nombre de la app + versión (p. ej., “Shotivo 1.x” o el número de compilación del producto afectado)
  • Sistema operativo + versión (“macOS 15.2”)
  • Nota de entorno de una línea si es relevante (“monitor externo 4K”, “VPN activada”)

El flujo: tres segundos hasta una captura compartible

Con un utilitario de captura de barra de menús (valores por defecto de Shotivo):

  1. ⌘⇧9: arrastra sobre la región rota. El editor se abre al instante.
  2. Elige la herramienta Flecha y marca el elemento; desenfoca lo sensible; recorta ajustado.
  3. ⌘↩ (Compartir): sube la imagen y copia un enlace shotivo.app/s/… en tu portapapeles.
  4. Pega el enlace en el ticket, seguido de los pasos de reproducción.

Total desde la primera pulsación hasta el enlace listo para pegar: de tres a cinco segundos. Los enlaces Free caducan a los 7 días; los Pro pueden durar hasta 90 días (90 días por defecto). Descarga el original si el ticket necesita una copia local duradera. Si no estás seguro de qué límite te corresponde, aquí tienes cómo funciona la retención según el plan.

Plantilla

[App] [Componente]: [resumen de una línea]

Pasos:
1. …
2. …
3. Observar: <qué pasa>

Esperado: <qué debería pasar>

Captura: <pegar enlace de compartir>
Entorno: macOS 15.2 · versión de la app 1.x · <nota del monitor si es relevante>

Rellena la plantilla en menos de un minuto y habrás escrito un informe con el que un desarrollador puede actuar sin necesidad de una llamada de seguimiento. La captura muestra el problema y las tres líneas lo explican.

Errores comunes

  • “Ver adjunto.” sin pasos de reproducción. El desarrollador tiene que adivinar cómo llegar a ese estado.
  • Captura completa de un problema diminuto. La flecha apunta al 2% del encuadre.
  • Secretos sin desenfocar. El informe se reenvía, se archiva, se indexa. Tu token acaba siendo público.
  • Cinco capturas del mismo estado. Una buena con algo de texto vale más que cinco mediocres.
  • Captura hecha tras “arreglarlo”. Captura primero el estado roto; siempre puedes volver a capturar después.

El listón es bajo y merece la pena alcanzarlo: ¿podría un desarrollador que nunca ha visto esta app llegar al estado roto solo con tu texto y ver exactamente qué falla con tu imagen? Si la respuesta es sí, el informe está listo.