This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Mobile software testing and requirements require planning: Read more in this section
- QA testing: First mobile steps
- Requirements specs for mobile apps
- Fixing broken processes for mobile apps
Explore other sections in this guide:
- 2. - Building security into mobile connections
- 3. - Creating usable mobile app dev lifecycles through teamwork
When I joined TechTarget and began writing about the software lifecycle, the first topic I tackled was mobile testing.
Those initial pieces for SearchSoftwareQuality explored how mobile testing differs from testing desktop and Web applications. Mobile app testing has to accommodate many different devices, operating systems and updates to those operating systems -- a much wider mix than desktop and Web apps. Add to this a broad range of locations and connectivity conditions under which mobile apps are deployed, and a new testing reality emerges: Unless time and money are no object, mobile apps cannot be tested as exhaustively as their desktop and Web cousins.
The mobile testing challenge is so daunting -- not to mention a dominant theme on conference agendas -- that it seemed to me the earlier stages of the mobile software lifecycle remained more or less the same as those for Web and desktop apps, give or take a new programing language or two.
Over the last few months, I've been doing some serious investigation into the issues facing mobile developers upstream of the testing process. Over 50 interviews with mobile experts and at least a dozen stories later, I discovered testing isn't the only radical change in the mobile lifecycle. The planning and coding stages are also undergoing major shifts and makeovers.
In this installment of Quality Time, let's look at the changes occurring during the planning and coding stages of the mobile software lifecycle.
The mobile applications emerging today are enterprise applications first, and mobile applications second.
Development of native mobile applications, such as those written in objective-C, the programming language for Apple's iOS operating system, will certainly continue. But they will most likely be produced by mobile consultancies and not enterprise development teams. An example might be iPad applications used by medical staffers in a hospital setting.
What will happen with cross-platform tools for mobile development -- where a single codebase is deployed to different mobile operating systems -- is anyone's guess. These products still require a lot of customization and coding for each platform, and I'm not sure where or how these tools will fit into the mobile app development process.
Mobile app planning
Defining application requirements -- specifying at the outset of a project what the software should and should not do -- has always been a difficult, people-intensive process. Planning mobile projects adds new complexities. First among them is the need for user experience (UX) design skills. Mobile apps destined for smart phones with small screens and constrained keyboards change the rules for how an application looks and feels. Developers, who traditionally haven't given this issue much thought, can no longer crowd the user interface with icons or menus that aren't essential. How do they determine what is essential? In an ideal world, an enterprise mobile team includes full-time UX experts, but in the real world, teams seek out expert advice on the optimal placement of UI controls, effective labeling of those controls, designing workflows that mirror the most common use cases for the app, and learn how to conduct basic usability testing.
Another crucial step for mobile app planning is security. Of course, this is an ongoing concern for all projects; but mobile projects introduce new fears as employees demand routine mobile access to corporate data that once remained inside company firewalls. Mobile applications exchange data over insecure networks, and the devices themselves are easy to lose -- or steal. This means mobile projects must devise requirements that address how data will be stored and encrypted on a variety of mobile devices, in addition to addressing basic security testing and authentication and authorization measures.
These are just two areas where the mobile lifecycle is changing, and it will continue to evolve. Indeed, from planning and coding through testing and deployment, the challenges facing each stage of mobile projects are so steep, me and my colleagues at SearchSOA and TheServerSide have identified mobile application lifecycle management (ALM) as an emerging process distinct from traditional ALM.