POM is the most asked topic in automation interviews. Every interviewer expects you to explain the pattern, justify your design choices, and describe your framework structure. Here are the remaining questions not covered inline.
Q: Why do you use POM? What problems does it solve?
A: POM solves three problems: (1) Maintenance — when a locator changes, I update it in one place instead of every test. (2) Readability — tests read like user stories: loginPage.loginAs("user", "pass"). (3) Reusability — multiple tests share the same page methods. In my project, adopting POM reduced maintenance effort by 70% because UI changes only required updates in one page class.
Q: How do you handle popups and alerts in POM?
A: I handle them inside the page method that triggers them. If clicking a button opens a JS alert, the method that clicks that button also handles the alert. For modal dialogs, I create a separate component class if the modal is reused across pages, or handle it within the page method if specific. The test class never interacts with Alert or window handles directly.
Q: How do you handle pages with the same elements?
A: Two approaches: (1) If multiple pages share a component like a header or sidebar, I create a separate component class and compose it into each page using has-a relationship. (2) If pages share a large amount of functionality (like a common form layout), I create a parent page class that both extend. But I prefer composition over inheritance for flexibility.
Q: What is the difference between POM and Keyword-Driven Framework?
A: POM is a design pattern — it organizes your code with one class per page. A Keyword-Driven Framework is an architecture where test steps are stored externally (in Excel or a config file) and mapped to keyword functions at runtime. They can coexist: you can have a keyword-driven framework that uses POM internally. POM is about code organization; keyword-driven is about test data externalization.
Key Point: Be ready to explain POM principles, BasePage pattern, PageFactory trade-offs, framework structure, and component handling.