I just had a project manager and developers request we use end-users for User Acceptance Testing. They want end-users to try and break the software prior to launch. This really caught me off guard. From my experience this is what beta testing is for and is not the role of UAT. I think you beta test for whatever duration need to have whatever level of confidence you want prior to release. I think this type of testing lives in QA and is not best performed with end-users.

Any thoughts? Thanks.

2 Answers 2


UAT is typically used for functional acceptance testing in waterfall approach. That is, a business analyst has taken the user input in coming up with the specs, or a set of feature requirements at the beginning of the project. The users will now verify that the system behaves as expected based on the feature requirements.

Questions like:

  • Does the system do what I want it to do?
  • Does the system behave in the way I expect it to?

Are valid and should be assessed in UAT.

Asking the user to "try and break the software" goes against requirements for UAT. You're asking the user to not behave as a user, but as a tester to go through atypical edge case workflows.

Users aren't testers. They're not trained in proper QA methodologies. So they're likely not going to cover all the test cases and bugs will slip through. But asking them to try, you've also told them to forget about their normal use cases... which means they're also not acting as end-users. So you effectively end up with poor testing in both cases.

So please have dedicated QA for your product and have users focus on functional testing.

  • Nightning, thank you for your thoughts. Very to the point, "Users aren't testers". Well said.
    – TheArtOfUX
    Commented May 5, 2015 at 20:38

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)

  1. Unit testing - testing small units in isolation
  2. Integration testing - testing if the units work together
  3. System testing - testing if the software as a whole meets the technical requirements

Acceptance tests (by the accepting customer)

  1. Functional acceptance test - testing the functionality against the functional requirements; this is the domain of testers, test analysts, test engineers, etc
  2. Chain acceptance test - testing the software in combination with the other systems it should interface with
  3. User acceptance test - testing with end users to validate that the software actually meets the users' needs
  4. Performance, security tests etc - final check on specific quality attributes
  5. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.