Last updated July 29, 2016.
Many of our clients ask us for advice with mobile application testing strategy. One of the questions we’re asked most often is when an instrumented browser should be used versus a device’s built-in browser for testing a mobile web application.
Many people need to test browser-based mobile web sites often built with HTML 5.
For manual testing, nothing special is needed to view objects. In fact, testing can be done using a regular browser that comes preloaded on the device such as Safari for the iPhone® or Chrome for Android™ phones.
When to Use an Instrumented Browser
For automated testing, which gives testers the benefit of performing repeatable tests over time, using an instrumented browser is the way to go. In fact, using an instrumented browser with a mobile app testing solution is a more efficient way to insure a mobile website is working properly.
The benefit of using an instrumented browser running on a mobile device is that it allows an automated testing tool to treat the HTML document object model (DOM) as objects within a script.
The result is increased accuracy in finding and interacting with objects and testers get a better understanding of the state of the website than they would if relying on surface-based testing of built-in browsers.
The Purpose of an Instrumented Browser
Apple and Android have an application sandbox. This means that an app cannot be permitted to access other resources in other applications outside of some allowed APIs.
This means that in most cases retrieval of objects from the native browsers is not an option. This also means that in order to have an agent (a process that is created by instrumentation) retrieve the HTML objects, an instrumented browser app has to be developed.
An instrumented browser will use the same rendering engine as the native browser ensuring that the testing results of a mobile website under test is accurate and reliable.
Testing to Ensure Your Mobile App Works
When responsive website design is used many mobile applications can adjust based on the form factor and size of the screen. In many cases the website might look different and relying on surface-based testing can become challenging.
Take, for instance, a mobile website rendered on an iPad® versus an iPhone. The sign-in button on a login screen will be larger and the button will appear in a different location on an iPad than it will on an iPhone.
Having access to the objects through an instrumented browser approach enables testers to find the sign-on button without depending on a specific X-Y coordinate or image representation of the button. Another example on the login screen is the password field.
The user will see the password mask – a surface-based testing approach cannot tell a tester the value of the password field. Using an instrumentation approach, however, testers can detect the password that was entered or even saved. In fact, all a tester has to do is click on an object spy button and the automated testing tool will find the password field along with its properties.
When it comes right down to it, the only way to be certain that a field is working properly from a programmatic standpoint is to use an instrumented browser for mobile website testing.
In addition, performing testing using an instrumented browser gives testers the power to access all the properties and methods of an object. Ultimately, testers will also be better positioned to extract objects and reuse them in their next mobile website automated test.
For more tips on what to consider when making the switch from surface-based to native object instrumentation testing, read this blog post.
Want to learn more? Check out our latest posts!
Don’t forget to download our eBook on Amazon, to stay ahead of the curve in 2017!