Cómo probar tu app antes de lanzarla: un plan práctico previo al lanzamiento

Para probar tu app antes de lanzarla, haz una lista de los pocos recorridos que un usuario debe poder completar, ejecuta cada uno como un usuario nuevo en un ordenador y en un móvil, y después prueba las formas en que puede salir mal: datos vacíos, entradas incorrectas, una segunda cuenta, una conexión lenta. Prueba con especial cuidado todo lo que implique dinero o datos privados, y repite los recorridos principales en la URL en vivo después de publicar. Termina observando a alguien que nunca ha visto la app mientras intenta usarla.

No necesitas un equipo de QA ni un framework de pruebas para esto. Necesitas una lista, una o dos horas y la disciplina de recorrerla de verdad.

Paso 1: Anota los recorridos que importan

Un recorrido es una tarea de principio a fin que un usuario viene a hacer. La mayoría de las apps tienen entre tres y seis que de verdad importan. Para una app de reservas:

1. Registrarse y confirmar la cuenta
2. Buscar una clase y reservarla
3. Cancelar una reserva
4. Pagar un bono de clases
5. Personal: ver las reservas de hoy

Si has escrito historias de usuario, sus criterios de aceptación ya son tus casos de prueba. Si no, escribe una línea por recorrido con lo que significa «éxito».

Ordénalos por prioridad. Los recorridos que generan dinero o que todo usuario recorre (registro, inicio de sesión, la acción principal) se prueban primero y con más detalle.

Paso 2: Prueba el camino feliz como un usuario nuevo

El «camino feliz» es el recorrido que sale exactamente como se pensó. Pruébalo como lo viviría un desconocido:

• Usa una ventana privada del navegador, para no tener sesión iniciada ni datos guardados.
• Usa una cuenta nueva con un correo real al que puedas acceder.
• Empieza desde la página de inicio o desde un enlace, no desde una página que hayas guardado en favoritos mientras construías la app.

Los usuarios nuevos no tienen datos. Muchos errores solo aparecen cuando una lista está vacía, un perfil no tiene foto o todavía no se ha comprado nada. Tu propia cuenta, llena de datos de prueba, los oculta.

Paso 3: Intenta romperla

Ahora repite cada recorrido y haz las cosas mal a propósito.

La recarga merece una mención aparte: si la app funciona cuando haces clic, pero al recargar una página más profunda aparece un 404, consulta cómo arreglar errores 404 tras desplegar.

Paso 4: Prueba los permisos con dos cuentas

Esta es la prueba más importante para cualquier app con cuentas, y la que más se omite.

Crea dos usuarios normales, A y B, y (si tu app los tiene) un administrador.

• Como A, crea un registro. Inicia sesión como B. ¿Puede B verlo, editarlo o borrarlo? No deberían poder, salvo que ese sea el diseño.
• Como A, copia la URL de uno de tus registros. Inicia sesión como B y abre esa URL directamente.
• Como usuario normal, abre páginas de administración escribiendo sus URLs.
• Cierra sesión por completo e intenta las mismas URLs.

Si encuentras un problema aquí, no lances hasta que esté corregido. La comprobación debe hacerse en el servidor, no solo ocultando un botón. Nuestra lista de comprobación de seguridad para apps creadas con IA profundiza más.

Paso 5: Prueba en dispositivos reales

Abre la app en un teléfono de verdad, no solo en una ventana estrecha del navegador.

• ¿Puedes pulsar cada botón sin hacer zoom?
• ¿El teclado tapa el campo en el que estás escribiendo?
• ¿Las tablas y el contenido ancho se desplazan o se ajustan, en lugar de empujar la página hacia los lados?
• ¿El texto se lee sin tener que hacer pinza?

Prueba al menos un iPhone (Safari) y un teléfono Android (Chrome) si puedes pedir prestados. Safari, en particular, tiene sus propias particularidades con las fechas, los vídeos y los elementos de posición fija.

Paso 6: Prueba los pagos y el correo de principio a fin

Todo lo que cobra con tarjeta o envía correos necesita una prueba completa.

Pagos. Usa el modo de prueba de tu proveedor de pagos y sus números de tarjeta de prueba. Comprueba un pago correcto, una tarjeta rechazada y un pago cancelado. Confirma que el pedido o la suscripción aparece en tu app después del pago, no solo en el panel del proveedor. Si tu app depende de webhooks (mensajes que el proveedor de pagos envía a tu servidor), comprueba que llegan a la app publicada, no solo en desarrollo. Después, antes del lanzamiento, cambia a las claves reales y haz una compra real pequeña que luego reembolses.

Correos. Regístrate con direcciones reales en dos o tres proveedores distintos. Comprueba que los correos llegan, que no caen en el spam y que cada enlace apunta al dominio en vivo, no a una dirección de vista previa.

Paso 7: Revisa la velocidad y los errores

• Abre las herramientas de desarrollo del navegador (clic derecho → Inspeccionar) y mira la pestaña Consola en cada página principal. Los errores en rojo merecen corregirse aunque nada parezca roto.
• Carga el sitio en un móvil con datos móviles, no con Wi-Fi. Si la primera pantalla tarda varios segundos, revisa antes el tamaño de las imágenes.
• Ejecuta una auditoría gratuita como Lighthouse en las herramientas de desarrollo de Chrome para una lectura rápida del rendimiento y la accesibilidad.

Paso 8: Prueba la app publicada, no solo la vista previa

Una vista previa y una app publicada no son el mismo entorno. Antes de comunicar el lanzamiento a nadie, repite los recorridos principales en la URL en vivo:

• ¿Están configuradas todas las variables de entorno y secretos en la app publicada?
• ¿Usa la base de datos correcta, con los datos que esperas?
• ¿Las redirecciones del inicio de sesión y los enlaces de correo usan el dominio en vivo?
• ¿Una recarga en una página profunda carga correctamente?

Paso 9: Observa a otra persona usándola

Da a una o dos personas un objetivo («reserva una clase de yoga para el sábado»), no instrucciones. Observa, no ayudes, y anota dónde dudan. Es la forma más rápida de encontrar textos confusos y botones escondidos. Para una versión más amplia de esto, consulta cómo hacer una prueba beta.

Cuando encuentren un fallo, anótalo bien, con pasos, resultado esperado y resultado real. Nuestra guía sobre cómo escribir un buen informe de errores muestra el formato.

Usar la IA para ayudarte a probar

Si construyes con IA, puedes pedirle que te ayude a planear y ejecutar las pruebas:

Enumera los recorridos principales de esta app y, para cada uno, los casos límite con más probabilidad de fallar: estados vacíos, entradas no válidas, permisos y recarga. Preséntalo como una lista de comprobación que pueda recorrer.

Inicia sesión con dos usuarios de prueba distintos y comprueba si el usuario B puede ver o cambiar algo que creó el usuario A, incluso abriendo directamente las URLs de los registros de A. Informa de lo que encuentres antes de corregir nada.

Trata el informe de pruebas de la IA como una primera pasada. Aun así, recorre tú mismo los recorridos de dinero y de permisos.

Pruebas en Mythex

En Mythex, el comando /test ejecuta Pruebas de la app: el agente maneja un navegador sobre tu vista previa en vivo, recorre las páginas, hace capturas de pantalla e informa de los flujos rotos en el chat. Funciona mejor con un recorrido concreto, como «prueba el registro y la reserva de una clase». Corrige lo que encuentre con /fix o con un mensaje normal, y luego vuelve a ejecutar /test. Las pruebas de la app usan la vista previa, así que comprueba tú mismo los recorridos principales en la URL publicada después de publicar. Consulta Pruebas de la app en la documentación, y nuestra guía sobre cómo depurar una app creada con IA para cuando algo falle.

Errores habituales

• Probar solo como tú mismo. Tu cuenta de administrador, con muchos datos, oculta los errores de estados vacíos y de permisos.
• Probar solo en el ordenador. La mayoría de los visitantes de muchas webs llegan desde un móvil.
• Saltarse la segunda cuenta. Que los datos se filtren entre usuarios es el error más grave con el que puede lanzarse una app.
• Fiarse de la vista previa. La app en vivo tiene otra configuración; pruébala también.
• Corregir errores sin volver a probar lo cercano. Un arreglo en un formulario puede romper otro que comparte código.

Lista de comprobación previa al lanzamiento

• Recorridos principales listados y ordenados por prioridad
• Cada recorrido se supera como usuario nuevo en una ventana privada
• Entradas vacías, no válidas, largas y duplicadas gestionadas
• La recarga funciona en todas las páginas
• Los usuarios no pueden ver ni cambiar los datos de los demás, ni siquiera por URL
• Páginas de administración bloqueadas para usuarios normales y visitantes sin sesión
• Funciona en un iPhone real y en un teléfono Android
• Pagos probados: éxito, rechazo, cancelación, y la app se actualiza después
• Los correos llegan, no caen en el spam y enlazan al dominio en vivo
• Sin errores en rojo en la consola de las páginas principales
• Recorridos principales repetidos en la URL publicada
• Al menos una persona externa lo ha probado mientras la observabas

Preguntas