Logo
/ mobile-testing

And this why you should never use Emulators! Top 3 reasons for you, testers!

By DeviQA on Tue Jan 03 2017 00:00:00 GMT+0000 (Coordinated Universal Time)

And this why you should never use Emulators! Top 3 reasons for you, testers!

Subscribe Now!

Get the latest QA news and tips from DeviQA


Currently emulators are available and are widely used for both manual and automated mobile application testing. Today you can find plenty ios emulators all over the app store and find necessary android app emulators in play market. They are powerful tools for developing mobile applications; they have unique features which enable them to provide a rich set of development tools as well as an integrated debugging environment and mostly they are available for free from the vendors.

Well for starting real devices give you a real feeling of the app, how it performs on real hardware and all the factors that may contribute to make an application work or crash. App emulators for PC can be used to navigate through an application and look at the screen layout and presentation, but the true user experience, how application looks, and feels can only be properly tested as a customer would: on a physical device. It is a totally different experience using a full-sized keyboard with mouse than physically navigating the mobile application via touch and gestures.

A few major reasons why testing on real devices usually result in better testing results than using app emulators:

1. User experience and usability

Situation Based Testing: You cannot emulate real life usage with software. How does the app look when you are outside in the sun, or when it’s raining? How comfortable will be using your app while walking? Does the interface translate well with swipes and finger usage? All these situations are impossible to replicate with emulators.

Interrupts: You cannot test on an emulator how you app react when phone receiving a text message or phone call while using the app.

2. Wide range of device configurations

Memory Related Issues: Emulators simple have a great deal more memory available than real devices. This is because they are not multitasking the way a real device is. The performance of your app on an emulator may perform much better than on a real device. This could cause a misconception of how fast your app responds.

Display related issues: In this case it’s not about the resolution but in fact mostly about the quality of display - density, color and quality of the display in general. All of it can be cause of mismatching between designate UI and how it look on current device.

Chipset: We have already mentioned that device fragmentation has increased in a several times over the past year. While not all of these have dramatically different chipsets, display sizes, sensors and other hardware differences, it is safe to say that out of 24 thousand distinct android devices some permutations are bound to occur. Chipsets in particular can also provide very different user experiences between high and low end devices, yet can completely fool an emulator, because the processor of the PC they run on is ten times more powerful than that android devices actualy have. Even with constraints placed, the emulator can inadvertently borrow to get the job done.

Battery related issues: Another advantage of using physical phone is that you actually can test a battery live during running you app. There is simply no way to test the efficiency and power consumption of your app via an emulator. An application that kills your phone in an hour will not become popular.

3. Customization and Platforms

Your app is software but there are tons of other software involved in mobile device too. And this software can make your software perform differently on array of devices. First of all it is the operating system version that combined with rest of the software – typically brought in by OEM – have an influence on developers and how their app/game performs on any device. Sometimes apps depend access to some other application. For example, many applications include social media and in worst implementations it is taken for granted that some of the social media applications should be already installed on devices before user can actually use those shortcut buttons.

The decisions of when to use emulators or real devices, and to what point, are a function of each organization’s risk management approach. Obviously, there is a trade-off between the cost of mobile testing and the risk of releasing full of bugs application to the market. In the case of a mobile banking application, for example, a software defect may result in severe business consequences. On the other hand, an independent developers can take risks to test only on an emulators and save costs.

The grey area between these two extremes is likely to vary among different organizations, depending on each one’s risk management approach, internal needs, and customer demands. Each team will need to determine at what stage to introduce real devices, how many devices are enough to cover market needs, and how best to manage those devices.