The objective of this blog is to reflect my experience on defining a test strategy during the deployment of an on-demand application. Will be high-lighting few important activities which were key in an on-premise implementation but now became obsolete in an on-demand deployment.

Though the reflection is based out of Ariba on-demand deployment, the below discussed factors remains same for most of the on-demand application deployment.

  • Test script steps:

While writing the test scripts, the best practice in an on-demand application deployment projects would be to document the steps at a higher level instead of documenting the test scripts at a detailed level.

For example:

In any typical test script, the step description may be mentioned as below to create requisition:


Click – > Home – > Create – >  Select ‘Requisition’ in the drop down list.

However when Ariba on-demand application moved on from their classic screens to new user interface, the above detailed step became less efficient as there are easy way to maneuver for creating the requisition in the new user interface.

So it is better to write the same step as: Create requisition using the links in the home screen.

  • Automated testing:

In an on-premise implementation, in order to minimize the testing efforts the project team will automate the test scripts. There are various tools available for this and SAP’s prescribed tool is E-CATT. Such automated testing cannot be leveraged in an on-demand application deployment. On-demand application features, screens and fields are controlled by the product provider. So any effort in creating the automated test scripts would be a wasted effort. For example, when Ariba on-demand application moved on from their classic screens to new user interface, most of the test scripts which were created based out of the classic screens were of no use and were re-done using the new user interface.

  • Scope of testing:

The scope of testing in an on-demand deployment project needs to be carefully defined. Instead of testing each business processes, it is sufficient to test only the custom fields, enhancements and the interfaces. It is seldom necessary to test the core business processes. The core business processes shall be tested to validate how the data appears in print preview and to check the field value visibility.

The points discussed in this blog may appear trivial however it is suggested to consider these aspects in order to minimize the testing effort involved in an on-demand application deployment.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply