I work as a Vue developer and complete a number of tasks and move them to UAT on a regular basis, let's say daily.

So let me elaborate what usually is the process, and why I have mixed feelings about it being the part of QA.

Don't get me wrong, it is the client who decides whether the issue is solved and the solution is working, however the criteria doesn't always follow a clear pattern. Let me give you few examples.

Approximately one third of the times, there is a realization that something needs adding to the task, so requirements are being clarified, often some additional sub-task also gets added. It's normally a case, where the lack of the details initially was a reason however another reason that often there is at least one or few closely related tasks pending, and so the client spends a reasonable amount of time to go through them and realizes that there is something additional or slightly better approach is needed in order to solve them down.

There is an old version of the code where we often look to compare and treat it a source of truth. The old version is outdated and uses old-school JavaScript libraries (as Jquery), isn't really a modern and up-to-date codebase, but the system does work. The new version which we are about to release soon is basically a refactored version of the same, just it's done using typescript, VueJs, let call it the modern tooling & practices

It does actually mean, that there are some specific differences between the repos. For instance we don't really have a real backend as we take everything through soap (from their api) and we use molecular micro-service approach for API related stuff, so even the architecture is not the same. We don't use get requests, and we just utilise the router to change the urls in our spa application. So technically it is occasionally a case of incompatibility between the old and new repositories with no easy solution we can apply to solve these, usually tiny differences.

For instance, if there is a element in Jquery, which uses some sort of deprecated 3rd party library for validations, we wouldn't really be trying to mimic the design and all the details and very specifically compare and target that a new system should match it.

It's usually a matter to explain the benefits not to chase these small details in layman terms, as we should really be concerned about the functionality and general benefits, and not about the goal to make a like for like copy of what it looks now.

There are obviously other reasons why the tasks don't get passed through UAT, which are more less more related with the actual QA process as there maybe differences between local environment and production which we devs may have missed or it couldn't be seen, other developers may have committed some changes which caused issues, the infrastructure may have changed due to introduced dependencies and similar things

So to my understanding, the process really should be defined more as an iteration rather than individual status or criteria. Because, it is much easier to take an informed decision when there is a number of completed tasks - for one reason, it will be just one release to the production, and also, it makes the process and milestone into a clear focus and goal to reach, and obviously more efficient to manage.

I understand we need to follow industry standards, gherkin style, etc - however the current way does seem to work - so if there is a happy client at the of the day, I think we done our job properly.

So the key word in the term UAT is the acceptance, not testing. Have a good day.