Your project is getting close to the end. The programmers unit tested the code, and then the entire team participated in a series of interface and system tests. Now you only have one major test to go: user acceptance testing. Ultimately, the customer owns and must live with the business application you’re developing. Acceptance testing allows customers to ensure that the system meets their business requirements.
In fact, depending on how your other tests were performed, this final test may not always be necessary. If the customers and users participated in system tests, such as requirements testing and usability testing, they may not need to perform a formal acceptance test. However, this additional test will probably be required for the customer to give final approval for the system.
The customer’s responsibility
The acceptance test is the last opportunity customers have to make sure that the system is what they asked for. When this final test is complete, the team expects that the customer will formally approve the system or point out any problems that still need to be resolved. Therefore, unlike all the other tests performed so far, acceptance testing is the customers’ responsibility. Of course, unless the customers are very savvy in testing techniques, they will still need the participation of the IT team.
The Acceptance Test Plan
The prior tests were all conducted under the direction of the project team, so it was easier to determine what everyone needed to do and what the test would look like. Since the customer is responsible for the acceptance test, you’ll need to develop a more formal and documented testing process than you used in previous tests. This will keep the team from being uncertain about what’s happening. The Acceptance Test Plan can be a separate document, or you can include the information in the general Test Plan you created during the design phase. Either way, you should define the following information:
- Customer responsibilities: Describe the activities the customer is responsible for and what others are responsible for. On some projects, the customer is responsible for all aspects of the test, including creating test scenarios, performing the tests, and validating the results. On other projects, the entire teams may assist in the various activities.
- Acceptance criteria: Before you begin the acceptance test, the team should know what criteria will be used to decide whether the system is acceptable or not. Does the system have to be perfect? You better hope not. But the acceptance criteria should define how the decision will be made. The customer may accept a system with certain minor types of errors remaining. But there may be other levels of errors that will render the system unacceptable. Part of the acceptance criteria may be to revalidate some of the other system tests. For instance, the customer may want to thoroughly test security, response times, functionality, etc. even if some of these tests were done as a part of system testing.
- Acceptance Test Workplan: Here, you define the activities associated with the acceptance test, when they will begin and end, who is responsible, and so on. In other words, you define the workplan for the test. Defining all this up front will help people understand what is expected of them, and they’ll be aware of the timeframe and know when things are due. You should move all this information to the main project workplan.
The actual acceptance test follows the general approach of the Acceptance Test Plan. After the test is completed, the customer either accepts the system or identifies further changes that are required. After these subsequent changes are completed, either the entire test is performed again or just those portions in question are retested. In some cases, portions of the system may be accepted while others are sent back for more work. If the project involves an outsourcing relationship, a major portion of payment is usually made based on the results of the acceptance test.
Last great hurdle
As you enter this home stretch of testing, keep these points in mind:
- Acceptance testing completes the formal testing process and is the only test that is the responsibility of the customer.
- After the acceptance test is finished, you should be ready to implement with a high level of confidence that the system will be relatively error-free and stable.
- A formal Acceptance Test Plan defines the responsibilities of the customer, the acceptance criteria, and the overall Acceptance Test Workplan. This information is then placed in the general Test Plan.