If there are two stakeholders who have different understandings of the requirement, then there may be more. What about how you interpret the requirement, from the perspective of a tester? Or how about the customer? Or even the end-users of the product? If the requirement is ambiguous to the point where two people who (in theory, anyway) are working closely together to deliver the product have different interpretations, I'd consider it likely that there are other interpretations out there.
I'd expect that the QA team is watching out for this by being involved in every step of the process. Looking at quality assurance as post-development testing is insufficient to deliver a quality product. Looking at the requirements as another pair of eyes to find ambiguity or asking questions about how to go about testing the requirement early in the development process is important for setting the team up for long-term success.
If you're already to the point where the work is ready for integration and testing, yet there are disagreements about the requirement, the first step would be to figure out what the requirement truly is. Someone has to make the final decision. One option would be for someone to contact the customer or an end-user and get clarification as to what the need actually is. In some cases, the project manager or product owner may be empowered to make the decision and provide the voice of the customer, in which case their word is the true requirement. Once you have the true requirement, the tests are built to exercise the system within the bounds of the requirement and demonstrate that it fulfills the need.
Depending on what the true requirement is and how far the design and implementation is from that requirement will determine the following steps.