Cómo probar una actualización móvil con un borrador pendiente

Una actualización móvil puede funcionar en una instalación limpia mientras una persona que ya usaba la app no logra abrir un formulario pendiente. Una comprobación útil comienza con trabajo guardado por la versión anterior y lo sigue durante la actualización admitida.

Este es un ejercicio propuesto de aceptación para un borrador ficticio de trabajo en campo. No describe una prueba realizada para un cliente ni garantiza que toda actualización conserve los datos. El negocio y el equipo de desarrollo deben aprobar qué borradores deben mantenerse, qué versiones se admiten y qué significa recuperarlos antes de probar.

Define el borrador y el cambio de versión

En el ejemplo, una persona técnica ha guardado un borrador local con una referencia de ubicación, una nota, una selección incompleta y un archivo de prueba adjunto. El borrador no se ha enviado. La siguiente versión añade un campo obligatorio y cambia cómo se almacena una selección.

Anota la compilación instalada, la compilación de destino, la plataforma del dispositivo y la versión relevante de los datos locales. Distingue la versión de la app de la del almacenamiento: una entrega puede cambiar pantallas sin modificar los datos guardados, o cambiar ambas cosas. Elige las versiones iniciales realmente admitidas, incluida una más antigua cuando las personas puedan saltarse entregas.

Reúne evidencia antes de instalar la actualización

• Crea el borrador en la app anterior con datos sintéticos y no sensibles.
• Guarda su identificador y los valores esperados, incluidos los campos vacíos deliberadamente.
• Registra si el adjunto está almacenado localmente, cargado o pendiente.
• Cierra y vuelve a abrir esa versión para confirmar que el borrador guardado existe antes de actualizar.
• Registra la cuenta con sesión iniciada y conserva el contexto del usuario autorizado.

Usa un proceso de actualización que conserve los datos existentes de la app. Una instalación nueva puede comprobarse por separado, pero no demuestra que un borrador anterior haya sobrevivido. Si la preparación de la prueba borra el almacenamiento, considera inválida la prueba de actualización y reconstruye el caso.

Inspecciona el borrador después de actualizar

Abre la app actualizada, localiza el mismo borrador y compara cada valor registrado. Comprueba que la información ausente siga apareciendo como pendiente: un campo obligatorio nuevo debe seguir la regla aprobada, sin tomar silenciosamente un valor de negocio inventado. Confirma que la persona pueda entender qué debe completar.

Para aplicaciones que usan Room, la documentación de migraciones de Android explica por qué deben considerarse los datos existentes del dispositivo al cambiar el esquema de la base de datos. Admite rutas de migración automáticas y manuales y recomienda probarlas. Esas comprobaciones deben acompañar a la revisión del borrador en pantalla; abrir la base de datos no demuestra por sí solo que el formulario muestre y utilice correctamente sus valores.

Continúa el trabajo hasta un envío controlado

En un entorno de prueba, completa el campo nuevo, revisa el adjunto y envía el borrador una vez. Confirma el registro resultante en el servidor, su identidad y sus valores. Vuelve a abrir la app para comprobar que el borrador completado no aparezca como una segunda tarea pendiente. Si el envío falla, verifica que la app comunique el resultado real y conserve el trabajo exigido por la política de recuperación aprobada.

Prueba también el comportamiento sin conexión definido si el producto lo admite. Registra si la actualización puede abrir el borrador sin conexión y qué debe esperar a recuperar conectividad. Separa esto de los conflictos entre dos dispositivos: este ejercicio trata la compatibilidad entre un borrador antiguo guardado y una app nueva.

Incluye la recuperación en la decisión de lanzamiento

Acuerda una prueba segura para un borrador ilegible o no admitido. La app debe ofrecer una ruta útil de recuperación y evitar presentar silenciosamente el trabajo perdido como un formulario vacío. No presupongas que reinstalar una versión anterior permitirá leer datos ya modificados por una versión nueva; incluye cualquier reversión propuesta en un plan admitido y probado por separado.

Conserva juntas las compilaciones de origen y destino, los valores anteriores y posteriores, la evidencia del envío, las limitaciones y la persona revisora. Bloquea la aprobación si desaparece un valor necesario, un adjunto queda inaccesible o no puede conciliarse el resultado observado. La ficha respalda una decisión sobre las rutas probadas, no sobre todos los dispositivos o borradores posibles.

Contacta con Dynelink para conversar sobre requisitos de actualización móvil y pruebas de aceptación para trabajo pendiente.

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