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

Para probar tu app antes de lanzarla, enumera los pocos recorridos que un usuario debe poder completar, ejecuta cada uno como un usuario completamente 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 flujos 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. En una app de reservas:

1. Registrarse y confirmar la cuenta
2. Encontrar una clase y reservarla
3. Cancelar una reserva
4. Pagar un abono 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 importancia. Los recorridos que generan dinero o que todo usuario recorre (el registro, el 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 pretendía. Pruébalo como lo viviría un desconocido:

• Usa una ventana privada del navegador, para no estar conectado ni tener 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 tengas guardada en marcadores 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, oculta esos errores.

Paso 3: Intenta romperla

Ahora repite cada recorrido y haz a propósito lo incorrecto.

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

Paso 4: Prueba los permisos con dos cuentas

Esta es la prueba más importante en 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ía, 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 las páginas de administración escribiendo sus URL.
• Cierra sesión por completo y prueba las mismas URL.

Si encuentras un problema aquí, no lances hasta arreglarlo. La comprobación debe hacerse en el servidor, no solo ocultando un botón. Nuestra lista 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 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?
• ¿Se lee el texto sin pellizcar la pantalla?

Prueba al menos un iPhone (Safari) y un teléfono Android (Chrome) si puedes dejarte uno prestado. Safari en particular tiene sus propias peculiaridades con fechas, vídeo y elementos de posición fija.

Paso 6: Prueba el dinero y el correo de principio a fin

Todo lo que cobra con tarjetas o envía correos necesita una revisión completa.

Pagos. Usa el modo de pruebas 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 en la app publicada, no solo en desarrollo. Después, antes del lanzamiento, cambia a las claves reales y haz una pequeña compra real que luego reembolses.

Correos. Regístrate con direcciones reales en dos o tres proveedores distintos. Comprueba que los correos llegan, que no caen en spam y que todos los enlaces apuntan al dominio real, 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 arreglo aunque no se note nada roto.
• Carga la web en un móvil con datos móviles, no con Wi-Fi. Si la primera pantalla tarda varios segundos, revisa primero 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

La vista previa y la app publicada no son el mismo entorno. Antes de avisar a nadie del lanzamiento, repite los flujos 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 tras el inicio de sesión y los enlaces de correo usan el dominio real?
• ¿Una recarga en una página interior carga bien?

Paso 9: Observa a otra persona usando la app

Da a una o dos personas un objetivo («reserva una clase de yoga para el sábado»), no instrucciones. Obsérvalas sin ayudar 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 error, anótalo bien: pasos, resultado esperado y resultado real. Nuestra guía sobre cómo escribir un buen informe de error muestra el formato.

Usar la IA para ayudarte a probar

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

Enumera los principales recorridos de usuario de esta app y, para cada uno, los casos límite más propensos a fallar: estados vacíos, entradas no válidas, permisos y recargas. 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, incluido abrir directamente las URL de los registros de A. Informa de lo que encuentres antes de arreglar 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.

Probar en Mythex

En Mythex, el comando /test ejecuta App Testing: el agente maneja un navegador contra tu vista previa en directo, recorre las páginas, captura 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». Arregla lo que encuentre con /fix o con un mensaje normal, y después ejecuta /test de nuevo. App Testing usa la vista previa, así que comprueba tú mismo los flujos principales en la URL publicada después de publicar. Consulta App Testing 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 un ordenador. Muchos 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.
• Arreglar errores sin volver a probar lo cercano. Un cambio en un formulario puede romper otro que comparte código.

Lista de comprobación previa al lanzamiento

• Recorridos principales enumerados y ordenados
• Cada recorrido funciona para un usuario completamente 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 otros, 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 spam y enlazan al dominio real
• Sin errores en rojo en la consola en las páginas principales
• Recorridos principales repetidos en la URL publicada
• Al menos una persona ajena lo ha probado mientras la observabas

Preguntas