The Architecture of Remote Execution With Test Studio

To start doing remote testing, all you need to do is configure another computer to act as your execution server.

If you’re running scheduled tests with Test Studio, then you’re already running all the Test Studio components that let you offload test execution onto another computer—it’s just that you’re running all those components on the same computer.

To offload running tests to another computer, you just need to take advantage of Test Studio’s remote testing execution capabilities to distribute those components over multiple computers. Specifically, all you need to do is move Test Studio’s execution server to a different computer than the one you’re using for Test Studio itself.

The Components of Remote Testing

While moving Test Studio’s execution server to another computer is the first step in enabling remote testing, Test Studio gives you four components to create the remote testing architecture you need: Test Studio itself, scheduling server, execution server and storage server.

Test Studio is where you create both the collections of tests (called “test lists”) that you want to run remotely and the schedules that control when (and on which computers) those test lists will be executed. You can also, from Test Studio, trigger the execution of an “ad hoc” test run that you want to execute on a remote computer right now.

A scheduling server holds the schedules you create in Test Studio and directs the execution servers to run your test lists. You may have a single scheduling server (typically on the same computer as Test Studio) or, as you’ll see, you may want to set up multiple scheduling servers, all managed from Test Studio. Each scheduling server controls one or more execution servers.

Execution servers are the workhorses of the remote testing components—execution servers are the components responsible for actually running your test lists. You may create multiple execution servers because you want to:

• Set up multiple environments to run your tests, with each execution server implementing one of those environments (though a scheduling server makes it easy to run a test list on multiple browsers on a single execution server)
• Run your tests in parallel on multiple servers to have your tests finish sooner (a scheduling server will automatically distribute your tests over the execution servers you choose)

The storage server holds the test lists you create in Test Studio (and that the execution servers run) along with the results of those test runs. The storage server is used both by Test Studio itself and Test Studio’s web-based Executive Dashboard to report the results of your test runs.

Whatever architecture you create for remote testing, Test Studio is your user interface to all these components. Test Studio lets you create your tests, assemble them into test lists, schedule those tests to run and review the detailed results.

Your First Remote Testing Architecture

You’ve been using all these components even if you’ve only been doing “local testing”: Your Test Studio computer (acting as a scheduling server) has been giving work to just one execution server (itself) and storing the results in the storage server (also your Test Studio computer).

The simplest architecture for remote testing just involves two steps:

• Installing the Test Studio runtime on the remote computer to create an execution server
• Telling your new execution server on which computer it can find Test Studio (along with its scheduling and storage servers)

Once you’ve done that, you can start delegating test runs to your execution server from Test Studio.

Eventually, you may want to create more execution servers to handle different testing environments or to run tests in parallel. As you set up each execution server, you’ll need to connect it to a scheduling server (which, at this point, is probably still your Test Studio computer).

Adding Scheduling Servers

Once you start doing remote testing for several different teams or applications, though, the schedules on your Test Studio computer can start getting complicated, hard to read and hard to manage. One way to address that problem is to set up some other computers to act as scheduling servers, with each scheduling server holding a schedule for a different team or application.

Now, from Test Studio, you can connect to the scheduling server you want to manage as when you need to adjust or review your schedules. You’ll still only need one storage server, though, running on your Test Studio computer, so that all your test results from all your execution servers are gathered together in one location.

In the end, the key criteria for your remote testing architecture is that the architecture makes sense to you. For example, giving each team its own Test Studio computer and enabling the teams to manage their tests on their own scheduling and execution servers might give you the combination of flexibility and independence that’s right for your teams, even if some teams’ execution servers aren’t constantly executing tests.

Obviously, Test Studio provides a very flexible (and reliable) framework for building the remote testing architecture you need. With this much flexibility, the key question is “What works for you?”—because you can have whatever you want.