I have noticed that many development teams automate UAT with many test cases. It's things that users care about, but the tests are not done by real users. For example, automation will test whether this is true or not: "When user password is incorrect, the show error message". This is an excellent practice, but I don't understand why this is called UAT?
The definition of UAT includes statements like "... software is tested in the real world by its intended audience" and "In UAT, users are given the opportunity to interact with the software before its official release"
Even the name itself says it User Acceptance Testing (The user has to accept it, not a developer on behalf of the user)
This is very different from the UAT tests that I see which are often:
- Written and maintained by developers (not end users)
- Automated in a "lab" environment, not a real one
Again, I'm not saying that there is anything wrong with it, it's just confusing to me that it's called UAT. The only explanation that I could come up with on my own is that real users are busy, bored, and uninterested in doing real UAT, so developers have to fill the void by creating virtual users that test the system. Would a better way to think of it be pre-UAT, or simulated-UAT?
The related question is, how is "real" UAT possible in a CI/CD environment? The automation and short cycles seems to make real UAT infeasible. For modern CI/CD styled SaaS applications does anyone really do UAT with real humans anymore?
What terminology do QA people use when talking about "real" UAT vs "simulated" UAT?
Am I understanding UAT, its (mis)use by necessity, and its limits correctly?