Guest Post By:- Zap-Fix
While there are many aspects of the application life cycle that remain constant regardless of the platform, whether it be mainframe batch, online, client-server, web and mobile, there are some huge differences specifically related to mobile applications.
First is the user interface. It is no longer a GUI, it is NUI (Natural User Interface); finger-based input. This includes multi-touch gestures on virtual keyboards and even extends to voice commands.
There are some things that are cool about NUI, including new ways of triggering application events, such as Swipe/Flick to scroll and pan, Pinch/Stretch to zoom, Tap to click, even Shake to do whatever makes sense to the app.
But everything comes with a price and there are some things that are not so cool with NUI. Small screens make typing burdensome whether the keyboard is virtual or not. Soft keyboards often cover widgets and controls in ways that limit normal interaction. Navigation is challenged by small pieces of information always around your fingertips.
Then there is the environment. True multi-tasking is limited. The OS can kill background applications at any time. Mobile apps are more prone to interruptions, such as incoming calls, or switching to other applications.
Top 7 Quality Issues with Mobile
Pressure to get to market leaves many application developers choosing to hit the ‘fast forward button’ on their testing process, as it occurs at the end of the cycle. Small glitches, crashes and malfunctions often get overlooked.
2. Inadequate processes
Mobile application testing is still in the infancy stage and to be honest, many QA teams haven’t defined new processes to effectively test mobile applications.
3. Lack of test plans
Traditional application testing plans are unfortunately still the guideline amongst many QA’s and mobile application testing requires a fresh approach which few have implemented and/or are still learning.
4. Data Entry
Mobile devices are small (and getting smaller) and many have touch screen or miniaturized keyboards making data entry to be an untimely or a more lengthy process.
5. Validation issues
Understanding the results of processes and test scripts require articulate attention to detail on a mobile device and teams are still learning how to do this.
6. Lack of physical devices
Gaining access to all the permutations for Android, Blackberry and iPhone could be an endless quest as each quarter turns out a new operating system, leaving developers as well as QA’s scrambling
And lastly and the most important…
7. Lack of test automation
Existing industry-leading test automation tools are restricted by object recognition limitations. Most tools rely on open and published APIs to obtain the discrete properties of a control. Mobile platforms do not provide the traditional APIs, rendering your favorite tools useless in mobile. This translates to the bulk of mobile application testing being relegated to manual testing. Without test automation, quality suffers in mobile initiatives, in all aspects.
Enabling Test Automation for Mobile (automated testing for iPhone, iPad and Android)
In early 2011, ZAP Technologies launched a solution called ZAP-fiX (ZPX). Based on ZAP’s close ties to HP/Mercury since 1998, ZPX is provided as an add-in to HP’s ALM Suite, most notably, QuickTest Professional, Quality Center and LoadRunner
In its simplest terms, ZPX performs deep object recognition without relying on APIs. Through a simple wizard known as the Object Collector Workbench, ZPX populates the QTP Object Repository in the same way that QTP does in the environments it currently supports. Once Object Repository is populated, the QTP user can go about business as usual, leveraging the tool’s full capabilities and the way it was designed to be used.
ZPX was also designed to run tests on the physical device. Although it also supports testing via emulators, it is critical to test mobile applications in the real environment in which it runs. As we have come to know, emulators are great, until we find the differences between the emulator and the real device.
To accomplish this, another component of ZPX is the Viewer. The ZPX Viewer is Windows-based allowing the QTP user to see the real-time current dynamic state of the display for the Device Under Test (DUT). It also accepts input from a standard full-sized keyboard and mouse to interact with the Application Under Test (AUT). As illustrated here, the QTP user is looking at the current page on an iPad.
One of the hallmarks of ZPX is the tight integration with QTP, making the learning curve minimal. If you know how to use QTP, you know how to use ZPX.
The level of integration is best stated with the following illustrations:
Keyword View and Expert View
Just as you use QTP today, you can toggle back and forth between Keyword View and Expert View
The Data Table in QTP is fully available with ZPX and operates exactly in the same way.
Once objects are collected, they are fully available in Object Repository for analysis and manipulation.
Test results are provided in the same way QTP does today. Notice the familiar purple rectangle highlighting the control on focus (OK Button) in the test steps.
ZPX is not just for automation.
As the unique ZPX Viewer not only displays the device, it also allows interaction. Thus ZPX is the ideal platform for simplifying manual testing. Illustrated below is an example of ZPX being used with QC Sprinter. In this example, we are leveraging Sprinter’s Mirror Testing feature to simultaneously test multiple instance of AUT, even on heterogeneous platforms. In this example, the test is being driven on the iPhone and automatically replicated on the Android.