How do you choose locators for UI tests, and what makes a locator fragile?

What the interviewer wants to hear

• Prefer user-facing locators: role, label, text
• Use stable test ids when roles are not enough
• Avoid absolute XPath, generated classes and indexes
• Locators should reflect what the user sees and does
• Keep locators in one place such as page objects

Model answer

I start with locators that match how a user finds the element: its role and accessible name, its label or its visible text. In Playwright that means getByRole or getByLabel. These survive layout and styling changes and also push the team toward accessible markup. When there is no good accessible name, for example in a dense table, I ask developers for a data-testid attribute. Fragile locators are ones tied to page structure or build output: absolute XPath, nth-child indexes, auto-generated CSS classes or long chains of divs. They break when someone wraps a button in a new container. I keep locators inside page objects or component objects so a change is fixed in one place, and I review new locators in pull requests just like any other code.

More easy Automation Test Engineer questions

• Why do teams automate tests, and what should not be automated?
• Explain the Page Object Model and its benefits. Are there any downsides?
• What is the difference between implicit waits, explicit waits and auto-waiting?
• How do you run automated tests in a CI pipeline?
• When would you write an API test instead of a UI test?
• Explain the test pyramid. How does it guide what you automate?
• When you automate tests for a REST API endpoint, what do you check?
• What makes an automated test good?
• Compare Selenium and Playwright. When would you choose each?