What is acceptance testing? Definition, process, and types explained
October 29, 2023
Test automation tools have the ability to automate a wide range of tests. We pick and choose tests that are appropriate for the software we’re developing and that best meet the needs of the end users, and then run a combination of different types of tests. This allows us to find problems in the software and check whether the software meets the end users’ requirements before release.
In this article, we’ll look at one of the types of testing that test automation tools can handle: Acceptance Testing.
What is acceptance testing?
Acceptance testing, sometimes called UAT (User Acceptance Testing), is a testing technique to verify whether the system works as the end user requested or not. Acceptance testing is run after software testing is complete, and the main purpose isn’t to find bugs in the system but to check if the system works as expected. By running acceptance testing before going live, development teams can ensure users can use the software/app smoothly.
Why do we need to run various tests in software development? Here are the main reasons why software testing is important:
- It eliminates release risks caused by bugs and errors.
- It eliminates the software’s vulnerabilities and protects it from attacks by external parties.
- It helps satisfy the end users’ requests and gains their trust.
- It makes the software development process more efficient.
- It allows teams to check if the completed software satisfies the end users’ requests and objectives, and to assure quality.
Acceptance testing achieves the 5th item in the above list.
The software testing process
How do teams decide on the scope and the steps to test their software? In general, the software testing process follows these steps:
- Analyze requirements and define the scope of testing.
- Plan the testing approach.
- Design test scenarios (create the test steps, test data, and test scripts).
- Prepare the test environment (prepare test platforms/devices and install the test environment).
- Perform testing (run the software according to plan).
- Confirm that completion criteria are met and end testing.
The above process assumes you’re not using any test automation tools. If you do use a test automation tool, you can skip steps 4 and 5.
Usually, teams use test automation tools to automate the following eight types of testing. They select the ones necessary for the software they’ve developed.
- Unit testing
- API testing
- Integration testing
- UI testing
- Smoke testing
- Acceptance testing
- Performance testing
- Accessibility testing
As you can see, acceptance testing is one of the tests that test automation tools can handle.
Related article: What is automation testing?
A brief background of acceptance testing
Acceptance testing, or User Acceptance Testing (UAT), means checking whether the end user will accept the deliverable.
When system development was often outsourced, acceptance testing was mostly done by the end user. However, system development has shifted to be done in-house, and now it’s common practice for developers to handle acceptance testing.
Acceptance testing process
How should teams decide on the scope and steps for acceptance testing? In general, the acceptance testing process follows these steps:
- Analyze business requirements.
- Create an acceptance test plan.
- Define test scenarios and test cases.
- Prepare test data.
- Run test cases and gather results.
- Check if all business requirements are met.
We can see that there are quite a few similarities between the acceptance testing process and the software testing process. What are the differences?
Types of Acceptance Testing
There are three main types of acceptance testing (UAT). Let’s take a look at how ISTQB (International Software Testing Qualifications Board) defines them.
- Acceptance testing
Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.
- Factory acceptance testing
Acceptance testing conducted at the site at which the product is developed and performed by employees of the supplier organization, to determine whether or not a component or system satisfies the requirements, normally including hardware as well as software.
- Site acceptance testing
Acceptance testing by users/customers at their site, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes, normally including hardware as well as software.
Site acceptance testing is not carried out by the developer or the client but by employees of a third-party supplier organization. Acceptance testing usually doesn’t include hardware, whereas site acceptance testing does.
What the three types of acceptance testing described above have in common is that they are all conducted from the perspective of a third party, such as users, customers, and employees of a supplier organization. Software testing, on the other hand, is carried out by engineers of development teams, so the perspective is different from acceptance testing.
Teams don’t always have enough time for acceptance testing
When you create an acceptance test plan, you must decide how much to test. However, if you cover too much, or if the plan is too detailed, it can cause the project to fall behind schedule. Better acceptance testing means better software quality, but if you get overzealous, it could also mean missing deadlines or going over budget.
If the development team completes the software on time, there will be enough time for the next step – acceptance testing. However, problems during software testing can result in delays that eat up the time allotted for acceptance testing.
Further, if problems are found during acceptance testing, you will have to go back and fix them, putting more pressure on the overall schedule.
It’s best to ensure that your team can perform acceptance testing, regardless of how much time is available.
The key to successful acceptance testing is to prioritize
The purpose of acceptance testing is to verify that the system works as the end user requested, but what exactly should we check? The key to successful acceptance testing is to prioritize and test the most important features.
Software developed by your team has to pass software testing before it reaches acceptance testing. The development team has already done extensive testing, so it would be a waste of time to go over everything again during acceptance testing.
Acceptance testing should focus on verifying the most important features without taking up too much time. It’s crucial to ensure that there is no overlap between what the development team tests and what acceptance testing covers, and that nothing is missed. This way, you can test every feature and find any remaining issues in the system.
Make sure that changes and additions made after software testing are communicated
There’s always time pressure in software development, and work is often completed just before the deadline. Even if you’ve already run the final test and found no issues, someone may make even more changes or additions.
Before you start acceptance testing, it’s best to double-check that no changes or additions have been made after software testing. There’s always a chance that a small change could lead to a major error.
Be mindful of data used in acceptance testing
Using fake data in software testing can cause unexpected problems after production release. To reduce this risk, we recommend using real data from real environments in acceptance testing. If available, get real data as early as possible.
Acceptance testing is the final step in the testing process, so it is easy to become overzealous, such as having too many test items or spending too much time going back to fix issues, and this can put pressure on the entire schedule.
The key to acceptance testing is to trust the results of all the software testing that’s already been done, focus on testing the bare minimum, and let go of the notion that it’s the last line of defense.