Visitor Monitoring Quality at the Speed of Mobile | Keynote

Quality at the Speed of Mobile

By Josh Galde | December 10, 2014

CATEGORIES: Mobile Quality

Mobile QualityHere’s a dilemma: If you wanted to find a company’s mobile testing professionals for native or hybrid apps, where would you look? In a QA department? On a separate mobile project team? Development? Your guess would be as good as anybody’s, because even though we’re fully seven years into the “mobile revolution,” companies have various approaches to mobile testing, and many are still trying to figure it out.

In some ways, it’s understandable, because native and hybrid app quality assurance is so different from the traditional desktop-centric process. The design and requirements process is different, the development tools and processes are different, the distribution systems are different, and the pace is light years faster. These factors can make it a challenge for traditional QA to incorporate mobile into its existing processes. And there are compelling arguments why the traditional QA process is not the ideal one for mobile.

The fact is that today, if you look for an effective mobile testing program, you find developers doing a (perhaps surprising) share of the testing. You find testing happening earlier in the process, and integrated with open source frameworks and tools. You see greater collaboration between dev and QA in mobile project teams. And you see QA professionals dedicated to the special requirements of mobile.

Two factors drive the complexity and flow of mobile testing. First is speed: To keep up with the demands of consumers and the marketplace, mobile releases more typically happen quarterly, monthly, or weekly, versus the annual or semi-annual updates of desktop apps. Second is diversity: The sheer number of mobile OSs, devices, and form factors is overwhelming.

To keep up with fast-track development processes, mobile testing has to start much earlier, be integrated with the open framework tools supporting development, and continue throughout the app lifecycle. Development needs to own unit and integration testing, QA needs to be involved during design-driven development (as the design and requirements process is so different) and own smoke and user-acceptance testing. All have to work together to ensure a user experience that delights customers every step of the way, that the apps work on all the core platforms, and that release schedules can be met.

It’s the “continuous quality” arm of continuous integration, or the “mobile quality” extension of DevOps. It’s baking testing and quality into the process instead of waiting for a bad review on an enterprise or public app store and then trying to fix it, which is a much more time and labor-intensive process — and visible to your entire world!

So what goes into a nimble, integrated, full-lifecycle mobile testing program?

  1. Leverage the cloud. Cloud-based testing provides access to an extensive pool of real, up-to-date devices without the need to manage physical devices and their contracts.  You need to be sure you’re testing on the needed breadth of the latest and greatest devices that are most important to your customers. And the cloud gives you centralized management so distributed teams can access everything: the devices, the test scripts, and the results.
  2. Integrate. Whatever your development approach, whatever your frameworks (e.g., open source like Selenium), development tools (e.g., different IDEs, SCM and Build), make sure your testing program/platform integrates seamlessly so that quality becomes core to the process, not an afterthought.
  3. Automate. While there will always be a need for manual testing, automation enables broader, deeper, faster testing at every stage of the lifecycle. Automated testing keeps quality high while also keeping up with accelerated release cycles. It’s reasonable to aim for 70 to 80% automation of a test program, and to include automation in development as well as QA. Durable automation that is object-based is a must for this! Anyone who tries to get by with less will be making compromises on quality.

Mobile quality for native and hybrid apps is a discipline unto itself because this core part of mobile is not just an extension of the Web. Most importantly, it’s not an add-on or tangent to traditional QA. Best practices are for it to be integrated into development tools and processes and to be carried out through the full app lifecycle, in step with the accelerated pace the marketplace now demands. Get engaged during the design process. Test early and test often — it’s not just for QA anymore. It’s part and parcel of the entire app development and delivery discipline, if those apps are going to meet the high expectations put on them.

Back to Top