What Is The Difference Between SIT Vs UAT Testing?

Có thể bạn quan tâm

This Article Explains the Key Differences Between SIT And UAT. You Will Also Learn About System Integration Testing And User Acceptance Testing Methods:

In general, testing is done by both testers and developers. Each of them follows its pattern to test an application.

System Integration Testing or SIT is done by testers whereas User Acceptance Testing, commonly known as UAT is done lastly by the end-users. This article will compare both SIT and UAT in detail and help you understand the key differences between the two.

Let’s Explore!!

Table of Contents:

SIT Vs UAT: Overview
System Integration Testing (SIT)
- Working Steps Of SIT
- Techniques Used In SIT
User Acceptance Testing (UAT)
- Working Steps Of UAT
- Types Of UAT Testing
Key Differences Between SIT Vs UAT
Conclusion

SIT Vs UAT: Overview

In general, the levels of testing have the following hierarchy:

Unit testing
Component testing
System testing
System integration testing
User acceptance testing
Production

Let us analyze the key differences between System Integration Testing (SIT) and User Acceptance Testing (UAT).

System Integration Testing (SIT)

Two different subsystems/systems will combine at a point in any project. We have to then test this system as a whole. Hence this is called System Integration Testing.

Working Steps Of SIT

The individual units have to be integrated first in separate builds.
The entire system has to be tested as a whole.
Test cases have to be written using proper software based on software requirements.
Errors such as UI errors, data flow errors, and interface errors can be found in this testing.

Example:

Let us consider that a healthcare site has 3 tabs initially i.e. Patient Information, Education, and Previous medical records. The healthcare site has now added a new tab called Injection information.

Now the new tab’s details or database has to be merged with the existing tabs and the system has to be tested as a whole with 4 tabs.

We have to test the integrated site that has four tabs.

The integrated site looks something as shown below:

Techniques Used In SIT

Top-down Approach
Bottom-up Approach
Big bang approach

#1) Top-Down Approach

As the name itself suggests it means that it follows the top-to-bottom execution. It is a method in which the main functionality or module is tested followed by the sub-modules in order. Here, arises a question as to what will we do if the consecutive actual sub-modules are not present immediately for integration.

The answer to this gives rise to STUBS.

Stubs are known as called programs. They act as dummy modules and perform the required module function in a limited manner.

Stubs perform the functionality of a unit/module/sub-module partially until the actual module gets ready for integration as the integration of sub-modules is difficult.

The low-level components may be replaced by stubs to integrate. Hence top-down approach may follow a structured or procedure language. After one stub is replaced with the actual component, the next stub can be replaced with the actual components.

The execution of the above diagram will be module A, module B, module C, module D, module E, module F, and module G.

Example For Stubs:

#2) Bottom-Up Approach

This approach follows the bottom-to-top hierarchy. Here, the lower modules are integrated first and then the higher modules are integrated and tested.

The bottom-most modules or units are merged and tested. The set of lower units is called Clusters. While integrating the sub-modules with the main module, in case the main module is not available then the DRIVERS are used to code the main program.

DRIVERS are called calling programs.

Defect leakage is less in this approach.

To integrate the sub-modules to a higher level or main module a driver module is created as shown in the above figure.

#3) Big Bang Approach

In simple words, in the Big Bang Approach, you need to connect all the units at once and test all the components. No partition is done here. Defect leakage must not occur.

This approach is useful for freshly developed projects that are developed from scratch or those that have undergone major enhancements.

User Acceptance Testing (UAT)

Whenever a tester is handing over the completed tested project to the client/end-user then the client/end-user will again test the project to see if it is designed correctly. This is called User Acceptance Testing.

Appropriate test cases have to be written for both in order to perform testing.

[image source]

The developers develop a code based on the Functional Requirement Specification document. The testers test it and report bugs. But the client or end-user only knows how the system exactly works. Hence they test the system from their end.

Working Steps Of UAT

The UAT plan has to be created based on the requirements.
The scenarios have to be built from the requirements.
The test cases and test data have to be prepared.
The test cases have to be run and checked for any bugs present.
If there is no bug and the test cases have passed then the project can be put to sign off and sent for production.
If any defects or bugs are found then it has to be fixed immediately to prepare for release.

Types Of UAT Testing

Alpha And Beta Testing: Alpha testing is done at the development site whereas beta testing is done in the external environment i.e. an outside company etc.
Contract Acceptance Testing: In a contract, the accepted predefined specifications need to be met.
Regulation Acceptance Testing: As the name says the testing is done against the regulations.
Operational Acceptance Testing: The operation or the workflow designed must be as expected.
Black Box Testing: Without going deeply the software needs to be tested for its vital purpose.

Key Differences Between SIT Vs UAT

SIT	UAT
This is performed by testers and developers.	This is performed by end users and clients.
Integration of the sub units/units is checked here. The interfaces are to be tested.	The whole design is checked here.
The individual units are integrated and tested such that the system works as per the requirements.	The system is tested as a whole for the main functionality of the product as desired by the user.
It is done based on the requirements by the testers.	It is done based on the user perspective as to how the product has to be used by end user.
SIT is performed as soon as the system is assembled.	UAT is performed finally just prior to the product release.

Conclusion

System integration testing is done mainly to test the interface requirements of a system. Whereas user acceptance testing is done to verify the system functionality as a whole by an end-user. Appropriate test cases have to be written for both the testing.

SIT can be done by 3 techniques (Top-down, Bottom-up, and Big Bang approach). UAT can be done using 5 methodologies (Alpha and Beta testing, Contract Acceptance testing, Regulation Acceptance testing, Operational Acceptance testing, and Black box testing).

Defects found in system testing can be corrected easily. Different builds can be made based on defects. At the same time, defects found in UAT are considered as a black mark to the testers and are not accepted.

In UAT the business officials or clients must be satisfied that the developed product meets their needs in the business environment. SIT should satisfy the system’s functional requirements.

We hope this article has clarified all your queries on SIT Vs UAT!!