Arunkumar Khannur's Software Testing Knowledge Center
2.10 Acceptance Testing

Acceptance testing is the activity performed by the client at his site, possibly involving the representative of the development team. It is a black box testing at client site with test cases possibly written by the client based on system test cases. This document briefly explains the various activities performed as part of Acceptance Testing.

The purpose of acceptance testing is for the users to verify that the system or changes meet their original needs. The emphasis is on evaluating the system via normal business circumstances, but in a controlled testing environment.

This is a formal testing conducted to enable users, customer, or other authorized entity to determine whether to accept a product or product component.
  • The acceptance testing may take place in different forms. Typical forms of acceptance testing are:User acceptance testing which typically verifies the fitness for use of the system by business users
  • Operational (acceptance) testing which is the acceptance of the system by the system administrators. Operational (acceptance) testing includes testing of- Interoperability, backup/restore, disaster recovery, user management, maintenance tasks, periodic checks of security vulnerabilities, performance benchmarking in real environment etc.
  • Contract and regulation acceptance testing is performed against a contract’s acceptance criteria for producing custom developed software. Acceptance criteria should be defined when the contract is agreed. Regulation acceptance testing is performed against any regulations which must be adhered to overnmental, legal or safety regulations

The scope of acceptance testing shall be clear. Else thiswould result in extended acceptance testing period and warranty with no extra revenue. It is nice to address this issue related to scope of acceptance testing at the initial phases of software development, especially at the time of requirements review. This involves arriving at Test Success/Completion Criteria and also deciding on testing needs so as to include the business processes, help desk functions (including knowledge base and procedures), backup and recovery, disaster recovery features, system administration tools, specialized hardware, maintenance and operation procedures, year-end and quarterly reports, and other user documentation.

In some cases, it may be difficult or impractical to test a given requirement such as verifying peak time performance in banking application, system reliability during festival season sales on business to customer site. In such situations, a method of verifying such requirements should be established. These un-testable requirements should be included in a test procedure/script(s) and verified during or just prior to commencing Acceptance Test. The method of verification and appropriate evidences and supporting documentation should be documented. These verification methods may include code inspection, simulation using test tools, or, as a last resort, a release note and its content. These activities shall be carefully carried out, especially when client includes claim for any damages resulting from failure of the requirement.

The criterion for acceptance is a critical decision that must be documented. Although not all criteria may be identified during the planning phase, the majority should be documented as part of the Request for Proposal (RFP) and/or contract. Acceptance criteria typically include (but are not limited to) satisfaction of all requirements (as stated in the RFP/ contract and any associated change orders), approval of all deliverables, and satisfaction of all performance requirements. Some projects require the system to be in production for a specified period of time (to test system stability and its ability to satisfy the user's business needs) prior to conferring acceptance.

Acceptance testing shall commence after:
  • Successful completion of system and regression and all critical errors have been addressed
  • An updated version of the code has been delivered to the Configuration Manager, installed under configuration control, and a full backup of the system has been taken
  • All test data has been delivered to the Configuration Manager, placed under configuration control and loaded to the system
  • The requirements and design documents are in final format
  • The sponsor, users and any other participating stakeholders have been briefed on their roles and responsibilities during this test phase.
  • An overview of the testing procedures and methods should be presented to ensure all parties are aware of the expectations
  • A formal Go/No-Go Decision should be made to enter into Acceptance Testing. This may be part of the prior test phase's exit decision (from System, Performance, or Regression), or may be a standalone decision
  • All participants have been briefed on the any special expectations/criteria specified in the proposal and/or contract.
  • Acceptance criteria is documented, typically in the proposal and/or contract. Also, these criteria are discussed and any interpretations or clarifications are made before beginning of testing. It is recommended to document all these agreements on interpretation. Also, while documenting it is better to check whether such criteria are testable and objective. Also, where possible, specific test cases or procedures should be identified to ensure traceability and proof of satisfaction.
Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
Skype: arun.isqt