Operational acceptance testing

Operational Acceptance Testing (OAT) is a new type of testing in the market. This is now-a-days 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:

1. Build the system,
2. Deploy the application,
3. Break the system.
4. 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) unaccessible 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.

The main advantage of OAT is also to test the exception logging methods used by the application. Because, whenever there would be any system failure, it would write/ log an exception. So, automatically the exception logging part of application will be tested.

Let us understand this with an example now: Say for there is a new production environment which need to be setup. The application is a 3 tier application and has a mixed architecture (as the legacy application being built in VB 6/ ASP and the later enhancements in .Net technology). And we need to perform the OAT for this environment. We will first identify all the environment related things which our application is using. For a simple example, let say our application is using window service to validate/ authenticate the user credentials. This window service takes the input from user and matches the credentials fetched from the database. What if this window services stops incidentally? This would surely be a problematic situation. But, as a proactive measure there is provision to deal with this situation. A mail with service details will be shot to responsible team for corrective action.

So, now our OAT test cases would become any of case give below:

1. Stopping the window service. Stop the responsible window service and then try to access the application.
2. Taking Database off-line. Take the DB off-line and then try to access the application.

In both the scenarios, when user access the application with valid credentials would result into failure/ crash. The mail will be automatically sent to the responsible team for taking the corrective action. So, this will help us to validate the backup procedures setup for any emergency.