An absolute XPath is a full path from the root element to the target element in the HTML document. It starts with a single slash (/). It shows the exact location of the element in the page structure.
Click to reveal answer
beginner
What is a relative XPath?
A relative XPath starts from anywhere in the document and finds elements based on conditions or attributes. It starts with double slashes (//). It is shorter and more flexible than absolute XPath.
Click to reveal answer
intermediate
Why is relative XPath preferred over absolute XPath in Selenium tests?
Relative XPath is preferred because it is less fragile. If the page layout changes, absolute XPath may break since it depends on the full path. Relative XPath uses attributes or conditions, so it adapts better to changes.
Click to reveal answer
beginner
Example of an absolute XPath for a button element:
/html/body/div[2]/div[1]/button
Click to reveal answer
beginner
Example of a relative XPath for a button with text 'Submit':
//button[text()='Submit']
Click to reveal answer
Which XPath starts from the root element and shows the full path?
ARelative XPath
BAbsolute XPath
CCSS Selector
DID Selector
✗ Incorrect
Absolute XPath starts with a single slash (/) and shows the full path from the root.
Which XPath is more flexible and less likely to break if the page layout changes?
ARelative XPath
BTag Name Selector
CAbsolute XPath
DClass Name Selector
✗ Incorrect
Relative XPath uses conditions and attributes, making it more adaptable to page changes.
What does a relative XPath start with?
A/
B.
C//
D#
✗ Incorrect
Relative XPath starts with double slashes (//) to search anywhere in the document.
Which XPath would be fragile if a new div is added at the top of the page?
AAbsolute XPath
BRelative XPath
CCSS Selector
DName Selector
✗ Incorrect
Absolute XPath depends on the full path, so adding elements can break it.
Which XPath is best to locate a button with specific text?
A/html/body/div/button
B//*[@class='button']
C//div[@id='button']
D//button[text()='Submit']
✗ Incorrect
Using relative XPath with text() function targets the button by its visible text.
Explain the difference between absolute and relative XPath and when to use each.
Think about how page changes affect each XPath type.
You got /5 concepts.
Write an example of an absolute XPath and a relative XPath for a login button.
Use /html/body/... for absolute and //button[@id='login'] or //button[text()='Login'] for relative.
You got /3 concepts.
Practice
(1/5)
1. Which of the following best describes an absolute XPath?
easy
A. It uses CSS selectors to locate elements.
B. It starts anywhere in the document using // to find elements by attribute.
C. It starts from the root node and follows the full path to the element.
D. It only works with elements having unique IDs.
Solution
Step 1: Understand XPath types
Absolute XPath always starts from the root node, indicated by a single slash (/), and follows the full path down to the target element.
Step 2: Compare with relative XPath
Relative XPath starts with double slashes (//) and can start anywhere in the document, not necessarily from the root.
Final Answer:
It starts from the root node and follows the full path to the element. -> Option C
Quick Check:
Absolute XPath = full path from root [OK]
Hint: Absolute XPath starts with / from root, relative with // anywhere [OK]
Common Mistakes:
Confusing absolute with relative XPath syntax
Thinking relative XPath always starts from root
Assuming absolute XPath uses //
Believing XPath only works with unique IDs
2. Which of the following is a correct relative XPath syntax to find a button with text 'Submit'?
easy
A. //button[text()='Submit']
B. /html/body/button[text()='Submit']
C. button[text()='Submit']
D. //*[@id='Submit']
Solution
Step 1: Identify relative XPath syntax
Relative XPath uses // to search anywhere in the document. The expression //button[text()='Submit'] finds any button element with exact text 'Submit'.
Step 2: Check other options
/html/body/button[text()='Submit'] is absolute XPath, not relative. button[text()='Submit'] is invalid because it lacks // or /. //*[@id='Submit'] looks for an element with id='Submit', not text.
Final Answer:
//button[text()='Submit'] -> Option A
Quick Check:
Relative XPath uses // and matches element by text [OK]
Hint: Relative XPath starts with // and matches anywhere [OK]
//ul finds any <ul> element anywhere. li[2] selects the second <li> child of that <ul>.
Step 2: Identify the second <li> in the HTML
The <li> elements are: 1) Home, 2) About, 3) Contact. So li[2] is <li>About</li>.
Final Answer:
The second <li> element inside <ul> -> Option A
Quick Check:
//ul/li[2] = second list item [OK]
Hint: li[n] selects nth child li under the matched parent [OK]
Common Mistakes:
Confusing li[2] with the first li
Thinking XPath selects ul element
Assuming XPath is invalid syntax
Mixing absolute and relative XPath concepts
4. You wrote this XPath to find a login button: /html/body/div/button[@id='loginBtn'] But your test fails when the page structure changes slightly. What is the best fix?
medium
A. Add more parent nodes to the XPath
B. Keep the same XPath; the failure is unrelated
C. Use CSS selector instead of XPath
D. Change to relative XPath: //button[@id='loginBtn']
Solution
Step 1: Analyze the problem with absolute XPath
Absolute XPath starts from root and depends on full path. If page structure changes, the path breaks and test fails.
Step 2: Use relative XPath for stability
Relative XPath like //button[@id='loginBtn'] finds the button anywhere by id, making tests more stable and maintainable.
Final Answer:
Change to relative XPath: //button[@id='loginBtn'] -> Option D
Quick Check:
Relative XPath is more stable than absolute [OK]
Hint: Use // and attributes for stable locators, not full paths [OK]
Common Mistakes:
Adding more parents makes XPath fragile
Ignoring XPath type causes flaky tests
Assuming CSS selector always better
Not updating XPath after page changes
5. You want to locate an input field inside a form, but the form's position in the page changes often. Which XPath is best to locate the input with name='email' reliably?
hard
A. /html/body/div[2]/form/input[@name='email']
B. //form//input[@name='email']
C. /form/input[@name='email']
D. //input[@id='emailField']
Solution
Step 1: Evaluate absolute XPath option
/html/body/div[2]/form/input[@name='email'] is absolute and depends on exact page structure, which changes often, so it's fragile.
Step 2: Evaluate relative XPath options
//form//input[@name='email'] finds input with name='email' anywhere inside any form, making it flexible and stable despite page changes. /form/input[@name='email'] is invalid because it starts from root but form is not root. //input[@id='emailField'] depends on id which may not exist or be different.
Final Answer:
//form//input[@name='email'] -> Option B
Quick Check:
Relative XPath with attributes inside form is best [OK]
Hint: Use //form//input[@name='email'] for flexible, stable locating [OK]
Common Mistakes:
Using absolute XPath that breaks on layout changes
Assuming input has id when it may not
Starting XPath from root incorrectly
Not using // to search anywhere inside form
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.