The main purpose of user acceptance testing is determining whether the application under test is fit-for-use by the business user (with a focus on functionality). It is good practice to involve end users in this stage of testing. Test strategy and test design are performed by QA.
A typical testing process in a large organisation (waterfall) goes through several stages:
Technology facing tests (by the supplier)
- Unit testing - testing small units in isolation
- Integration testing - testing if the units work together
- System testing - testing if the software as a whole meets the technical requirements
Acceptance tests (by the accepting customer)
- Functional acceptance test - testing the functionality against the functional requirements; this is the domain of testers, test analysts, test engineers, etc
- Chain acceptance test - testing the software in combination with the other systems it should interface with
- User acceptance test - testing with end users to validate that the software actually meets the users' needs
- Performance, security tests etc - final check on specific quality attributes
- Production acceptance test - run on the production environment after installation
After the software is deployed to production, the beta testers can start using it on their own devices and in their own environments.
Without knowing the details of the project, I don't think it is a good idea to jump from developers' tests to the end users. Typical end users are very good at telling whether the software is useful to them, but lack the skills and knowledge to perform a thorough test that includes edge cases, different flows, data combinations etc.