Problem solve Get help with specific problems with your technologies, process and projects.

Should QA check changes from outside the requirements document?

Should QA be checking over requirements changes from sources such as emails, Excel spreadsheets and other documents besides the requirements document?

Should QA be checking over requirements changes from sources such as email communication, Excel spreadsheets and other documents besides the requirements document? I ask because I have been directed to check all these, not only the requirements document, as the team does not have enough time to update it.

Should quality assurance (QA) check requirements changes from outside the requirements document?

I'm tempted to respond simply, "Yes."

If I put on my consultant hat, the response becomes, "It depends."

Since I'm in my Ask the Expert role, I'll elaborate and explain a bit more.

Both requirements and proposed changes to the requirements should be checked for clarity, completeness and correctness. The questioner is right on in recognizing that requirements, and especially changes to them, may be introduced in a variety of manners, many of which may not be readily identifiable as requirements/changes.

Articulation in some document at least gives you a fighting chance to realize that a requirement may be involved. The bigger recognition problems often occur when QA isn't even in the loop, such as requirements changes that are made de facto in the software or procedures without ever being described explicitly.

Once a requirement/change is recognized, the next issues are who and how to check it. One cannot assume an organization has QA or, even if they do, that QA is both charged with and positioned to check requirements. In many organizations, if requirements are checked at all, it's usually in a one-time review of the entire set of requirements.

QA may or may not be participating in the review, let alone leading it. After all, many groups which are called "QA" are actually quality control (QC), responsible mainly for dynamic testing of developed code. It's relatively rare for testing groups to be involved in requirements reviews.

Some organizations may perform several requirements reviews, typically with a review as part of each development iteration. I think it's much less common for individual requirements changes to be subjected to review, especially by QA. Many organizations do have a change control board which must approve requested requirements changes before they are made, but such approvals are likely to be from a business perspective and may not include the types of checking QA or a requirements review ordinarily would focus on.

Besides just recognizing existence of a prospective requirements change, the other key issue is how to check it. QA's main concerns are often limited to whether the requirement is clear enough to be testable. In many ways, lack of testability is merely a distracting false issue. Moreover, while clarity and testability are important and necessary, checking them alone is not sufficient since it does not assure the requirement is correct; and of course there is no checking of overlooked requirements. Such shortcomings are even more likely when checking individual requirements than in a typical review of a group of related requirements.

All this is not to say QA, or others, should not review individual requirements changes. It's good to catch requirements problems as soon as possible, including change by change, but the checking needs to be for wrong and overlooked requirements as well as for clarity/testability.

This was last published in April 2009

Dig Deeper on Penetration Testing

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.