Our CEO Isaac Marcelo Malamud Kobrinsky created this article describing how normal interaction with users and mobile tech is changing testing minds.
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…