The rebirth of quality assurance

Traditionally, quality assurance was viewed as the final step in debugging software before deployment. In this column, Tim Landgrave argues that current trends dictate an expanded role for QA.

Some organizations view the quality assurance (QA) group as the gatekeeper for applications as they roll into production. In fact, in most organizations, the QA group is a set of developers who have been given the unenviable task of testing someone else’s code to see if it breaks. And the tests follow scenarios given to them by the program designers and are naturally influenced by the biases of the tester. In many organizations, unless QA “signs off” on the application, it doesn’t get deployed. Unfortunately, this minimizes the importance of QA as part of the software process and focuses instead on a single function—testing for bugs. In this article, we’ll look at what functions are performed by a robust QA role and why companies are beginning to increase their focus on deploying quality software.

What is QA?
In companies that take QA seriously, the QA functions extend well beyond just bug bashing. Simply put, QA engineers are responsible for ensuring that the deployment of a software product doesn’t create a huge increase in support calls resulting from usability, scalability, or stability problems. Usability problems generally stem from poor interface design. Scalability problems are the result of inadequate design or testing for the assumed deployment environment. Stability problems can be caused by either faulty code development or poor testing methodology for the universe of potential deployment platforms. An experienced, well-staffed, well-trained QA department will reduce or eliminate all of these problems.

Many companies decry the QA function as “too expensive” or “a roadblock to release.” The leaders in these organizations fundamentally believe that it’s cheaper to pay for back-end support for the release of a shoddy product than to spend the money up front to get it right the first time. This faulty theory ignores both the cost of software reengineering to fix problems that don’t get caught before release as well as the ultimate cost to the company’s reputation for releasing “buggy” products. (Polaris Software is the poster child for the demise of a company for its ignorance of QA standards. Polaris, maker of PackRat software, disappeared from the software market after two bug-ridden releases. The company shifted its QA budget to marketing in an attempt to overtake personal information management [PIM] market leader ACT!)

But if QA isn’t just about killing bugs before release, then how does QA become part of the overall software development process? Designing for usability and scalability starts with a functional specification, not with the first line of code. Involving QA in the development of the initial functional specification allows the QA engineers to look at the key interface design issues before developers put together the first screen. By understanding the intended end user and deployment environment, QA can begin developing testing scripts for user scenarios as well as automated testing routines that exercise the software to expose potential scalability issues. Many of the stability issues are also exposed by stress-testing the software with test scripts. Unless QA gets involved at the very beginning of the process, there’s not enough time to develop adequate automated testing routines.

As developers begin working on their “units of work”—whether these are screens, database scripts, components, or Web pages—the developers will perform simple “unit tests” to ensure that their piece works by itself. QA, on the other hand, performs system testing to make sure that all of these units work together when combined into a subset or a complete implementation of the system. Testing the interaction of the components, system interfaces, and user interfaces requires a thorough understanding of how the system will ultimately be deployed and used. QA becomes the collector of this systems interaction data and, in a well-tuned organization, gives feedback to development teams early in their development cycle, helping them to avoid costly code rewriting or system redesign. A well-oiled QA machine clearly saves companies money.

Why QA is increasing in importance
QA becomes more important as the size and complexity of the system increases. Where a dedicated QA department may be overkill in a company with three developers writing systems for small businesses, it’s a necessity in large corporate development shops or large systems developers writing programs intended for mass distribution. Now, imagine a scenario where the company and its developers basically lose control of when and by whom its code can be accessed. Without QA, that situation is quite plausible.

Once companies begin exposing their internal systems to business partners and consumers at large through XML service interfaces, the necessity for expert QA engineering for all applications becomes critical. The QA function de-emphasizes usability (since the interface is for developers rather than users and is well defined) and increases emphasis on stability and scalability while adding a new area where exhaustive scenario testing becomes imperative: security. Existing QA teams will need to beef up their knowledge of security issues, technologies, and testing methodologies in order to be effective in this new paradigm. Once you “open the barn door” to outsiders using your interfaces to access your data for (what you believe is) controlled access, the importance of QA on your development security mechanisms should be obvious.

If you don’t have a dedicated QA function now (and a bunch of former developers sitting in a corner with a rubber stamp doesn’t count), it’s time to explore adding it. If you’re too small to add one on your own, look into some of the outsourced QA services that are available. The shift toward a Web-services world will shift the onus for system creation, management, and maintenance away from the designers and developers of the Web services themselves and toward the QA, deployment, security, and operations teams. It’s time to get ready.

Share your QA experience
Is the QA function changing in your company? How have new access and security issues affected your QA requirements? Send us your comments by e-mail or start a discussion below.


Editor's Picks