Test recommendations for smart phone and tablet starter stores

You can efficiently test smart phone and tablet starter stores by following the test implications and guidelines. These recommendations apply to the mobile web storefronts and mobile applications.

Before you begin, ensure that you are familiar with the following concepts:

Testing mobile Web starter stores

Follow the same testing approach and strategy as the Aurora starter store and Elite starter stores, as mobile Web starter stores follow the same development architecture. For more information, see Creating a high-level functional verification test plan.

In addition to performing test verification against storefront use cases, the mobile channel also contains the following areas that require test verification:

Different operating system stack levels on the mobile devices.
Different browsers available for the mobile devices.
Change in orientation of the mobile devices.
Features on the storefront JSP files that might trigger native functionality on the mobile devices, such as GPS, voice recording, and camera for barcode scanning.

Depending on hardware resources, for example, the number of available smart phones and tablets, a test team can run a percentage of the mobile web application test cases on a computer. This is achieved using a desktop web browser and changing the user agent of the browser to simulate accessing the web site on a smart phone browser. This technique is also helpful for regression test cases and automating test assets for repeatable tasks.

Testing mobile applications

The mobile hybrid application contains the web application, wrapped by a native shell. Therefore, many of the functional tests performed against the web application implicitly validate the same test flows on the hybrid application. This results in test savings in this area.

Full test coverage on mobile hybrid applications is needed against all the functionality that is provided as part of the native shell. This coverage includes the following functionality:

Triggering the native GPS using the store locator.
Triggering the local phone address book.
Triggering the phone camera using barcode scanning functionality.
Triggering voice recording using voice searching.
Triggering application updates from the Worklight server.

It is recommended that the test team runs a representative subset of the web application test cases against the hybrid application, with full test coverage of all the features provided by the native shell in the hybrid application.

WebSphere Commerce requirements

To be more focused on testing hybrid mobile applications, your WebSphere Commerce server should resemble the following setup:

WebSphere Commerce should be on Version 7 Feature Pack 6.
WebSphere Commerce should have Extended Sites and AuroraMobile published.
WebSphere Commerce search must be enabled to test most of the search-related functions and end-to-end flows.
The hybrid application should be deployed using a Worklight server. For more information, see csmmobileappworklight.html.

Testing native features

For functional verification testing where the test flows include integration with native mobile phone features, it is recommended that test runs are performed against an actual mobile device. There are known differences between mobile devices, even when they are running on the same operating system. For example, differing hardware specifications, or branded customizations against the operating system might cause differences in store behavior. For more information, see the Limitations section of Smart phone and tablet starter stores.

As a baseline, a test team can also use a mobile emulator to run functional verification tests to serve as a comparison between the behavior on a particular phone, and the expected behaviour from the operating system.

The following sections detail specific native features that integrate with the sample mobile starter store available in WebSphere Commerce:

GPS details for store locator integration for Android devices

To test the store locator feature, the emulator must support GPS features. Emulators use simulated GPS, with the geo fix command used to set the geographic location. This can be performed from the client side. That is, from the phone or emulator.

To enable GPS on phones:

Go to Menu > Settings > Location & security.
Select Use GPS satellites.

To enable GPS on simulators (using AVD):

Ensure that the Android Virtual Device (AVD) platform target contains the Google API and is set to a minimum API level of 8.
Run the following command to open the emulator in a telnet session: emulator -avd avd_name, , where avd_name is the name given to your AVD.
Confirm that the Google Maps application is installed in the AVD.
Run the following command before using the store locator function: command : geo fix -79.33300 43.85100. These coordinates return store locator results near Toronto, Ontario, Canada.
If searching for stores based on your current location and GPS is disabled, the application displays an error message stating that the GPS is disabled.
For more information, see Download and install the Android SDK and Using DDMS: Emulating phone operations and location.

Store locator

The store locator uses Google Maps to locate and view store locations. When you open Google Maps, it searches for GPS satellites automatically if GPS is enabled on your phone. A blinking satellite icon in the notification bar indicates that Google Maps is searching for GPS satellites. A steady icon indicates an active GPS satellite connection.

Address book

The phone contact list is used to import the address details of a shopper.

Note:

If the contact from the phone contact list contains incomplete mandatory fields, the application adds a hyphen (-) to all those fields and the shopper must update them during checkout.
If there are no contacts in the phone contact list, shoppers can create a new contact with the address details, with the information reflected on the shipping and billing page.

Barcode scanner

The phone camera is used to scan barcodes or QR codes, provided the device contains the prerequisite barcode scanner application.

If the barcode scanner is selected in the application and the phone does not have it installed, the Aurora Mobile application displays an error message stating that the scanner application was not found.

Worklight Server application update

Worklight server allows for remote management of deployed applications, including forcing an application update, forcing a complete reinstall, and disabling an application. When these changes are made in the Worklight Server setting, launching the application enables a popup at the launch screen, with the appropriate action to be taken by the shopper.

Scope for automation

Automation is critical to ensure that product quality remains at a high standard. Whenever there is an update to your existing mobile application, you must run regression tests to ensure that all existing features are working correctly and are not affected by the new code changes. If this was manually performed for every update, it would be at a high cost. Therefore, automation is necessary for functional verification test.

The mobile channel can be separated into main areas:

Mobile web application storefront JSP files: This area is automated.; For mobile web application storefront JSP files, automated test cases can be written in the same manner as described in the WebSphere Commerce Starter Store companion assets using the provide automation framework. This is because it is essentially an online storefront that is accessible through a web browser. Repeatable automated tests can be run using any WebKit-enabled browser and by using automation tooling such as Selenium.; By running repeatable automated test coverage against the mobile web application storefront JSP files, this allows a high level of test coverage against the mobile web application channel, and store web flows with the mobile hybrid application.
Native shell on the hybrid application against the different devices: This area is not automated.; The native shell must be tested manually. However, the mobile web storefront JSP files displayed within the hybrid application shell can be automated.