Test WebView used within android native app

Unfortunately currently robotium does not support testing of webview even if it is used with native app but there is a way to test webview using Android WebDriver. So the solution is using combination of robotium + android webdriver. Here is the sample code to test contents of webview.
Little background about AUT: Native app has a button (assume ‘Google’) clicking on which opens webview with google.com.

Sample Code:
Activity mActivity = getActivity();
WebView web;
ArrayList<View> views = solo.getCurrentViews();
for(View view : views) {
if(view instanceof WebView) {
web = (WebView) view;
break;
}
}
WebDriver driver = new AndroidWebDriver(mActivity);
driver.get(web.getOriginalUrl());
WebElement element = driver.findElement(By.name("q"));
element.sendKeys("Test");
element = driver.findElement(By.xpath("//span[text()='Google Search']"));
element.click();

Testing strategy for mobile apps

The biggest challenge most of the mobile app development companies face is maintaining huge inventory of mobile devices which requires good amount of investment in procurement of the devices and then maintenance cost and operational cost like data usage etc. Also as new mobile devices are coming in the market every now and then (especially in case of android) so it’s practically not feasible to test app on each and every devices. Because of all these constraints mobile app testers should take balanced approach in testing.

Testing on emulators: Initial functional testing of the AUT should be done on emulators. Today most of emulators and simulators are capable of simulating the functionality of real device so first approach testers should follow is test AUT on emulator with target OS version to uncover most of the functional issues. AUT should be tested on each supported OS version.

Incase of android you can fully configure you emulator like SD card support, keyboard support etc.

Testing on real device: Once you feel that build is stable enough and most of the application specific functional and UI issues have been uncovered and fixed then you should start testing of AUT on real devices to uncover device specific issues. If you have all the devices available then you should perform testing on each device otherwise you should select required devices intelligently like one device of each target screen resolution and one device of each manufacturer, one device of each OS version. You should talk to developers to know if developers are using any OS version specific APIs etc.

Note: One important point to note here is you should select devices based on targeted mobile operator like AUT might work differently on two iPhones, one on Verizon and other on AT&T. This happens because of different technologies on both. And also sometimes because of customization done for mobile operator like one operator might block some APIs etc.

Testing on virtual devices: Today we have virtual environments like DeviceAnyWhere, PerfectoMobile etc. They have very good device inventory which you can use to test your AUT. They are very helpful as you need not to maintain huge device inventory in your organization. But as they charge on hourly basis, you need to make sure that you use them intelligently. When you have tested on app on different combination of screen resolution, os versions etc. then you could DAW etc. to sanity test your app on other devices with same configuration just to verify AUT works perfectly on them also. Before using them, make sure you have very good network connectivity otherwise you might observe some issues which might not occur on real devices.

Test case writing techniques:

Most of the time we starting writing test cases based on our experience and intuition and sometimes we end up writing some useless or repetitive test cases (in the sense that specific scenario might have already been covered in some other test case). I am not saying that we should not use our past experience but experience should be used along with some scientific techniques.

There are many techniques which can be used (and should be used) to write test cases (especially test data). These are mainly test data generation techniques which should be used to write effective and optimized test cases. Some of the techniques are like Boundary value analysis, equivalence partitioning, orthogonal arrays etc.

BVA and EP should be used to generate valid and invalid data for each field. Orthogonal array is used when we have multiple fields on the screen and we want test data with different combinations.

Boundary Value Analysis: In BVA, we generate test data at the boundary of the field i.e. if any field accepts numeric value between 18 and 60 then test data for that field should be 17,18,60,61.

Equivalence Partitioning: In EP, first we determine valid range of the field for example in our example valid range is 18 to 60 so test data should be selected as:

Valid range: 18-60: any one value

Invalid range1: -ve no. to 17: any one value

Invalid range2: 61 to +ve no.: any one value

Invalid range3: any alphanumeric value

Orthogonal Arrays: Above two techniques are used only for single field. For different combination of multiple fields orthogonal arrays are used. For example if there are 5 fields on a screen then orthogonal arrays should be used to come up with minimal test data required to cover maximum test functionality. There are various tools like AllPairs which generate test data for combination of fields. AllPairs is a very simple and free to use tool which reads data for each field from file and generate test data file.

Finally some test cases should be created based on experience. Some of the examples are:

1. If field accepts alphanumeric values then some test cases for:

                a. Special characters

                b. Escape characters

                c. Specific special characters combination like ';-- (database comment)

                d. leading/ trailing blank spaces

                e. foreign characters

and some other project specific special requirements.