If you have ever worked on a mobile project, you know that there is a lot of variables. You can use simulators and emulators, but that will only take you so far. If you really want to be effective, you need to have real physical devices, and then you have to make a few choices. You could say “OK, I’ll get an iPhone and an Android device” but that will lead to a myopic view, in the sense that different devices behave differently. additionally, devices in the mobile space age quickly. The rate of enhancement in the mobile/smartphone space has been exponential. Devices made five years ago may as well have been made twenty years ago. Yes, the rate of technology development has jumped that much ahead.
In many ways, our experience will be determined by what we had before. If we operated an old style terminal window app, a modern mobile app may feel wonderful. For those who are almost exclusively used to modern mobile development, apps may feel ill suited to the way that they work. Ultimately, that’s the real goal of our testing, to see how they help us do our work or accomplish our goals.
Some things to consider:
- What is the purpose of the app?
- Who will be using it?
- Is there an analog to another product/platform?
- What devices will it be available to work with?
Once we have a feel for the scope of what we will be doing, then we need to dig in and consider the mechanics of how we can work with our app and effectively test. A simulator/emulator attached to an IDE may be the quickest and least expensive option. Additionally, a legitimate question is “who will be doing the testing and what environment will be used?” Can you do effective testing with the IDE and emulation? Sure, just don’t rely on it 100%. Can you do all the testing on a mobile device? Sure, but the feedback loop may be long.
The key takeaway is that a hybrid approach of simulation/emulation via developer IDE and access to dedicated devices, even if a subset, may prove a winning combination.