Automation Plan Execution Environments

Sometimes the execution of an AutomationPlan requires a certain type of environment. For example, an AutomationPlan could be created for testing an application using Firefox, DB2, and Tomcat on Linux 64bit architecture. Another AutomationPlan could be created for testing the same application using Safari, Oracle, and Websphere on Windows 32bit architecture.

The parameter definitions (oslc_auto:parameterDefinition properties) for these AutomationPlans are used to specify the input parameters that should be provided to the application, such as the username and password required to log into the application and data that should be entered into various HTML forms. The parameter definitions for both AutomationPlans are likely the same. They are also likely to be defined during design and construction of the AutomationPlan.

But on the other hand the execution environments for each of the AutomationPlans are different, and may need to be determined at a later time, perhaps just-in-time immediately before the AutomationRequest is created. Its also common for the environment to be defined and provisioned in a system that is external to the Automation Provider, such as a virtualization or cloud deployment provider.

In this type of scenario it is convenient to conceptualize the environment as a resource having a URI rather than a collection of input parameters. This allows the deployment provider to understand and prepare for the execution in advance (before it receives input parameters for the execution) and to also provide an opportunity to “map” the environment to actual resources, which may require some reconciliation.

Contents

• Automation Plan Execution Environments
  • Scenario

Scenario

1. Test architect creates a test case and defines the input parameters for the test
   • credentials to login to the application
   • phone number
   • text for a message to send from the application (“hello world”)
2. Test architect