HistoryViewLinks to this page Revision from: 2013 April 25 | 04:16 pm
This is the revision from 2013 April 25 at 04:16 pmView the current live version of the article.

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


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