What is difference between SIT and UAT testing?

If you have ever worked in system testing, you must have seen when a system does not integrate correctly or just doesn’t work as expected, even after the system testing has passed. This is usually due to the lack of SIT (System integration testing), but how is this different from UAT? Let me explain…

What is the difference between SIT and UAT testing? SIT (System Integration Testing) focusses on proving that the system functions integrate successfully. With each input/output message invoking the next function successfully. Whereas UAT proves that the system meets the User requirements.

Now you know the difference. Let me explain who works on these phases, how they fit into the software development life cycle, the different types that are available and more.

What is UAT testing?

UAT (User Acceptance Testing) testing is a method to verify that the system application meets the user requirements that were laid out before the software development began.

It verifies from a user perspective that they are happy to accept the system.

What is SIT?

SIT stands for Software Integration Testing. It is basically a way to verify that the overall system integrates with the subsystem modules as expected.

Essentially, it makes sure that the end-to-end system hangs together as expected after system testing.

SIT typically follows system testing and is based on verifying that the system meets the functional specification. This is the process typically used with the V-model.

When is UAT usually done?

UAT usually happens towards the end of a project test phase. Usually, the last step before the system is accepted to go into production.

This is after its been proven in system testing, SIT and sometimes other phases such as OAT (Operational Acceptance Testing).

The reason it is usually at the end of the project is that at this point in time the system should be almost clear of all system serious system defects.

In fact, if you are following the correct procedure it will have had to have passed the exit criteria (click here to see what QA sign off is) of the other phases before it gets to UAT. So, by that time there should only be non-show stopper defects if any.

Who usually carries out this UAT testing?

UAT testing is typically done by a designated product owner. When I say product owner, these are users that typically use the system day in day out and are deemed as product experts or SMEs (Subject matter experts).

When I say experts they are not necessarily technical people. They are usually very skilled in using the application on a day-to-day basis, so they know all the nuances or expected behaviors, are you with me?

As well as verifying the requirements have been met, they are ideal for catching ad-hoc issues that could ordinarily get missed by a less experienced individual.

Their input is valuable because there are a lot of things that they know about the system that maybe even the technical testers may overlook.

Who usually does SIT?

SIT is usually done by very technical and skilled testers. These are usually dedicated resource who focus on testing in their job role.

They usually have very good technical skills and understanding of the modules that will be integrated. For example, these skills may include advanced SQL query skills.

What types of UAT testing are there?

There are two types of UAT testing which are as follows:

Alpha testing
Beta testing

In all honesty, these distinct types of UAT testing are not always implemented by every company. In my years of experience working on software projects, which includes some large blue-chip companies, it is very rarely split up into these two distinct phases.

But, for your benefit, I will break these two distinct approaches.

Alpha testing

Alpha UAT is typically done on the development site by a product owner or user accepted acceptance representative. This user will be able to test the system at the control of the development or project team.

Therefore, the project team is still largely in control of the environment and user access, etc.

Beta testing

Beta testing, on the other hand, is typically done on the clients actual site. This is using their own environment outside of the project teams control.

The benefit is, it mimics the real-life environment more. There still may be a representative from the project team on site to lend assistance, but not always.

Let me share an example of this from my experience of testing. Whilst working for an energy software consultancy. We were tasked with providing some software for them.

After SIT testing, was a phase of UAT on the client site using their environment. Any defects were entered into our defect management system for triage.

So what types of SIT is there?

SIT can also be broken down into two major approaches:

Top-down
Bottom-up

Let Me Explain…

Top-down approach

The top-down approach is focusing on the main parent function. The child modules can or will be replaced by stubs.

What is a stub?….

A stub is a test harness that will return an expected result to a parent function. This is used to test an application with missing (or incomplete) functions.

For example… Cash machine…

Let’s assume we have a cash machine application and we want to test the interface that the customer uses (the parent module). In this example we want to test that the interface links to two child functions:

Withdraw cash page
View Statement

In this example, we could replace the whole withdrawal cash page with a stub. This could be written to return an expected value when the user selects the option from the main interface page.

This is a way of testing to see how the parent function will perform in the absence of the parent function.

Bottom up approach

The bottom up approach is essentially the complete opposite of top-down. You start with the lower level modules and use drivers instead of stubs.

A driver is the opposite of a stub. It will actually provide the input that you expect into a bottom level function to prove that the child function works.

So if we revert back to a cash machine application example…

If we want to prove that after viewing your statement you are returned to the parent menu. A driver could be used to provide a value to confirm that it performed as expected.

The importance of a UAT Kick-off meeting.

An information session or UAT kick-off session is a basic session to transfer information to the UAT testers before starting the UAT phase.

In this session, you will give important information such as

login information
System availability times
The expected duration of the UAT phase
Who is the point of call for any issues
Defect detail expectations
If screenshots are required and detail required

So, in a nutshell, it’s a way of establishing the expectation for UAT after following system integration testing.

In my experience of UAT testing, this is always been a very useful session. Because, if you do not have this initial startup information meeting you will find that you’ll get a lot of these questions asked by multiple people during the test process. Often, you will end up duplicating information again and again.