Automation Plan Execution Environments

Sometimes an AutomationPlan needs to be executed in a certain type of environment. For example, an AutomationPlan could be created for testing a web application using Firefox, DB2, and Tomcat on Linux 64bit architecture. Another AutomationPlan could be created for testing the same web application using Safari, Oracle, and Websphere on Windows 32bit architecture. In terms of test coverage you might imagine that AutomationPlans could be created for executing this same test in many other combinations or permutations of browser/database/application server/OS. In this scenario, each such grouping of is called an execution environment.

The set of AutomationPlans for executing a single test case are often identical with the exception of their execution environment. In fact it is typical for a test architect to define their test cases in a generic way that abstracts out the environmental details and focuses instead on the inputs/outputs for the test cases and the expected precondition/postcondition of the system under test. Then at a later time the test architect may define or automatically generate a multitude execution environments and create an AutomationPlan for executing each test case on each environment. The execution environments might also be defined in a separate system such as cloud provisioning or in a virtualization server, and then bound to the AutomationPlans during an execution setup/preparation phase or just in time before execution.

In this type of scenario it is convenient to conceptualize execution environments as resources having URIs and having their own lifecycle that is independent from any AutomationPlans that use them. This allows the Automation Provider to delegate the responsibilities of defining execution environments to an external system, and allows a single execution environment to be bound to multiple AutomationPlans or vice-versa. It may also provide an opportunity to handle execution environments as reconcilable resources.

Contents

• Automation Plan Execution Environments
  • Scenarios
    • Test architect creates AutomationPlans and binds them to execution environments

Scenarios

Test architect creates AutomationPlans and binds them to execution environments

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