Skip to content
Movilion

Trucos para probar sitios y aplicaciones en móviles

prueba-sitios-aplicaciones-moviles

Seguramente tanto los software como las aplicaciones web se ejecuten en tablets y smartphones, así que las pruebas en móviles se están convirtiendo en algo crucial.

¿Cómo elegir el dispositivo para hacer esas pruebas? Algunas preguntas a tener en cuenta para no perder tiempo:

1. Smartphones, tablets o los dos?
2. ¿Cuál es la versión compatible más antigua del sistema operativo (OS)?
3. ¿Qué dispositivos podrían ser los más populares para el público objetivo?
4. ¿Qué tamaños de pantalla y versiones del sistema operativo no están incluidos por los dispositivos en los puntos anteriores?

Tatyana Mahlaeva, que es gerente de control de calidad en A1QA, dice que cuando se trabaja con iOS, no se necesitan más de 10 dispositivos para probar. Para Windows Phone serán no más de 20 dispositivos por lo que para la mayoría de los proyectos, serán necesarios de 5 a 10.

Android es un poco más complejo. Se necesita un enfoque completo durante la elección, porque existen cientos de aparatos y varias versiones. Es crucial seleccionar la mejor combinación.

¿Cómo? Primero hay que consultar toda la documentación para entender la idea de negocio y la arquitectura de la aplicación. Esto permite encontrar los defectos más importantes para que los desarrolladores puedan arreglarlos.

Después hay que tener en cuenta en primer lugar la funcionalidad, y solo después los gráficos. Agarrar el dispositivo más conocido y hacerle un testeo completo. Así, saldrán a la luz todas las especificaciones de la aplicación que no están en los documentos.

Por otro lado, hay que preguntarse sobre las soluciones funcionales que parezcan controversiales e identificar los defectos más graves de la aplicación. No hay que dejar de lado estos inconvenientes cuando se pruebe la aplicación en dispositivos menos populares.

Además, hay que incluir comprobaciones básicas de usabilidad. Aunque estemos probando la funcionalidad de la aplicación, cosas referidas al uso podrían hacer que la aplicación no sea clara. Por ejemplo, comprobar que la lógica de la aplicación no sea complicada, que la sección de ayuda sea entendible, que el fondo de la aplicación no moleste a la hora de poner marcas o etiquetas, etc.

Tampoco hay que olvidarse del entorno real, que se logra recabando los resultados del entorno que comprueben en todas las condiciones específicas que el dispositivo puede experimentar durante su uso. Hacer esto garantiza que los usuarios no tendrán inconvenientes con la aplicación.

Otra cosa importante es cerciorarse que la aplicación no tenga problemas si se ejecuta con una conexión de red inestable, cualquier tipo de interrupción originada en otro servicio (SMS, notificaciones de calendario, llamadas, alarmas y notificaciones de batería baja, etc). Tampoco debería trabajar con diferentes zonas horarias ni incomodar las diferentes combinaciones de ajustes de sonido y notificaciones.

Por otro lado hay que hacer pruebas exploratorias y ad hoc, incluso si ya se probaron todas las funciones y los posibles problemas y los resultados fueron satisfactorios, es aconsejable esperar un poco antes de considerarlos finales.

Por último, es conveniente dar un paso atrás e intentar “quebrar” la aplicación, o también puede resultar bueno llevársela a alguien que no la conozca para tener una mirada objetiva. Esto puede ayudar a descubrir defectos que antes no se notaron.

¿Cómo se presentan los resultados?
Cuanta más información y descripciones se presenten en el informe, mayor es la probabilidad de fijar los errores y reproducir los defectos.

1. Condiciones previas
Describir si se trabajó a la par con otras cuentas, si hubo algún inconveniente con las aplicaciones preinstaladas, es información que hay que registrar.

2. Pasos
Esta es la parte fácil, hay que describir minuciosamente lo que se hizo y lo que se vio sin dejar nada afuera.

3. Medio Ambiente
Incluir entorno y ajustes utilizados durante la prueba. Incluye el tipo de dispositivo y versión utilizados, versión del sistema operativo elegido para cada dispositivo, si se utilizó un simulador para reproducir un defecto que deba ser especificado, si el defecto se reproduce en todos los dispositivos, excepto uno o dos, se debe aclarar debido a que puede resultar de mucha ayuda para el desarrollador que trabaje en su corrección.

4. Resultados esperados
Aquí es donde se explica la forma en que la aplicación se comporta o debe comportarse después de que el error se corrija. Básicamente, en este apartado se proporcionan las instrucciones reales para el desarrollador, los detalles de cómo la aplicación debería funcionar correctamente.

5. Información adicional
Esta sección del informe le permite dar una idea completa de lo que el verificador realizó y los resultados obtenidos.

Los puntos descriptos a continuación, pueden ayudar a los desarrolladores a definir mejor el campo de batalla:

• Additional items that were used to reproduce the defect: all of the files, images, videos, provisioning profiles used to reproduce the defect must be affixed; sometimes one symbol in the file may cause the defect, and even logs could not reflect this.

• Imágenes y videos (si la pantalla es suficiente o no)

• Registros de la aplicación: es necesario que se adjunte cada defecto en torno a los gráficos. Todos los registros deben estar incluidos (recogidos por el dispositivo en sí, por aplicaciones adicionales como CatLog para Android, recogidos con la ayuda de SDK u otras utilidades, incluida la consola en las utilidades de configuración del iPhone).

• Elementos adicionales que se utilizaron para reproducir el defecto: todos los archivos, imágenes, videos, perfiles de datos que se utilizaron para reproducir el defecto deberán adjuntarse. A veces un símbolo en el archivo puede causar el defecto, e incluso los registros pueden no reflejarlo.

Esta es, básicamente, una estructura para probar sitios y aplicaciones en móviles.