Editor’s note: Last week we brought you the first half of the “7 Best Practices in SQA Mobile Automation”. If you missed it, you can find it here.
To recap, within this post I presented the first 4 of the 7 best practices from my perspective:
1. Premeditate Your Architecture
2. Get Something ‘Out There’
3. Separate the Impractical
4. Maximize Coverage, Minimize Devices
Hopefully you’ve had a chance to digest the information. And, without further delay, here are the remaining three tips:
5. Leverage Mobile Automation Tools
The wide array of screen resolutions, screen sizes, operating systems and manufacturer customized OS modifications create an environment where the number of variables which require testing can manifest into thousands of permutations with potentially exhausting upkeep. Utilizing a third party automation tool to avoid routine maintenance of devices, complications of plan contracts, and simplifying the process of getting hands-on with the latest and most popular devices becomes a must-have.
There are multiple Mobile Automation tool suites available which alleviate the costs and consolidate some of the major complications that arise when it comes to acquiring, maintaining, and testing mobile devices. Finding the best software suite for your purposes will depend largely on the scope and goals of your testing effort. There are, however, some important features to look for in any such suite. Purchase, ownership, setup, and maintenance of mobile devices should be handled externally – simplifying the costs and complications brought on by broken devices, carrier contracts and the acquisition of new devices. Additionally, a tool should provide the ability to directly interact with devices on a hardware level – creating a closer analogy to real-world user interaction. Finally, a suite which builds everything, including hardware interactions with devices, in a single programming language such as Java, is crucial to developing a coherent ecosystem of scripts which will play nicely with checkpoint verification, external parameterization and script execution logging.
6. Define Checkpoints Upfront
Checkpoints are the state the phone is in: whether it is locked with a blank screen, a snippet of text on the home screen, or a page from your mobile application/website. Using an automation software tool to define checkpoints such as what the phone will look like before you run your script or after you’ve executed a step of your script, ensures the verification process while testing a mobile application.
Part of what saves time and money for upkeep and maintenance will be the act of creating ubiquitous scripts which can be applied to multiple devices and operating systems. Defining the checkpoints upfront enables a smooth process. The benefits of this practice reduce long term costs, making the implementation of a new phone or tablet as easy as defining the checkpoints unique to that device, and then pointing them to your generic scripts.
7. Parameterization: Separate Data and Logic
Creating data-driven scripts and external parameters allow functional areas to have one generic script that is more easily managed. If you are working with dynamic environments, using parameters to set variables used during execution, this will limit the number of scripts required to verify functionality. By limiting the number of scripts required to verify functionality, valuable time and money is saved. Altering parameters and data from a centralized, external database is faster and cheaper than searching for and performing code changes in a vast library of scripts.
And there you have it…the 7 best practices in SQA Mobile Architecture from my point of view. If you have any additional tips or discussion on my thoughts, please share your knowledge by commenting below.
Joshua Sawyers is a Consultant II at SDLC Partners, a leading provider of business and technology solutions. Please feel free to contact Joshua at firstname.lastname@example.org with any questions on this blog post or to further discuss mobile automation.