How to conduct QA testing in a changing app life cycle landscape

Quality assurance testing has always been a key part of the software development life cycle, but today it's more important than ever. The pressure is on to design, develop and distribute enterprise or consumer-facing apps as quickly as possible, and traditional modes of QA testing need to be addressed. No developer or business wants to hold up the introduction of a new app with redundant testing, but releasing a piece of software before it is ready can alienate users and diminish the program's long-term profitable potential.

The nature of applications, especially self-service reporting tools in enterprise environments, is in the midst of change. As CNNMoney contributor Adrian Covert recently wrote, the era of "polished and perfect" software is effectively over.

"In the 1990's and early 2000's, [sic] a company would only release software it spent years poring over and refining," Covert said. "Users would buy and install that software, and that was the end of the process until a fundamentally new version came out -- save for a couple of minor updates that relatively few users would install. If there were any major problems with the software, the consequences could be catastrophic. That's no longer the case."

Modes of digital distribution have changed substantially, Covert observed, with mobile devices and forums where users can engage directly with developers and companies meaning that fairly significant fixes and overhauls can be administered after the application's first technical release. App users now live in an era of constant beta testing, whether or not they realize it.

Adjusting expectations and QA testing
However, this new paradigm does not give software developers and app vendors free reign to distribute beta versions of apps well before they're ready, assuming they have a tacit understanding with users that the "correct" version is yet to come. An entrenched software titan like Google or Apple may be able to get away with beta iterations - even if they receive some backlash - relying on their brand value to assure customers that improvements can and will be swiftly made. A more unknown company doesn't have this luxury. Furthermore, an organization deploying apps to its own end users has to remember that these employees are accustomed to high-functioning programs they use in their personal lives. A dysfunctional beta version with a promise of future improvement could put off users, delaying or squashing adoption and ensuring the app will be hard pressed to gain the traction the company had foreseen.

This means that QA testing's expectations have to be adjusted. Developers may need to infuse QA testing more directly into the software development life cycle, relying more heavily on languages like HTML5 and processes like agile development that support more direct, piecemeal tinkering. Programmers need to build up their QA testing expertise, instead of leaving this part of the process to a specific professional or consultant.

"[There's a] greater integration of QA and testing within development itself," said Dave Parkinson, Sony Computer Entertainment Europe director of global first party QA, in a recent interview with Develop Online. "We're potentially moving away from the premise of a completely independent, centralized QA organization. We're seeing tighter, more intimate levels of engagement with development and test. Because really testing is a discipline of product development."

As Parkinson pointed out, the further integration of QA into the software development process is part of the effort to build bridges between programming and business logic. Apps needed to be designed for end users and tested with the limits that the those employees will bring with them as they use the application. Eliminating issues through QA testing at every stage can get applications out faster and designed for more productive, immediate adoption.