As organizations embrace mobile QA, they will need to develop their quality standards, teams, and approaches for mobile QA as they do for traditional QA. Poor or nonexistent mobile QA strategies and tools have led to many myths taking strong roots in organizations. Brian Bernknopf explores the truth about five of the most common myths.
Mobility is the next frontier of the enterprise. As consumers in a digital age, we are driving change to our employers, business partners, and even clients to allow for the same flexibility, speed, and interaction with data that we have in our personal lives. This applies to device usage as well as software development, access, and usability.
Not so long ago, we were considered “innovative” to ask for a VPN to access our email from home, and now we are shifting to a bring your own device (BYOD) community workforce. The expectation of technology and its capabilities has surpassed the enterprise’s ability to roll it out quickly, maintain, and customize it.
According to Cisco's "Visual Networking Index Global Mobile Data Traffic Forecast Update," by the end of this year, “connected devices” will outnumber people on the planet. The increasing popularity of using mobile devices to access data and information is changing the definition of quality as it applies to business users and consumers. Even in the past few years, being able to access a web portal via a smartphone was acceptable, but now those sites must be optimized for both the available real estate, gesture and multi-touch, and (depending on the business use) take advantage of the features of the device itself. This often leads to the creation of mobile-specific portals and then, of course, to mobile applications. Whether it’s a portal or specific app, we have to provide our mobile workforce and customers high-quality products—fast! This is especially for the millennials. They have a mastery of the capabilities and the expectations to match.
The Changing Face of QA
While a broken website is often corrected in seconds or minutes, fixing a mobile application requires development time, app store approval, and often a user-initiated update. The role of a QA team assumes greater responsibility for the integration of hardware and software components of mobility, not to mention the even more important needs of reducing cycle time, cost, and effort while ensuring conformance to the latest standards and expectations of users.
In this mobile-driven economy, many enterprises lag in implementing a mobile strategy, let alone a mobile QA strategy. The mindset appears to be: “I don’t have a mobile platform, so I don’t need a mobile application or strategy.” Yet, their employees and customers are accessing portals and sites via mobile devices and younger workers expect to be able to access email and data via their own devices. This will continue to drive higher expectations as the available consumer technology improves. Mobile QA strategies are not needed because a company has decided to build an application. They are needed because the lines between a mobile deployment and a standard deployment will continue to blur and eventually combine. Just like security, performance, and regression are now regular parts of our QA vernacular and process, they were not always. They were add-on testing cycles done when time permitted, and they have now become as critical as functional testing to today’s enterprise SDLC.
As organizations embrace mobile QA, they will need to develop their quality standards, teams, and approaches for mobile QA as they do for traditional QA. Unlike in a traditional QA program where functionality and UAT top the list of priorities, the core focus areas for mobile QA includes usability, security, and performance. For example, the most commonly requested features and functionalities in an enterprise mobile app are support for multiple mobile platforms, browser and native app support, security, and device registration and management. Organizations need to adapt to mobile QA practices while realizing that it is a moving target—a multitude of new tools and new mobile development and mobile testing techniques are introduced every week! Given the rapid pace of technology development and the increase in the number of connected devices, the complexity of tests continues to evolve.
Today, we are busy keeping up with the basic functionalities of mobile devices and changing OSs, but, tomorrow, with thecommercial arrival of augmented reality and the “connected home” becoming a reality, it will be the interplay of smart phones with TVs, cars, and appliances that will require interoperability testing on a scale we have not had to address previously. Imagine the test labs of tomorrow equipped with car infotainment systems, TVs, and appliances.
Poor or nonexistent mobile QA strategies and tools have led to many myths taking strong roots in organizations. Here is the truth about five of the most common myths.
Myth 1: I have a “traditional” website, I don’t need a mobile QA strategy.
Truth: Ask your children how they accessed the web today. If you have a publically available site, then it will be—or currently is—being accessed by mobile devices. This is easily tracked by the way. The impact of the lack of a mobile QA strategy (even if you only consider usability) can lead to poor user adoption, poor social reaction, and revenue leakage. Mobile QA strategies don’t have to be complex and tool-laden to start. Simple usability QA approaches can be implemented as part of your software development lifecycle (SDLC).
Myth 2: I need to buy every type of device and operating system for my organization.
Truth: There are many combinations of mobile devices, operating systems, and platforms, but it is important to understand the needs of your organization and accordingly zero-in on the right platforms and devices. For example, at this point in time, not all employees of your organization may be using mobile as part of their work needs; therefore, streamlining and focusing on a single mobility platform may be the right approach. Differentiating between what is supported and what is allowed within your organization will also help engineering teams. Moreover, the availability of tools and service providers has drastically reduced the cost and barriers to entry for the creation of mobile labs and mobile testing services. As with all QA justifications, the cost of a QA approach and strategy can be less costly than a failed application, lost customers, and poor feedback.
Myth 3: My third-party development team tests the apps, so I don’t need to worry about it.
Truth: While third-party developers are typically responsible for unit and functional validation, integration to the enterprise will still fall on the shoulders of QA teams. Integration, regression, security, and usability testing are all components of a robust mobile QA strategy. Most enterprise apps are not standalone, but are extensions of traditional functionality of our enterprise systems and, therefore, will require additional knowledge that comes from the existing QA teams. Integrating a mobile QA strategy into existing release management, QA practices, etc., is an important part of being flexible and able to change based on technology.
Myth 4: I am not creating the next Angry Birds; the application is just for my team.
Truth: Mobile applications are designed for a variety of purposes. The fact that the intent is not one million downloads in the first week doesn’t negate the need to ensure appropriate quality. There will always be a risk/reward equation, but the level of quality for mobile engineering is not dependent on the expected downloads of an application. Anyone can make and sell an application. The handset makers or operating systems owners do not always vet the applications extensively. As QA professionals, we must take a risk-based approach to all of our applications. Even if the application is for limited use, quality must still be addressed. Moreover, if the application is a limited-use app to start with, the investments we make in tools, resources, education, and process development should be evaluated against longer-term plans. The processes we put in place today do not always support the goals of tomorrow.
Myth 5: I need the one best tool for my organization.
Truth: The fast-paced mobile industry cannot stick to any single tool. Given the price and capability differences of the tools available in the market, there are a number of choices, but the good news is that we do not have to lock in to single decisions. As the prices have come down with market saturation and vendors offering more managed services, a multi-tool approach is often possible. As our application technology changes, our tools may need to change with them. Also, the increase in open source and alternative licensing models allow our QA teams to make point-in-time decisions, allowing for shorter time to automation for each application.
There may be more myths to discuss and, hopefully, many more truths to uncover, but this is an evolving landscape with a lot to learn. With the passage of time, the focus of IT on mobility will only increase and be directly driven by customer sentiment, experience, and the power of social media. Do not fall prey to the myths of mobile application testing. Get your applications tested early in the development phase. It is important to ensure that applications function smoothly, perform quickly, and work under all conditions.
