Operational acceptance testing

Operational Acceptance Testing (OAT) is a new type of testing in the market. This is nowadays in very much demand in support and maintenance type projects. In this type of testing we only concentrate about the operational readiness of the system which would be supported or become the production environment later. Hence, it is also known as operational readiness testing. The functional testing of application should not be included or merged in OAT. This may include checking the backup facilities, maintenance and disaster recovery procedures. In OAT we play with those environmental things which our application uses to run smoothly. For a mixed/ hybrid architecture application, this may include: window services, config files, web services, XML files, COM+ components, web services, IIS, stored procedures in databases, etc. This type of testing should be conducted before the user acceptance testing. The approach to be used in OAT is:

Build the system,
Deploy the application,
Supportability of the system.
Validate the backup procedures setup for system

Then check how our application is behaving and moreover how our system is behaving in these conditions? Are the backup procedures setup for emergency situation working properly?

For running the OAT test cases, the tester should have exclusive access to the system/ environment. This means that a single tester would be executing the test cases at a single point of time. Here breaking the system means; making the application dependent things (listed above) inaccessible to the application. Like, stopping the window services, deleting the SP in databases, taking the DB off-line and then access the system/application. So, this clearly indicates that this is a destructive type of testing.

For OAT we should define the exact OR quality gates; Entry and Exit Gate. This should list down all the activities which would be part and covered in the different phases of testing. The main emphasis should be on the operational part of the system.