Some companies, for better or worse, leave the requirements-based testing of their internal-facing software to the end-users.
Unless project management is clear about the responsibilities of the testers, you can run into a "tennis" situation. This situation occurs when the tester believes their goal is to find something wrong with the product. This is attractive to the end-user because it means that as soon as they find something they don't like, they can stop testing until the developer comes back with the problem fixed. After all, testing isn't their job, they have real work to do.
What is needed instead is more like bowling. The tester sets up the pins (test cases), and the developer knocks them down. How pany pins are in a frame, and how many frames are in a game, etc, depends on your development lifecycle.
Developers can sense when they're stuck playing tennis, but they sometimes describe it as shifting requirements. There is a distinction to be made, however. With requirements drift, you're still bowling, but they're moving the pins around on you, or adding pins to the frame.
It is important to define responsibilities at the launch of the project (if not earlier), and to be clear about how the development lifecycle is going to be structured.