I am an Affilate!

I hope you get value from any product or service that I recommend. :) Just to be transparent, I may get a share of any sales or other compensation from the links on this page. As an Amazon Associate I earn from qualifying purchases. Thanks if you use any of my links, I do really appreciate your support.

Is UAT functional testing?

If you are involved in UAT or functional testing, you may have wondered what are the key differences, or if they are one of the same things. Well, let me explain…

Is UAT functional testing? No, UAT is not functional testing. UAT is a process of checking and validating that the user requirements have been met. This is typically governed by the User Requirements document. Functional testing, on the other hand, is verification that the system meets the functional specification. 

To put things into perspective, it is possible to pass functional testing, with the system meeting the functional specification, but still failing UAT. But now that you know that they are different let me explain each one in more detail, the types of testing that fall into these categories and more…

What is UAT?

UAT is a validation process that proves the contract (user requirements) between the project team and the user has been met.  This is based on User requirements agreed from the beginning of the project.

This is typically conducted by end-users (customers). Or in some cases, it is done by a product owner who is working as a proxy for the actual end-user.

Why is UAT testing important?

UAT testing (click here to see if UAT exists in Agile) is important because it confirms that the customer’s requirements have been met. It is also possible to find issues in the system that could have been missed during functional testing.

It is also an important quality gate. Often the final gate before the system goes live.

What is functional testing?

Functional testing (Click here to see Why Functional Testing is Required) is a way of verifying that each system function meets the functional specification document.

Inputs are put into the system with the actual results (or outputs) of these functions compared against the expected results defined in the functional specification.

I have mentioned the functional specification a few times in this article. Which is a key document in the traditional v-model, used in testing? However, in the real world, from my experience, you will often find that there is no functional specification.

This is the real challenge to a tester. Because, the books ion testing, or ISTQB exam never really prepares you for this.

The main activities of functional testing use black-box testing…

Black box testing is a functional-based procedure which does not concern itself with the underlying code within each functional module.

Therefore, a tester running a black-box test does not need to know the exact code behavior within that function. Meaning they don’t have to be a developer.

They just need to know what input is required and what to expect to get out of it, as per the defined specification. Hence the reason it’s called the “black box”.

Functional testing usually tests functions such as APIs, databases, user interfaces, etc.

What different types of functional testing is there?

In this section, I’m going to explain what different types of functional testing there is.

The following forms of testing would be regarded as Functional testing:

  • Regression testing
  • Smoke testing
  • System integration testing

Integration testing is a classic example of this ( Click here to see the difference between System Integration Testing and UAT testing). During integration testing, you will be verifying if each individual system module can integrate and talk to each other successfully.

For this to be successful, inputs from one module will feed into another function. Hence the reason why it is typically called Integration testing.

Working Example from my experience…

So, for example, in one of my previous testing projects, we were working on a large financial system. This system was responsible for checking customer debt. Depending on the debt levels, certain actions would be triggered, etc a letter to a customer.

To gather accurate data on the customers, required multiple XML feeds into a central database. It would collect data, for example, address information and credit score data from external vendors.

Each one of these XML feeds was effectively integration tests that needed to be verified using functional testing.

Related questions:

Q: What is the difference between verification and validation?

Verification is what most people think of when they talk about system testing.

It is a procedure to verify that the system works as per the specification. In particular, the functional specification. In basic terms, it means – is the product built correctly?


Validation is different if you are thinking of user-related testing. Then, the chances are your thinking of validation testing.

Validation in basic terms means – are we building the right product?

It Focuses on confirming if the system that has been built and verified actually delivers on the user’s expectations.

And this is validated against the User Requirements that were drafted in the very beginning of the project.

Q: What is non-functional testing?

Non-functional testing is test procedures that confirm non-functional related specifications such as reliability, performance, etc.

These tests are performed based on separate non-functional requirements. They are not covered during functional testing.

An example

An example of a non-functional test would be: How many simultaneous users can be loaded onto the system?

Typically these tests are done by specialist test resource. They focus on non-functional testing. These testers are usually very well paid because they have rare skills that are often needed by large organizations.

Highly Paid

If if you are ever considering a highly paid contracting role for the future, this is something to consider.

Usually, this testing is done by some form of automation such as LoadRunner, QTP,  etc.

The reason for this is, it is usually quite challenging replicating these test scenarios without using test automation.

My example of a real-life manual load test…

An example of non-functional testing that I was involved in, as a test manager. During a previous project for a large energy company, we needed to simulate some load on the system.

We didn’t have the budget for automation tools, and time scales were tight. So, to simulate this load, we required multiple people all in the same room.

Each person was using the system at one time to verify the system could handle the load. The reality is this method is quite hard to coordinate, and there is room for error.

Also, this is quite a costly affair because you need to have everyone coordinated in the same room at the same time. And time is money. For these non-functional tests, If the project has the budget, automation is easier. because you can click a button to replicate the load.

Q: Is white box testing functional testing?

No, white box testing focuses on the underlying code in a function. This is typically referred to as unit testing and is usually executed by an actual developer.

It is a very important activity which typically happens before the system is passed on for functional testing. Think of it as an important prerequisite before you get into black box testing (or functional testing).

Q: What is end-to-end testing?

End-to-end testing is a testing method to verify that the entire system application, from start to finish, performs as expected. It verifies the flow of data works as per the specification.

Q: What is compatibility Testing?

This is classed as a non-functional test. Its main job is to verify that the application is compatible with different devices, browsers, etc. For example, let’s say you were working on a web application, such as an online sweet shop.

To perform compatibility tests, you would check the web app on multiple browsers to verify that it is compatible with the major browsers. This is just one example obviously.

These requirements, governing which browsers will need to have been documented and agreed on ahaead of time so that it is not an open-ended test on whatever browser the tester feels like testing. And to also ensure that the agreed coverage is met.

Talented Tester Support

Skip to toolbar