Una lista de problemas conocidos indica a los testers lo que ya sabes, para que dediquen su tiempo a lo que tú no sabes. Reduce los reportes duplicados y deja claro qué problemas se aceptan en esta build y cuáles no.
Plantilla para copiar y pegar
PROBLEMAS CONOCIDOS: [Nombre de la app], build [versión / número de build], [fecha]
Ya conocidos, no hace falta reportarlos:
1. [Título corto] - [Dónde ocurre]. Workaround: [workaround o "ninguno"]. Estado: [se arreglará en la build X / aceptado por ahora].
2. ...
Aún no están listos, por favor sáltatelos:
- [Pantalla o función] - [una línea con el motivo]
Sigue siendo necesario reportar:
- Cualquier cosa que se cierre o pierda datos, incluso en un área de la lista de arriba.
- Un problema conocido que se comporte distinto a lo descrito aquí.
Cómo reportar: [enlace o canal]. Incluye dispositivo, versión del sistema y pasos.
Ejemplo (inventado)
PROBLEMAS CONOCIDOS: Pocket Budget, build 0.9.3 (42), 2026-10-17
Ya conocidos, no hace falta reportarlos:
1. Modo oscuro: las etiquetas del gráfico son difíciles de leer en la pantalla de Estadísticas. Workaround: usar el modo claro. Estado: se arreglará en la próxima build.
2. La exportación a CSV es lenta con más de unos cientos de entradas. Workaround: ninguno. Estado: aceptado por ahora.
Aún no están listos, por favor sáltatelos:
- Ajustes > Copia de seguridad: todavía no está conectado
Sigue siendo necesario reportar:
- Cualquier cosa que se cierre o pierda datos, incluso en un área de la lista de arriba.
- Un problema conocido que se comporte distinto a lo descrito aquí.
Cómo reportar: responde a este mensaje. Incluye dispositivo, versión del sistema y pasos.
Cómo adaptarla
- Mantenla corta. Si la lista tiene más de unos diez puntos, los testers dejan de leerla. Quita los puntos arreglados en cada build.
- Pon el número de build. Una lista sin número de build está mal una versión después.
- Describe síntomas, no causas. Los testers comparan con lo que ven, no con los nombres de tus tickets internos.
- Mantén las líneas de "sigue siendo necesario reportar". Si no, los testers asumen que un área listada está prohibida y te pierdes los nuevos cierres ahí.
- No ocultes problemas graves. Un bug conocido de pérdida de datos debe estar en la lista, con un aviso, no en silencio.
- Úsala con la build. Envía la lista en el mismo mensaje que entrega la build y enlázala desde las notas de la versión.
Relacionados: checklist de go / no-go para el lanzamiento, checklist de hotfix y el hub checklists de pruebas de apps móviles.
¿Quieres testers que reporten de forma estructurada? Empieza gratis.