Acceptance Testing

 Acceptance testing is formal testing based on user requirements and function processing. It determines whether the software is conforming specified requirements and user requirements or not. It is conducted as a kind of Black Box testing where the number of required users involved testing the acceptance level of the system. It is the fourth and last level of software testing.

User acceptance testing (UAT) is a type of testing, which is done by the customer before accepting the final product. Generally, UAT is done by the customer (domain expert) for their satisfaction, and check whether the application is working according to given business scenarios, real-time scenarios.

In this, we concentrate only on those features and scenarios which are regularly used by the customer or mostly user scenarios for the business or those scenarios which are used daily by the end-user or the customer.

However, the software has passed through three testing levels (Unit Testing, Integration Testing, System Testing) But still there are some minor errors which can be identified when the system is used by the end user in the actual scenario.

Acceptance testing is the squeezing of all the testing processes that have done previously.

Note:

It is done in the separate environment at the customer place, which is known as the UAT environment. The user acceptance testing is done by a different team called as domain expert who is known to the application.

Generally, small companies do not have a domain expert because there is no frequent changes happen in the application.

Reason behind Acceptance Testing

Once the software has undergone through Unit Testing, Integration Testing and System Testing so, Acceptance Testing may seem redundant, but it is required due to the following reasons.

• During the development of a project if there are changes in requirements and it may not be communicated effectively to the development team.
• Developers develop functions by examining the requirement document on their own understanding and may not understand the actual requirements of the client.
• There's maybe some minor errors which can be identified only when the system is used by the end user in the actual scenario so, to find out these minor errors, acceptance testing is essential.

Note:
Once we collect the requirement from the customer and done the coding process completely then the test engineer starts all different types of testing until the application becomes stable.

Once the application is bug-free, we handover it to the customer, no customer accept the application blindly before using it. Hence, they do one round of testing for their satisfaction, which is known as user acceptance testing.

Who performs user acceptance testing?

The acceptance testing can be performed by different persons in different cases.

For example, the blue-dart company gives the requirement to TCS for developing the application, and the TCS will accept the needs and agree to deliver the application in the two releases as we can see in the below image:

On August 10, the test manager tells the project manager that there is a critical bug in the application, and that will take another four days to fix it.

But the project manager said we have to deliver the software within a given time. It takes another 30 days to fix the defect, or otherwise, we will have to pay the penalty (fine) for each day after the given release date. Is this the real situation? NO, let us see three different cases and understand who perform the acceptance testing.

Case1

In this, we will discuss how the acceptance testing is performed, and here the test engineer will do the acceptance testing.

Mostly, the actual flow for testing the application will be seen in the above image, but here it is little difference, as we know where the end-to-end testing or system testing ends and the acceptance testing will proceed. To understand this scenario, follow the below process:

The blue-dart provides the requirements, and TCS develops the application and performs all the testing and handover to the blue-dart company.

Now the question arises the blue-dart will use the application as soon they get it from TCS? NO, the blue dart company has a group of test engineers after they get the software, and this team will start testing the application, and this end-to-end testing is done at the customer environment, which is called the User Acceptance Testing.

Let us see the difference between TCS test engineers and Blue-dart Engineers:

In TCS, the tester will perform the functional testing, integration testing, and system testing and whereas in Blue-dart, the tester will do only the end-to-end or system testing, which is known as acceptance testing.

The difference between end-to-end testing at TCS and blue-dart is as follows:

• The blue-dart test engineer is the one who gave the requirements
• The blue-dart engineer understands the product well
• The blue-dart engineer is a domain expert.
• They test the real-time data on the application.

To understand this, we can see the below example, or if we have the application format is like this:

When the application is given to blue-dart test engineers, and they will perform testing and the application should generate a text message "Parcel 1 invoice Id created." It was not mentioned in the requirement, or it is there, and TCS does not fix it. Then fine(penalty) counts for TCS from that only, and whereas the test engineers at TCS will not knowing this, due to that, we can see the difference between the testing done at TCS and Blue-dart.

Case2

In this case, we will see how the Employee is becoming end-users and performing acceptance testing.

The application is developed and tested at the TCS environment and then sent to blue-dart. And in the Blue-dart, they have fewer test engineers, so they can't do acceptance testing. So for this, out of 300 employees of blue-dart, they will provide the application to the 30 employees and install the application to their systems and ask them to start using the application and find any defect or issues.

Now 30 employees will do the dummy implementation, which means they provide the data into the application and also written that data manually. And here, the employee becomes the end-user and also identify the bugs and issues while using the application.

These issues are verified against the requirements, and now the fine is charged for TCS (sometimes the penalty is charged on an hourly basis). If the identified bug is not as per requirement, then blue-dart can go for the Request For Enhancement [REF] and Change Request [CR].

Where Request for enhancement means that if the blue-dart feels that a particular module can be improved and developed in a better way, and then they can send the Customer Requirement Specification [CRS] as REF and TCS will follow the CRS and also make sure to do the necessary changes.

And the Change Request means, if the requirement has not been specified accurately, then blue-dart provides the exact needs and Request for changes.

Therefore, the acceptance testing can also be defined as end-to-end testing, which can be done by the engineers who are working in the client environment. Here, they take real-time scenarios and check whether the application is working fine or not, and also we can make real-time business scenarios because the end-user knows how the business flow works.

Note:

If we are getting more builds for acceptance testing, this means that:

• After receiving the application, the customer is getting more and more ideas, so they are asking for more and more changes.
• The quality of the software, which we delivered to customers, is not appropriate, and the development and testing both are not correctly done.
• The requirement which was given in the starting is not clear.

Case3

In this case, if the blue-dart customers become the end-users.

Here, the application is developed and tested and implemented at a blue-dart production server, and n-numbers of users start using the application, which is in the first release. While using the application, the blue-dart comes up with more number of features and enhancements, which is sent with the CRS to the TCS after that TCS will do the further changes in modules and sent it back to the blue-dart.

Hence, what is happing here, the application was developed when the requirement is collected by blue-dart from their end-users and customers.

The numbers of releases depend on the following facts:

• Difficulty of modules
• The number of modules.
• How the new module affects the old module.

Note:

Hotfix: In the production environment, whenever the customer identify the critical bug, we will do the following

• The developers fix the bugs.
• Small teams of test engineers will test the software.
• Re-install the application on the client environment.
• The client starts using the new software.

This entire process is known as a hotfix, and it can be done in a few hours or one day.

For example: If the significant module, suppose the Login module itself is not working at the production server, then the client will send it immediately for fixing it, and that has to be done as soon as possible.

Short release

Between two major releases, this is a short release of improvements, and it happens when the client needs some small features to change on an urgent basis.

For example, if we have 60 developers, where the ten developers will come out, and out of 40 test engineers, the 3 test engineers will come out, and they develop and test the application. And before adding it to the production server, the customer does one short round of acceptance testing.

Steps to Perform Acceptance Testing

Requirement Analysis:

In this step, the testing team analyzes requirement document to find out the objective of the developed software. Test planning accomplished by using requirement document, Process Flow Diagrams, System Requirements Specification, Business Use Cases, Business Requirements Document and Project Charter.

Test Plan Creation:

Test Plan Creation outlines the whole strategy of the testing process. This strategy is used to ensure and verify whether the software is conforming specified requirements or not.

Test Case Designing:

This step includes the creation of test cases based on test plan documents. Test cases should be designed in a way that can cover most of the acceptance testing scenario.

Test Case Execution:

Test Case Execution includes execution of test cases by using appropriate input values. The testing team collects input values from the end user then all test cases are executed by both tester and end user to make sure software is working correctly in the actual scenario.

Confirmation of objectives:

After successful completion of all testing processes, testing team confirms that the software application is bug-free and it can be delivered to the client.

Tools used in Acceptance Testing

Acceptance Testing can be done by using several tools; some are given below:

done by using several tools; some are given below:

Watir:

Acceptance testing uses this tool for the execution of automated browser-based test cases. It uses Ruby language for the inter-process communication.

Fitness tool:

This tool is used to enter input values and generate test cases automatically. The user needs to input values, these values used by the tool to execute test cases and to produce output. It uses Java language for the inter-process communication. This tool makes it easy to create test cases as well as record them in the form of a table.

Advantages of Acceptance Testing

• It increases the satisfaction of clients as they test application itself.
• The quality criteria of the software is defined in an early phase so that the tester has already decided the testing points. It gives a clear view to testing strategy.
• The information gathered through acceptance testing used by stakeholders to better understand the requirements of the targeted audience.
• It improves requirement definition as client tests requirement definition according to his needs.

Disadvantages of Acceptance Testing

According to the testing plan, the customer has to write requirements in their own words and by themselves but

1. Customers are not willing to do that; it defeats the whole point of acceptance testing.
2. If test cases are written by someone else, the customer does not understand them, so tester has to perform the inspections by themselves only.

If the process is done in this manner, it destroys the existence of the Acceptance Testing.