QA testing should ideally be a highly collaborative process, but it’s a common belief that the QA testing process is strictly the domain of coders in the IT department. However, 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.
Unfortunately, time constraints work against the notion of quality when it comes to QA testing. 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 QA testing process is often misconstrued by some as a roadblock rather than a method to ensure quality.
The most ideal situation in an efficient shop that is adhering to high QA testing standards would be to engage those who are exerting pressure in the QA testing process as one of the major stakeholders.
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 providing feedback for the final product to help determine whether the product meets expectations and accomplishes the goals it set out to accomplish.
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 QA testing by ensuring that everyone involved is aware of all the issues—not just the ones they are concerned about.