Objective 5: Achieve Stakeholder Concurrence That Deployment Is Complete

Product Acceptance Test

Product acceptance testing is the final test action prior to deploying the software. The goal of acceptance testing is to verify that the software is ready and can perform those functions and tasks it was built for.

There are three common strategies for acceptance test:

Formal acceptance
Informal acceptance
Beta test

Formal acceptance testing is a highly managed process where there is a clear one-to-one supplier-acquirer relationship. It is often an extension of the system test. The tests are planned and designed carefully and in the same detail as system testing. The test cases selected should be a subset of those performed in system testing. It is important not to deviate in any way from the chosen test cases. In many organizations, formal acceptance testing is fully automated. Formal acceptance testing is most frequently performed by the supplying organization under control of the acquirer, by the acquirer itself, or by a third party appointed by the acquirer.

Informal acceptance testing has less rigorously defined test procedures than those of formal acceptance testing. The functions and business tasks to be explored are identified and documented, but there are no particular test cases to follow. The individual tester determines what to do. This approach to acceptance testing is not as controlled as formal testing and is more subjective than the formal one. Informal acceptance testing is most frequently performed by the end- user organization.

Beta testing is described in an earlier section, Objective 1: Beta Test to Validate That User Expectations Are Met.

Independent of the approach selected, you should agree on the test cases and how they should be evaluated before acceptance testing is implemented and executed.

Product acceptance testing often involves more than executing the software for readiness; it also involves all product artifacts delivered to the customer(s), such as training, documentation, and packaging. Evaluating the nonsoftware artifact(s) varies greatly depending on the artifact being evaluated (refer to the Guidelines and Checklists, available in the RUP product, for information regarding what and how to evaluate). For examples, see the Guidelines and Checklist s for the artifacts Use Case and Software Architecture Document, in the RUP product.