Telerik blogs
Test StudioT2 Light_1200x303

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.

Four icons representing the components of Test Studio’s remote execution solution: The green Telerik icon - labeled ‘Test Studio’ and, under it, three black-and-white icons: a server with a turning circle that’s labeled ‘Execution server’, a calendar that’s labeled ‘Scheduling server,’ and a box that’s labeled ‘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).

A single computer running Test Studio with scheduling server, execution server, and storage server

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.

The simplest remote testing configuration: Two computers joined by a line. One computer is running Test Studio and the scheduling/storage servers. The other computer is running an execution server

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).

A single computer running Test Studio and the scheduling server connected to three computers running execution server

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.

A computer running just Test Studio that is connected to two computers running scheduling server: One scheduling server is labeled “Scheduling Server Accounting” and the other is labeled “Scheduling Server Marketing.” The Accounting Scheduling Server is connected to three computers, each running an execution server {the three execution servers are labeled “A/R,” “Invoicing,” and Finance}. The Marketing Scheduling Server is connected to two computers, each running an execution server, one labeled “Social Media” and the other labeled “Campaign Scheduling”

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.

On the right is a cluster of computers: One is running Test Studio and is connected to two other computers running execution server (one is labeled “Social Media” and the other is labeled “Campaign Scheduling.” On the left is a more complicated architecture: There is a computer running Test Studio connected to two scheduling servers (one labeled “Accounting” and one labeled “Finance”). The Accounting scheduling computer is connected to two computers running execution server, labeled “A/R” and “Invoicing.” The Finance scheduling server is connected to a computer running execution server, which is also labeled “Finance”

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.

Peter Vogel
About the Author

Peter Vogel

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter also writes courses and teaches for Learning Tree International.

Related Posts


Comments are disabled in preview mode.