Why use an instrumented browser for Mobile Web Test Automation?

amazon Why use an instrumented browser for Mobile Web Test Automation?

There are a lot of discussions in the software testing community discussing the benefits and drawbacks to use an instrumented browser approach to run mobile web automation. As I’m working with a number of customers on this exact subject, I thought I would share my opinion on the subject.

If you want support for precision, complex gestures (multi-touch) while being able to access DOM elements as objects, there are no best way today than to use an instrumented browser. On mobile devices, at least on iOS and Android, applications are sandboxed, meaning that they’re not allowed to access the environment of other apps. This is why, there are no good options today to retrieve objects from native browsers (Mobile Safari, Chrome, Opera, etc.). This is why most solutions on the market today have developed their own instrumented browser which comes in the form of a UIWebView. On iOS, there are hard restrictions from Apple that prevent anyone to come up with a different type of browser. Apple imposes the use of the built-in UIWebView as well as a single-process model. It means that rendering on Chrome, Opera and any other browsers will be similar. But any other third-party browsers can’t use their own JavaScript engines or use Apple’s Nitro engine. A huge advantage for Apple for performance!

I’ve seen solutions that drives Apple UIAutomation (or Android UIAutomator) to perform mobile web automation. Unfortunately, at least for now, they all fall short of expectations. UIAutomation doesn’t provide any precision, so good luck automating mobile web apps such as Google Map. It is also tight to Instruments that can only run one instance per Mac OS. This is not realistic in a Continuous Integration scenario. These solutions require also a lot of coding and personally I’m not a big fan of coding for functional testing. First it takes forever to write the tests but you end up quickly in a maintenance nightmare. I love these type of tests for unit tests, not for functional testing. Finally, these solutions have problem supporting the latest OS and on iOS it’s a big problem since adoption is very, very fast: In less than a week, 50% of people had upgraded to iOS7. We’re at close to 80% today. If the automation framework you’re relying on doesn’t support the new OS from day 1, you’re in big trouble!

Yes, it would be awesome to be able to record tests on native mobile browsers on real devices, be able to perform complex gestures, be able to replay them on other mobile native browsers and add meaningful object based validations. It’s just not possible today due to too many restrictions. Your best bet is still today to use an instrumented browser. I personally didn’t find one customer having problems with this approach.

amazon2 Why use an instrumented browser for Mobile Web Test Automation?

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>