Summary: The quality assurance process involves a large team of players that go far beyond those that are actually developing the software. Continuous input must be recognized from multiple stakeholders throughout the entire project lifecycle.

QA Involves Multiple Stakeholders

Quality assurance (QA) testing should ideally be a highly collaborative process. It is a common mistake to believe that the QA process is strictly the domain of the coders in the IT department; in fact, it involves multiple stakeholders throughout the entire enterprise.

True quality cannot be achieved without continuous input from end users, management, and the CFO. This input must be solicited before the project even begins, for the purpose of creating a requirements document; further input must also be obtained during the process; and lastly, input is obtained after the product is delivered to ensure that it has met expectations for everyone involved.

Time Constraints
Unfortunately, time constraints work against the notion of quality. While the IT department and developers may wish to deliver the best quality product possible, the marketing department may have other ideas—and will often exert pressure on developers to deliver a product before it is really ready. As a result, the all-important quality testing process is often incorrectly seen by some people within the enterprise as a roadblock rather than a method to ensure quality.

The most ideal situation, in an efficient shop that is adhering to quality standards, would be to engage those who are exerting pressure in the quality process as one of the major stakeholders.

Getting Buy-in
Areas outside of the IT department may acknowledge that they are truly stakeholders in the development process, but only in the sense that they will benefit from the final outcome (in terms of having a tool to use, a tool to sell, or a tool to pay for). The big mistake is only acknowledging that they will benefit from the product, but not acknowledging that they are responsible, along with the developers, for the actual production of the product.

Even if those stakeholders do not write any code, their responsibility kicks in early in the process by providing clear and detailed requirements to the developers, cooperating in periodic reviews and end-user tests, and finally, providing feedback for the final product to help determine whether the product meets expectations and accomplishes the goals it set out to accomplish.

Team Approach
In determining requirements before development, and evaluating effectiveness afterwards, there may also be a temptation to isolate stakeholders and gain their feedback through email and memos. This too, is a critical mistake; as the requirements determination and evaluation processes should rather be collaborative in nature.

In executing these two vital steps, stakeholders should be able to communicate with one another, and have at least one joint meeting whenever possible. The meeting of multiple stakeholders will help to promote a more holistic view of the product, not only by each stakeholder, but by the developers as well. Each stakeholder has a particular concern, and particular features that are most important to them. Making every stakeholder aware of the concerns of every other stakeholder will promote better quality by ensuring that everyone involved is aware of all the issues—not just the ones they are concerned about.