Once upon a time, a clinical laboratory realised that, if instead of having to find the paper documents related to each test and writing down the results by hand they could have a smart monitor, they would save a lot of time.
The practitioner would only tap on the test they were working on and quickly update its status with a second tap. They found an engineering firm and explained to them what they needed and the engineering work began.
A dedicated team of engineers started working on the product. There were so many parts: the software, the touch screen, the computer-like device running the software, the height-adjustable stand, etc.
After several months of hard work, the product was ready. Not only had they tested every single part on its own, but they had also even tested the larger components after coming together. They provided a demonstration to the lab, showing the software and how they can put it in any room thanks to its simple design of only one height-adjustable monitor.
The order was delivered and everyone was satisfied; until they started using it. The lab came back to the engineering team complaining that the monitor is useless because it only detects the touches of the bare hand.
It was a disaster. The engineering team had no idea that the practitioners are required to have medical gloves on at all times in the lab. All the different parts of the monitor were tested. The only issue was that it was tested by the wrong people and in the wrong environment.
The idea is clear. In the process of testing our products, it is also important to give the actual user a chance to test it too because, well, they are the user of this product. If they are not satisfied with it there is no point in producing it anyway.
It might seem like this does not apply when the product in question is software but the reality is it does apply the same if not more. This part of the testing is called User Acceptance Testing or UAT for short.
Most of the other types of testing you might be familiar with happen in the process of development or deployment. We write unit tests to make sure each individual function of the code does what we expect it to do, similar to testing if the power button on the monitor in that clinical lab turns it on. The very last test that happens right before the product is pushed out is UAT.
Let me interest you in another anecdote about manufacturing. In the early 1800s wristwatches were becoming a thing and manufacturers were about to emerge. However, a Swiss company that had managed to be one of the first to export watches to foreign countries was having a frustrating issue.
They would export the watches all around the world and a lot of them would be returned reporting that the watch was not working. They would try these returned watches to see what the issue is only to find out there are no issues and the watch is working perfectly fine.
They would send the watches back again as all tests were showing that the watches were fine but the same thing would happen again - most people found the watches to quickly get out of sync so they would return them.
After thorough investigations, they finally found what the issue was. The mechanical pieces behind the watch were designed to move with the speed that would represent a second… in Switzerland! Other countries with significantly different altitudes would have different air pressure which meant the same mechanics would not work on the watch and the handles would either move faster or slower, causing the time to get out of sync.
There are many lessons to learn from that story but the one we are interested in is that, not only UAT should happen by the end-user but also it should happen in the exact same environment the product is going to be used.
Let us put it all together in the context of software development. The product is developed and all unit tests, integration tests, etc. have passed. The final step of testing is UAT. We said UAT should happen by the end-user but how is that possible in software?
It really depends on who your user is. Sometimes companies have a group of test users who are willing to test the products. Sometimes your customer is other businesses using your APIs and tools so if their automated tests on your new version pass it can act as a UAT for you. And in some cases, you will have a Product Owner that will represent your end-user for you. If your team cannot be directly engaged with the customer then the product owner is your customer. They will define the requirements and then they will also test those requirements at the last stage.
The second thing we talked about was being in the same environment that the product is being used. This can be of special importance if your “production” environment is different from what the developers have on their local computers.
A lot of the companies that have an online service have something called a UAT environment. This is basically what that is. It is an environment with the same data and databases, the same networking and infrastructure and basically the same everything. The only thing that is different is the product/service. That way, you can ensure that the product is being tested in the same environment as it is going to be used and any performance issues or bugs will be discovered. The only difference between a UAT environment and a production one is who uses them.
Fun fact, this article was also UATed - I sent it to a couple of other engineers (the type of end-user I am expecting here) so they read it on their computers (the environment I am expecting you to be in) and make sure they understood it! And they did so I hope you got an idea of what User Acceptance Testing is too and why it is incorporated into the delivery process of engineering teams.
Of course, just like any other type of testing or any process really, there is a lot more to know about its good practices and frameworks, dos and don’ts, etc. that you can search about and find heaps of good articles on the internet!
Did you find this article interesting? Do you think others can enjoy it too? Feel free to share it with your friends!