Una lista de comprobación móvil mantiene visibles los riesgos importantes entre decenas de pantallas y dispositivos antes de una entrega. Vincula cada comprobación a una acción concreta y un resultado observable. «Comprobar la red» es demasiado amplio; «desconectar después de enviar un pedido y verificar que reintentar no crea un segundo pedido» puede descubrir un defecto.
Utiliza este material como punto de partida que debes adaptar. Una aplicación bancaria, un reproductor multimedia y un registro de hábitos requieren distinta profundidad y énfasis. Una buena lista evoluciona a partir del producto, los análisis de uso, los cambios de cada entrega y los incidentes anteriores.
Define el alcance de la ejecución
Antes de probar, registra versión y número de compilación, entorno de API, método de instalación, indicadores de funciones y cuentas de prueba. Crea una matriz breve de dispositivos: una versión clave del SO, la configuración mínima admitida, un tamaño de pantalla popular y un dispositivo de recursos limitados. Basa la selección en usuarios y riesgos e identifica explícitamente las omisiones.
Separa las pruebas smoke de la regresión ampliada. Las pruebas smoke determinan si una versión sirve para seguir trabajando y si funcionan los recorridos esenciales. No sustituyen las comprobaciones de migración de datos ni las pruebas tras varias horas de uso.
Instalación, actualizaciones y primer inicio
Comprueba una instalación limpia y una actualización desde una versión anterior admitida. Antes de actualizar, crea datos realistas en la aplicación: un borrador, ajustes y objetos sin conexión. Tras la actualización deben conservarse o migrarse según los requisitos.
En el primer inicio, comprueba la introducción, selección de idioma, consentimiento obligatorio y acceso a la pantalla principal cuando se deniegan permisos opcionales. Tras desinstalar y reinstalar, comprueba la restauración de datos según las reglas de la plataforma y del producto; que una cuenta del servidor siga existiendo no significa por sí solo que la desinstalación haya fallado.
Recorridos críticos del usuario
Identifica varias acciones que llevan a las personas al producto: iniciar sesión, buscar, hacer un pedido, enviar un mensaje o consultar una entrada. Para cada una, comprueba un resultado correcto y al menos un estado de fallo.
- →La acción modifica realmente los datos del servidor y volver a iniciar sesión muestra el estado guardado.
- →Una lista vacía explica el siguiente paso y los errores permiten continuar.
- →Los toques dobles y envíos repetidos no crean duplicados prohibidos.
- →El teclado, los textos largos y los paneles del sistema no ocultan una acción necesaria.
Verificar el resultado importa más que el número de pantallas abiertas. Una notificación breve correctamente mostrada no demuestra que se haya guardado una solicitud.
Estados de red y sin conexión
Comprueba el inicio sin red, la pérdida de conexión durante lecturas y escrituras, respuestas lentas, reconexión y cambio de Wi-Fi a datos móviles. Aclara el comportamiento esperado de las operaciones locales en cola y las reglas para resolver conflictos.
Para una operación con efectos secundarios, determina qué ocurre si el servidor la completa pero el cliente nunca recibe la respuesta. La pantalla no debe comunicar un éxito sin verificar ni obligar al usuario a repetir indefinidamente la acción. Tras reconectar, compara el estado local y el del servidor y busca duplicados.
Ciclo de vida e interrupciones del sistema
Envía la aplicación a segundo plano con un formulario abierto, vuelve a abrirla, bloquea el dispositivo y regresa después de caducar la sesión. Prueba la recreación de pantalla y la finalización del proceso por separado del paso ordinario a segundo plano: sus condiciones de recuperación son distintas.
Los requisitos pueden exigir conservar borradores y ocultar datos sensibles. El sistema no debe perder una operación confirmada ni continuarla con permisos obsoletos. Comprueba también una llamada entrante o un diálogo del sistema durante grabación de audio, pago o carga de archivos si el producto admite ese escenario.
Permisos, notificaciones y navegación externa
Comprueba la concesión, denegación y revocación posterior de los permisos utilizados. La aplicación debe responder claramente cuando no dispone de cámara, ubicación o notificaciones. No hace falta añadir permisos que no usa solo para completar la lista.
Para notificaciones push, comprueba primer plano, segundo plano e inicio desde la notificación. Para enlaces profundos, prueba una aplicación instalada, una sesión caducada, un objeto no disponible y la reapertura del enlace. Una notificación no debe mostrar datos de otro usuario tras cambiar de cuenta y la navegación no debe eludir los controles de acceso.
Datos, seguridad y compatibilidad
Utiliza dos cuentas de prueba para comprobar cambio de usuario, cierre de sesión y acceso a pantallas privadas abiertas previamente. Confirma que cachés, búsqueda y notificaciones push ya no exponen datos del usuario anterior. Los registros de diagnóstico y los informes no deben contener tokens reales ni secretos de usuarios.
Comprueba las configuraciones regionales, zonas horarias y formatos de fecha admitidos en los escenarios relevantes. Cruzar la medianoche resulta especialmente útil en reservas, horarios y límites diarios. Repite los escenarios de mayor riesgo en otros dispositivos, considerando el cambio concreto de la entrega.
Accesibilidad, velocidad y estabilidad
Recorre el flujo principal con TalkBack o VoiceOver, texto ampliado y los ajustes del sistema acordados. Evalúa el acceso a botones, orden del foco y mensajes de error. Los analizadores automáticos complementan las pruebas manuales.
Para el rendimiento, compara el inicio en frío y la operación principal con una versión de referencia aceptada en el mismo entorno. Registra el método de medición y varias repeticiones. Comprueba bloqueos, cierres inesperados, crecimiento de memoria tras acciones repetidas y actividad en segundo plano; una impresión subjetiva de «parece rápido» no basta.
Ejemplo práctico: prueba smoke de una aplicación de reparto
Supongamos que el equipo acuerda cinco comprobaciones obligatorias para una nueva versión: actualización, inicio de sesión, carrito, confirmación del pedido y apertura de un pedido desde una notificación. En el dispositivo principal, actualiza la versión anterior con una dirección guardada, inicia sesión, añade un artículo, realiza un pedido de prueba y abre su notificación.
Resultado esperado: se conserva la dirección, el importe coincide en cada paso, se crea exactamente un pedido, la notificación abre ese pedido y no hay cierres inesperados. Repite por separado la confirmación perdiendo la respuesta y recuperando después la red. En un segundo dispositivo, comprueba el inicio de sesión y la finalización del pedido. Esta ejecución tiene límites claros; el número de elementos aprobados no la convierte en una regresión completa.
Cómo comunicar los resultados
Para cada elemento, utiliza Aprobado, Fallido, Bloqueado o No ejecutado y añade el entorno y un enlace al defecto. Bloqueado significa que no fue posible probar; no equivale a aprobado. Enumera en el informe los problemas bloqueantes y riesgos sin cubrir, como una actualización en la versión mínima del SO todavía no comprobada.
Una lista es útil cuando ayuda a decidir sobre una versión. Mantenla después de incidentes y cambios del producto, elimina duplicados y automatiza las comprobaciones estables y repetibles. Cada elemento debe explicar exactamente qué observar y por qué importa.
Lecturas adicionales
- →Android Developers: directrices básicas de calidad de aplicaciones
- →Android Developers: probar la accesibilidad de la aplicación
Convierte la lista en una matriz de función × plataforma × estado
Elige dispositivos según el intervalo de SO admitido, el uso real del producto cuando esté disponible y riesgos como presión de memoria, pantallas pequeñas y funciones de hardware. Sin datos de uso, proponer tres dispositivos es una hipótesis basada en riesgos, no cobertura de mercado medida: una configuración Android con la versión más antigua admitida, una configuración Android actual de otro fabricante y una configuración iPhone admitida. Añade más variantes de SO y pantalla de iPhone cuando el intervalo admitido o el riesgo de la función lo justifique.
Función Plataforma/estado Acción Observación esperada Evidencias
Formulario en borrador Android: segundo plano/regreso Introducir texto, cambiar de aplicación, volver El estado cumple la regla de guardado acordada; ningún envío duplicado Versión + vídeo
Formulario en borrador iOS: inactivo/segundo plano/regreso Interrumpir la edición y volver El estado cumple la regla de guardado acordada Versión + vídeo
Cámara Cada plataforma; permiso denegado Invocar la función y denegar la solicitud Alternativa utilizable; explicación clara; sin cierre inesperado Estado del permiso + vídeo
Lista guardada Cada plataforma; sin conexión/reconexión Cargar, desconectar, actualizar y reconectar Caché y reintento cumplen los requisitos Traza de red + UI
Enlace profundo Cada plataforma; inicio en frío/en caliente Abrir enlace con y sin sesión iniciada Destino correcto o flujo seguro de inicio de sesión Enlace + estado de sesión
Actualización Cada ruta de actualización admitida Instalar la nueva versión sobre el estado anterior preparado Datos requeridos conservados y migrados Versiones anterior/nueva + diferencia de datosNo supongas que los callbacks de actividades Android y las transiciones de escenas iOS son intercambiables. Las actividades Android pueden recrearse; el comportamiento de primer y segundo plano en iOS sigue el ciclo de vida de sus escenas o de la aplicación. Registra el SO real, la acción de ciclo de vida y la recuperación observada. Prueba por separado la denegación de permisos y su revocación en ajustes; las opciones exactas dependen de la versión del SO y del tipo de permiso.
En cada fila registra Pass/Fail/Blocked/Not run, el dispositivo y SO exactos, la versión de la aplicación, el estado inicial y un enlace a evidencias sin datos sensibles. Una ejecución solo en simulador no demuestra el comportamiento de una cámara real, la entrega de notificaciones, un cambio de red o la presión de memoria del dispositivo. Selecciona las comprobaciones en dispositivos reales según el riesgo de la función, sin afirmar que todas las configuraciones están cubiertas.
Continúa aprendiendo
Permisos, interrupciones y notificaciones
Ciclo de vida de actividades Android