The Philosophy of a Great Locator

The most common mistake junior automation engineers make is adopting the mindset of "if it works now, it's good enough". This approach leads to tests that are brittle and break with the slightest UI change. A professional engineer doesn't just find a locator; they architect one. A great locator is engineered to be a stable contract between your test and the application, surviving the chaos of constant development.

Consider this reality: modern web applications change constantly. Developers add new features, refactor code, update CSS frameworks, and redesign interfaces. Your locator must be resilient enough to survive these changes while remaining precise enough to find exactly what you need. This requires thinking beyond the immediate moment and designing for the long term.

The Three Pillars of Quality

Before writing a single character of your locator, evaluate your potential approach against these three foundational pillars:

• Uniqueness: Your locator must resolve to exactly one element under all the conditions you are testing. Finding multiple elements when you expect one is a common source of flaky tests and debugging nightmares. This means considering not just the current state of the page, but how it might change with different data, user states, or feature flags.
• Stability and Resilience: This is the most critical pillar and where most automation efforts fail. The locator should be coupled to the element's purpose and functionality, not its appearance, position, or implementation details. It must survive when a developer adds an unrelated container div, updates the CSS framework, or restructures the component hierarchy. Think of it as building a bridge that can withstand earthquakes rather than a house of cards.
• Readability and Intent: A teammate should be able to look at your locator six months from now and understand what it's trying to find and why. Code is read far more often than it's written, and locators are no exception. A locator like [data-testid='confirm-purchase-button'] clearly communicates intent, while //div[3]/div[1]/div[2]/button[1] is meaningless without deep DOM inspection and will confuse anyone who encounters it.

The Locator Strategy Pyramid

To make the best choice every time, follow this strategic pyramid. Think of it as your decision-making framework where you always aim for the highest tier possible, falling back to lower tiers only when necessary.

The Locator Landscape – Your Options

Before diving into the technical details of CSS and XPath, let's survey the complete landscape of locator strategies available to you. Understanding all your options helps you make informed decisions about which approach to use in different situations.

Traditional Location Strategies

• By ID: The classic approach when you have a unique, stable identifier. IDs are fast, reliable, and clearly communicate intent. They're perfect for major page sections, forms, and key interactive elements.
• By Class Name: Effective when dealing with well-structured CSS that uses semantic class names. Particularly useful for components in modern frameworks where classes like .user-profile-card or .error-message have clear meaning.
• By Tag Name: Rarely used alone but valuable in combination with other selectors. Useful for generic elements like finding all buttons or inputs within a specific container.
• By Name Attribute: Essential for form elements where the name attribute provides stable identification. This is especially common in traditional web forms and server-side rendered applications.
• By Link Text: Specifically for anchor tags, this approach finds links by their visible text. It's straightforward but vulnerable to content changes and localization issues.
• By Partial Link Text: A more flexible version that matches parts of link text. Useful when the full text is dynamic or when you want to match based on key words.
• By CSS Selector: The most versatile and powerful approach for modern web applications. CSS selectors can combine multiple criteria, traverse relationships, and handle complex scenarios with elegant syntax.

• By XPath: The heavy artillery of element location. XPath provides unmatched flexibility for complex DOM navigation, text-based selection, and scenarios where CSS selectors fall short.

The key to mastering locators is understanding not just how each approach works, but when to use each one. A skilled automation engineer seamlessly moves between these strategies, choosing the right tool for each specific situation.

CSS Selectors – The Foundation

Before we explore advanced techniques, let's solidify the fundamentals. CSS selectors are your primary tool for element location, and mastering them thoroughly is essential for effective automation.

Basic Selectors Revisited

These fundamental selectors form the building blocks of more complex expressions:

• Element Selector: button selects all button elements. Simple but rarely specific enough for automation needs.
• ID Selector: #login-form selects the element with id="login-form". IDs should be unique, making this highly reliable when available.
• Class Selector: .error-message selects all elements with class="error-message". Remember that elements can have multiple classes, so this selector will match any element where "error-message" is one of its classes.
• Attribute Selector: [type="submit"] selects elements with a specific attribute value. This is incredibly versatile and forms the foundation for many advanced techniques.
• Universal Selector: * selects all elements. Primarily used in combination with other selectors for advanced patterns.

Advanced CSS Selectors

The industry consensus is clear: prefer CSS selectors over XPath when possible. They are generally faster, have simpler syntax, and are natively optimized by browsers. Let's explore the advanced techniques that make CSS selectors so powerful.

Combinators: Building Relationships

Combinators allow you to create precise locators based on the element's position within the DOM hierarchy. Think of them as ways to navigate the family tree of HTML elements.

• Descendant Combinator (space): form .error-message selects any element with class "error-message" that is a descendant (child, grandchild, great-grandchild, etc.) of a form element. This is useful when you want to find elements within a specific container but don't care about the exact nesting level.
• Child Combinator (>): ul > li selects only list items that are direct children of an unordered list. This is more precise than the descendant selector and helps avoid selecting nested list items from sublists.
• Adjacent Sibling Combinator (+): label + input selects the first input element that immediately follows a label element at the same level. This is perfect for form layouts where labels are positioned directly before their associated inputs.
• General Sibling Combinator (~): h2 ~ p selects all paragraph elements that are siblings of and appear after an h2 element. This is useful for selecting content that follows a specific heading or section marker.

Advanced Attribute Selectors

These selectors are invaluable for dealing with dynamically generated attributes, especially CSS classes from modern frameworks where class names might include random suffixes or prefixes.

• Exact Match (=): [class="btn-primary"] matches elements where the class attribute equals exactly "btn-primary". Note that this won't match elements with multiple classes like "btn btn-primary".
• Contains Word (~=): [class~="primary"] matches elements where the class attribute contains "primary" as a complete word. This is perfect for matching one class among many.
• Substring Contains (*=): [class*="error"] finds any element whose class attribute contains the substring "error" anywhere within it. This is perfect for dynamically generated classes like "form-field-error-validation-123".
• Substring Starts With (^=): [class^="btn-"] finds any element whose class attribute starts with "btn-". This is excellent for matching button variants in CSS frameworks.
• Substring Ends With ($=): [class$="-icon"] finds any element whose class attribute ends with "-icon". This pattern is common in icon libraries and component systems.
• Contains with Hyphen (|=): [lang|="en"] matches elements where the attribute equals "en" or starts with "en-". This is primarily used for language codes but can be useful for versioned attributes.

Pseudo-Classes: Targeting State and Position

Pseudo-classes provide powerful ways to select elements based on their state, position, or relationship to other elements. They're essential for handling dynamic content and complex layouts.

• Positional Pseudo-Classes: These help you select elements based on their position among siblings. :first-child selects the first child element, :last-child selects the last child, and :nth-child(3) selects the third child. The :nth-child() selector is particularly powerful, accepting formulas like :nth-child(2n) for even-numbered children or :nth-child(2n+1) for odd-numbered children.
• Type-Specific Positional Pseudo-Classes: :first-of-type, :last-of-type, and :nth-of-type() work similarly to their child counterparts but count only elements of the same type. For example, :nth-of-type(2) finds the second paragraph among all paragraphs, ignoring other element types.
• Negation Pseudo-Class: :not() is incredibly powerful for excluding elements. :not(.disabled) finds elements that do not have the "disabled" class, while :not([aria-hidden="true"]) finds elements that are not hidden from screen readers.
• State Pseudo-Classes: These target elements based on their current state. :checked finds selected checkboxes or radio buttons, :disabled finds disabled form elements, and :focus finds the currently focused element.

Combining Selectors for Precision

The real power of CSS selectors comes from combining these techniques. Consider this example:

form:not(.submitted) .field-group:first-child input[type="text"]:not(:disabled)

This complex selector finds text inputs that are not disabled, within the first field group, of a form that hasn't been submitted yet. While complex, it's still more readable and maintainable than equivalent XPath expressions.

XPath – When CSS Isn't Enough

XPath (XML Path Language) is your powerful, all-terrain vehicle for when the smooth roads of CSS selectors reach their limits. While CSS selectors handle the majority of automation scenarios elegantly, XPath provides capabilities that CSS simply cannot match.

When XPath Beats CSS

Understanding when to reach for XPath instead of CSS is crucial for efficient automation. Here are the key scenarios where XPath is not just useful, but necessary:

Traversing Upwards in the DOM

CSS selectors can only traverse downwards and sideways in the DOM tree. They cannot select a parent element based on its children. XPath breaks this limitation completely, allowing you to navigate in any direction through the DOM hierarchy.

Consider this common scenario: you have a table of products, and you need to click the "Add to Cart" button for a specific product named "Wireless Headphones". The HTML structure looks like this:

<tr class="product-row">
    <td class="product-name">Wireless Headphones</td>
    <td class="product-price">$99.99</td>
    <td class="product-actions">
        <button class="add-to-cart">Add to Cart</button>
    </td>
</tr>

CSS cannot solve this elegantly because it cannot start from the product name and navigate up to the row and then down to the button. XPath handles this naturally: //td[text()='Wireless Headphones']/parent::tr//button[contains(@class, 'add-to-cart')].

Selecting by Text Content

While CSS selectors can match attribute values, they cannot directly select elements based on their text content. XPath's text() function makes this straightforward and powerful.

Examples of text-based selection:

• //button[text()='Sign Up'] finds a button with exactly the text "Sign Up"
• //h2[contains(text(), 'Welcome')] finds heading elements containing the word "Welcome"
• //span[normalize-space(text())='Active'] finds span elements with "Active" as text, ignoring extra whitespace

Selecting by Numeric Position with Complex Logic

While CSS has positional pseudo-classes, XPath provides more sophisticated position-based selection with complex predicates and mathematical operations.

XPath excels at scenarios like:

• //tr[position() > 1 and position() < last()] selects all table rows except the first and last
• //div[@class='item'][position() <= 3] selects the first three items with a specific class

Understanding XPath Syntax

XPath uses a path-like syntax similar to file systems, but with powerful extensions for navigating XML and HTML documents.

Relative vs Absolute XPath

This distinction is crucial for writing maintainable automation code. An absolute XPath (with a single slash /) starts from the document root and specifies the complete path: /html/body/div[2]/form/input[1]. This is extremely brittle and will break if any element in that path changes.

Professional, maintainable XPath is always relative and starts with //, meaning "search anywhere in the document". This approach focuses on the element's characteristics rather than its position in the hierarchy.

Essential XPath Functions

XPath provides a rich set of functions for text manipulation, string matching, and logical operations:

• Text Functions: text() returns the direct text content of an element, while normalize-space() removes leading and trailing whitespace and collapses internal whitespace. contains() checks if one string contains another, and starts-with() checks if a string begins with a specific substring.
• Logical Functions: not() negates a condition, and and or combine conditions, and count() returns the number of matching elements.
• Positional Functions: position() returns the position of an element among its siblings, last() returns the position of the last element, and mathematical operations allow complex position-based logic.

XPath Axes: Navigating the DOM Tree

Axes are XPath's superpower, allowing you to navigate in any direction through the DOM hierarchy. Think of them as compass directions for DOM navigation:

• Upward Navigation: parent:: moves to the direct parent, ancestor:: moves to any ancestor (parent, grandparent, etc.), and ancestor-or-self:: includes the current element in the ancestor search.
• Downward Navigation: child:: moves to direct children (this is the default axis), descendant:: moves to any descendant, and descendant-or-self:: includes the current element.
• Sideways Navigation: following-sibling:: moves to siblings that come after the current element, preceding-sibling:: moves to siblings that come before, and following:: and preceding:: move to any elements that come after or before in document order.

XPath Best Practices

Writing effective XPath requires understanding not just the syntax, but the patterns that lead to maintainable, reliable selectors.

• Be Specific About Context: Instead of //input, use //form[@id='login']//input[@name='username']. This reduces the chance of matching unintended elements and makes your intent clearer.
• Use Meaningful Predicates: //button[contains(@class, 'primary')] is more maintainable than //button[1] because it describes what you're looking for rather than where it happens to be.
• Combine Multiple Conditions: //div[@class='product' and contains(text(), 'Special Offer')] is more precise than separate conditions and often performs better.
• Consider Performance: More specific selectors typically perform better. //div[@id='content']//button is faster than //button when you know the button is within a specific container.

CSS vs XPath – Strategic Decision Making

Understanding when to use CSS selectors versus XPath is crucial for building efficient, maintainable automation. The professional's rule of thumb is simple: use CSS selectors when you can; use XPath when you must.

Criteria	CSS Selectors	XPath
Performance	Generally faster; native to browser engines and highly optimized.	Can be slower, especially for complex expressions, as the XPath engine has more overhead.
Syntax Complexity	Simpler, more concise, and easier to read for most scenarios.	More verbose and can become complex quickly, but offers greater expressiveness.
DOM Traversal	Downwards and sideways only. Cannot select parent elements.	Can traverse in any direction (up, down, sideways). This is its primary advantage.
Text Content	Cannot directly select elements based on their text content.	Excellent support for text-based selection using the text() function.
Browser Support	Universally and consistently supported across all browsers.	Implementations can have minor differences between browsers, though this is rare.

Decision Framework

Use this framework to make consistent, strategic decisions about locator approaches:

Choose CSS Selectors When: You're selecting elements based on attributes, classes, or IDs. You need to traverse downwards or sideways in the DOM. You're working with straightforward element relationships. You want maximum performance and browser compatibility.

Choose XPath When: You need to traverse upwards from a child to find a parent or ancestor. You're selecting elements based on their text content. You need complex conditional logic or mathematical operations. You're dealing with scenarios where CSS selectors become overly complex or impossible.

Real-World Decision Examples

Let's examine some practical scenarios to illustrate this decision-making process:

Scenario 1 - Simple Form Field: Finding a username input field with id="username". CSS wins: #username is simple, fast, and clear.

Scenario 2 - Table Row by Content: Finding the delete button for a user named "John Smith" in a table. XPath wins: //td[text()='John Smith']/parent::tr//button[contains(@class, 'delete')] elegantly handles the text matching and upward traversal.

Scenario 3 - Error Message in a Form: Finding error messages within a specific form. CSS wins: #registration-form .error-message is clean and efficient.

Scenario 4 - Dynamic Content with Text: Finding a status indicator that shows "Processing..." within a dashboard widget. XPath wins: //div[@class='dashboard-widget']//span[contains(text(), 'Processing')] handles the text matching elegantly.

Anti-Patterns and Pitfalls

Learning what not to do is often as important as learning what to do. These common anti-patterns and pitfalls can destroy the reliability and maintainability of your automation suite.

The Brittle Structure Trap

The most dangerous anti-pattern is creating locators that depend on DOM structure rather than element characteristics. Locators like //div[3]/div[1]/button[2] or body > div > div > form > button are ticking time bombs. They break whenever developers add, remove, or reorder elements, leading to constant maintenance overhead.

Why This Happens: It's often the easiest solution when first writing the locator, especially when using browser tools that generate absolute paths. It seems to work perfectly during initial development.

The Solution: Focus on what the element is, not where it is. Look for identifying characteristics like IDs, classes, attributes, or text content that describe the element's purpose rather than its position.

The Magic Number Syndrome

Using arbitrary numeric indices without understanding their meaning creates fragile locators. Examples include :nth-child(5) when you mean "the submit button" or //tr[3] when you mean "the row containing user data."

Why This Happens: It's a quick fix when other approaches seem complicated, and it works reliably in controlled test environments.

The Solution: If you must use positional selectors, ensure they have semantic meaning. :first-child for the header row or :last-child for a footer element makes sense. Random numbers do not.

The Overly Complex Selector

Creating unnecessarily complex selectors that try to handle every possible edge case. A selector like div.container > div.row:nth-child(2) > div.col-md-6:first-child > form#contact-form > div.form-group:nth-child(3) > input[type="email"] is both fragile and unreadable.

Why This Happens: Fear of false positives leads to over-specification, creating selectors that are too tightly coupled to the current DOM structure.

The Solution: Find the right balance of specificity. Often, a simple #contact-form input[type="email"] achieves the same goal with better maintainability.

The Text Localization Trap

Hard-coding text content in locators without considering internationalization. A locator like //button[text()='Submit'] will fail when the application is translated to other languages.

Why This Happens: Text-based locators are often the most intuitive and seem stable during development in a single language.

The Solution: Prefer attribute-based locators when possible. If you must use text, consider using test-specific attributes or ensure your test strategy accounts for localization.

The CSS Framework Dependency

Building locators around CSS framework classes that might change when the framework is updated. Locators like .btn-primary or .col-md-6 are vulnerable to framework migrations or updates.

Why This Happens: These classes are stable during development and provide convenient hooks for element identification.

The Solution: Use semantic classes that describe function rather than appearance. .submit-button is better than .btn-primary because it describes what the element does rather than how it looks.

The Dynamic Content Nightmare

Failing to account for dynamic content that changes based on user state, time, or data. A locator that works for a logged-in user might fail for a guest user, or a locator that works with test data might fail with production data.

Why This Happens: Development and testing often happen in controlled environments with predictable data and user states.

The Solution: Test your locators under different conditions. Consider how page content changes with different user roles, data states, and application configurations. Build flexibility into your locators to handle these variations.

Best Practices for Locator Resilience

Building resilient locators requires adopting practices that prioritize long-term maintainability over short-term convenience. These practices will help you create locators that survive the constant evolution of modern web applications.

The Semantic Approach

Always prioritize semantic meaning over implementation details. A locator should describe what an element does, not how it's implemented or where it appears.

Good Example: [data-testid='user-profile-save-button'] clearly indicates this is the save button for user profile functionality.

Bad Example: //div[@class='container']//div[2]//button[@class='btn btn-primary'] describes the implementation but not the purpose.

The Multiple Fallback Strategy

When possible, design your locator strategy to have multiple fallback approaches. This doesn't mean using multiple locators in your code, but rather choosing locators that combine multiple identifying characteristics.

Example: button[data-testid='save-button'][type='submit'] combines a test-specific identifier with a functional attribute. If the test ID is removed, the type attribute provides a fallback clue.

The Stable Attribute Partnership

Work with developers to establish stable attributes specifically for testing. This creates a contract that benefits both development and testing teams.

Implementation: Agree on a consistent naming convention for test attributes, such as data-testid or data-qa. Ensure these attributes are included in the definition of done for user stories and are preserved during refactoring.

The Context-Aware Approach

Build locators that are aware of their context within the application. This means considering not just the element you're finding, but its relationship to the page, section, or component it belongs to.

Example: Instead of input[name='email'] which might match multiple email fields, use #login-form input[name='email'] to specify the email field within the login form.

The Graceful Degradation Principle

Design your locators to degrade gracefully when the ideal identifying attributes are not available. This means having a hierarchy of preferences built into your approach.

Implementation: If your first choice is a test-specific attribute, your second choice might be a semantic class, and your third choice might be a functional attribute. This approach is particularly useful when working with legacy applications or third-party components.

The Documentation and Communication Strategy

Document your locator strategy and communicate it clearly to your team. This includes not just what locators to use, but why certain approaches are preferred and how decisions should be made.

Implementation: Create a locator style guide that includes examples of good and bad locators, decision trees for choosing approaches, and guidelines for handling common scenarios like dynamic content and third-party components.

Practical Implementation Considerations

While this lesson focuses on fundamental locator concepts rather than specific framework implementation, understanding how these principles apply in practice will help you make better decisions when you move to specific automation frameworks.

Framework-Agnostic Principles

The locator strategies we've discussed apply regardless of whether you're using Selenium WebDriver, Playwright, or any other automation framework. The syntax for using these locators might vary, but the underlying principles remain constant.

For example, the CSS selector #login-form input[name='username'] would be used similarly across frameworks:

• In Selenium: driver.FindElement(By.CssSelector("#login-form input[name='username']"))
• In Playwright: await page.Locator("#login-form input[name='username']")

The key insight is that mastering locator strategy is a foundational skill that transcends any specific tool or framework.

Performance Considerations

While correctness and maintainability are the primary concerns, understanding performance implications helps you make informed decisions when multiple approaches are equally valid.

CSS Selector Performance: Simple selectors like IDs and classes are fastest. Complex selectors with multiple combinators and pseudo-classes can be slower but are still generally faster than equivalent XPath expressions.

XPath Performance: XPath expressions that start with specific elements perform better than those that use // to search the entire document. Adding specific context like //form[@id='login']//input is better than //input when you know the form context.

Debugging and Troubleshooting

When locators fail, having a systematic approach to debugging saves time and frustration. Common issues include timing problems (element not yet available), specificity problems (locator matches multiple elements), and stability problems (locator breaks due to page changes).

The browser developer tools will be your primary debugging environment, which we'll explore in detail in the next lesson. Understanding how to test and validate your locators in the browser before implementing them in your automation code is crucial for efficient development.

Hands-On Practice – Locator Gauntlet

Time to test your skills with a comprehensive set of challenges. Use the HTML snippet below, which represents a user management dashboard, to solve the challenges. Test your selectors in DevTools to verify they work correctly!

<div id="user-dashboard">
  <header class="dashboard-header">
    <h1>User Management Dashboard</h1>
    <nav class="primary-navigation">
      <a href="/users" class="nav-link active">Users</a>
      <a href="/roles" class="nav-link">Roles</a>
      <a href="/settings" class="nav-link">Settings</a>
    </nav>
  </header>
 
  <main class="dashboard-content">
    <section class="user-form-section">
      <h2>Add New User</h2>
      <form id="new-user-form" class="user-form">
        <div class="form-group">
          <label for="email">Email Address</label>
          <input type="email" id="email" name="user_email" required>
          <span class="error-message" style="display: none;">Please enter a valid email</span>
        </div>
        <div class="form-group">
          <label for="username">Username</label>
          <input type="text" id="username" name="user_name" required>
          <span class="error-message" style="display: none;">Username is required</span>
        </div>
        <div class="form-group">
          <label for="role">User Role</label>
          <select id="role" name="user_role">
            <option value="">Select a role</option>
            <option value="admin">Administrator</option>
            <option value="editor">Editor</option>
            <option value="viewer">Viewer</option>
          </select>
        </div>
        <div class="form-actions">
          <button type="submit" class="btn btn-primary" data-testid="create-user-btn">Create User</button>
          <button type="button" class="btn btn-secondary">Cancel</button>
        </div>
      </form>
    </section>
 
    <section class="user-list-section">
      <h2>Existing Users</h2>
      <div class="search-bar">
        <input type="text" class="search-input" placeholder="Search users..." data-testid="user-search">
        <button class="search-button" aria-label="Search users">🔍</button>
      </div>
 
      <table class="users-table">
        <thead>
          <tr>
            <th>Email</th>
            <th>Username</th>
            <th>Role</th>
            <th>Status</th>
            <th>Actions</th>
          </tr>
        </thead>
        <tbody>
          <tr class="user-row" data-user-id="1">
            <td class="user-email">[email protected]</td>
            <td class="user-name">admin</td>
            <td class="user-role">Administrator</td>
            <td class="user-status"><span class="status-active">Active</span></td>
            <td class="user-actions">
              <button class="btn-edit" data-testid="edit-user-1">Edit</button>
              <button class="btn-delete" data-testid="delete-user-1">Delete</button>
            </td>
          </tr>
          <tr class="user-row" data-user-id="2">
            <td class="user-email">[email protected]</td>
            <td class="user-name">john.doe</td>
            <td class="user-role">Editor</td>
            <td class="user-status"><span class="status-inactive">Inactive</span></td>
            <td class="user-actions">
              <button class="btn-edit" data-testid="edit-user-2">Edit</button>
              <button class="btn-delete" data-testid="delete-user-2">Delete</button>
            </td>
          </tr>
          <tr class="user-row" data-user-id="3">
            <td class="user-email">[email protected]</td>
            <td class="user-name">jane.smith</td>
            <td class="user-role">Viewer</td>
            <td class="user-status"><span class="status-active">Active</span></td>
            <td class="user-actions">
              <button class="btn-edit" data-testid="edit-user-3">Edit</button>
              <button class="btn-delete" data-testid="delete-user-3">Delete</button>
            </td>
          </tr>
        </tbody>
      </table>
    </section>
  </main>
</div>

Part 1: CSS Selector Mastery

1. Basic Selection: Find the "Create User" button using its test-specific attribute.
2. Form Context: Find the username input field, but only within the new user form (not if there were other username fields elsewhere).
3. Attribute Matching: Find all required input fields within the form.
4. Combinator Challenge: Find the error message that appears after the email input field.
5. Pseudo-class Power: Find the currently active navigation link.
6. Multiple Criteria: Find buttons that have both "btn" and "btn-primary" classes.
7. Negation: Find all user rows that do NOT have a "status-inactive" span.
8. Positional Selection: Find the second column (Username) in the table header.

Part 2: XPath Challenges

1. Text-based Selection: Find the table header cell that contains the text "Status".
2. Upward Traversal: Find the table row that contains the user "john.doe", then find the edit button within that row.
3. Text + Traversal: Find the delete button for the user whose email is "[email protected]".
4. Conditional Logic: Find all user rows where the status is "Active".
5. Complex Navigation: Find the form that contains an input with the placeholder "Search users...".
6. Positional with Conditions: Find the second user row (not including the header).
7. Attribute + Text: Find the button with class "btn-edit" that is in the same row as the user "admin".

Part 3: Strategic Thinking

For each scenario below, choose the best locator strategy and explain your reasoning:

1. Scenario A: You need to automate clicking the "Create User" button. What's the best locator and why?
2. Scenario B: You need to verify that a specific error message appears after submitting an invalid form. The error message text might change based on validation rules.
3. Scenario C: You need to delete a user whose name is provided dynamically by your test data.
4. Scenario D: You need to count how many users have "Active" status in the table.