Comunicar cambios de cita con fiabilidad en una aplicación
Un plan de pruebas para los permisos, el estado del envío y el regreso a la cita de servicio vigente.
El cambio pertenece al sistema de citas
Una notificación push informa de una cita modificada. El cambio válido debe guardarse primero en el sistema responsable. Planifique dónde encuentra el cliente el estado actual y quién sigue un cambio importante si el mensaje no le llega.
Apple y Android describen permisos de notificación propios de cada plataforma. Explique el beneficio en el momento adecuado, por ejemplo cuando el cliente quiere activar avisos de citas. Un permiso denegado no es consentimiento. Compruebe el comportamiento en los dispositivos y versiones de sistema previstos.
Ejemplo y plan de prueba completo
En el ejemplo ficticio, el equipo de planificación mueve la cita de servicio AP-17 de 14:00 a 15:00. Un mensaje discreto sería: «Una cita de servicio ha cambiado. Abra la aplicación para consultar el estado actual». No hacen falta detalles personales del trabajo en la pantalla bloqueada.
Situación | Comportamiento previsto | Evidencia esperada |
|---|---|---|
Sin permiso de notificaciones | Las citas actuales siguen localizables en la aplicación; usar el contacto acordado para cambios importantes. | El equipo no da por hecho que el aviso push haya llegado y conoce el rol responsable. |
Cambia la cita | Guardar el cambio y vincular claramente el aviso a esa cita. | El estado nuevo está guardado; intentar enviar no sustituye guardarlo. |
El proveedor acepta el mensaje | Registrar el estado de envío realmente conocido. | La aceptación del proveedor no se registra como recepción en el dispositivo ni como lectura del cliente. |
Dispositivo sin conexión o mensaje tardío | Cargar el estado actual al abrir. | Un mensaje antiguo no restaura un estado anterior; un fallo de actualización se muestra claramente. |
El cliente toca el aviso | Abrir la cita tras el inicio de sesión necesario y la comprobación de permisos vigentes. | Aparece la cita correcta. Si falta el acceso o los datos no cargan, el cliente recibe información adecuada. |
Compruebe por separado el envío y la acción del cliente
FCM documenta la aceptación del servidor y la entrega al SDK del dispositivo como eventos distintos. La recepción tampoco prueba que el cliente haya leído o aceptado el cambio. En este ejemplo, tocar el aviso no debe crear otra cita ni dar automáticamente una aprobación que exija el proceso de negocio.
Fije una validez adecuada al mensaje. Puede llegar tarde; una notificación antigua no debe ser la única fuente del estado de la cita. Acuerde cuándo la persona responsable sigue los cambios importantes por la vía definida.
Pruebe permisos concedidos y denegados, recepción tardía, falta de acceso y datos que no cargan. La tabla describe resultados esperados del ensayo. Evalúe si el cliente encuentra la cita actual y entiende la siguiente acción necesaria.
Fuentes
Escrito por
- Katharina WeberRedactora de software y tecnologíaKatharina Weber se encarga en ASES de los artículos sobre desarrollo de software. Escribe sobre las cuestiones que se plantean las empresas al elegir software, desarrollar nuevas aplicaciones y modernizar sus sistemas existentes.
Seguir leyendo
Todos los artículos
Desarrollo de software con ASES
Software a medida, aplicaciones web y móviles