Acceptance testing

Acceptance testing, a testing technique performed to determine whether or not the software system has met the requirement specifications. The main purpose of this test is to evaluate the system's compliance with the business requirements and verify if it is has met the required criteria for delivery to end users.

• After the system test has corrected all or most defects, the system will be delivered to the user or customer for acceptance testing.
• Acceptance testing is basically done by the user or customer although other stakeholders may be involved as well.
• The goal of acceptance testing is to establish confidence in the system.
• Acceptance testing is most often focused on a validation type testing.
• Acceptance testing may occur at more than just a single level, for example:
  
  1. A Commercial Off the shelf (COTS) software product may be acceptance tested when it is installed or integrated.
  2. Acceptance testing of the usability of the component may be done during component testing.
  3. Acceptance testing of a new functional enhancement may come before system testing. 

  
  
  

  

Types of Acceptance Testing:

1. User Acceptance test: The User Acceptance test focuses mainly on the functionality thereby validating the fitness-for-use of the system by the business user. The user acceptance test is performed by the users and application managers.
2. Operational Acceptance test: The Operational Acceptance test also known as Production acceptance test validates whether the system meets the requirements for operation. In most of the organization the operational acceptance test is performed by the system administration before the system is released. The operational acceptance test may include testing of backup/restore, disaster recovery, maintenance tasks and periodic check of security vulnerabilities.
3. Contract Acceptance testing: It is performed against the contract’s acceptance criteria for producing custom developed software. Acceptance should be formally defined when the contract is agreed.
4. Compliance acceptance testing: It is also known as regulation acceptance testing is performed against the regulations which must be adhered to, such as governmental, legal or safety regulations. 

Acceptance Criteria:  

Acceptance criteria are defined on the basis of the following attributes

• Functional Correctness and Completeness
• Data Integrity
• Data Conversion
• Usability
• Performance
• Timeliness
• Confidentiality and Availability
• Installability and Upgradability
• Scalability
• Documentation 

Acceptance Test Plan:

The acceptance test activities are carried out in phases. Firstly, the basic tests are executed, and if the test results are satisfactory then the execution of more complex scenarios are carried out.

The Acceptance test plan has the following attributes:

• Introduction
• Acceptance Test Category
• operation Environment
• Test case ID
• Test Title
• Test Objective
• Test Procedure
• Test Schedule
• Resources 

Acceptance Test Report:

The Acceptance test Report has the following attributes:

• Report Identifier
• Summary of Results
• Variations
• Recommendations
• Summary of To-DO List
• Approval Decision

Adhoc Testing

Adhoc testing is an informal testing type with an aim to break the system. This testing is usually an unplanned activity . It does not follow any test design techniques to create test cases. In fact is does not create test cases altogether! This testing is primarily performed if the knowledge of testers in the system under test is very high. Testers randomly test the application without any test cases or any business requirement document.

Adhoc Testing does not follow any structured way of testing and it is randomly done on any part of application. Main aim of this testing is to find defects by random checking. Adhoc testing can be achieved with the testing technique called Error Guessing. Error guessing can be done by the people having enough experience on the system to "guess" the most likely source of errors.

This testing requires no documentation/ planning /process to be followed. Since this testing aims at finding defects through random approach, without any documentation, defects will not be mapped to test cases. Hence, sometimes, it is very difficult to reproduce the defects as there are no test-steps or requirements mapped to it.

 
When execute Adhoc Testing?

Adhoc testing can be performed when there is limited time to do elaborative testing. Usually adhoc testing is performed after the formal test execution. And if time permits, adhoc testing can be done on the system).Adhoc testing will be effective only if the tester is knowledgeable of the System Under Test. 

Types of adhoc testing 

There are different types of Adhoc testing and they are listed as below:

1. Buddy Testing: Two buddies, one from development team and one from test team mutually work on identifying defects in the same module. Buddy testing helps the testers develop better test cases while development team can also make design changes early. This kind of testing happens usually after completing the unit testing. 
2. Pair Testing: Two testers are assigned the same modules and they share ideas and work on the same systems to find defects. One tester executes the tests while another tester records the notes on their findings.
3. Monkey Testing: Testing is performed randomly without any test cases in order to break the system.  

Best practices of Adhoc testing

Following best practices can ensure effective Adhoc Testing.

Good business knowledge

Testers should have good knowledge of the business and clear understanding of the requirements- Detailed knowledge of the end to end business process will help find defects easily. Experienced testers find more defects as they are better at error guessing.

Test Key Modules

Key business modules should be identified and targeted for adhoc testing.. Business critical modules should be tested first to gain confidence on the quality of the system.

Record Defects

All defects need to be recorded or written in a notepad . Defects must be assigned to developers for fixing. For each valid defect ,corresponding test cases must be written & must be added to planned test cases.

These defect findings should be made as lesson learned and these should be reflected in our next system while we are planning for test cases.

Conclusion:

The advantage of Adhoc testing is to check for the completeness of testing and find more defects then planned testing. The defect catching test cases are added as additional test cases to the planned test cases.

Adhoc Testing saves lot of time as it doesn't require elaborate test planning , documentation and test case design.