Cómo probar un enlace a una app cerrada, abierta o sin sesión

Un enlace que abre la app solo ha completado la primera parte de su trabajo. Quien espera una solicitud concreta todavía puede acabar en la pantalla inicial, perder el destino al iniciar sesión o ver un registro de otra cuenta.

Define la aceptación según el destino previsto y la persona autorizada para verlo. Este ejercicio ficticio utiliza la solicitud REQ-42 en una cuenta de pruebas. Es un plan propuesto, no el relato de una app entregada a un cliente ni de una prueba ejecutada en dispositivos.

Ilustración conceptual generada con IA; no es una captura de un cliente.

Separa el estado de la app del estado de la cuenta

“Cerrada”, “abierta” y “sin sesión” no son tres condiciones excluyentes. Una app puede estar cerrada y conservar una sesión válida, o estar ejecutándose sin una sesión iniciada. Registra ambas dimensiones para que un lanzamiento correcto no sustituya todos los casos.

Empieza con cuatro combinaciones: cerrada con sesión, en ejecución con sesión, cerrada sin sesión y en ejecución sin sesión. Añade el comportamiento en segundo plano o suspendido si la plataforma admitida lo trata aparte. Especifica cómo estableces cada estado, en vez de usar “reiniciar” como instrucción ambigua.

La guía de enlaces universales de Apple describe puntos de entrega diferentes para apps que usan escenas según estén arrancando o ya se encuentren en ejecución o suspendidas. Esa diferencia justifica probar ambas rutas; superar una no demuestra que la otra reciba el destino previsto.

Escribe un contrato de destino

Para el ejemplo, define el resultado como “mostrar el detalle de REQ-42 en la cuenta de pruebas autorizada”. Abrir la app o su lista de solicitudes no satisface esa condición. Registra la cuenta esperada y una marca visible inocua que permita confirmar qué registro se abrió.

No incluyas credenciales ni datos privados de clientes en la URL de prueba. Utiliza un identificador ordinario de un conjunto de datos controlado. La aplicación todavía debe comprobar si la cuenta actual puede acceder al registro; poseer el enlace no constituye el criterio de permiso.

Sigue el destino durante el inicio de sesión

El ejemplo de navegación condicional de Android dirige a una persona no autenticada al inicio de sesión antes de regresar a un perfil protegido tras autenticarse. También define un resultado distinto si abandona sin iniciar sesión. Usa esa distinción para especificar tu propio destino y el comportamiento al cancelar.

Para REQ-42, escribe la secuencia esperada: recibir el enlace, solicitar autenticación y resolver el destino con la cuenta autenticada. Comprueba que el registro previsto se conserve durante el acceso sin mostrar antes detalles protegidos.

• Completa el acceso con la cuenta autorizada y confirma que se abre REQ-42.
• Cancela el acceso y verifica que aparezca la pantalla segura acordada, sin contenido protegido.
• Introduce credenciales inválidas y comprueba que la app no abra el registro ni anuncie éxito.
• Accede con otra cuenta de pruebas sin permiso y verifica la respuesta acordada de acceso denegado o recurso no disponible.

No supongas que autenticarse concede acceso a cualquier registro. Conserva por separado la observación de navegación y la decisión de permisos.

Comprueba una app que ya está abierta

Empieza en otro registro de prueba y activa después el enlace a REQ-42. Confirma que la app muestra el registro solicitado en vez de conservar datos de la pantalla anterior. Repite desde una pantalla neutra y desde un estado de segundo plano admitido por la app.

Si hay un borrador sin guardar, acuerda antes su tratamiento: conservarlo, preguntar antes de salir u otra regla explícita. Registra ese resultado sin cambiar el propósito del enlace. Comprueba también la siguiente acción de volver atrás; debe seguir el comportamiento documentado de la aplicación, no una supuesta regla universal.

Prueba destinos inválidos y repetidos

Incluye un identificador ausente, una URL mal formada y un enlace bien formado a un registro de prueba inexistente. Apple indica que deben validarse los parámetros de la URL y probarse enlaces mal formados. Para este ejercicio, define una alternativa clara que no revele registros protegidos y ofrezca un siguiente paso útil.

Activa dos veces el mismo enlace válido. Comprueba si duplica pantallas de detalle o repite una acción que debería exigir confirmación expresa. Este ejemplo abre una vista de consulta; recibir el enlace no debe aprobar ni modificar por sí mismo la solicitud.

Registra la entrada junto con el resultado

En cada caso, conserva la compilación de la app, versión del sistema operativo, pantalla inicial, estado de sesión, origen del enlace, destino esperado y resultado observado. Pulsar un enlace en un mensaje y escribir una dirección en el navegador son entradas diferentes; prueba las que realmente utilicen tus usuarios.

Registra aparte el comportamiento sin la app instalada si forma parte del alcance. Este plan supone una app instalada y no promete restaurar automáticamente el destino después de instalarla. Repite los casos aceptados en la compilación prevista para la entrega antes de declarar verificado el recorrido.

Contacta con Dynelink para definir un plan concreto de aceptación de enlaces a destinos de tu aplicación móvil.