Developers/ Testers must keep in mind that the software is being built to satisfy the user requirements and no matter how elegant its design is, it will not be accepted by the users unless it helps them achieve their goals as specified in the requirements. After the software has passed all the system test and defect repairs have been made, the customer/client must be involved in the testing with proper planning. The purpose of acceptance testing is to give the end-user a chance to provide the development team with feedback as to whether or not the software meets their needs. Ultimately, it's the user who needs to be satisfied with the application, not the testers, managers, or contract writers.

Acceptance testing is one of the most important types of testing we can conduct on a product. It is more important to worry whether users are happy about the way a program works rather than whether is or not the program passes a bunch of tests that were created by testers in an attempt to validate the requirements, that an analyst did their best to capture and a programmer interpreted based on their understanding of those requirements.

Thus, acceptance testing is the formal testing conducted to determine whether a software system satisfies its acceptance criteria and to enable buyers to determine whether to accept the system or not.

Acceptance testing must take place at the end of the development process. It consists of tests to determine whether the developed system meets the predetermined functionality, performance, quality, and interface criteria acceptable to the user. Therefore, the final acceptance acknowledges that the entire software product adequately meets the customer's requirements. User acceptance testing is different from system testing. System testing is invariably performed by the development team, which includes developers and testers. User acceptance testing, on the other hand, should be carried out by end-users.

Thus, acceptance testing is designed to:

• Determine whether the software is fit for the user
• Making users confident about the product
• Determine whether a software system satisfies its acceptance criteria
• Enable the buyer to determine whether to accept the system or not.

The final acceptance marks the completion of the entire development process. It happens when the customer and the developer have no further problems.

Acceptance test might be supported by the testers. It is very important to define the acceptance criteria with the buyer during various phases of SDLC. A well defined acceptance plan will help development teams to understand users needs. The acceptance test plan must be created or reviewed by the customer. The development team and the customer should work together and make sure that they:

• Identify interim and final products for acceptance, acceptance criteria, and schedule
• Plan how and by whom each acceptance activities will be performed
• Schedule adequate time for the customer to examine and review the product
• Prepare the acceptance plan
• Perform formal acceptance testing at delivery
• Make a decision based on the results of acceptance testing

Entry Criteria

• System testing is complete and defects identified are either fixed or documented.
• Acceptance plan is prepared and resources have been identified.
• Test environment for the acceptance testing is available.

Exit Criteria

• Acceptance decision is made for the software.
• In case of any warning, the development team is notified.

Types of Acceptance Testing

Acceptance testing is classified into the following two categories:

Alpha testing: These are tests conducted at the development site by the end users. The test environment can be controlled a little it this case.

Beta testing: These are tests conducted at the customer site and the development team, does not have any control over the test environment.

1. Alpha Testing

Alpha is the test period during which the product is complete and usable in a test environment, not necessarily bug-free. It is the final chance to get verification from the customers that the trade off made in the final development stage are coherent.

Therefore, alpha testing is typically done for two reasons:

(i) To give confidence that the software is in a suitable state to be seen by the customers.

(ii) To find bugs that may only be found under operational conditions. Any other major defects on performance issues should be discovered in this stage.

Since alpha testing is performed at the development site, testers and users together perform this testing. Therefore, the testing is in a controlled manner such that if any problem comes up, it can be managed by the testing team.

Entry criteria to Alpha

• All features are complete/ testable (no urgent bugs)
• High bugs on primary platforms are fixed verified
• 50$\%$ of medium bugs on primary platforms are fixed verified
• All features have been tested on primary platforms
• Performance has been measured compared with previous releases (user functions)
• Usability testing and feedback (ongoing)
• Alpha sites are ready for installation

Exit Criteria from Alpha

After alpha testing, we must:

• Get responses/feedbacks from customers
• Prepare a report of any serious bugs being noticed
• Notify bug-fixing issues to developers

2. Beta Testing

Once the alpha phase is complete, development enters the beta phase. Beta is the test period during which the product should be complete and usable in a production environment. The purpose of the beta ship and test period is to test the company's ability to deliver and support the product (and not to test the product itself). Beta also serves as a chance to get a final vote of confidence' from a few customers to help validate our own belief the product is now ready for volume shipment to all customers.

Versions of the software, known as beta-versions, are released to a limited audience outside the company. The software is released to groups of people so that further testing can ensure the product has few or no bugs. Sometimes, beta-versions are made available to the open public to increase the feedback field to a maximal number of future users.

Testing during the beta phase, informally called beta testing, is generally constrained to black-box techniques, although a core of test engineers are likely to continue with white-box testing parallel to beta tests. Thus, the term beta test can refer to a stage of the software-closer to release than being in alpha-or it can refer to the particular group and process being done at that stage. So a tester might be continuing to work in white-box testing while the software is 'in beta'(a stage), but he or she would then not be a part of 'the beta test' (group/activity).

Entry Criteria to Beta

• Positive responses from alpha sites
• Customer bugs in alpha testing have been addressed
• There are no fatal errors, which can affect the functionality of the software
• Secondary platform compatibility testing is complete
• Regression testing compatibility testing is complete
• Regression testing corresponding to bug fixes has been done
• Beta sites are ready for installation

Guidelines for Beta Testing

• Don't expect to release new builds to beta testers more than once in every two weeks.
• Don't plan a beta with fewer than four releases
• If you add a feature, even a small one, during the beta process, the clock goes back to the beginning of eight weeks and you need another 3-4 releases

Exit Criteria from Beta

After beta testing, we must:

• Get responses/feedbacks from the beta testers
• Prepare a report of all serious bugs
• Notify bug-fixing issues to developers