In software engineering, acceptance testing is formal testing conducted to determine whether a system satisfies its acceptance criteria and thus whether the customer should accept the system.
Acceptance Testing checks the system against the “Requirements”. It is similar to systems testing in that the whole system is checked but the important difference is the change in focus: Systems Testing checks that the system that was specified has been delivered. Acceptance Testing checks that the system delivers what was requested. The customer, and not the developer should always do acceptance testing. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment.

The forms of the tests may follow those in system testing, but at all times they are informed by the business needs.

The test procedures that lead to formal ‘acceptance’ of new or changed systems. User Acceptance Testing is a critical phase of any ’systems’ project and requires significant participation by the ‘End Users’. To be of real use, an Acceptance Test Plan should be developed in order to plan precisely, and in detail, the means by which ‘Acceptance’ will be achieved. The final part of the UAT can also include a parallel run to prove the system against the current system.

Factors influencing Acceptance Testing

The User Acceptance Test Plan will vary from system to system but, in general, the testing should be planned in order to provide a realistic and adequate exposure of the system to all reasonably expected events. The testing can be based upon the User Requirements Specification to which the system should conform.
As in any system though, problems will arise and it is important to have determined what will be the expected and required responses from the various parties concerned; including Users; Project Team; Vendors and possibly Consultants / Contractors.
In order to agree what such responses should be, the End Users and the Project Team need to develop and agree a range of ‘Severity Levels’. These levels will range from (say) 1 to 6 and will represent the relative severity, in terms of business / commercial impact, of a problem with the system, found during testing. Here is an example which has been used successfully; ‘1′ is the most severe; and ‘6′ has the least impact :-

Show Stopper i.e. it is impossible to continue with the testing because of the severity of this error / bug
Critical Problem Testing can continue but we cannot go into production (live) with this problem
Major Problem Testing can continue but live this feature will cause severe disruption to business processes in live operation
Medium ProblemTesting can continue and the system is likely to go live with only minimal departure from agreed business processes
Minor Problem Both testing and live operations may progress. This problem should be corrected, but little or no changes to business processes are envisaged
Cosmetic Problem e.g. colours; fonts; pitch size However, if such features are key to the business requirements they will warrant a higher severity level.
The users of the system, in consultation with the executive sponsor of the project, must then agree upon the responsibilities and required actions for each category of problem. For example, you may demand that any problems in severity level 1, receive priority response and that all testing will cease until such level 1 problems are resolved.

Caution
Even where the severity levels and the responses to each have been agreed by all parties; the allocation of a problem into its appropriate severity level can be subjective and open to question. To avoid the risk of lengthy and protracted exchanges over the categorisation of problems; we strongly advised that a range of examples are agreed in advance to ensure that there are no fundamental areas of disagreement; or, or if there are, these will be known in advance and your organisation is forewarned.
Finally, it is crucial to agree the Criteria for Acceptance. Because no system is entirely fault free, it must be agreed between End User and vendor, the maximum number of acceptable ‘outstandings’ in any particular category. Again, prior consideration of this is advisable.
N.B. In some cases, users may agree to accept (’sign off’) the system subject to a range of conditions. These conditions need to be analysed as they may, perhaps unintentionally, seek additional functionality which could be classified as scope creep. In any event, any and all fixes from the software developers, must be subjected to rigorous System Testing and, where appropriate Regression Testing.

Conclusion

Hence the goal of acceptance testing should verify the overall quality, correct operation, scalability, completeness, usability, portability, and robustness of the functional components supplied by the Software system.

Rational RequisitePro

Rational RequisitePro is a requirements management tool that helps project teams control the development process. RequisitePro organizes your requirements by linking Microsoft Word to a requirements repository and providing traceability and change management throughout the project lifecycle. A baseline version of RequisitePro is included with Rational Test Manager. When you define a test requirement in RequisitePro, you can access it in Test Manager.

Rational Clear Quest

Rational Clear Quest is a change-request management tool that tracks and manages defects and change requests throughout the development process. With Clear Quest, you can manage every type of change activity associated with software development, including enhancement requests, defect reports, and documentation modifications.

Rational Purify

Rational Purify is a comprehensive C/C+ + run-time error checking tool that automatically pinpoints run-time errors and memory leaks in all components of an application, including third-party libraries, ensuring that code is reliable

Rational Quantify

Rational Quantify is an advanced performance profiler that provides application performance analysis, enabling developers to quickly find, prioritize and eliminate performance bottlenecks within an application.

Rational Pure Coverage

Rational Pure Coverage is a customizable code coverage analysis tool that provides detailed application analysis and ensures that all code has been exercised, preventing untested code from reaching the end-user.

Rational Suite Performance Studio

Rational Suite Performance Studio is a sophisticated tool for automating performance tests on client/server systems. A client/server system includes client applications accessing a database or application server, and browsers accessing a Web server. Performance Studio includes Rational Robot and Rational Load Test. Use Robot to record client/server conversations and store them in scripts. Use Load Test to schedule and play back the scripts.

Rational Robot

Rational Robot. Facilitates functional and performance testing by automating record and playback of test scripts. Allows you to write, organize, and run tests, and to capture and analyze the results.

Rational Test Factory

Rational Test Factory. Automates testing by combining automatic test generation with source-code coverage analysis. Tests an entire application, including all GUI features and all lines of source code.

Rational Load Test

During playback, Rational Load Test can emulate hundreds, even thousands, of users placing heavy loads and stress on your database and Web servers.

Rational Test

Rational Test categorizes test information within a repository by project. You can use the Rational Administrator to create and manage projects.

Contents of a Test Report

The contents of a test report are as follows:

Executive Summary
Overview
Application Overview
Testing Scope
Test Details
Test Approach
Types of testing conducted
Test Environment
Tools Used
Metrics
Test Results
Test Deliverables
Recommendations

These sections are explained as follows:

1. Executive Summary

This section would comprise of general information regarding the project, the client, the application, tools and people involved in such a way that it can be taken as a summary of the Test Report itself (i.e.) all the topics mentioned here would be elaborated in the various sections of the report.

2. Overview

This comprises of 2 sections – Application Overview and Testing Scope.

2.1 Application Overview

This would include detailed information on the application under test, the end users and a brief outline of the functionality as well.

2.2 Testing Scope

This would clearly outline the areas of the application that would / would not be tested by the QA team. This is done so that there would not be any misunderstandings between customer and QA as regards what needs to be tested and what does not need to be tested.
This section would also contain information of Operating System / Browser combinations if Compatibility testing is included in the testing effort.

3. Test Details

This section would contain the Test Approach, Types of Testing conducted, Test Environment and Tools Used.

3.1 Test Approach

This would discuss the strategy followed for executing the project. This could include information on how coordination was achieved between Onsite and Offshore teams, any innovative methods used for automation or for reducing repetitive workload on the testers, how information and daily / weekly deliverables were delivered to the client etc.

3.2 Types of testing conducted

This section would mention any specific types of testing performed (i.e.) Functional, Compatibility, Performance, Usability etc along with related specifications.

3.3 Test Environment

This would contain information on the Hardware and Software requirements for the project (i.e.) server configuration, client machine configuration, specific software installations required etc.

3.4 Tools used

This section would include information on any tools that were used for testing the project. They could be functional or performance testing automation tools, defect management tools, project tracking tools or any other tools which made the testing work easier.

4. Metrics

This section would include details on total number of test cases executed in the course of the project, number of defects found etc. Calculations like defects found per test case or number of test cases executed per day per person etc would also be entered in this section. This can be used in calculating the efficiency of the testing effort.

5. Test Results

This section is similar to the Metrics section, but is more for showcasing the salient features of the testing effort. Incase many defects have been logged for the project, graphs can be generated accordingly and depicted in this section. The graphs can be for Defects per build, Defects based on severity, Defects based on Status (i.e.) how many were fixed and how many rejected etc.

6. Test Deliverables

This section would include links to the various documents prepared in the course of the testing project (i.e.) Test Plan, Test Procedures, Test Logs, Release Report etc.

7. Recommendations

This section would include any recommendations from the QA team to the client on the product tested. It could also mention the list of known defects which have been logged by QA but not yet fixed by the development team so that they can be taken care of in the next release of the application.