Introduction
Let's ensure we understand the foundational concepts before delving further into the subjects. Here is a brief introduction if you are unfamiliar with Katalon Studio.
Katalon Studio is a tool that is developed by KM technology. It will also help you automate Web Based Applications, Mobile Applications, and API Testing. It increases the speed of delivery and time to market. Our organization has become better.This product's recording feature is helpful for our testing needs. User-friendliness and AI smart healing capabilities are two of Its most valuable features.
This article explains how to handle Web element locators using Katalon Studio.
Without further ado, let's get started.
Handling Web element locators using Katalon Studio
A locator must be used in Web test automation to identify an element on a Web page when running test scripts. Choosing a good method is crucial for the automated testing of Web applications. There is no one-size-fits-all method for web element locators because they depend fully on the implementation process. Web application frameworks, development practises, software life cycles, and automation leaders' experience can all impact the decision process.
Both Selenium and Katalon Studio depend heavily on a certain approach. So that customers simply have to select the appropriate locator, Katalon Studio offers options to produce relevant locators (XPath, CSS, etc.). In other words, Katalon Studio has completed 80% of the work; users will select the final 20%. Test projects will become robust and scalable due to sound project planning, which will ease the burden on maintenance staff.
The most popular web elements include Labels, Textboxes, buttons, Select, Hyperlinks, Checkboxes, and Radio buttons. There are numerous other types as well. Frame, Dialog, Dropdown, Calendar, and Form are custom elements constructed from other fundamental elements.
💁 We can use one of these methods to locate these components.
🎯 Simple locators include id, name, class, tag, link text, and attribute.
🎯 Combining the above simple locators will produce advanced locators.
✔️ XPath
✔️ CSS
🎯 Using functions in XPath:
✔️ contains
✔️ sibling
✔️ ancestor
Understanding Your Application Under Test
💁 Choosing a great strategy for UI functional automation testing depends up to 80% on the outcome of this phase. Your team must respond to the following queries before beginning any automation testing:
☑️ What types of web technologies are used?
☑️ Which standards does the development team follow?
Which location value is static or dynamic will depend on the responses to these questions. Take ID, for instance. Due to its simplicity and exclusivity on a web page, ID is typically recommended as the ideal locator in Web UI testing. But if it is dynamically constructed at runtime, there is an issue. Various Web technologies use settings that vary when rendering items on a web page. For instance, the default behaviour of ExtJs or Angular frameworks frequently produces dynamic element IDs. Because of this, if your AUT was created utilising these technologies, you may anticipate that IDs are dynamic and shouldn't be utilised as primary selectors. Instead, you should use the Class, Name, or Text properties.
The customs of the development team should also be considered. These static attributes can be utilised as primary locators if the team has adopted the norm of assigning static IDs and names to every element. Furthermore, if an element has parents, siblings, or other children who can be located by static locators, there is no need to locate the element by its static locator. XPath functions are used instead to find the element. Consider this:
<div class="field-group">
<label accesskey="u" for="tl0156">Username</label>
<input class="text medium-field"
id="tl0156" type="text">
</div>
Locate the //label[.='Username']//ancestor::div[1]Locate the //label[.='Username']/following-sibling::inputUnderstanding Application Lifecycles
If the AUT life cycle is too brief and the information is static, absolute XPath, which can be taken from the browser, will do. Finding a better method is not necessary for this kind of job.
However, if the AUT is substantial and has a long life cycle, including the maintenance phase, you must consider the locator approach. A poor strategy could result in a significant loss of time and effort in maintaining and updating test cases.
Using Static Locators
Use them if you've studied the AUT and development norms and are satisfied that all of an element's locators are static. The simplest approach is this. The following illustration
<div class="field-group">
<label accesskey="u" for="login-form-username"><u>U</u>sername</label>
<input class="text medium-field" id="login-form-username"
name="os_username" type="text" value="">
</div>
💁 To find the Username textbox, you can use one of the XPaths shown below:
- Id
//*[@id='login-form-username']
- Name
//*[@name='os_username']
- Class
//*[@class='text medium-field']
- Tag
//input[@class='text medium-field']
- Attribute
//input[@class='text medium-field'][@type='text']Using Uniquely Present Text
If a given element lacks a static location, you may want to use combined locators. Several ideas are provided below.
Label
A message (error message, info message, hint message, etc.), a control (textbox, radio button, text area, etc.), or a tooltip is typically described by a label. A label is often distinct, as displayed in the user interface. Otherwise, it would be difficult for users to distinguish between UI elements. As a result, the label's text is thought to be a strong candidate for the location. It is possible to use the locator's scope to make it easier to read.
Textbox
<input, type="text">Typically, a textbox is used to capture user input. To find the textbox, if there isn't a single static locator, check for references to particular elements. The text next to a textbox frequently makes it easier to understand how it works while viewing a webpage. This method of finding the textbox is effective.
Here are a few textbox examples:
- There is a label outside and next to a textbox. You can choose the best XPath based on where the label is located.
<div class="field-group">
<label accesskey="u" for="tl0156">Username</label>
<input class="text medium-field"
id="tl0156" type="text">
</div>
- The following XPath can be used to find the textbox.
//label[.='Username']/following-sibling::input
//label[.='Username']//ancestor::div[1]//input
//input[@id=//label[.='Username']/@for]
- Textboxes with placeholders or text already in them can appear from time to time.
<input data-selenium="textInput" tabindex="-1" type="text" class=
"SearchBoxTextEditor SearchBoxTextEditor--autocomplete"
placeholder="Enter a destination or property" value="">
To find the textbox, use the 'placeholder' property in an XPath like follows:
//input[@placeholder='Enter a destination or property']Button
A button is often used to respond to user actions like hovering over, clicking, and double-clicking. A button's text is frequently used to identify it, much like a textbox is. The following are some typical web page button examples:
<input accesskey="s" class="aui-button aui-button-primary" type="submit" value="Create">
The 'value' parameter provided the text for this button. Therefore, the XPath should be
//input[@value='Create']
Sometimes the button's text is not taken directly from the attribute's "value." It is a text or label that has been formatted to look like a button, but it is actually just that.
<button type="submit" class="_1ptkf58d" aria-busy="false" data-veloute="book-it-footer-trigger">
<span class="_cgr7tc7">
<small class="_1pqj8ky3">
<div class="_1283fq">
<span>
Book
</div>
</small>
</button>
The button can be found using the XPaths below. Use any one of them.
//span[text()='Book']//ancestor::button[1] *
//button[.//span[text()='Book']] * //button[.='Book']Select
You can choose an item from a list of defined items using a choose (or drop-down) list. The location of a select typically resembles that of a textbox, with the exception that it uses the 'select' tag rather than the 'input' tag.
<label for="tl0023">Priority</label>
<select class="select aui-ss-select" id="tl0023" multiple="multiple">
<option class="imagebacked" value="10000">Blocker</option>
<option class="imagebacked" value="1">Highest</option>
<option class="imagebacked" value="2">High</option>
<option class="imagebacked" value="3">Medium</option>
<option class="imagebacked" value="4">Low</option>
</select>
The select element above can be found using the following XPaths:
//Select[@id=//label[.="Priority"]/@for]//Select[.//option[.="Highest"]]//option[.="Highest"]//ancestor::Select[1]Hyperlink
A hyperlink is a link on a website typically activated by the user clicking on it. A hyperlink appears as text in a different color, with or without underlining. Since the tag is utilised, the location of a hyperlink is quite similar to that of a text or label. Use the 'href' attribute if a hyperlink lacks text or its URL is more reliable than its text.
<a accesskey="`" class="aui-button aui-button-link cancel" href="/secure/ForgotLoginDetails.jspa" title="Press Ctrl+Alt+` to cancel">Can't access your account?</a>
A hyperlink is often located by the text providing it or the 'href' attribute:
//a[@href="/secure/ForgotLoginDetails.jspa"]//a[.="Can't access your account?"]Checkbox
A checkbox is used to receive the "click" action when the tag "input" is used. A checkbox locator typically resembles a textbox in appearance.
<div class="input-list-item input-list-item-checkbox">
<input type="checkbox" class="sm-input sm-input--stretch"
id="tl0056" name="remember_me">
<label class="sm-label" for="tl0056">Remember me</label>
</div>
A label is frequently linked to a checkbox. In order to find the checkbox, we can use the label:
//label[.='Remember me']//preceding-sibling::input[1]//label[.='Remember me']//ancestor::div[1]//input//input[@id=//label[.="Remember me"]/@for]//input[.//following-sibling::label[.='Remember me']]Radio button
A radio button is made to be "clicked," just like a checkbox. Its locator is an exact duplicate of the checkbox locator.
<form name="agreementFormjdk-8u181-oth-JPR" method="post" action="radio"
class="lic_form">
<input type="radio" value="on" id="agreementjdk-8u181-oth-JPR-a"
onclick="">
<label for="agreementjdk-8u181-oth-JPR-a">
Accept License Agreement</label>
<input type="radio" value="on" id="agreementjdk-8u181-oth-JPR-d"
onclick="">
<label for="agreementjdk-8u181-oth-JPR-d">
Decline License Agreement</label>
</form>
On the UI, a radio is frequently displayed with a label. We use the following labels to identify a radio button:
//label[.='Accept License Agreement']//preceding-sibling::input[1]//label[.='Accept License Agreement']//ancestor::div[1]//input//input[@id=//label[.="Decline License Agreement"]/@for]//input[.//following-sibling::label[.='Decline License Agreement']]
34+ registered 
