Does it make sense to give signoff authority to testers? Should a test teamJust test features, issues, etc, and simply report on a pass/fail basis, leaving it up to others to act on those results, orHave authority to hold up releases themselves based on those results?In other words, should testers be required to actually sign off on releases? The testing team I'm working with feels that they do, and we're having an issue with this because of testing scope creep -- the refusal to approve releases is sometimes based on issues explicitly not addressed by the release in question.
Should testers approve releases, or just report on tests?
testing;release management;process
Most places I have worked the QA people do have some sort of sign-off step, but do not have final authority on if the release proceeds or not.  Their sign-off represents that they completed the testing expected by the release plan, not that the release is flawless.Ultimately QA != the business and the business needs to decide if they are OK with deploying the code in the current state or if the benefit outweighs the downside or whatever.  This is often done by clients or stakeholders immediately prior to deploy and is often called User Acceptance.If your QA is also your User Acceptance group then there is the potential that they do have the authority to define your release candidate as unacceptable, but if you are getting this over issues that are out of scope to the bugfix/iteration/sprint/change request/whatever you bucket your time in, then the Project Manager or the business line stakeholders needs to have a come to Jesus meeting with the QA team.It is fine to report on preexisting defects or unintended outcomes of new requirements, but if it is out of scope and non-disastrous it is generally not acceptable to label it as a blocking issue. It goes in the backlog for the product owner to prioritize like everything else.