Mi esposa intenta descargar con su teléfono móvil, una nueva aplicación para nuestro niño de 2 años de Google Play Store. Oh oh … Algo no está bien! Obtiene un error: “NewKidsApp no se pudo descargar debido a un error (403)”... Ella me llama desesperada … Mis primeras palabras son: «Tratemos de descargar la aplicación con WIFI sin usar la red proporcionada por el proveedor» Justo en el clavo! Funciona y la aplicación se descarga en un instante. Pero no funcionaba en la red proporcionada por el Carrier. Ahí está: «Un ERROR móvil que nunca sucederá en un entorno de escritorio»
Probar aplicativos móviles es algo completamente diferente en comparación con realizar pruebas Web o de Aplicaciones Desktop. Si somos capaces de entender la diferencia y los desafíos de probar aplicaciones móviles, será un poco más fácil de abordar.
Hay muchas diferencias que podemos encontrar muy fácilmente en Internet:
- Limitaciones de RAM y almacenamiento: muchos dispositivos móviles todavía incluyen 2 o 4 GB de RAM, junto con SSD de 16 GB relativamente pequeños. Estas restricciones imponen severas limitaciones a la memoria RAM y la capacidad de almacenamiento para las operaciones de prueba, especialmente con respecto a la gran cantidad de memoria y almacenamiento a la que accede prácticamente cualquier navegador web moderno.
- Más complejidades: la entrada de escritorio / computadora portátil se ha estabilizado básicamente hace más de 35 años, con el combo de mouse y teclado como estándar para todo, desde navegar por Facebook hasta jugar un juego de PC. Las aplicaciones móviles presentan desafíos adicionales. Además de la gran variedad de acciones táctiles (deslizar, tirar, etc.), hay asistentes de voz como Siri y Google Now. Las innovaciones específicas del dispositivo, como los gestos de la mano en algunos auriculares Samsung, o el nuevo conjunto de audio del iPhone, agregan más complejidades a las operaciones móviles.
- Debe funcionar correctamente tanto de forma horizontal como vertical
- Distintos tipos de aplicaciones: una aplicación web de escritorio está construida con HTML, CSS y JavaScript, con algunas variaciones según los marcos que un desarrollador decida utilizar. Las aplicaciones móviles no son tan sencillas.
- Tamaños y espacios entre las partes interactivas: No estamos usando un mouse que haga clic en un punto específico, estamos usando nuestros dedos, por lo que también debemos pensar en los tamaños y espacios entre las partes interactivas.
- Tratar con el proveedor del servicio y el WIFI: No es un problema fácil de resolver en el lado móvil y no tenemos este problema en nuestros portátiles, correcto?
Pero cuanto más complejo, mejor! Entonces, Qué sucede si uso ambos entornos al mismo tiempo?
Tipos de errores que podrían descubrirse:
- Los tiempos de respuesta en los datos que se encuentran solo en la base de datos central son cruciales: Qué datos descargamos en el dispositivo móvil? Cuáles dejamos en el repositorio central? Cómo resolvemos los problemas de conectividad?
- Tratar de adaptar las mismas funcionalidades en un espacio más pequeño
- Problemas con la carga y descarga de datos (proceso de sincronización)
- Problemas de pantallas según el tipo de dispositivo: Celular, tableta, relojes, etc.
Como mencioné antes, cuanto más complejo, mejor!
Y qué sucede si tengo que usar la aplicación móvil en modo fuera de línea? Y cuando el dispositivo vuelve a estar en línea?
Cambiar las condiciones de la red: Puede pasar que alguien pierda su conexión, o simplemente que no la tenga disponible cuando usa la aplicación móvil. No todo el mundo tiene el lujo de LTE y la aplicación móvil debe seguir trabajando …
Aquí hay otros tipos de errores:
- Los datos no se registran en el repositorio central trabajando en modo fuera de línea
- Duplicación de eventos cuando se vuelve al modo Online
Entonces, volvemos a la pregunta inicial: In Code We Trust? Por supuesto no! Vamos a probar!
A quién no le ha pasado! Continuará …
Autor
Isaac Malamud
CEO & Founder at Mate Quality Services
MQS
English version
Code
In Code We Trust? — Web and Mobile Testing on the same App
My wife tries to download with her mobile, a new app for our 2-year old kid from the Google Play Store. Oh oh…. Something’s not quite right! She gets an error: NewKidsApp could not be downloaded due to an error (403). She calls me desperate… My first words are: “Let’s try downloading the App on WIFI without using the Carrier provided Network” Right on the spot! It works and the App is downloaded in a flash. But it would not work on the Carrier provided network. There it is, “A Mobile BUG that will never happen in a Desktop environment…”
Mobile Testing is a completely different thing compared to Desktop/Web Testing. If are able to understand the difference and challenges of testing Mobile Apps, it will be a bit easier to tackle.
There are a lot of differences that we can find very easily on the Internet:
- RAM and storage limitations: Many mobile devices still ship with 2 or 4 GB of RAM, along with accompanying relatively small 16GB SSDs. These limitations place severe constraints on RAM and storage capacity for testing operations, especially with respect to the vast amounts of memory and storage which virtually any modern web browser accesses.
- Further complexities: Desktop/laptop input has essentially been stabilized for more than 35 years, with the mouse and keyboard combo still the standard for everything from browsing Facebook to playing a PC game. Mobile applications present further challenges. In addition to the wide variety of touch actions – swiping, pulling, and so on – there are voice assistants such as Siri and Google Now. Device-specific innovations such as hand wave gestures on some Samsung headsets, or the new iPhone audio set, add further complexities to mobile operations.
- It must work correctly in either Landscape or Portrait
- Distinct application types: A desktop web app is built with HTML, CSS and JavaScript, with some variations depending on which frameworks a developer chooses to utilize. Mobile applications are not as straightforward.
- Sizes and spaces between the interactive parts: We are not using a mouse that clicks on one specific point, we are using our fingers, so we must also think about the sizes and spaces between the interactive parts.
- Dealing with the service provider and the WIFI: Is not an easy issue to solve in the Mobile side and we do not have this issue in our Notebooks right?
But the more complex the better! So, what happens if I use both environments at the same time?
Types of errors that could be discovered:
- Response times on data found only in the central database are crucial: What data do we download to the mobile device? Which ones do we leave in the central repository? How do we solve connectivity problems?
- Try to adapt the same functionalities in a smaller space
- Issues with uploading and downloading data (Synchronization process)
- Screens Issues depending on the type of device: Cellular, Tablet, Watches, etc.
As I mentioned before, the more complex the better!
And what happens if I have to use the Mobile application in offline mode? And when the device returns to Online?
Changing network conditions: You can count on someone losing their connection, or just not having it available at all when using the mobile app. Not everyone has the luxury of LTE and the Mobile App must keep working…
Here are other types of errors:
- Data is not recorded in the central repository working in offline mode
- Duplication of events when I went online
So, In Code we trust? Of course not! Let´s go testing!
Life itself… To be continued…
Artículos relacionados
MQS – CORRESPONSAL DE ARGENTESTING EN LA EXPOQA – ÚLTIMO DÍA
MQS – CORRESPONSAL EN MADRID EN EXPOQA – DÍA 05-06-18
MQS – CORRESPONSAL EN MADRID EN EXPOQA
MQS SERÁ NUESTRO CORRESPONSAL EN LA EXPO:QA’18
MQS NUEVO SPONSOR GOLD DE ARGENTESTING ED 2018
