Cómo reproducir errores de Android en varios teléfonos reales

Un flujo de trabajo de soporte práctico para convertir una queja específica del dispositivo de Android en un caso reproducible, un paquete de pruebas y una transferencia de ingeniería útil.

Por qué los equipos de soporte mantienen más de un teléfono Android

Un cliente puede describir un fallo con precisión y aún así dejar al soporte incapaz de reproducirlo. La versión de la aplicación puede estar correcta, pero el problema solo aparece en una construcción del fabricante, versión de Android, tamaño de la pantalla, estado de las permisos, idioma, red o política de la batería. Un solo teléfono de referencia no puede representar ese rango. Por eso los equipos de soporte móvil a menudo mantienen un pequeño conjunto de teléfonos Android reales incluso cuando el ingeniería ya los utiliza con emuladores y pruebas automatizadas.

El objetivo no es poseer todos los modelos. Es mantener una cobertura lo suficientemente amplia como para responder rápidamente a tres preguntas: ¿puede el equipo reproducir el informe, qué condición lo desencadena y qué evidencia permitirá que el equipo de ingeniería continúe sin repetir toda la conversación de soporte? AWS Device Farm identifica igualmente a los representantes del soporte al cliente junto con los desarrolladores y los equipos de QA, y describe la interacción con dispositivos reales como una forma de depurar y reproducir los problemas de los clientes.

• Autenticación, pago, notificación, permiso, cámara, Bluetooth y fallos en el procesamiento en segundo plano.
• Diseños que se rompen en una densidad de pantalla, escala de fuente, idioma o modo de navegación en particular.
• Problemas de actualización o instalación relacionados con una versión de Android o el firmware del fabricante.
• Problemas que solo aparecen después de un cambio de red, ejecución en segundo plano de la aplicación, restricción de la batería o interrupción.
• Los informes de los clientes que necesitan una captura de pantalla, una breve grabación, los detalles del dispositivo y los pasos exactos de reproducción antes de la escalada.

Recoja los datos mínimos del estuche antes de elegir un teléfono

No comience haciendo clic en teléfonos al azar. Primero, convierta la conversación de soporte en un caso probable. La pérdida de datos de entrada pierde más tiempo que la configuración del dispositivo físico porque el equipo no puede distinguir un defecto específico del dispositivo de un problema de cuenta, versión, red o datos caducados.

Si un cliente no puede proporcionar todo, registre lo que es desconocido en lugar de llenar silenciosamente las lagunas. El soporte aún puede probar el camino conocido, pero la ingeniería debería poder ver qué suposiciones se hicieron. Nunca pida a los clientes que envíen contraseñas, detalles de pago, documentos de identidad, mensajes privados o archivos personales no relacionados.

Construya una pequeña matriz de dispositivos a partir de las pruebas del cliente

Una mesa de soporte útil se basa en los dispositivos que realmente usan sus clientes, no en una estantería de atractivos teléfonos insignia. Comience con análisis, informes de fallos, volumen de tickets y segmentos críticos para las ventas. Elija un dispositivo de gama baja, un modelo común de gama media, un teléfono insignia reciente y cualquier fabricante o versión de Android que aparezca repetidamente en casos no resueltos.

1. Exporta los modelos de dispositivos más populares y las versiones de Android de datos de productos fiables.
2. Agrupa dispositivos similares por el firmware del fabricante, el nivel de rendimiento, las características de la pantalla y la generación del sistema operativo.
3. Elija el conjunto físico más pequeño que cubra la mayor parte de los casos importantes.
4. Añade un modelo solo cuando los boletos o el riesgo del producto justifiquen su costo de mantenimiento.
5. Revise la matriz trimestralmente y retire los dispositivos que ya no representen un tráfico o riesgo significativo.

Una mesa de tres a seis teléfonos a menudo es más útil que una gran colección no mantenida. Las pruebas de compatibilidad más amplias aún pueden ir a un servicio en la nube. La mesa local existe para una reproducción interactiva rápida, demostraciones de soporte y casos en los que se utilizan los mismos dispositivos repetidamente. Para la configuración física, consulte elGuía de laboratorio de dispositivos Android de bajo costo.

Organizar la mesa de soporte multihotelero

Cada teléfono necesita una identidad estable. Dale un código corto, etiquétalo físicamente y registra su modelo, versión de Android, fecha de última reinicio, estado de la batería, método de conexión, versión de prueba instalada y cuentas de prueba asignadas. Utilice cables confiables y hubs USB con alimentación cuando varios teléfonos compartan un ordenador; la energía inestable y los cables dañados pueden crear fallos que parecen defectos de la aplicación.

Controla varios teléfonos AndroidDesde un espacio de trabajo común cuando el equipo necesita comparar pantallas, moverse entre dispositivos o repetir un paso de configuración autorizado. indioLaiCai Screen Mirroring, los dispositivos pueden ser visibles desde una estación de trabajo de Windows o macOS, por lo que el operador gasta menos tiempo recogiendo teléfonos y más tiempo comparando el estado de la funda. El agrupamiento es útil para separar líneas de base limpias, casos de soporte activos, dispositivos de gama baja y teléfonos que esperan ser reiniciados.

• Mantenga un dispositivo de base conocido como bueno para comparación.
• Utilice cuentas de prueba dedicadas con datos sintéticos siempre que sea posible.
• Restablecer los datos de la aplicación entre casos cuando el estado anterior podría cambiar el resultado.
• Mantenga el código del teléfono visible en cada captura de pantalla o nota del caso.
• Registre la carga, el USB, el Wi-Fi y las condiciones térmicas cuando afecten a la prueba.

Realizar una reproducción controlada

El camino más rápido hacia un resultado útil suele ser una comparación controlada, no un gran lote de acciones simultáneas. Comience en el dispositivo que coincida más cerca y reproduzca el estado inicial del cliente. Ejecute los pasos reportados una vez sin cambiar nada. Si aparece el problema, repítalo para confirmar la frecuencia. Si no lo hace, cambie una variable a la vez: red, permiso, idioma, datos de la aplicación, versión de Android, fabricante, escala de fuente o política de batería.

1. Crea la tarjeta de caso con el código del teléfono, la versión de la aplicación, el tipo de cuenta, la red, el idioma y la pantalla de inicio.
2. Reproduzca los pasos exactos del cliente en el teléfono compatible más cercano.
3. Repita el mismo camino en el teléfono de referencia que se sabe que está en buen estado.
4. Cambie solo una condición sospechosa y ejecute el camino de nuevo.
5. Detenerse cuando el gatillo esté aislado o se alcance el límite de intentos acordado.
6. Escribe tanto los intentos exitosos como los fallidos; las pruebas negativas reducen la próxima investigación.

No utilice la entrada sincronizada cuando los dispositivos ya se hayan desviado. Un cuadro de diálogo de permisos, un carga lento, un teclado o una solicitud de actualización pueden enviar el mismo clic a controles diferentes. Las acciones compartidas solo son útiles mientras todos los teléfonos seleccionados estén visiblemente en el mismo estado seguro. De lo contrario, opere los dispositivos individualmente y preserve la diferencia que está tratando de entender.

Cree un paquete de pruebas que la ingeniería pueda reproducir

Una transferencia de información útil es lo suficientemente pequeña como para revisarla rápidamente y lo suficientemente completa como para reproducirla. Un ticket debe conectar el entorno, los pasos, el resultado observado, el resultado esperado y las pruebas de apoyo. Las capturas de pantalla prueban un estado estático; una breve grabación de pantalla prueba el tiempo y la secuencia; los registros explican lo que la interfaz no puede mostrar. Ninguno de ellos reemplaza a los demás.

Nombra los archivos con el ID del ticket, el código del teléfono, la versión y la hora y fecha de creación. La transferencia de tareas debería permitir que un ingeniero entienda el fallo en unos minutos sin abrir múltiples hilos de chat. Para un flujo de trabajo de QA más amplio, consulteReflejo de pantalla de Android para pruebas de aplicaciones móviles.

Elige teléfonos locales, emuladores o un servicio de dispositivo en la nube

Estas herramientas resuelven diferentes problemas de cobertura. Una oficina telefónica local no es una sustitución para una granja de dispositivos en la nube, y un laboratorio en la nube no elimina el valor de los teléfonos familiares junto al equipo de soporte. Seleccione el entorno menos costoso que pueda reproducir fielmente la condición.

Una secuencia práctica es emulador primero para una rápida comprobación de integridad, teléfonos locales para causas probablemente reales del dispositivo y dispositivos en la nube cuando falta el modelo o la funda necesita una confirmación más amplia.Reflejo de pantalla de Android en un PC o MacEs más útil cuando el soporte necesita un control visual directo sobre los teléfonos locales en lugar de la gestión de políticas en una flota empresarial distribuida.

Proteger los datos del cliente durante la reproducción

La resolución de problemas de dispositivos reales puede exponer información personal si el proceso es descuidado. Utilice cuentas sintéticas y datos de prueba por defecto. Si se requiere realmente datos de producción, obtenga la autorización adecuada, restrinja el acceso, capture solo lo que necesita el caso y siga la política de retención de la empresa. AWS también advierte a los usuarios de su servicio de dispositivos que no ingresen credenciales de cuenta, información personal u otros detalles sensibles a la seguridad porque las sesiones pueden producir registros y videos.

• Nunca copie la contraseña, la información de pago, el token de autenticación, las fotos privadas o los documentos de identidad de un cliente en un teléfono de laboratorio.
• Desenfocar o recortar nombres, mensajes, direcciones de correo electrónico y números de cuenta no relacionados antes de adjuntar pruebas.
• Mantenga las cuentas de prueba separadas por entorno y gire las credenciales de acuerdo con la política de la empresa.
• Elimine capturas de pantalla, grabaciones, registros, archivos descargados y datos de la aplicación cuando finalice el período de retención.
• Registre quién accedió a un caso sensible y por qué cuando la política requiere un registro de auditoría.

Dirija el flujo de trabajo con tres teléfonos

No empiece comprando un muro de teléfonos. Elija una clase recurrente de casos de soporte y tres dispositivos representativos: un punto de referencia conocido como bueno, el teléfono de cliente más común y un teléfono de gama baja o específico del fabricante en contraste. Ejecute el flujo de trabajo durante dos semanas, luego decida si otro dispositivo o un servicio en la nube resolvería los casos que el piloto no pudo cubrir.

1. Seleccione diez billetes recientes que se retrasaron debido a la incertidumbre del dispositivo.
2. Define los campos de entrada requeridos y una única plantilla de paquete de evidencia.
3. Etiquete y prepare tres teléfonos con cuentas de prueba limpias.
4. Realice un seguimiento del tiempo hasta la primera reproducción significativa, los bucle de aclaración, la aceptación de la escalada y las lagunas no resueltas en el dispositivo.
5. Revise qué teléfono o condición ambiental realmente cambió el resultado.
6. Expandir solo cuando la evidencia demuestre una brecha repetida en la cobertura.

El resultado que hay que verificar es simple: un ingeniero de soporte debería poder recibir un caso, seleccionar un teléfono adecuado, reproducir el camino y entregar una transferencia de manos autosuficiente sin buscar en varios sistemas no relacionados. Si un espacio de trabajo local compartido ayuda a ese piloto,LaiCai Screen Mirroringpuede mantener los teléfonos Android seleccionados visibles y controlables desde un ordenador Windows o macOS.

Preguntas frecuentes

¿Cuántos teléfonos Android necesita un equipo de soporte?

Comience con tres a seis teléfonos seleccionados a partir de datos reales de billetes y uso. Añada dispositivos solo cuando un caso repetido e importante no pueda ser cubierto por la matriz actual o una sesión ocasional en la nube.

¿Debería apoyar la reproducción de todos los informes de clientes?

No. Priorice la gravedad, los usuarios afectados, el impacto en el negocio, el riesgo de seguridad, la recurrencia y si la reproducción cambiará la siguiente acción. Un laboratorio de dispositivos es una herramienta de decisión, no un requisito para reproducir cada queja vaga.

¿Puede el control sincronizado reproducir un error en todos los teléfonos al mismo tiempo?

Solo mientras los dispositivos estén visiblemente en el mismo estado y la acción sea segura. Una vez que los tiempos, los mensajes de diálogo, las permisos, los teclados o los diseños difieran, opere los teléfonos individualmente. La divergencia es evidencia, no algo que haga clic ciegamente.

¿LaiCai reemplaza una plataforma de gestión de dispositivos móviles?

N.ºLaiCai Screen MirroringEs una herramienta de control visual y flujo de trabajo local. Las flotas empresariales distribuidas que necesitan inscripción sin contacto, aplicación de políticas, distribución de aplicaciones, inventario o borrado remoto deben utilizar un sistema MDM o EMM adecuado.

Fuentes

• Preguntas frecuentes sobre AWS Device Farm
• Guía para desarrolladores de AWS Device Farm
• Laboratorio de pruebas funcionales de OpenText para dispositivos móviles y web
• Laboratorio de pruebas remotos de Samsung
• Guía de soporte de Google Android Enterprise