To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
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.
|
