Hi and welcome to the introduction of web automation in Leaptest.
In this video I will introduce the basics of Leaptest and show you some examples of how to automate web testing.
The first test case looks like this:
When I run the case, a browser will open and navigate to amazon.com. On the web site it enters LEGO in the search field and selects the LEGO Star Wars category. In the list of LEGO star wars products, it opens one of the products and on the detail page we test if the product is in stock or not.
Let’s start with the beginning.
I have selected “Projects” in the main menu on the left, which gives me a list of all existing projects. In this case I only have 1 project named “Web – Introductions”. A project is the highest level of category when you organize your test cases.
I’ll create a new project.
In the Project popup I can select a Name for the project, and add a Description. I can also specify a default environment which is important when the test cases should run on remote environments – more about this later.
I can also select if I want to record videos when the test cases run and specify the maximum time that a test case is allowed to run for. I’ll just keep the default and press “Save”
Under the new Project, I select to create a new test case by clicking new case. I specify a title and select the case type “Web application”. This ensures that we have the right perspective in the case and that we have access to the web automation features.
Test cases in Leaptest are flows made up of building blocks, and you design and maintain the flows on the design canvas. When you create a new test case, you only have one building block to start with – The Start building block. You can move the building block around on the canvas, and you can zoom and center using the buttons in the lower right corner of the canvas.
When we build a flow we start by pulling the connector on the start building block. The connector is flexible and we can add the next building block where ever we want. When I release the connector, the building block menu pops-up and shows all the categories of building blocks. I can either open a category and select a building block or just use type ahead if I know the name of the building block.
In this case I’ll open the web blocks and select the Start Web Browser building block.
- Add Start Web Browser block
As we can see there is a green wire pointing from the Start block to the Start Web Browser block, which tells the test case to start executing the Start block, and once finished hand over the execution to the Start Web Browser block. So you could say that the green wires or arrows drives the execution of a flow.
All the web blocks are using the Selenium webdriver as the engine, so when ever one of the web blocks executes as part of a flow it is actually producing Selenium code under the hood.
The Start Web Browser building block is in most cases the first building block added when doing web automation. In the block you can select which browser to use for the test case, and you can specify the URL to navigate to. In this case we will use Chrome and specify amazon.com as the URL. Now we have a small skeleton for a test case that will open a browser and navigate to amazon.com.
Once the web site is opened we want to set focus in the search field on amazon.com, as shown in the start of this video. To do this we add a Click Web Element block after the Start Web Browser block. This block will click a web element when the test case is running, and we can select the element by clicking
“Select web element to click” followed by “capture new element”. We then select what browser to capture the elements in, and browser will open using the URL specified in the Start Web browser block.
In the browser I can easily select an element just by hovering the elements on the web page. When I hover a selectable element, it is highlighted with a blue border. In this case I will select the search field by hovering this and then click the mouse. This will capture the element and an image of the element is shown in the building block. In this case a white field!
Let’s run the case
Browser opened, page loaded and test case done!
It’s called a preview run when we start the test case from the editor. After the test has run we get access to a video recording of the test case, and we can follow the execution of the flow by watching the orange border around the building block as the video plays. We can also see the activity log, and by clicking the individual log entries we can see which building block was responsible for writing the individual log entry in the editor window.
The test case ended in status Fail, which is the default if we are not explicitly telling the test case to Pass -more about this later.
The next thing to do is to add the search term into the search field on amazon.com. We do this by adding a Type Web Text block, and insert the search term we want inserted in the Text Value field.
- Add Type Web Text block
- Add “LEGO” to Test Value field
When we add “LEGO” to the search field, a drop down containing the matching product categories is shown. We would like to click on the “LEGO Star wars” category.
I add yet another Click Web Element block and select capture a new web element. In this case, the web element is not displayed in the browser because the drop down is closed. I start by disabling our capture functionality in the Capture mode box. This allows us to use click and navigate on the web site without capturing elements. In this case I add some text to the search field, and the drop down is now shown.
If I click the Capture mode window to re-enable capturing, the drop down will again disappear so I use CTRL+F1 to re-enable capture mode. This allows me to select the right category – LEGO Star Wars.
Let’s run the test case.
Notice that the browser that was opened when we ran the test case in preview mode, is still opened and is now used for capturing elements in. This means that
you can run your test case in preview mode to make sure that the web page you are capturing from is in the correct state.
We now landed on the product page for LEGO Star Wars which contains a long list of products, and we want to go to the details of one of the products.
To click the right product we again add a click web element block, and capture a new element.
I turn off capture mode to scroll down the page. Once I see the right product I re-enable capture mode and capture the product. In this case the Darth Vader Building Kit.
On the product page we will use a Find Web Element to search for the “In Stock” element.
I select ‘capture a new web element’ and deactivate capture mode to navigate to the product page. Then I’ll re-activeate capture mode and select the “In Stock” element.
If the element is found, the green connector at the top of the Find Web Element will be triggered, so we add a Pass block to this connector.
This will end the test case in status passed. If the element is not found, the “Not found” connector is triggered. We can continue the flow by adding more building blocks to the “Not found” connector. We could for instance check details about lead time, but in this case we are just gonna fail the case, by adding a Fail block.
We have now build the entire case and we are ready to run the case.
The product was found and the product is In Stock, so the test case is passed.
This test case shows the basic principles of the web blocks in Leaptest. No coding required, just use the building block to instrument the flow engine.
Let’s look into another web automation case that will show more of the features in the Web blocks.
I have a login form, and when I supply the correct username and password and submit the form I get a confirmation message telling me, that my login was correct.
The test case looks like this.
And this is how it looks when we run the case.
Let’s start by deleting everything on the canvas and build up the case again.
- Delete all blocks except Start block
I start by adding a Start Web Browser and add in the URL from the Clipboard.
You can find the URL in the transcript for this video.
First, we want to set focus in the username field, so I add a Click Web Element and capture the user name field.
- Add Click Web block
- Capture username field
Then I add a Type Web Text to insert the username.
Now I could just insert the username, but instead I want to read the username and password from an Excel file. I add a Read Excel block
When I click the Browse button I can select an excel file. I have prepared one in advance, and when I click “Open” the file is added into the block. When I click Define, the Excel sheet is opened, and I can see the data in the file.
In this case I have 2 columns: ‘username’ and ‘password’. I have one data row, but I could have added more if I needed this. I define the data range by dragging with the mouse and check the “Use first row as header” and click Save. As we can see the columns from the Excel file is now added as properties on the Read Excel block allowing easy access to the data in the excel sheet.
I only have row of data so I’ll keep the “First Row” setting in the methods field. You can find much info about this type of datadriven tests in the Learning Center on Leaptest.com.
To add the value of the username to the Type Web Text I just pull the connector from the username property onto the Text Value field. When the test case runs, the value is read from the Excel sheet and transferred to the Type Web Text block.
Another way of doing this is to pull the connector to the Add Field area in the Type Web Text block. This allows me to use the username value as a token in the Text Value, so I can compose the exact text I want to insert into the login form. To use the token I right click in the Text value field and select “field 1”
When we look at the login form we can see that I can use a simple TAB to navigate from the username field to the password field, so I don’t have to use another Click Web Element to set focus in the password field. To insert a TAB in the Text Value field I activate Capture on the block, press TAB, and then deactivate Capture.
The next thing to do is to add the password value as a field as well.
We are not done yet, but let’s just see how the test case looks when it runs.
The values were correctly transferred from the excel sheet into the form. Next we need to click the login button. We will use a Click Web Element and capture the button.
Now the form is submitted and we need to confirm that we have a correct login. We will use a Find Web Element block to search for the confirmation message.
I turn off Capture mode to submit the form. Then reactivate capture mode to capture the confirmation message.
In this case it’s important to make sure that we are capturing a web element that contains the confirmation message.
This brings me to the topic of locator strategies. When we capture web elements, what we are actually capturing is a set of properties and values, that uniquely locates the element we have captured. So when we capture the confirmation element, it could be that the element is uniquely identified by the position on the page, by an ID for a DIV-tag or simply by the text value. Each of these different ways of uniquely identifying an element is called a strategy, and you have the
option of selecting between different strategies and changing them if needed.
If I click Edit Web Element on the captured confirmation text, the Web Editor is opening. We will not cover all the functionality in the Web Editor in this video, but just look at the different strategies. When we capture a web element, Leaptest generates a number of different strategies that you can select from. All the strategies are listed in the left pane when the Web Editor opens.
Each strategy has a short description that can help to select the right strategy. In this case we can see that we can select the box containing the confirmation message by simply finding the first H4 tag on the page. Or we can find it by finding a H4 with a CSS class named subheader.
The third strategy looks like the one we want. This strategy will look for an H4 tag where the text starts with “Welcome to the Secur”. Selecting this strategy means we will only find the element if this text is present, which in turn means that we had a successful login.
I Save our new selection, and add a Pass block to the Find Web element top connector that is triggered if the element is found.
I expand the Find Web Element, to handle the scenario where the confirmation message is not found. Most building blocks contains much more, than what you see when you first add them to the case. By expanding them you get access to a lot of useful features that can be used in various scenarios.
In this case we will add a Fail block to the “Not found” connector, which is is triggered if the element is not found within the time specified in the timeout field.
This could happen if we entered wrong credentials – the test case simple wouldn’t get to the confirmation page, and the confirmation message would never be found.
The test case is now ready to run.
The test case passed. We can see it found the confirmation message with the selected strategy on the page.
This test case is an example of how to use some of the more advanced data-driven blocks, how to compose text values using fields and how to optimize your web test by selecting the right locator strategy.
Now I will turn the attention to the scheduling and reporting features in Leaptest.
Once you finished designing your test case, you probably don’t want to execute them on your local machine. In this case you define one or more “Environments” which is definitions of machines where you can run the test cases.
When I click Add new, I can specify a title and a description of the environment, and when we are doing web automation, I can select between 3 different types of environments.
I will just briefly introduce each of them:
- The Remote Agent is the Leaptest native setup, with the Leaptest controller sending commands to a machine, where the Leaptest agent is installed. This type of environment can be used both for web testing and for desktop testing and is an option if you have your system under test only available on-premise.
- The second option is SauceLabs which is a cloud provider of Selenium enabled environments. When I select this option I will have to specify my SauceLabs Username and Access Key, so you need to create an account with Sauce Labs to use this option.I can specify the operating system and version, what browser I want to use for this environment and what display resolution I want.The browser settings in the environment will override whatever browser is specified in the test case itself, so by running the same test case on several environments, you can pretty easy perform cross browser testing.
Using SauceLab will get most companies up and running pretty fast, so if you have the option you should consider this. It does require that the machines running at SauceLab has access to the system you want to test or monitor, so if you have an internal test environment behind a firewall it might not be possible.
- The third option is the Selenium Grid, which is a setup that typically runs on-premise. So if your system under test is behind a firewall this might be a good option. A Selenium Grid is basically just a Selenium proxy with a number of selenium agent machines, so when the test case runs in the Leaptest controller, it will send the instructions to the Selenium Grid instead of to a Leaptest agent.You can easily find information about the setting up a Selenium Grid on the internet.
So based on needs and possibilities you can setup these environments in different ways.
Once the environments and test cases are ready we can create a schedule. A schedule is a selection of test cases within a project that is executed by the Leaptest controller on one or more environments.
I will create a new schedule and run through the different options.
On the first tab we have the Title and Description and we can specify if it’s at all enabled or not.
On the schedule tab we can select if we want to run this Adhoc. This setting is used if the schedule should be started from Studio, which means it’s started manually, or if the schedule should be triggered through the API. So if you want to run a set of test cases from either Jenkins, Team City, Bamboo or a similar system, you should create an AdHoc schedule.
If we set the Run Type to ‘Scheduled’ we can define when and how often the schedule should run. We can select the week days, the time window on a daily level, and how often it should run.
On the “Cases to run” tab we can select the project that holds the test cases, and then select the test cases. In this case we have 2 test cases that we can run.
On the environment tab we can select one or more of the environments I talked about previously. So now we have the combination of test cases and environments defined.
We can add one more thing to the schedules which is Actions, that are based on various events that can trigger when a schedule runs. I can add as many actions as I want to, and for each action I have to define the event that will trigger the action. In this case we can select “When automation run is completed”, but there are a few more to select from. Then I can specify the action and depending on the action I get a number of fields presented. In the case of “Send email” I can specify both the received, the subject and the body. Further I get access to tokens that have values based on the scheduled run.
When I click save, the schedule is ready to run, and depending on the environments and the schedule setup, it can start right now running cases and producing test results.
This leads us to the reporting section. I have a list of the existing reports, and I will create new report. I start by giving it a title and then I select the filter. In this case I choose to select by schedule and then I select the schedule we just created. This means the report will only contain the result of test runs from this schedule. I will group the results by date and by result, and then I click Save.
We can now see the results categorized by Date and by the actual test result. If I click an entry, I will get a view of the test case that ran, a video recording of the test run and the activity log for the run. Just as we did in the preview runs.
I can right-click the video to get a link to the video and I can select to export the report in various formats: HTML, Excel and PDF.
The last feature in Leaptest are the dashboards which are visual representations of the report data. The dashboards
are made up of widgets showing data in various formats and types and are very useful to create trend overviews and to overview – for instance – the result of all test runs today.
To get more information about Leaptest, please visit leaptest.com/support or just click the Support link in the
left menu. This will give you access to videos, articles, support chat etc.
Thank you very much.