Hi

In this video, we will a take a look at how to schedule web cases. The idea with scheduling is, that once you have a set of test cases designed you want to be able to run them repeatedly and maybe on different operating systems and with different browsers.

A schedule in Leaptest is a selection of test cases, that is executed on one or more environments.

The schedule can be of Type “AdHoc” which means it will be triggered either manually from Leaptest Studio or through the Leaptest API.

If it is of type “Scheduled” then you can setup when and how often it should run.

If we have a set of web cases defined and we want to run them on remote computers on multiple occasions, then we create a Schedule.

—-

The first thing to look at when we setup a schedule is the defined environments. When you click “Environments” in the left menu, you will get a list of all defined environments.

Think of environments as the definitions of where you can and will run your test cases. Sometimes you want to run them locally, sometimes on a virtual machine behind your firewall and sometimes use an external, cloud-based provider to test your web site.

It’s all based on the defined environments.

When we create a new environment, we can select between 3 different types of environments. I will go through these one-by-one.

—

The first one named “Remote (Agent)” is using the components of Leaptest only. Let’s have a look at the components in a simple drawing.(Presentation attached). Leaptest Studio is used to create and maintain web cases etc. and everything is saved on the controller, incl. any schedules that we add.

The controller will keep track of the schedules and make sure to execute the test cases at the specified time and with the correct frequency. Schedules can also be of type “AdHoc”which means they are to be triggered either manually or through the Leaptest API. The controller will still be responsible for executing the sche

The controller will send instructions to the machines where the Leaptest agents are installed. In the case of a web test, the agents will perform whatever is defined in the case by using a selenium driver, that is installed as part of the agent installation. So if a web case starts with a Start Web browser block, the agent will open a new instance of the browser using the selenium driver.

If you are using the “Remote (Agent)” environment type you just have to install the Leaptest agents on a number of machines and create an environment for each of these, to get started.

For each agent machine specify the name of these machines or IP of these machines and the port number you want to connect on. When you install the Leaptest agents you can specify the port number as well, and these port numbers obviously needs to match. The same goes for the password which can be specified during installation of the agent and needs to match in the environment settings for the machine.

The Remote (Agent) environments can be used for both web and desktop automation which is not the case for the 2 other options I will go through. We have a dedicated video for setting up schedules for remote agents in the Desktop automation section in the Learning Center on leaptest.com

—

The “Web only – Sauce Labs” is used when you want to run your web case on Sauce Labs infrastructure. Sauce Labs is a cloud based provider of machines and devices, that all supports selenium which is the engine used for the web blocks in Leaptest.

The diagram for Sauce labs looks like this. (Presentation attached). Again all test cases and schedules are defined using Leaptest Studio and are saved on the Leaptest Controller.

When a schedule is executed, the Leaptest Controller uses the settings in the Sauce labs environment to send instructions to Sauce Labs. Sauce Labs will then fire up an environment matching the settings in the environment and use a Selenium Grid – which I will come back to in a while – to run the test case on the selenium agent.

Te really nice part about this setup is that you don’t have to install and maintain any agent computers your self, and you get access to all kind of devices and operating systems that it would take an army to administer in an internal setup.

To use this environment type, you need to create a Sauce Labs account. You have the option to start with a free trial, if you are not sure if this is the right setup. Once you have an account, you need to go onto the Sauce Labs web page and into the User settings area to get the Access Key.

(Browser opened on saucelabs.com).

On my demo account I’m in the User Settings and can get the access key from here.

(Leaptest)

The next thing to specify is the Operating System and the version. Please check the notes added to this video-post to see the level of support for
all operating systems, as we are constantly adding more options.

For each environment you can specify what browser to use when a web case is executed on the environment. This settings will override the browser specified
in the Start Web Browser building block in the test case. This means you can run the same test case against multiple Sauce Labs environments,
where the only difference is the selected browser. This is an easy way of doing cross browser testing.

It is also possible to specify the screen resolution which can be important if the application is changing based on the size of the view port.

I have prepared a Sauce Labs environment, and I will use this, to run a web case I have prepared in advance, in this environment.

This simple web case will open a browser, navigate to Leaptest.com and find the Leaptest logo. If the logo is found, the test case will pass.

To run this web case I go to the Schedules and create a new schedule. I select AdHoc, which means we can start it manually from Studio or trigger it from the API. In this case we will start it manually.

On the “Cases to run” tab I select the “Schedule demo” project and select the “Sauce Labs Demo Case”. I click Save, and the schedule is now in the list of schedules. I right-click the schedule and select “Run now”.

We can see that the schedule is first getting queued which means it’s waiting to be executed. Then it starts running, which means that Sauce Labs is now starting an instance of windows 10 to run the web case on.

If we go to the reporting section, we can see the result. I have created a report based on the “Scheduled demo” project, and we can see the entry from the run.

When I open the report I can see the result of the schedule that just ran. When I double click a report entry I get to the details for this test case run. I can see the test case as it looked at the time when the schedule was triggered, and I can see the the activity log and click through it to debug what happened in case the test case failed.

So using the Sauce Labs environments I can execute a number of web cases against a lot of different combinations of operating systems and get the result back into Leaptest. The amount of work to have this setup is not big. Just install Studio on the local testers machines and have the controller service on a server, then you can start executing web cases on Sauce Labs.

Be aware that to use Sauce Labs it requires, that the machines at Sauce Labs has access to the web app that you want to test.

—

The third and last option in the environments is the “Web Only -. Selenium Grid“. (Presentation attached)

The Selenium grid is part of the Open Source Selenium project and contains a Selenium Hub and a Selenium agents. You could say that the Selenium Grid
is an on-premise version of Sauce Labs, but you just need to install the agent machine yourself.

When a schedule is executed on the Leaptest Controller, the instructions are pushed to the Selenium Hub that then distributes this to the Selenium agents machines. Sometimes the Selenium Hub and an agent is installed on one single machine, and sometimes there are dozens of Selenium agents machines available.

The selenium hub is responsible for sending instructions to the agents and to collect and send the result of the test cases back.

(Leaptest)

If you already have – or will install – a Selenium Grid, you just have to specify the address of the Selenium Grid/Hub and then you can select browser, version and resolution. You obviously need to make sure that the correct browsers are installed on the Selenium agent machines otherwise the test cases will fail.

—-

In this video we covered how to create Schedules that can be triggered either manually, through the API or by using a scheduled trigger. We looked at the 3 different environment options available and saw an example of how to run a test case using a schedule on Sauce Labs.

Thank you.