There has been a question on twitter that I find interesting and have seen a few times in the real world.

Requirements only cover so much of the product performance. Testing only to requirements may leave the company, and the clients at risk. For example, there may not be a requirement that says a certain combination of inputs should not make the product fail in such a way to put the customer's safety at risk. These things will require thinking beyond the requirements for the product, but extend to the application and potential misuse of the product. Testing is not all about meeting the requirements, though this is important from the contractual obligations and minimum level of expectations.


Ideally, there would be other ways to review these presumed defects. If the tester believes this to be a big deal, a severe failure that is plausible to happen in the field, they probably feel the need to push this discussion. What I can say, is that problems found in testing that is not part of the requirements often gets the response, "that will never happen in the field", but eventually shows up in the field. If the result of this non-requirement deemed defect, is harm in the field somebody should stand up for this, and that is probably the tester.


It could be good to sit down with the tester and quantify the risk due to this "defect". Find a way to give the defect its day in court - so to say. Assess the issue for impact beyond the requirements but in real life.