Defina la actualización y sus condiciones de prueba
Imagine una lavandería de Budapest actualizando la pantalla de direcciones guardadas de su aplicación de recogida. Los clientes actuales necesitan elegir su dirección habitual y encontrar pedidos anteriores. Acuerde qué versión se aprueba, desde cuáles pueden actualizar los clientes y qué teléfonos y sistemas operativos admite la empresa.
Los fundamentos de pruebas de Android distinguen entre componentes individuales y recorridos completos. Pida al equipo que explique qué evidencias cubren cada aspecto. Use una matriz breve con versión, dispositivo, idioma y estado inicial de la cuenta. Más combinaciones exigen más tiempo: priorice las de sus clientes y registre lo no probado.
Ensaye la actualización con datos existentes
En una cuenta de prueba de la versión anterior, guarde dos direcciones ficticias y cree un historial de pedidos de ejemplo. Instale la actualización mediante el proceso de distribución de pruebas del equipo, sin borrar antes la aplicación. Compare direcciones, selección predeterminada y detalles de pedidos con el resultado esperado acordado.
Una instalación nueva se prepara más rápido, pero deja sin explorar esa situación inicial. Mantenga ambas comprobaciones. Volver a iniciar sesión puede ser intencionado; perder una dirección requiere investigación. Use datos inventados para que grabaciones e informes no expongan direcciones de clientes reales.
Interrumpa una tarea en un momento relevante
Las recomendaciones de calidad de Android incluyen interrupciones y cambios de red. En la lavandería, empiece a editar una nota de recogida, cambie de aplicación y vuelva. Compare el resultado con lo prometido sobre guardar borradores. Repita bloqueando la pantalla y registre el punto exacto donde se produce una pérdida inesperada.
Abra después el historial con una conexión deliberadamente lenta y desconéctela. ¿Puede el cliente distinguir los datos ya cargados de un intento fallido de actualizarlos? Restablezca la conexión y compruebe que el pedido mostrado pertenece a la misma cuenta. Acuerde los mensajes esperados antes de probar, para identificar fallos de forma coherente.
Incluya clientes con distintos ajustes
Repita la selección de dirección con el permiso de ubicación denegado si la aplicación ofrece ese acceso directo. Pruebe texto ampliado y un lector de pantalla, también al volver de otra aplicación. Pida a alguien familiarizado con esa tecnología de asistencia que encuentre y cambie la dirección guardada sin orientación.
React Native advierte que las pruebas de componentes JavaScript no ejecutan el código nativo subyacente. Solicite una demostración en cada plataforma móvil admitida. Compartir código puede reducir trabajo duplicado, pero superar una comprobación en una plataforma no sustituye probar la otra.
Apruebe evidencias vinculadas a una versión concreta
Conserve un registro breve que puedan revisar juntos propietario, desarrollador y responsable de soporte. Si una corrección genera otra compilación, repita las comprobaciones afectadas y el recorrido esencial del cliente antes de aprobarla.
- Registre la compilación probada y las versiones anteriores usadas al comprobar actualizaciones.
- Conserve resultados esperados y reales de direcciones guardadas e historial de pedidos.
- Enumere interrupciones, condiciones de conexión y ajustes de accesibilidad probados.
- Asigne a cada problema pendiente un responsable y una decisión explícita de lanzamiento.
- Identifique quién atiende los avisos de clientes y comprueba los primeros fallos comunicados.