Skip to content
RED SAGSkills
hardAutomation Test Engineer interview question

Developers keep changing the UI and breaking your tests. How do you fix this at the team level, not just in your code?

What the interviewer wants to hear

  • Agree on testability standards such as data-testid or accessible roles
  • Run tests on pull requests so developers see failures before merge
  • Make developers co-owners of tests
  • Use resilient locators and component-level tests
  • Show data on time lost to breakages

Model answer

The root problem is that tests are seen as QA's responsibility only. First I make breakages visible early: tests run on every pull request, so the developer who changes the UI sees the failure before merging, not me the next morning. Second, we agree on testability standards: use semantic HTML and accessible names, which helps both users and role-based locators, and add data-testid on key elements, documented in the definition of done. I switch my tests to these resilient locators. Third, I invite developers to co-own the suite: they update affected tests in the same pull request, and I review test changes in their pull requests and vice versa. I show data, like hours lost each sprint to broken tests, to get support from the team lead. Over time, testing becomes part of how the team builds features, not a separate step.

Can you answer it under time pressure?

Take a timed hard round and get scored on every answer.

Start mock interview

More hard Automation Test Engineer questions