What requirements gathering and requirements management goals would you recommend to software testing managers...
I would not think of the software testing manager as being responsible for gathering or managing requirements. When I am defining responsibilities for roles on a team (think RACI), I consider the testing team to be a group that (1) consumes requirements and (2) provides feedback on requirements. I would contend that if someone with the software testing manager title is gathering requirements, then that person is playing more than one role on the team. The product manager, product owner or business analyst is the role that is responsible for gathering and managing requirements -- providing them to the members of the implementation team -- developers and testers.
That said, I believe there are responsibilities, with respect to requirements, that do fall on the testing team (and by inference, the software testing manager) -- because of the expectation of providing feedback to the team member who is gathering and documenting those requirements. In Waterfall projects, you see an explicit acknowledgement of this responsibility by the process-requirement of getting "sign off" from the software testing manager about the requirements.
Before the software testing manager signs off on a requirement, she should do the following:
- Assure that the requirement is measurable -- specifically, her team has designed tests (aka a test plan) that can concretely determine if the implementation has passed / failed to meet the requirement.
- Confirm that their interpretation of the requirement matches what the writer of the requirement intended -- through any number of active listening techniques (including getting the requirements writer to approve the test design).
- Agree that they do not see any logical inconsistencies in the requirements -- either gaps, ambiguities, or contradictions. People with a testing background think about things differently than people who do not. I've repeatedly seen members of the testing team discover requirements "bugs" that no one else on the project team caught.
Issues of shared responsibility can be tricky for some organizations. Ultimately, the writer of the requirements is responsible for writing measurable, complete, consistent, unambiguous requirements. When the team agrees, the software testing manager can be the person who "approves" that the requirements meet those criteria.
Dig Deeper on Topics Archive
Related Q&A from Scott Sehlhorst
Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing. Continue Reading
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype. Continue Reading
Scott Sehlhorst offers strategic guidance on how to approach application portfolio management with a focused vision. Continue Reading