Acceptance Testing

Acceptance Testing is software testing, which is done after the software is ready to be launched in the market. Acceptance testing is done by the set of customers which is the main userbase of the software.


Acceptance testing is important as this is the last testing in the software development life cycle, and it depends on the Acceptance testing, whether the software is usable and meeting all the requirements which were mentioned in the software requirements specification document.

The functional and non-functional requirements are equally important for Acceptance testing. Because, not only on the functions but also, the user is very much concerned about the non-functional requirements.

The non-functional requirements such as the usability, reliability, clarity, and ease of access are the major attributes which are sometimes considered more important than the functional testing itself.

Ad-hoc Testing

Attributes considered in acceptance testing:

  • Usability
  • The validity of all the functional requirements.
  • The ease of access to the software or the interface.
  • Clarity of the interface.
  • The support system of the software.
  • Functional correctness.
  • Functional Completeness.
  • Confidentiality of the software.
  • Availability of the software.
  • The durability of the software.
  • Scalability of the software.
  • Performance of the software.
  • Timeliness of the software.
  • Data integrity of the software
  • Data conversion ability of the software.

As we have seen what are the different attributes which are required to be checked in the acceptance testing.

Interface Testing

Pre-requisites for Acceptance Testing:

The codes must be developed completely:

This means that there should not be any coding left to be done after the acceptance testing. The codes must be complete and should be assured as consistent at the time of the usability test. There are cases when some parts of the coding in the software are left, for coding in the next phase.

By doing an edit after the acceptance testing, increase the risk that, there may be newly induced errors and bugs in the updated software and that may hamper the image of the complete software development industry. However, cosmetic errors can be allowed before or after the acceptance testing.

Unit, Integration and System Testing should be done completely:

It is clear that the unit test, integration test, and the system test is completely done before the software is produced anywhere for acceptance testing. Only because the system is working fine, the unit test and integration test should not be avoided.

However, there can still be cosmetic errors after the unit and integration test itself, but that is ignorable and the software can be pipelined for acceptance testing.

Regression Testing should be iterated till last

As mentioned earlier, the regression testing is carried out when new features or functionalities are added into the software. Therefore, since regression testing cannot be left for the future after the software release, all new features and functionalities should be added beforehand only.

Regression testing should be iterated, as much as possible, till the last update of the software, just before producing the software for the acceptance testing.

Fix all major defects

All major defects must be fixed anyway. If defects are not found in the stages of the unit test, system test or even regression test, it never means defect is not there. Any sorts of defect rather then the cosmetic defects are not at all allowed for shifting the software into the acceptance testing phase.

First Create the UAT environment

It is simply not like that, the software can be directly released, and the customers or the users are left to test it. Instead, all the needed elements such as the required add-ons, the set-up, or anything required should be provided to the customers so that they are able to run the software smoothly.

For example, it is an internet browsing application. Then to test the application's performance, the customers should have the right operating system, a required speed internet, and all the memory or the CPU requirements, before the testing is carried out.

By testing software in a non-compatible UAT environment, it is not possible to see the actual performance, results or the output of the software. Therefore, it is too important.

For example, if we allow the window's application maker software to be installed in a system with 0.9 Clock speed CPU, and 512 MB of RAM, then the software performance is compromised in this case. And this is not honest testing.

So, to make clear that the software is honestly tested, it has to be in a suitable environment or set-up.

Clear Bussiness requirements must be available:

"Order something- want anything Policy" should be strictly avoided. Since the softwares are made for people who are in business, they will try to get extra functionalities with the same software which they ordered for.

Now the problem is that, while developing the software the SRS documentation was strictly followed and no additional functionalities which are not in the SRS were not included. No software company will be adding extra functionalities and increase their burden and cost.

Therefore, in this case, when the completed software is produced to the customers, then the customers who are the client or the business owner, try to use the software as per current requirements, which is illegal for the developed software.

That is why the business requirement document should be kept in hand in a detailed format before any sort of acceptance testing is carried out. If in case, the customers are looking for something new and different which they have not ordered for, they should curse themselves, not the company.

The responsibility of the software team

There are different responsibilities of the software team, some are summarized below:

  • Creating a set-up environment for software end-users.
  • Taking care of the software, so that now vulnerabilities are induced before the acceptance testing.
  • Should be able to keep the confidentiality of the software, it should not be leaked anyways.
  • The proper signing of documents and paperwork must be carried out, stating that acceptance testing can be carried out.
  • The team must not behave as a defaulter in anyways to the business, for which it is making the software.
Generating the test case or the test scenarios

It should be noted, that for acceptance testing also, there should be a test plan which says that test case or test scenarios should be developed before the testing may be carried out.

This test scenario is a very practical one and the sole objective is not only that, the software should provide the desired output, but the software should be able to handle the complicated business process for which is solely developed.

For example, the software is designed for a business which calculates GST (Goods And Services Tax), for all the items purchased. So, a simple test case would be entering a few items and checking that whether the result expected (balance sheet or anything else) is okay.

But in the case of test scenario for the software, the user should make entry of the highest number of items that can be purchased and a maximum number of clients which can be addressable to the shop or the business place at an individual working day in a month.

This is a threshold surpassing test scenario for the software and will test not only the output but the speed, usability, and performance after the software has crossed its threshold of load balancing capacity.

Creating a Test Plan

Creating a Test plan is the most important step for, the initiation of acceptance testing.

A test plan is nothing but a document, written in a well-structured format. This document shows and lists what to do, when to do, how to do, and what not to do in the acceptance testing process.

The significant of the test plan is huge. It is a one by one step or a guide for the entire acceptance testing process.

There can be different types of the test plan, which are:

  • Master test plan.
  • Phase Test plan.

The master test plan is the test plan which is for all the test levels. It addresses almost all the test levels. On the other hand, the phase test plan address only one test phase or phase levels.

To carry out a test there should be a test plan. Similarly, to create a test plan, there should be a guide or procedure. This is called Test Plan Template.

This is itself a template and just the attributes can be altered to create a standard test plan. Let us see what are the different attributes that are available inside a test plan:

  • Test Plan ID: This provides a unique ID for the Test plan for reference.
  • Introductions : This provides the objectives and goals of the test plan and the steps.
  • References: This is a reference section, that is the case of unknown scenario what should be done.
  • Features to be tested: What are the features should be tested or allowed to be tested (in the partial test.)
  • Features not to be tested: What are the features which should not be tested.
  • What measures to be taken in an emergency: What are the measures that can be taken in an emergency.
  • Remark: Whether the test carried out has passed or failed?
  • Approaches: What are the different approaches to be taken during the steps.
  • Test Environment: What should be the test environment.
  • Estimates: What should be the cost and how much time/effort is required to carry out the test.
  • Staffing: Who are the different persons to be involved during the testing.
  • Training: Is there any pieces of training which are required to be carried out for the persons performing the test.
  • Assumptions: What are the presumptions which are to be taken before the initiation of the test.
  • Add-ons: What are the different add-ons and plugins required for the test.
  • Dependencies: Is the testing software is somehow dependent on any other software during the test.
  • Approvals: What are things to be approved by the developer board or the tester itself for the release.


Who will perform Acceptance Testing?

  • Internal acceptance testing : Also known as the (Alpha Testing), is done by the developer team but does not involve the developer of the team itself. This is the first phase of acceptance testing.
  • External acceptance testing: There are two different types of External Acceptance Testing. In one of this type, the software is tested by the set of customers which belongs to the developing agency. And the other is the end-users for which is the software is developed for. This is also called Beta Testing.

We shall learn more about Alpha and Beta Testing in a different article.

Backend Testing


Acceptance Testing is the software testing type in which the testing is carried out just before the launch of the product. This testing is carried out only to assure all the ease of accessed and reliability of the software and is fully carried out as per the user's point of view.

Acceptance testing is important because it gives a core idea about how the software will be accepted by the users and will the company face any loss after launching the product.

There are also testing like Beta testing which is carried out after the launch of the software product, and so is a type of post-acceptance testing. Alpha testing is also an acceptance testing which is carried out before the launch of the product.

Comment / Suggestion Section
Point our Mistakes and Post Your Suggestions