Mobile Functional Automation – Real Object Identification

The Mobile applications market is growing rapidly and so are the mobile automation testing solutions with record-replay capabilities. In this post, I will try to introduce one of the major problems in mobile functional testing automation, focusing on Android un-rooted devices and non-jailbreak iOS devices.

 

As you may already know, there are three main methods to achieve record-replay for functional automation. Real-object identification, image-based recognition and analog record-replay (based on x- and y-axes). The most stable, reliable, and maintainable technique is real-object identification. Unfortunately, it’s difficult to implement in the mobile arena due to the different platforms’ security mechanisms and the mobile operating systems architectures.

 

Nevertheless, there are several solutions available in the market with real object recognition capability! So how is that?

After investigating the main players in the market, I found out that most of them (if not all of them) use the same technique to accomplish real-object identification. They modify the application under test source code\project in order to record and replay automation tests with real-object recognition. In Android, this can be done by decompiling the apk-file and injecting some additional code (hooks).

In iOS, an external library (provided with the automation framework) must be added to the application under test project. This library will be loaded at runtime and injects its hooks inside the application so that record-replay capabilities can be achieved. In both platforms, the solution is implemented by changing the application under test source code. Because the solution lives inside the application context it’s easier to retrieve UI control data and UI operations for record.

 

What are the implications?

In order to automate your application you should create two deployments, a testable version (for QA) and another one for production. Usually, the testable one can’t be released to the market especially in iOS due to Apple restrictions and reviews before publishing the application (In several frameworks they asks you not to upload the testable version of your application for this reason). In addition, you don’t know how the hooks might affect your application. In this case, better not to keep them in production.  

 

Now we reach the real purpose of this post.  I’d like to hear your opinions on this: Is it acceptable to release a different version of application than the one you tested? Please share your answers with me.

 


This post was written by Ameer Tabony

Labels: mobile
Comments
Karim_Fanadka | ‎06-05-2013 04:43 AM

It’s very important to let customers trust the hooks mechanism (I mean to deliver Reliable test framework :) ), to be sure that the hooks doesn’t damage the App, and then (according to my opinion) I will release 2 internal candidates of my App:

 

- App 1 : test candidate

- App 2 : release candidate

 

The “Test candidate” will be used for testing, actually for hooking J, and after create and run the tests I will be able to know if the “Release candidate” is ready for production, ready when all tests pass, not ready when defects discovered, in case we have to fix defects then we need 2 new candidates.

 

What I am saying that I don’t have to release the same App under test otherwise the “Release candidate” should be released , in addition if the hooks mechanism could damage the App then we should find defects while running the tests.

 

I think the “Mobile Functional Automation – Real Object Identification solution should be tested on many Apps, and the concern of the damage that could be done because of the hooks mechanism need to be tracked and described,

For example, if the mechanism will cause may App to crash then it’s very critical, but if the damage is like to show button with color black instead of blue then we could live with it J.

Again all above answer is based on my opinion.

When I am using test mechanism that based on hooks mechanism my expectation will be high, accurate, fast, easy, etc..

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation