QA Automation interview questions and answers for 2025

Automation testing involves using software tools and scripts to execute tests, whereas manual testing is performed by human testers who interact with the application directly. In automation testing, a tool (such as Selenium, Cypress, or Appium) replicates user actions (like clicking buttons, entering text, verifying UI elements) and compares expected outcomes with actual results. This approach reduces repetitive work, speeds up regression testing, and improves test accuracy. Manual testing, on the other hand, is more suitable for exploratory, usability, and ad-hoc testing where human judgment is crucial.

Commonly used automation tools include:

• Selenium WebDriver: Widely used for web application testing.
• Cypress: A JavaScript-based tool focusing on modern web applications.
• Appium: For mobile application testing (Android and iOS).
• Playwright: For fast and reliable end-to-end testing of modern web apps.
• TestComplete: A commercial tool for desktop, web, and mobile testing.
• Katalon Studio: An all-in-one solution built on top of Selenium and Appium.

Cypress and Playwright are modern end-to-end testing frameworks designed for web applications. They are popular because they offer fast, reliable, and developer-friendly testing environments. Both tools allow for real-time browser interaction and automatic waiting, which reduces flaky tests. Cypress runs directly inside the browser, providing real-time feedback and a robust debugging experience, while Playwright supports multiple browsers (Chromium, Firefox, WebKit) and is known for its ability to test across various platforms with strong automation features. Both tools offer improved performance, better handling of asynchronous operations, and modern features like network interception and multi-page testing, making them more efficient than older tools like Selenium.

Elements can be located using:

• ID: driver.findElement(By.id("username"))
• Name: driver.findElement(By.name("email"))
• XPath: driver.findElement(By.xpath("//input[@id='username']"))
• CSS Selectors: driver.findElement(By.cssSelector("#username"))
• Link Text or Partial Link Text: driver.findElement(By.linkText("Sign In"))
• Tag Name: driver.findElement(By.tagName("input")) Using unique and stable locators is essential to maintain reliable tests.

import { test, expect } from '@playwright/test';

test('should visit the homepage and check the title', async ({ page }) => {
  await page.goto('<https://example.com>');  // Navigate to the webpage
  const title = await page.title();        // Get the title of the page
  expect(title).toContain('Example Domain');  // Assert the title contains the expected text
});

This test uses Playwright’s modern API to interact with a webpage and perform assertions. Let me know if you’d like further details!

Synchronization issues occur when tests run faster than the web application’s response. To handle this:

• Implicit Wait: Waits for a certain duration for elements to appear.
• Explicit Wait: Waits for specific conditions (element clickable, element visible) before proceeding.
• Fluent Wait: Similar to explicit waits but with polling intervals and conditions.

Code example for explicit wait:

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("username")));

In Playwright with TypeScript, there are several types of waits to handle synchronization:

1. Implicit Waits: Playwright automatically waits for elements to be ready before interacting with them, reducing the need for explicit waits.
2. Explicit Waits: You can use page.waitForSelector(selector) to wait for a specific element to appear in the DOM before interacting with it.
3. Timeouts: Playwright allows you to set timeouts for actions like waitForTimeout(ms) to introduce delays or wait for specific conditions.
4. Assertions: Methods like expect(element).toBeVisible() wait until the element meets the expected condition, such as visibility or interactivity.

These built-in waits help ensure reliable synchronization without the need for complex custom waits.

In Playwright with TypeScript, the difference between page.locator() and

page.locator().all() is as follows:

• page.locator(selector): This method returns a single locator for the first matching element on the page. It’s used to interact with a specific element, like clicking or typing.
• page.locator(selector).all(): This method returns a locator for all matching elements. It can be used when dealing with multiple elements that match the selector, allowing actions like checking their count or iterating through them.

page.locator() is used for one element, while page.locator().all() is used for handling multiple matching elements.

In Playwright with TypeScript, you can perform a mouse hover action using the hover() method on a locator. Here’s an example:

import { test, expect } from '@playwright/test';

test('mouse hover action', async ({ page }) => {
  await page.goto('<https://example.com>');
  const element = page.locator('button#hover-target');  // Locate the element
  await element.hover();  // Perform the hover action
});

The hover() method simulates the mouse hovering over an element, triggering any associated hover effects.

In Playwright with TypeScript, dropdown menus can be handled using the
selectOption() method. Here’s an example of selecting a value from a dropdown:

import { test } from '@playwright/test';

test('handle dropdown menu', async ({ page }) => {
  await page.goto('<https://example.com>');
  const dropdown = page.locator('select#dropdown');  // Locate the dropdown
  await dropdown.selectOption({ label: 'Option 1' });  // Select an option by label
});

The selectOption() method can be used to select options by value, label, or index. This method works for <select> elements, ensuring smooth interaction with dropdown menus in forms.

In Playwright with TypeScript, alerts and pop-ups can be handled by using the
page.on() method to listen for events like dialogs. Here’s how to handle an alert or confirmation pop-up:

import { test } from '@playwright/test';

test('handle alert and popup', async ({ page }) => {
  await page.goto('<https://example.com>');

  // Listen for the dialog event
  page.on('dialog', async dialog => {
    console.log(dialog.message());  // Get dialog message
    await dialog.accept();  // Accept the alert or popup
  });

  // Trigger an alert on the page (e.g., through a button click)
  await page.click('button#trigger-alert');
});

In this example, the dialog event listens for alerts, confirms, and prompts, and the
accept() method is used to interact with the pop-up.

In Playwright with TypeScript, handling multiple browser windows or tabs can be done by interacting with page objects. Here’s an example:


import { test } from '@playwright/test';

test(‘handle multiple browser windows or tabs’, async ({ page, browser }) => {
await page.goto(‘<https://example.com>’);
const [newPage] = await Promise.all([
browser.waitForEvent(‘page’), // Wait for the new page
page.click(‘a[target=”_blank”]’) // Trigger the opening of a new tab/window
]);

// Perform actions on the new page
await newPage.goto(‘<https://anotherpage.com>’);
});

In this example, browser.waitForEvent('page') listens for the opening of a new page (or tab), and Promise.all() ensures that the action of opening the new tab is completed before performing operations on the new tab.

• Test organization: Both frameworks offer easy test structure and management with built-in functions like describe(), it(), and beforeEach() for clear, readable tests.
• Report generation: Cypress has built-in support for reporting, while Playwright can integrate with third-party tools like Allure or JUnit for advanced reporting.
• Parallel execution: Both tools allow parallel test execution; Cypress offers parallelization via the Dashboard service, and Playwright supports it with its own runner.
• Cross-browser testing: Playwright supports testing on multiple browsers (Chromium, Firefox, WebKit), while Cypress primarily focuses on Chromium-based browsers.
• Flake-free tests: Playwright and Cypress automatically handle waits and retries to reduce flaky tests, improving stability and consistency.
• Real-time reloading: Cypress offers an interactive test runner with live browser previews, while Playwright provides similar capabilities for debugging.

In Cypress and Playwright, assertions are built into the testing frameworks, making it easy to assert conditions without needing an external library. Here’s how you do it:

In Cypress:

describe('Test Example', () => {
  it('should assert that the element is visible', () => {
    cy.visit('<https://example.com>');
    cy.get('#element').should('be.visible');
    cy.title().should('eq', 'Expected Title');
  });
});

In Playwright with TypeScript:

import { test, expect } from '@playwright/test';

test('assertions in Playwright', async ({ page }) => {
  await page.goto('<https://example.com>');
  const element = page.locator('#element');
  await expect(element).toBeVisible();
  await expect(page).toHaveTitle('Expected Title');
});

In both Cypress and Playwright, you can use simple assertions like should() (Cypress) or expect() (Playwright) to check conditions such as visibility, element presence, text, or page title.

Page Object Model (POM) is a design pattern that separates the UI (locators and actions) from the test logic. In this pattern, each page of the application is represented by a class or a module that contains element locators and the methods for interacting with those elements. While the term POM is traditionally associated with Selenium, it is also used in Cypress and Playwright to improve code structure and maintainability.

Advantages of using POM:

• Improved code readability and maintenance: The logic for interacting with each page is centralized, making the tests cleaner and easier to maintain.
• Reduced duplication: Instead of writing redundant code for element locators and actions in each test, you centralize them in separate page objects.
• Increased test robustness: Tests become more resilient to UI changes because you only need to update the page object class/module instead of updating individual tests.

Example in Playwright with TypeScript:

import { Page } from '@playwright/test';

// Page Object Class for Login Page
class LoginPage {
	private usernameInput = page.locator('#username'),
  private passwordInput = page.locator('#password'),
  private submitButton = page.locator('#submit')
  constructor(
    page: Page,
  ) {
  
  }

  async login(username: string, password: string) {
    await this.usernameInput.fill(username);
    await this.passwordInput.fill(password);
    await this.submitButton.click();
  }
}

export { LoginPage };

// Test using Page Object Model
import { test } from '@playwright/test';
import { LoginPage } from './loginPage';

test('user login', async ({ page }) => {
  const loginPage = new LoginPage(page);
  await loginPage.login('user1', 'password123');
});

In Cypress, you would similarly create a page object for each page with methods for interacting with elements, using Cypress commands.

Playwright (TypeScript)

import { Page } from '@playwright/test';

// Page Object Class for Login Page
class LoginPage {
  constructor(
    page: Page,
    private usernameInput = page.locator('#username'),
    private passwordInput = page.locator('#password'),
    private loginButton = page.locator('#loginBtn')
  ) {}

  // Method to enter username
  async enterUsername(username: string) {
    await this.usernameInput.fill(username);
  }

  // Method to enter password
  async enterPassword(password: string) {
    await this.passwordInput.fill(password);
  }

  // Method to click login and return the next page
  async clickLogin() {
    await this.loginButton.click();
    return new HomePage(page); // Assuming you have a HomePage class
  }
}

// Usage in a test
import { test } from '@playwright/test';
import { LoginPage } from './loginPage';

test('user login', async ({ page }) => {
  const loginPage = new LoginPage(page);
  await loginPage.enterUsername('user1');
  await loginPage.enterPassword('password123');
  await loginPage.clickLogin();
});

Cypress

class LoginPage {
  constructor() {
    this.usernameInput = '#username';
    this.passwordInput = '#password';
    this.loginButton = '#loginBtn';
  }

  // Method to enter username
  enterUsername(username) {
    cy.get(this.usernameInput).type(username);
  }

  // Method to enter password
  enterPassword(password) {
    cy.get(this.passwordInput).type(password);
  }

  // Method to click login
  clickLogin() {
    cy.get(this.loginButton).click();
  }
}

// Usage in a test
describe('User Login Test', () => {
  it('should log in successfully', () => {
    const loginPage = new LoginPage();
    loginPage.enterUsername('user1');
    loginPage.enterPassword('password123');
    loginPage.clickLogin();
  });
});

Key Differences:

• In Playwright, methods like fill() and click() are used, and you interact with locators using the page.locator() method.
• In Cypress, you use cy.get() to interact with elements and chain commands directly.

• Use a build tool: For Playwright, you can use npm scripts or Yarn to execute tests. For Cypress, use cypress run as part of your build process.
• CI Tools Integration: Integrate test execution into CI tools like Jenkins, GitLab CI, or GitHub Actions. Use relevant steps to install dependencies, set up the environment, and run the tests.
  • Example for GitHub Actions (Cypress or Playwright):

jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v2
with:
node-version: '14'
- run: npm install
- run: npm test # Runs the Cypress/Playwright tests

• Test Reports: Configure test results to be published as build artifacts and/or uploaded to test management tools like Allure or JUnit.
  • Example for Playwright:

{
"reporter": [
["list"],
["json", { "outputFile": "test-results.json" }]
]
}

• Headless Execution: Run tests in headless mode to avoid UI dependencies during CI execution. Both Playwright and Cypress support headless execution out of the box.
• Docker for Scalability: Containerize tests with Docker to ensure consistent execution across environments. Use a pre-built Playwright or Cypress Docker image, or create your own.

• Verification: Ensuring the product is being built according to the specified requirements. It’s about correctness of the process.
• Validation: Ensuring the product meets the user’s needs and the intended use. It’s about evaluating the actual product behavior.

• Cypress:Cypress automatically retries commands and assertions to handle transient errors. For handling exceptions:
  • Use .catch() to catch errors in commands.
  • You can also use cy.on('uncaught:exception') to prevent Cypress from failing on specific exceptions.

  Example:

   

  cy.on('uncaught:exception', (err, runnable) => {
    // prevent Cypress from failing the test on this exception
    return false;
  });
  

• Playwright:Playwright provides try...catch blocks to handle exceptions explicitly. Playwright also supports assert statements for validation, and you can usepage.on('dialog') for handling dialog exceptions like alerts or prompts.Example:

  try {
    await page.click('button#submit');
  } catch (error) {
    console.log('Error occurred:', error);
  }
  

In both frameworks, it’s essential to handle exceptions gracefully to ensure tests are robust and do not fail unexpectedly.

• Cypress:Cypress does not provide direct control over browser contexts like Playwright. When you use cy.visit(), it automatically opens and manages the browser session. Cypress automatically handles opening and closing the browser for each test suite, and it does not have separate methods to close a specific browser tab or context manually.
  • To stop the browser session, you typically rely on Cypress shutting down the browser at the end of the test run.
• Playwright:In Playwright, there are two ways to manage browser contexts:
  • browser.close(): Closes the entire browser instance, ending the session.
  • context.close(): Closes a specific browser context, which is useful for multi-tab or multi-window tests where you want to isolate different sessions.

Example in Playwright:

const browser = await playwright.chromium.launch();
const context = await browser.newContext(); // Creates a new browser context
const page = await context.newPage();

await page.goto('<https://example.com>');
await context.close(); // Closes the specific context, not the whole browser

await browser.close(); // Closes the entire browser

In summary, Cypress automatically manages the session, while Playwright allows explicit control over browser contexts and instances.

• Cypress:Cypress allows you to take screenshots automatically on test failures or manually with the cy.screenshot() command.
  • Automatically: Cypress takes screenshots when a test fails, by default.
  • Manually: Use cy.screenshot() to capture a screenshot at any point during a test.

  Example:

cy.screenshot(); // Takes a screenshot of the entire page

• Playwright:Playwright provides the page.screenshot() method to capture screenshots of the page or specific elements.
  • You can capture the full page or a particular region by passing options.

  Example:

await page.screenshot({ path: 'screenshot.png' }); // Full-page screenshot
await page.screenshot({ path: 'element.png', clip: { x: 0, y: 0, width: 100, height: 100 } }); // Specific element screenshot

Both tools allow for easy screenshot capture, either manually or automatically on failure, making debugging easier.

A test framework provides a structured environment for writing, organizing, and executing tests. It defines coding standards, folder structures, utilities, reporting mechanisms, and integration points. Benefits include improved maintainability, reusability, and scalability of test code.

• Cypress:Cypress automatically waits for elements to appear or change states before interacting with them. It handles dynamic elements through commands like cy.get() that ensure elements are available before actions like clicks or text input. Additionally, you can use cy.wait() or custom assertions for more specific timing control.
  Example:

  cy.get('.dynamic-element', { timeout: 10000 }).should('be.visible'); // Waits for the element to become visible
  

• Playwright:Playwright waits for elements to be ready before interacting with them. Methods like page.locator() are used with built-in waiting mechanisms for dynamic content. You can also set explicit timeouts using locator.waitFor() for more control over the timing.
  Example:

  const dynamicElement = page.locator('.dynamic-element');
  await dynamicElement.waitFor({ state: 'visible' }); // Waits for the element to be visible
  

Both tools handle dynamic elements efficiently with built-in waiting mechanisms, ensuring tests don’t fail due to timing issues.

Headless browser testing runs browser tests without a visible UI. Tools like Headless Chrome or HTMLUnit allow tests to run faster and on servers without a GUI. This is useful for CI environments and can reduce resource usage.

A test suite is a collection of test cases that together validate a particular component, module, or the entire application. It’s an organized way to group related tests, often defined in configuration files (like testng.xml).

Parameterization involves running the same test with different sets of data. This is achieved using data providers, CSV files, Excel sheets, or configuration files. It helps in checking application behavior under different input conditions.

• Use external files (CSV, JSON, Excel) or databases to store test data.
• Use configuration files for URLs, credentials, and environment settings.
• Data-driven testing frameworks integrate data sources directly into test scripts.

• Identifying stable and reliable locators.
• Handling dynamic content and synchronization.
• Managing test data and environment configuration.
• Dealing with browser compatibility issues.
• Maintaining and refactoring large test suites.

Key metrics:

• Test coverage: Percentage of requirements or functionalities automated.
• Execution time reduction: Faster regression cycles.
• Defect detection ratio: How many defects are caught by automated tests.
• Maintenance effort: How easily new tests can be added or existing tests updated.

• Use stable and unique locators (prefer IDs, stable attributes, or custom data attributes).
• Implement the Page Object Model to isolate element locators from test logic.
• Use explicit waits and conditions instead of fixed delays.
• Create utility methods for complex UI interactions.

Cross-browser testing ensures that the web application works correctly across different browsers (Chrome, Firefox, Edge, Safari) and their versions. Automation tools like Selenium Grid or cloud platforms like Sauce Labs or BrowserStack help execute tests on various browser/OS combinations simultaneously. This ensures broader compatibility and a consistent user experience.

Cross-browser testing ensures that the web application works correctly across different browsers (Chrome, Firefox, Edge, Safari) and their versions. Tools like Playwright and Cypress, or cloud platforms like BrowserStack and Sauce Labs, help execute tests on various browser/OS combinations simultaneously. This ensures broader compatibility and a consistent user experience.

To optimize test execution time in CI/CD pipelines while maintaining high test quality, I use the following strategies:

1. Parallel Test Execution: Utilize test frameworks and CI tools to run tests concurrently across multiple environments, significantly reducing overall execution time.
2. Selective Test Execution (Test Impact Analysis): Run only the relevant subset of tests based on recent code changes, identified using tools like Azure Test Plans or custom scripts.
3. Headless Browser Testing: Leverage headless modes in tools like Playwright or Cypress to reduce resource usage and speed up UI tests.
4. Test Categorization and Prioritization: Divide tests into critical, smoke, regression, and exploratory groups. Prioritize running critical and smoke tests earlier in the pipeline.
5. Efficient Test Design: Minimize redundancy in test cases, use reusable utility functions, and ensure tests are modular and data-driven for flexibility.
6. Optimized Test Data Management: Use lightweight, pre-configured data sets stored in JSON or databases and reset the test environment programmatically for consistency and speed.
7. Mocking and Stubbing: Replace slow or unreliable external dependencies with mocks or stubs to isolate tests and improve execution speed.
8. Containerization: Use Docker to spin up isolated environments for consistent and scalable test execution.
9. Continuous Monitoring and Debugging Tools: Integrate monitoring and logging tools to quickly identify bottlenecks and flakiness, reducing the time spent on debugging.
10. Pipeline Configuration: Optimize CI/CD pipelines by caching dependencies, leveraging artifact storage, and ensuring resource scaling for peak test runs.

These strategies ensure faster feedback cycles without compromising the reliability or depth of automated testing.

• Check out code from a repository using Jenkins/GitLab CI job.
• Collect reports and artifacts and configure post-build actions to publish reports.
• Schedule jobs or trigger builds on code commits.

API testing automation ensures that web services meet functional and performance expectations. For automation, I focus on the following:

• Request/Response Validation: Verify status codes, response times, headers, and body content.
• Data-Driven Testing: Use external data sources like JSON or CSV for varied input scenarios.
• Error Handling: Check edge cases and error scenarios to ensure the API responds correctly.

Tools like Postman (for manual testing and automation via Newman CLI) and Playwright (for integrated API testing in the testing flow) are preferred.

For example, using Postman with Newman CLI:

newman run api_tests.json -e environment.json

In Playwright, API testing can be done directly in the test suite with the request API:

const response = await page.request.get('<https://api.example.com/users/1>');
expect(response.status()).toBe(200);

This integrated approach allows for faster feedback and comprehensive test coverage.

Behavior-Driven Development (BDD) focuses on collaboration between developers, QA, and non-technical stakeholders to define application behavior using natural language. In modern test automation, BDD integrates with frameworks that allow the creation of readable and maintainable test scenarios.

Key integration points include:

• Readable test scenarios: BDD uses the Given-When-Then syntax to define clear scenarios. This improves communication, ensuring all stakeholders, including business analysts, can understand test cases.
• Tool integration: Tools like Cypress, Playwright, and SpecFlow (for .NET) support BDD by mapping natural language steps to automation scripts, often with minimal boilerplate.
• Framework support: With Cucumber or Behave, test steps are written in Gherkin syntax, linking the feature files to step definitions, and executing tests in environments like Playwright or Cypress.
• CI/CD integration: BDD ensures that automated tests can be integrated seamlessly into the CI/CD pipeline, running efficiently and providing clear reports in simple language for all team members to understand.

This approach reduces ambiguity, improves collaboration, and makes automation accessible to non-technical stakeholders while maintaining test reliability and scalability.

• Externalize environment-specific data into configuration files (properties, YAML).
• Pass environment parameters through command-line or CI variables.
• Use conditional logic to select URLs, credentials, and test data based on the environment.
• Maintain a configuration manager or environment factory class.

Parallel execution reduces total test execution time and accelerates feedback cycles.

Continuous Testing involves running automated tests early and frequently within the CI/CD pipeline. By integrating testing at every stage of the software delivery lifecycle, issues are caught early, improving code quality, reducing time to market, and aligning with DevOps principles of continuous improvement and fast feedback loops.

• Layered architecture: Separate test logic, page objects, utilities, and configuration layers.
• Use well-defined coding standards and naming conventions.
• Regularly refactor and remove duplications.
• Introduce logging and reporting utilities.
• Implement CI/CD for continuous integration and feedback.

• API-based login: Use an API call to authenticate and store session tokens.
• Cookie management: Set browser cookies once authenticated to bypass login screens.
• Preconditions: Run a login step in a @BeforeTest method and reuse the session during the test.

Version control systems allow:

• Collaborative test script development.
• Tracking changes and rollback if needed.
• Branching strategies for different features or releases.
• Integration with CI/CD pipelines.

This ensures consistent and traceable code management.

• Use built-in frameworks like TestNG’s HTML report.
• Integrate with Extent Reports or Allure for richer, interactive reports.
• Store reports as CI artifacts.
• Publish test results to dashboards for stakeholder visibility.

To ensure test stability and consistency across browsers and devices:

• Use Robust Locators: Leverage stable attributes (IDs, data attributes) to avoid flaky element identification.
• Cross-Browser Testing Tools: Utilize tools like BrowserStack or Sauce Labs to test across various browser versions and devices in parallel.
• Flexible Wait Strategies: Implement dynamic waits (e.g., explicit waits) to handle different page load speeds and content rendering.
• Responsive Design: Design tests that adapt to different screen sizes and resolutions using tools like Selenium WebDriver with mobile emulation or Appium for mobile devices.
• Continuous Integration: Integrate tests into CI/CD pipelines to continuously validate against different environments, ensuring consistency with every code change.

• Use explicit waits based on conditions rather than fixed waits.
• Increase timeout durations.
• Use tools like HAR (HTTP Archive) to diagnose network issues.
• Optimize locator strategies and reduce unnecessary actions.

To ensure proper test isolation and avoid dependencies between test cases:

• Use independent test cases: Each test should be self-contained, focusing on one specific functionality.
• Leverage setup and teardown methods: Initialize and clean up test data before and after each test to prevent cross-test contamination.
• Utilize mocking and stubbing: Replace dependencies with mock objects to isolate the unit under test.
• Data-driven testing: Use different datasets for each test to ensure tests don’t rely on shared data.
• Avoid shared state: Ensure no test modifies the state that could impact others by using unique data or resetting state before each test.

These practices improve test reliability and maintainability, enabling faster identification of issues.

• Use tools like JMeter, Gatling, or Locust to measure response times, throughput, and resource usage.
• Integrate performance test scripts into CI/CD.
• Analyze performance trends over time.
• Identify and isolate bottlenecks.

While Selenium is not ideal for performance testing, it can validate perceived load times with navigation timings.

• For CAPTCHA: Avoid automating it directly. Use test environments with CAPTCHA disabled, or mock the captcha validation.
• For OTP: Access the OTP from an API, email inbox, or database. Pre-seed the system with known credentials or use test tokens in non-production environments.

Code reviews ensure:

• High code quality and adherence to standards.
• Early detection of logical errors.
• Knowledge sharing among team members.
• Continuous improvement of the testing framework and scripts.

• Store credentials in encrypted files or environment variables.
• Use a credentials manager or a secure vault (like HashiCorp Vault).
• Never hard-code sensitive information in test scripts.
• Rotate credentials periodically.

• Mock external services using stubs or mock servers (WireMock).
• Use test doubles to isolate the application from unreliable third parties.
• Validate only the interaction points, not the external service’s correctness.

Contract Testing checks that a service (provider) and a client (consumer) adhere to a contract. By ensuring APIs return expected structures and fields, UI automation can trust backend responses, reducing the need to test all UI workflows end-to-end. It speeds up feedback by catching integration issues earlier.

• Use data factories or builders to programmatically generate test data.
• Integrate with databases or APIs that seed test data before tests run.
• Use synthetic data tools to produce randomized but valid inputs.

• Review test reports, screenshots, and logs.
• Check recent code changes in the version control.
• Re-run tests locally to replicate the issue.
• Add temporary logging or breakpoints if running locally with a remote WebDriver.
• Investigate environment differences (browser versions, network conditions).

• Create utility classes for common actions (e.g., waiting, clicking, selecting dropdowns).
• Implement the DRY (Don’t Repeat Yourself) principle.
• Centralize configuration and constants.
• Build custom libraries or modules for repeated functionalities.

Use logging frameworks (e.g., Log4j, SLF4J) to record detailed information about test execution flow and errors. Logging is important for:

• Troubleshooting test failures.
• Auditing test runs.
• Monitoring performance and stability over time.

private static final Logger logger = LogManager.getLogger(MyTest.class);
logger.info("Test started");

• Identify stable and high-priority test cases for automation first (smoke tests, regression tests).
• Map manual steps to automated actions.
• Start with a small proof of concept to validate feasibility.
• Gradually expand coverage while ensuring maintainability.
• Involve the team in reviewing and refining the automation approach.

• Follow thought leaders, blogs, and tech conferences.
• Attend webinars, workshops, and training sessions.
• Experiment with new tools in test environments.
• Participate in QA communities and discussion forums (Stack Overflow, Reddit).
• Continuously update frameworks with new libraries and methodologies.

Task:

Write a helper function waitForElementEnabled that waits until a given selector is both visible and enabled before returning the element.

Example Task Code:

// Implement waitForElementEnabled(page, selector: string, timeout?: number)
// Must resolve once the element is ready for user interaction (visible, enabled).

Answer:

import { Page, expect } from '@playwright/test';

export async function waitForElementEnabled(page: Page, selector: string, timeout: number = 5000) {
  const element = page.locator(selector);
  await element.waitFor({ state: 'visible', timeout });
  // Check enabled by verifying it’s not disabled attribute or verifying it’s interactive.
  // Best practice: use assertions for clarity and meaningful error messages.
  await expect(element).toBeEnabled({ timeout });
  return element;
}

Applied Reasoning:

Instead of relying on complex custom polling, Playwright’s built-in conditions
(toBeVisible, toBeEnabled) and waitFor states are leveraged. This reduces code complexity and ensures the logic is directly tied to stable, Playwright-supported conditions. In real projects, waiting explicitly for enabled states prevents flakiness, especially in complex SPAs where elements may appear before they’re fully interactive.

Task:

Implement a helper findElementWithRetries that attempts to locate an element multiple times to handle intermittent rendering delays.

Example Task Code:

// Implement findElementWithRetries(page, selector: string, retryCount: number, timeout: number)

Answer:

import { Page, Locator } from '@playwright/test';

const isElementExists = (locator: Locator) => {
  let exist = false;

  try {
    exist = await locator.count() > 0
  } catch {}

  return exist;
}

export async function findElementWithRetries(page: Page, selector: string, retryCount: number = 3, timeout: number = 500) {
  const locator = page.locator(selector);

  for (let attempt = 0; attempt < retryCount; attempt++) {
    if (await isElementExists(locator)) {
      return locator;
    }
    
    await page.waitForTimeout(timeout);
  }

  throw new Error(`Element not found after ${retryCount} retries: ${selector}`);
}

Applied Reasoning:

While Playwright is generally reliable with its locator API, external conditions (like dynamic frameworks or slow backend responses) might cause flakiness. Short, controlled retries with small wait intervals can help stabilize tests in real CI pipelines. This is better than arbitrary long waits— it balances speed and reliability.

Task:

Create a wrapper around page to log navigation actions (goto, back, forward, reload) for debugging. Return a new “page” object that logs these actions before executing them.

Example Task Code:

// Implement a function wrapPageForLogging(page: Page) that returns an object with same methods but logs navigations.

Answer:

import { Page } from '@playwright/test';

export function wrapPageForLogging(page: Page): Page {
  const originalGoto = page.goto.bind(page);
  const originalGoBack = page.goBack.bind(page);
  const originalGoForward = page.goForward.bind(page);
  const originalReload = page.reload.bind(page);

  return new Proxy(page, {
    get(target, prop: keyof Page) {
      if (prop === 'goto') {
        return async (url: string, options?: Parameters<Page['goto']>[1]) => {
          console.log(`[NAVIGATION] Going to: ${url}`);
          return await originalGoto(url, options);
        };
      }
      if (prop === 'goBack') {
        return async (options?: Parameters<Page['goBack']>[0]) => {
          console.log('[NAVIGATION] Going back');
          return await originalGoBack(options);
        };
      }
      if (prop === 'goForward') {
        return async (options?: Parameters<Page['goForward']>[0]) => {
          console.log('[NAVIGATION] Going forward');
          return await originalGoForward(options);
        };
      }
      if (prop === 'reload') {
        return async (options?: Parameters<Page['reload']>[0]) => {
          console.log('[NAVIGATION] Reloading');
          return await originalReload(options);
        };
      }
      return target[prop];
    }
  });
}

Applied Reasoning:

Proxying the page object allows injection of logging without changing test code extensively. This pattern is practical in debugging complex navigation issues in distributed teams or flaky CI environments. Logging provides immediate insights into test flow and timing.

Task:

Write waitForTextContent(page, selector, text, timeout) that polls until the element’s text matches the given value.

Example Task Code:

// Implement waitForTextContent(page, selector, text, timeout).

Answer:

import { Page } from '@playwright/test';

export async function waitForTextContent(page: Page, selector: string, text: string, timeout: number = 5000) {
  const start = Date.now();
  const locator = page.locator(selector);
  while ((Date.now() - start) < timeout) {
    const currentText = await locator.textContent();
    if (currentText?.trim() === text) {
      return locator;
    }
    await page.waitForTimeout(200);
  }
  throw new Error(`Text "${text}" not found in element "${selector}" within ${timeout}ms`);
}

Applied Reasoning:

Even though Playwright provides expect(locator).toHaveText() for built-in waiting, building a custom polling logic shows you can adapt to special conditions not covered by standard assertions. In practice, you would typically use expect, but this demonstrates versatility for unique synchronization logic in complex UIs.

Task:

Use Playwright’s network request hooks to capture all network requests after navigating to a page.

Example Task Code:

// Implement getAllNetworkRequests(page, url) that returns array of request URLs after page load.

Answer:

import { Page } from '@playwright/test';

export async function getAllNetworkRequests(page: Page, url: string): Promise<string[]> {
  const requests: string[] = [];
  page.on('request', (req) => requests.push(req.url()));

  await page.goto(url);

  return requests;
}

Applied Reasoning:

This is useful for verifying the backend calls triggered by certain user actions. In real projects, monitoring network requests helps ensure that lazy-loaded content or third-party services are being called as expected. It’s a key aspect of modern web testing where frontends heavily depend on APIs.

Task:

Create a LoginPage class with methods fillUsername, fillPassword, and submit. Use Playwright’s locator strategies.

Example Task Code:

// Implement a LoginPage class encapsulating username, password fields and submit action.

Answer:

import { Page } from '@playwright/test';

export class LoginPage {
  constructor(private page: Page) {}

  async fillUsername(username: string) {
    await this.page.fill('#username', username);
  }

  async fillPassword(password: string) {
    await this.page.fill('#password', password);
  }

  async submit() {
    await this.page.click('#loginBtn');
  }
}

Applied Reasoning:

A POM improves test clarity and maintainability. Instead of scattering selectors throughout tests, centralizing them in one place reduces maintenance overhead. This is best practice in large test suites where UI elements may change frequently.

Task:

Use Playwright test fixtures to run a test with multiple username/password combinations and verify login scenarios.

Example Task Code:

// Implement a test using test.describe.parallel and test.each-like approach to run multiple credentials.

Answer (using Playwright test runner):

import { test } from '@playwright/test';

const credentials = [
  {username: 'user1', password: 'pass1'},
  {username: 'user2', password: 'pass2'}
];

credentials.forEach(({username, password}) => {
  test(`Login test with ${username}`, async ({ page }) => {
    await page.goto('<https://example.com/login>');
    await page.fill('#username', username);
    await page.fill('#password', password);
    await page.click('#loginBtn');
    // Implement meaningful assertions. For demonstration:
    await page.waitForSelector('#welcomeBanner');
  });
});

Applied Reasoning:

Data-driven testing is critical in validating various user roles and credentials. Using arrays and loops (or test.step in newer versions) is common. In real-world setups, test data might come from JSON files, environment variables, or APIs.

Task:
Load test configuration from a JSON file and create a helper getConfigValue(key) that returns the specified config.

Example Task Code:

// Implement getConfigValue(key) that reads from config.json

Answer:

import fs from 'fs';

const config = JSON.parse(fs.readFileSync('config.json', 'utf-8'));

export function getConfigValue(key: string): string {
  return config[key];
}

Applied Reasoning:

Externalizing configuration (URLs, credentials, feature flags) reduces code duplication and makes tests environment-agnostic. In real-world CI pipelines, swapping config files per environment is a common pattern.

Task:

Write a test helper that tries to find a non-existent selector, and if it fails, takes a screenshot.

Example Task Code:

// Implement tryFindOrScreenshot(page, selector, screenshotPath).

Answer:

import { Page } from '@playwright/test';

export async function tryFindOrScreenshot(page: Page, selector: string, screenshotPath: string) {
  try {
    return await page.waitForSelector(selector, { timeout: 2000 });
  } catch {
    await page.screenshot({ path: screenshotPath });
    throw new Error(`Element not found: ${selector}. Screenshot saved.`);
  }
}

Applied Reasoning:

Screenshots are invaluable in debugging CI test failures. This approach gives immediate visual feedback on the page state at failure time. In the wild, screenshots drastically reduce the time needed to diagnose flaky locator issues or unexpected UI states.

Task:

Create scrollElementIntoView(page, selector) to ensure an element is visible before interaction.

Example Task Code:

// Implement scrollElementIntoView(page, selector)

Answer:

import { Page } from '@playwright/test';

export async function scrollElementIntoView(page: Page, selector: string) {
  await page.locator(selector).scrollIntoViewIfNeeded();
}

Applied Reasoning:

Playwright provides scrollIntoViewIfNeeded() out of the box. In practice, ensuring elements are in view prevents click interception errors. This reduces flakiness that often occurs if elements are hidden off-screen in responsive layouts.

Task:

Write executeCustomScript(page, script) that runs arbitrary JS in the browser context.

Example Task Code:

// Implement executeCustomScript(page, script)

Answer:

import { Page } from '@playwright/test';

export async function executeCustomScript(page: Page, script: string) {
  return await page.evaluate(script);
}

Applied Reasoning:

Direct DOM manipulation or feature toggling via scripts can help in test setup or diagnosing page behavior. In real usage, this is often done to reset session storage or modify test data states without reloading pages.

Task:

Check all <a> elements on a page and verify their href URLs return HTTP 200.

Example Task Code:

// Implement validateAllLinks(page)

Answer:

import { Page, request } from '@playwright/test';

export async function validateAllLinks(page: Page) {
  const anchors = page.locator('a[href]');
  const count = await anchors.count();
  for (let i = 0; i < count; i++) {
    const href = await anchors.nth(i).getAttribute('href');
    if (href && href.startsWith('http')) {
      const response = await request.newContext().get(href);
      if (response.status() !== 200) {
        throw new Error(`Link ${href} returned ${response.status()}`);
      }
    }
  }
}

Applied Reasoning:

Link validation ensures no broken references. In large SPAs, broken links hurt UX. This check is a pragmatic approach to maintaining quality. In production CI, you might run this periodically or only for critical pages.

Task:

Write switchToFrameByTitle(page, title) that iterates frames and switches to the one with the given document title.

Example Task Code:

// Implement switchToFrameByTitle(page, title)

Answer:

import { Page } from '@playwright/test';

export async function switchToFrameByTitle(page: Page, title: string) {
  for (const frame of page.frames()) {
    const frameTitle = await frame.title();
    if (frameTitle === title) {
      return frame;
    }
  }
  throw new Error(`Frame with title "${title}" not found`);
}

pplied Reasoning:

Sometimes, multiple iframes are present. Identifying them by known attributes (like title) makes the code self-documenting and reduces maintenance burden. Real-world: Financial or embedded services often load content in iframes, and stable identification is key.

Task:

Implement a simple soft assertion mechanism that collects failures but doesn’t stop test execution immediately. Finally, call assertAll().

Example Task Code:

// Implement a SoftAssert utility class with softAssertEquals and assertAll.

Answer:

export class SoftAssert {
  private failures: string[] = [];

  softAssertEquals(actual: string, expected: string) {
    if (actual !== expected) {
      this.failures.push(`Expected "${expected}" but got "${actual}"`);
    }
  }

  assertAll() {
    if (this.failures.length > 0) {
      throw new Error(`Soft assertion failures:\\n${this.failures.join('\\n')}`);
    }
  }
}

Applied Reasoning:

Soft assertions help identify all issues in a single test run rather than stopping at the first failure. In complex end-to-end tests, this approach is helpful for thorough reporting, especially in regression testing where multiple UI discrepancies might appear.

Task:

Show a Playwright configuration snippet (playwright.config.ts) to run tests in parallel across multiple workers.

Example Task Code:

// Provide a snippet of playwright.config.ts for parallel execution

Answer:

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  workers: 4,
});

Applied Reasoning:

Parallel execution cuts down test run time significantly. By leveraging multiple CPU cores in CI, teams get faster feedback. This is common practice in large-scale enterprise test suites.

Task:

Send a GET request to https://api.github.com and verify status 200 using Playwright’s API testing.

Example Task Code:

// Implement testGitHubApi(request)

Answer (with test runner):

import { test, expect } from '@playwright/test';

test('GitHub API test', async ({ request }) => {
  const response = await request.get('<https://api.github.com>');
  expect(response.status()).toBe(200);
});

Applied Reasoning:

API tests integrated with UI tests ensure end-to-end coverage. By verifying API responses in the same framework, you maintain consistency and reduce the number of tools in your test stack.

Task:

Create a custom expect helper expectAttributeValue that waits until an element has a given attribute value.

Example Task Code:

// Implement expectAttributeValue(locator, attribute, value)

Answer:

import { expect, Locator } from '@playwright/test';

export async function expectAttributeValue(locator: Locator, attribute: string, value: string) {
  await expect(locator).toHaveAttribute(attribute, value, { timeout: 5000 });
}

Applied Reasoning:

Leverage Playwright’s native expect conditions for simplicity. Relying on built-in assertions is a best practice because it reduces custom code and leverages the tool’s stable retrying logic.

Task:

Generate a minimal HTML report of test results after the run. Assume you have a results array.

Example Task Code:

// Implement generateHtmlReport(results, filePath)

Answer:

import fs from 'fs';

interface TestResult {
  name: string;
  status: 'passed' | 'failed';
}

export function generateHtmlReport(results: TestResult[], filePath: string) {
  const rows = results.map(r => `<tr><td>${r.name}</td><td>${r.status}</td></tr>`).join('');
  const html = `<html><body><table><tr><th>Test</th><th>Status</th></tr>${rows}</table></body></html>`;
  fs.writeFileSync(filePath, html);
}

Applied Reasoning:

Custom reporting can integrate into internal dashboards or Slack notifications. While Playwright has HTML reports, customizing them can be useful to highlight certain metrics or integrate with proprietary tools.

Task:

Upload a file by setting the input’s files directly.

Example Task Code:

// Implement uploadFile(page, selector, filePath)

Answer:

import { Page } from '@playwright/test';

export async function uploadFile(page: Page, selector: string, filePath: string) {
  const input = page.locator(selector);
  await input.setInputFiles(filePath);
}

Applied Reasoning:

In modern testing, setInputFiles is straightforward and avoids hacky JavaScript injections. It’s reliable and reflect a common scenario: validating file uploads in web apps (resumes, images, etc.).

Task:

Perform a GET request using Basic Auth and verify status code.

Example Task Code:

// Implement getWithBasicAuth(request, url, user, pass)

Answer:

import { APIRequestContext } from '@playwright/test';

export async function getWithBasicAuth(request: APIRequestContext, url: string, user: string, pass: string) {
  const response = await request.get(url, {
    headers: {
      'Authorization': 'Basic ' + Buffer.from(`${user}:${pass}`).toString('base64')
    }
  });
  return response.status();
}

Applied Reasoning:

For APIs protected by Basic Auth, this pattern is common. Real projects often use environment variables or secure vaults for credentials, never hard-coded. This approach integrates seamlessly into CI/CD.

Task:

Wait until no pending network requests remain (simulate waiting for Angular/React AJAX completion).

Example Task Code:

// Implement waitForNetworkIdle(page)

Answer:

import { Page } from '@playwright/test';

export async function waitForNetworkIdle(page: Page, idleTime: number = 1000) {
  let noRequestsStart = Date.now();

  page.on('request', () => noRequestsStart = Date.now());
  page.on('requestfinished', () => noRequestsStart = Date.now());

  while ((Date.now() - noRequestsStart) < idleTime) {
    await page.waitForTimeout(100);
  }
}

Applied Reasoning:

While Playwright offers waitForLoadState('networkidle') for initial load, complex SPAs may trigger requests asynchronously. This approach ensures you only proceed when the app is stable. It’s a common technique in real E2E testing for complex UIs.

Task:

Implement a test that retries twice on failure using test.retry().

Example Task Code:

// Implement a test block that retries failed tests twice

Answer:

import { test, expect } from '@playwright/test';

test.describe('Retry Example', () => {
  test('flaky test', async ({ page }) => {
    test.info().config.test.retry = 2; // or set in playwright.config

    await page.goto('<https://example.com>');
    const random = Math.random();
    // Suppose the assertion might fail sometimes
    expect(random).toBeGreaterThan(0.8);
  });
});

Applied Reasoning:

Retries in test frameworks handle environmental flakiness, such as ephemeral network hiccups. Real-world best practice: Limit retries and fix root causes rather than relying solely on retries as a crutch.

Task:

Highlight an element by injecting CSS before clicking, for visual debugging in CI videos.

Example Task Code:

// Implement highlightElement(page, selector)

Answer:

import { Page } from '@playwright/test';

export async function highlightElement(page: Page, selector: string) {
  await page.evaluate((sel) => {
    const el = document.querySelector(sel);
    if (el) el.style.border = '2px solid red';
  }, selector);
}

Applied Reasoning:

Highlighting elements helps debug which element was interacted with in a recorded CI video, speeding up root cause analysis. It’s a practical technique in real UI test pipelines.

Task:

Compare DOM size before and after an action to see if the DOM changed.

Example Task Code:

// Implement hasDomChanged(page, action)

Answer:

import { Page } from '@playwright/test';

export async function hasDomChanged(page: Page, action: () => Promise<void>): Promise<boolean> {
  const beforeCount = await page.evaluate(() => document.getElementsByTagName('*').length);
  await action();
  const afterCount = await page.evaluate(() => document.getElementsByTagName('*').length);
  return beforeCount !== afterCount;
}

Applied Reasoning:

This can help verify that a button click triggers expected UI changes. Real-world: Useful in complex dynamic UIs where asserting exact content might be harder than detecting structural changes.

Task:

Perform drag-and-drop using Playwright’s dragTo.

Example Task Code:

// Implement dragAndDrop(page, sourceSelector, targetSelector)

Answer:

import { Page } from '@playwright/test';

export async function dragAndDrop(page: Page, sourceSelector: string, targetSelector: string) {
  const source = page.locator(sourceSelector);
  const target = page.locator(targetSelector);
  await source.dragTo(target);
}

Applied Reasoning:

Drag and drop tests are common in dashboards or CMS interfaces. Using Playwright’s native dragTo is robust and avoids the complexity of simulated mouse events.

Task:

Record all console logs while loading a page and return them.

Example Task Code:

// Implement getConsoleLogs(page, url)

Answer:

import { Page } from '@playwright/test';

export async function getConsoleLogs(page: Page, url: string) {
  const logs: string[] = [];
  page.on('console', msg => logs.push(msg.text()));
  await page.goto(url);
  return logs;
}

Applied Reasoning:

Console logs help identify JavaScript errors or warnings that could lead to UI or functional issues. In production testing, capturing logs aids in diagnosing UI regressions or third-party script failures.

Task:

Use Playwright’s built-in screenshot comparison if available, or implement a basic pixel-by-pixel comparison using an external library. Here, we’ll assume basic pixel comparison.

Example Task Code:

// Implement compareScreenshots(path1, path2) returning true if identical.

Answer (conceptual):

import { PNG } from 'pngjs';
import fs from 'fs';

export function compareScreenshots(path1: string, path2: string): boolean {
  const img1 = PNG.sync.read(fs.readFileSync(path1));
  const img2 = PNG.sync.read(fs.readFileSync(path2));

  if (img1.width !== img2.width || img1.height !== img2.height) return false;

  for (let i = 0; i < img1.data.length; i++) {
    if (img1.data[i] !== img2.data[i]) return false;
  }
  return true;
}

Applied Reasoning:

Visual regression testing ensures UI consistency. Pixel comparison is a fallback to built-in Playwright snapshot comparisons. Real teams often integrate tools like
@playwright/test’s toHaveScreenshot() or dedicated services for robust visual diffing.

Task:

Provide browser launch options that disable notifications in a test configuration.

Example Task Code:

// Implement getBrowserOptions() that returns launch config with notifications disabled (Chromium-based)

Answer:

import { BrowserTypeLaunchOptions } from '@playwright/test';

export function getBrowserOptions(): BrowserTypeLaunchOptions {
  return {
    args: ['--disable-notifications']
  };
}

Applied Reasoning:

Reducing UI noise improves test stability and avoids flaky modal conditions. In real CI builds, disabling features not under test leads to more stable, faster tests.

Task:

Read a config.json file and return values for given keys.

Example Task Code:

// Implement JsonConfigReader class with getValue(key)

Answer:

import fs from 'fs';

export class JsonConfigReader {
private data: any;
constructor(filePath: string) {
this.data = JSON.parse(fs.readFileSync(filePath, 'utf-8'));
}

getValue(key: string) {
return this.data[key];
}
}

Applied Reasoning:

Centralized config management ensures maintainability. Teams often keep secrets out of code, injecting them at runtime. This approach is common in real CI/CD environments.

Task:

Generate a CSS selector dynamically based on parameters, e.g., tag, attr, value.

Example Task Code:

// Implement generateSelector(tag, attr, value)

Answer:

export function generateSelector(tag: string, attr: string, value: string) {
return `${tag}[${attr}='${value}']`;

Applied Reasoning:

Dynamic selector generation is handy when dealing with parameterized tests. It ensures a consistent locator strategy. In real-world testing, stable selectors are essential. CSS selectors are generally preferred over XPath for clarity and speed.

}