Introduction: What Interviewers Expect From Real-Time Playwright Candidates

Playwright real time interview questions are different from questions that only test whether you remember Playwright syntax.

In a real automation project, a test may work perfectly on your laptop and fail in CI. A locator may suddenly match three elements. Authentication may expire halfway through a suite. Tests may pass sequentially but fail when executed in parallel.

Interviewers want to know how you respond to these situations.

They are evaluating whether you can:

Diagnose automation failures systematically.
Select stable locators.
Synchronize with dynamic applications.
Design reusable Page Objects and fixtures.
Manage authentication and test data.
Combine API and UI automation.
Debug CI-only failures.
Reduce flaky tests.
Scale a Playwright framework.
Explain engineering trade-offs.

Playwright’s current documentation emphasizes resilient, user-facing locators, auto-waiting, retryability, isolated browser contexts, fixtures, and trace-based debugging.

This guide focuses on real-world Playwright interview scenarios, from beginner problems to Senior SDET and QA Lead discussions.

How Real-Time Playwright Interviews Differ From Theoretical Interviews

A theoretical question might be:

What is a BrowserContext?

A real-time interview question might be:

Two users need to access the same application simultaneously with different permissions. How would you automate it?

The second question tests whether you can apply BrowserContext correctly.

Theoretical Interview	Real-Time Interview
What is a locator?	Why did your locator fail in CI?
What is POM?	Design POM for a large application
What is auto-waiting?	Diagnose a timeout despite auto-waiting
What is storageState?	Handle expired authentication
What are fixtures?	Design worker-scoped test data
What is parallel execution?	Fix conflicts caused by parallel workers
What is tracing?	Debug a failure that happens only in CI

The best candidates explain what they would investigate, why, and how they would implement the fix.

Beginner Real-Time Playwright Interview Questions

1. The Login Button Works Manually but Fails in Automation

Difficulty: Beginner

Real-Time Scenario

A login page works correctly when tested manually. Your Playwright script enters the username and password, but clicking Login times out.

Interview Question

How would you investigate this problem?

Interview-Ready Answer

I would first verify that the locator identifies the intended button. Then I would check whether the button is enabled, visible, stable, and receiving pointer events.

I would also inspect overlays, validation errors, iframe boundaries, authentication redirects, and the actual browser state.

Playwright performs actionability checks before actions such as click(), including visibility, stability, event reception, enabled state, and uniqueness.

Practical Solution

Start with a semantic locator:

const loginButton = page.getByRole(‘button’, {

});

await loginButton.click();

Then debug:

await expect(loginButton).toBeVisible();

await expect(loginButton).toBeEnabled();

await loginButton.click();

Interview Tip

Do not immediately answer, “Increase the timeout.”

Explain that a timeout is a symptom and you need to identify why the actionability conditions are not satisfied.

2. An Element Is Dynamically Rendered

Real-Time Scenario

A dashboard loads a “Generate Report” button two seconds after the page opens.

Interview Question

Would you add waitForTimeout(2000)?

Interview-Ready Answer

No. I would locate the button and use an action or web-first assertion that waits for the relevant condition.

TypeScript Example

const reportButton = page.getByRole(‘button’, {

});

await expect(reportButton).toBeVisible();

await reportButton.click();

Explanation

Playwright locators are designed around auto-waiting and retryability.

Interview Tip

Say:

“I wait for an application condition, not an arbitrary amount of time.”

3. Your Locator Matches Multiple Elements

Real-Time Scenario

You write:

await page.getByRole(‘button’, {

}).click();

The test fails because there are several Delete buttons.

Interview Question

How would you fix it?

Interview-Ready Answer

I would scope the locator to the relevant business entity rather than immediately using .nth().

TypeScript Example

const userRow = page

.getByRole(‘row’)

.filter({ hasText: ‘John Smith’ });

await userRow.getByRole(‘button’, {

}).click();

Explanation

Chaining and filtering allow you to narrow a locator to the correct component. Playwright recommends this approach for resilient locator design.

Interview Tip

Avoid saying:

await page.getByRole(‘button’, {

}).nth(2).click();

unless the position itself is part of the requirement.

Intermediate Real-Time Playwright Interview Questions

4. The Dynamic ID Changes After Every Refresh

Real-Time Scenario

A button has IDs such as:

submit-82391

submit-91283

submit-10482

Interview Question

How would you automate it?

Interview-Ready Answer

I would avoid the generated ID and find a stable user-facing attribute or explicit test contract.

TypeScript Example

await page.getByRole(‘button’, {

}).click();

Or, if the team has intentionally provided a test contract:

await page.getByTestId(‘submit-order’).click();

Explanation

Playwright recommends prioritizing user-facing attributes and explicit contracts. CSS and XPath can be useful, but selectors tightly coupled to DOM implementation are more likely to break when the UI changes.

Interview Tip

Explain that the best locator is not necessarily the shortest locator.

5. The Text Changes Based on Test Data

Real-Time Scenario

The application displays:

Welcome, John

Welcome, Priya

Welcome, David

Interview Question

How would you verify the greeting without hardcoding a particular user’s name?

Interview-Ready Answer

Use a regular expression or a locator scoped to the relevant component.

TypeScript Example

await expect(

page.getByText(/^Welcome, .+/)

).toBeVisible();

Or:

const greeting = page.getByRole(‘heading’);

await expect(greeting).toContainText(‘Welcome’);

Interview Tip

Choose the assertion based on what the requirement actually guarantees.

6. The CSS Selector Became Unstable

Real-Time Scenario

Your test uses:

page.locator(

‘#app > div:nth-child(2) > div:nth-child(3) > button’

);

A frontend developer changes the layout and several tests fail.

Interview Question

How would you prevent this?

Interview-Ready Answer

I would replace DOM-position-based selectors with semantic locators or stable test IDs.

TypeScript Example

await page.getByRole(‘button’, {

}).click();

Explanation

Long CSS/XPath chains are tightly coupled to page structure. Playwright’s locator guidance recommends user-facing locators or explicit testing contracts instead.

Interview Tip

This question tests whether you understand maintainability, not merely selector syntax.

7. XPath Works but Is Difficult to Maintain

Real-Time Scenario

A team has hundreds of XPath selectors containing multiple div levels.

Interview Question

Would you rewrite all of them?

Interview-Ready Answer

Not necessarily immediately. I would prioritize high-maintenance or frequently failing tests, establish a locator standard, and migrate selectors incrementally.

TypeScript Example

Instead of:

await page.locator(

‘//div[@class=”container”]/div[2]/button[1]’

).click();

prefer:

await page.getByRole(‘button’, {

}).click();

Interview Tip

A strong answer includes migration strategy, not just “XPath is bad.”

Authentication and Session-Management Scenarios

8. Authentication Expires During the Test Suite

Real-Time Scenario

Your suite authenticates successfully in the morning, but several hours later tests start failing because the session has expired.

Interview Question

How would you handle authentication?

Interview-Ready Answer

I would avoid logging in through the UI for every test. I would use a dedicated authentication setup and reuse authenticated state through storageState, while ensuring the state is refreshed when it expires.

Playwright supports reusing authenticated browser state and recommends protecting authentication-state files because they may contain sensitive cookies and headers.

TypeScript Example

await page.context().storageState({

path: ‘playwright/.auth/user.json’

});

Configuration:

use: {

storageState: ‘playwright/.auth/user.json’

}

Interview Tip

Mention that .auth files should not be committed to source control.

9. Parallel Tests Modify the Same Account

Real-Time Scenario

A test changes a user’s profile while another test checks that profile. Both tests pass individually but fail in parallel.

Interview Question

What is wrong with the framework?

Interview-Ready Answer

The tests share mutable server-side state.

I would isolate accounts or test data by worker/test and ensure that tests do not modify shared state.

Playwright’s authentication guidance specifically recommends separate accounts per parallel worker when tests modify server-side state.

TypeScript Example

const username =

`test-user-${testInfo.workerIndex}`;

Interview Tip

The underlying problem is test isolation, not simply parallel execution.

API and Test-Data Scenarios

10. API Response Is Slow or Inconsistent

Real-Time Scenario

A UI test depends on an API that sometimes takes 500 ms and sometimes 10 seconds.

Interview Question

How would you make the test reliable?

Interview-Ready Answer

First, I would determine whether the API behavior is a real product problem or a test-environment problem.

For deterministic UI tests, I may mock the API. For integration coverage, I would test the real API separately and avoid hiding genuine performance defects.

TypeScript Example

await page.route(‘**/api/products’, async route => {

await route.fulfill({

status: 200,

contentType: ‘application/json’,

body: JSON.stringify({

products: [

{ id: 1, name: ‘Laptop’ }

]

})

});

Interview Tip

Do not mock everything. A mature test strategy separates UI behavior, integration testing, and real backend validation.

11. Test Data Conflicts Between Workers

Real-Time Scenario

A test creates a customer named John and another worker tries to create the same customer.

Interview Question

How would you solve it?

Interview-Ready Answer

Use a data factory or API that generates unique records.

TypeScript Example

function createCustomerName(

workerIndex: number

): string {

return `Customer-${workerIndex}-${Date.now()}`;

}

Practical Solution

Prefer centralized test-data utilities:

const customer = await customerApi.create({

});

Interview Tip

Also discuss cleanup. Creating unique data without lifecycle management can eventually pollute the environment.

Page Object Model and Fixture Scenarios

12. Your Page Object Has 1,000 Lines

Real-Time Scenario

A large application has one ApplicationPage.ts containing hundreds of locators and unrelated business operations.

Interview Question

How would you refactor it?

Interview-Ready Answer

I would divide the object according to meaningful page or component boundaries.

For example:

pages/

LoginPage.ts

DashboardPage.ts

OrdersPage.ts

components/

Header.ts

DataTable.ts

DatePicker.ts

TypeScript Example

export class OrdersPage {

constructor(private readonly page: Page) {}

orderRow(orderId: string) {

return this.page

.getByRole(‘row’)

.filter({ hasText: orderId });

}

async openOrder(orderId: string) {

await this.orderRow(orderId)

.getByRole(‘link’, { name: ‘View’ })

.click();

}

Interview Tip

POM should model meaningful application behavior, not merely hide every Playwright statement behind another method.

13. When Should You Use a Fixture Instead of POM?

Real-Time Scenario

Several test suites need the same authenticated user, API client, or helper object.

Interview Question

What would you use?

Interview-Ready Answer

I would use a fixture for reusable test dependencies and lifecycle management. I would use POM for page or component behavior.

Playwright Test fixtures establish the environment required by tests and are isolated according to their configured scope.

TypeScript Example

type Fixtures = {

ordersPage: OrdersPage;

};

export const test = base.extend<Fixtures>({

ordersPage: async ({ page }, use) => {

await use(new OrdersPage(page));

}

});

Interview Tip

Think:

POM = application behavior

Fixture = test dependency/lifecycle

Parallel Execution and Flaky-Test Scenarios

14. Tests Pass Sequentially but Fail in Parallel

Real-Time Scenario

The suite is stable with one worker but fails with four workers.

Interview Question

What would you investigate?

Interview-Ready Answer

I would investigate:

Shared test data.
Shared accounts.
Database state.
File-system collisions.
Environment capacity.
Race conditions.
Worker-specific authentication.
Tests depending on execution order.

TypeScript Example

test(‘isolated order’, async ({

request

}, testInfo) => {

const orderId =

`order-${testInfo.workerIndex}-${Date.now()}`;

// Create isolated test data.

});

Interview Tip

Do not simply reduce workers permanently. Find the dependency causing the conflict.

15. Playwright Tests Have Become Flaky

Real-Time Scenario

A test fails approximately one out of twenty executions.

Interview Question

How would you debug it?

Interview-Ready Answer

I would reproduce it repeatedly and inspect:

Locator reliability.
Network timing.
Dynamic rendering.
Shared test state.
Authentication.
Parallel execution.
Environment resources.
Backend instability.
Race conditions.

I would collect trace, screenshot, and video evidence where useful.

TypeScript Configuration

use: {

trace: ‘retain-on-failure’,

screenshot: ‘only-on-failure’,

video: ‘retain-on-failure’

}

Interview Tip

Retries may reduce pipeline noise, but they do not fix the underlying flakiness.

CI/CD and Docker Failure Scenarios

16. Test Passes Locally but Fails in CI

Real-Time Scenario

A developer reports:

“It passes on my laptop.”

Interview Question

What is your debugging process?

Interview-Ready Answer

I compare the environments systematically:

Node.js version.
Playwright version.
Browser binaries.
OS.
Environment variables.
Secrets.
Base URL.
Authentication.
Viewport.
CPU and memory.
Network.
Test data.
Worker count.

I would also inspect the Playwright trace.

Example

node –version

npx playwright –version

npx playwright test –debug

Interview Tip

Think environment parity + evidence, not “increase timeout.”

17. Browser Is Not Installed in CI

Real-Time Scenario

The GitHub Actions job reports that the required browser executable cannot be found.

Interview Question

What would you add to the pipeline?

Interview-Ready Answer

Install Playwright browser binaries and their Linux dependencies.

GitHub Actions Example

– run: npm ci

– run: npx playwright install –with-deps

– run: npx playwright test

Playwright’s CI documentation recommends installing the required browser binaries and dependencies before running tests.

Interview Tip

Know the difference between installing the npm package and installing the browser binaries.

18. Docker Tests Fail but Local Tests Pass

Real-Time Scenario

Tests pass on Windows but fail inside a Linux Playwright container.

Interview Question

What would you investigate?

Interview-Ready Answer

I would compare:

Browser version.
OS dependencies.
Fonts.
Environment variables.
File paths.
Permissions.
Time zone.
Network access.
Display/headless configuration.

Interview Tip

Docker reduces environmental variation, but it does not automatically guarantee identical application behavior.

Debugging and Reporting Scenarios

19. Screenshot Comparison Fails Only in CI

Real-Time Scenario

Visual regression tests pass locally but report pixel differences in CI.

Interview Question

What could cause this?

Interview-Ready Answer

Potential causes include different browser versions, fonts, operating-system rendering, viewport size, animations, dynamic content, time zones, or data.

Practical Solution

Stabilize the rendering environment and remove dynamic content from visual comparisons.

await expect(page).toHaveScreenshot(‘dashboard.png’);

Interview Tip

Do not blindly increase the visual comparison threshold. First identify why the pixels differ.

20. Browser Crashes During a Large Suite

Real-Time Scenario

A 3,000-test regression suite occasionally crashes the browser process.

Interview Question

What would you investigate?

Interview-Ready Answer

I would investigate memory consumption, worker count, test isolation, browser leaks, large downloads, page lifecycle management, and CI resource limits.

Practical Solution

Reduce excessive concurrency and identify tests that leave resources open.

Playwright’s CI guidance notes that worker configuration should consider system resources and reproducibility; sharding can provide wider parallelization across jobs.

Interview Tip

Do not assume that increasing workers always makes tests faster.

Framework Architecture and Scalability Scenarios

21. Your Test Suite Takes Four Hours

Real-Time Scenario

The regression suite has grown to thousands of tests and takes too long.

Interview Question

How would you reduce execution time?

Interview-Ready Answer

I would first measure where the time is spent. Then I would consider:

Parallel workers.
CI sharding.
API-driven setup.
Reusable authentication.
Better fixture scopes.
Test selection.
Removing redundant UI setup.
Browser-project optimization.
Faster test data creation.

Example

npx playwright test –shard=1/4

Interview Tip

Optimization should be evidence-driven. More parallelism can actually hurt performance when CPU, memory, database, or application capacity becomes the bottleneck.

22. Framework Must Support Multiple Environments

Real-Time Scenario

The same tests must run against development, QA, staging, and production-like environments.

Interview Question

How would you design the framework?

Interview-Ready Answer

Keep environment-specific values outside test logic.

Example

import { defineConfig } from ‘@playwright/test’;

export default defineConfig({

use: {

baseURL:

process.env.BASE_URL ??

‘https://qa.example.com’

}

});

Run:

BASE_URL=https://staging.example.com npx playwright test

Interview Tip

Never hardcode environment URLs throughout test files.

Real-World E-Commerce Playwright Interview Scenarios

23. Automate an E-Commerce Purchase Flow

Real-Time Scenario

You must automate:

Login.
Search for a laptop.
Add it to cart.
Apply a coupon.
Checkout.
Validate the order.

Interview Question

How would you structure the automation?

Interview-Ready Answer

I would separate the workflow into page/component objects and use API setup where possible.

TypeScript Example

const product = page

.getByRole(‘listitem’)

.filter({ hasText: ‘Laptop’ });

await product.getByRole(‘button’, {

}).click();

await page.getByRole(‘link’, {

}).click();

await expect(

page.getByText(‘Laptop’)

).toBeVisible();

Practical Solution

Use:

LoginPage

ProductPage

CartPage

CheckoutPage

OrderPage

Use API calls for expensive preconditions such as inventory or account setup.

Interview Tip

The interviewer is evaluating framework thinking, not just whether the final assertion works.

24. Production Defect Must Be Reproduced

Real-Time Scenario

Users report that checkout occasionally displays a blank page.

Interview Question

How would you use Playwright to reproduce it?

Interview-Ready Answer

I would create a minimal reproduction test, use production-like data where permitted, capture traces and network behavior, and identify whether the problem is deterministic or timing-dependent.

Example

test(‘reproduce checkout issue’, async ({ page }) => {

await page.goto(‘/cart’);

await page.getByRole(‘button’, {

}).click();

await expect(

page.getByRole(‘heading’, {

})

).toBeVisible();

});

Interview Tip

Production debugging requires security awareness. Never expose real customer credentials or sensitive production data in test artifacts.

Selenium-to-Playwright Real-Time Interview Scenario

25. An Existing Selenium Framework Must Be Migrated

Real-Time Scenario

Your organization has 2,000 Selenium tests and wants to adopt Playwright.

Interview Question

Would you rewrite everything immediately?

Interview-Ready Answer

No.

I would perform an incremental migration.

First, audit the current framework and identify:

Business-critical tests.
Flaky tests.
Slow tests.
Shared utilities.
Authentication design.
Test-data dependencies.
CI architecture.

Then I would build a Playwright foundation and migrate a representative test group.

Migration Example

Selenium:

driver.findElement(

By.id(“username”)

).sendKeys(“john”);

Playwright:

await page.getByLabel(‘Username’).fill(‘john’);

Practical Solution

Create a migration matrix:

Selenium	Playwright
WebDriver	Browser / Context / Page
WebElement	Locator
Explicit waits	Auto-waiting + assertions
Cookies	BrowserContext storage
Grid	CI workers/sharding
Page Objects	Page Objects
TestNG/JUnit	Playwright Test or compatible architecture

Interview Tip

A Senior SDET should discuss migration ROI, team training, browser requirements, test stability, CI cost, and long-term maintenance.

Practical Playwright Coding Challenges

26. Create a Reliable Login Helper

Difficulty: Intermediate

Interview Question

Write a reusable login method.

TypeScript Example

async function login(

page: Page,

username: string,

password: string

) {

await page.goto(‘/login’);

await page.getByLabel(‘Username’).fill(username);

await page.getByLabel(‘Password’).fill(password);

await page.getByRole(‘button’, {

}).click();

await expect(page).toHaveURL(/dashboard/);

}

Interview Tip

A helper should represent a meaningful business operation rather than expose low-level DOM implementation unnecessarily.

27. Write a Dynamic Table Locator

Difficulty: Intermediate

Interview Question

Click “View” for order ORD-1001.

TypeScript Example

const order = page

.getByRole(‘row’)

.filter({ hasText: ‘ORD-1001’ });

await order.getByRole(‘link’, {

}).click();

Interview Tip

This is a strong example of locator filtering and contextual selection.

28. Build a Reusable API Client

Difficulty: Advanced

TypeScript Example

import type {

APIRequestContext

} from ‘@playwright/test’;

export class UserApi {

constructor(

private readonly request: APIRequestContext

) {}

async createUser(name: string) {

return this.request.post(‘/api/users’, {

data: { name }

});

}

async deleteUser(id: string) {

return this.request.delete(

`/api/users/${id}`

);

}

Interview Tip

Senior candidates should explain why API clients belong in a separate abstraction instead of being embedded throughout UI tests.

Common Mistakes Candidates Make in Real-Time Interviews

1. Giving a Tool-Specific Answer Without Explaining the Cause

Bad:

“Use force: true.”

Better:

“I would first determine what is blocking the click. If an overlay is incorrectly intercepting events, I would fix or synchronize around that state rather than hiding it with force.”

2. Increasing Timeouts for Every Failure

A timeout may indicate:

Wrong locator.
Missing state transition.
Network issue.
Authentication failure.
Application defect.
CI resource problem.

3. Using nth() as the First Solution

If three buttons match, ask why.

4. Ignoring Test Isolation

A test suite that only works sequentially is not a scalable automation framework.

5. Mocking Every API

Mocks improve determinism, but excessive mocking can reduce integration coverage.

6. Sharing Authentication State Incorrectly

A shared account is reasonable when tests do not interfere with each other. When tests modify shared server-side state, separate accounts may be necessary.

7. Forgetting CI Resource Constraints

A locally powerful laptop can behave very differently from a constrained CI runner.

8. Explaining Only the “Happy Path”

Real-time interview questions are often designed around failure.

Always explain what happens when:

The API fails.
The locator is ambiguous.
The session expires.
The browser crashes.
The test data already exists.
The application is slow.

Playwright Real-Time Interview Preparation Roadmap

Fresher

Focus on:

Playwright basics.
Page.
BrowserContext.
Locators.
Assertions.
Forms.
Navigation.
Frames.
Popups.
Basic debugging.

Practice Playwright Real-Time Interview Questions for Beginners by implementing small workflows.

2–3 Years

Add:

POM.
Fixtures.
API testing.
Authentication.
storageState.
Dynamic locators.
Test-data management.
Parallel execution.
CI/CD.

4–5 Years

Practice:

Framework architecture.
Custom fixtures.
Worker-scoped data.
Network mocking.
Sharding.
Docker.
Flaky-test diagnosis.
Multi-environment configuration.
Selenium migration.

Senior SDET

Be ready to answer:

How would you scale 10,000 tests?
How would you isolate test data?
How would you reduce CI cost?
How would you handle multiple roles?
How would you design authentication?
How would you debug CI-only failures?
How would you migrate Selenium?
How would you measure automation effectiveness?

QA Lead

Think beyond code.

Discuss:

Automation strategy.
Risk-based coverage.
Release gates.
Test ownership.
Environment stability.
Reporting.
Maintenance cost.
CI capacity.
Team standards.
Migration ROI.

Playwright Real-Time Interview Questions Checklist

Before your interview, make sure you can explain how you would handle:

Dynamic elements.
Multiple matching locators.
Strict-mode violations.
CI-only failures.
Slow APIs.
Expired authentication.
Parallel data conflicts.
Flaky tests.
Detached DOM elements.
Iframes.
Popups.
File uploads/downloads.
Visual comparison failures.
Browser crashes.
Docker failures.
Multi-environment execution.
Multiple authenticated users.
Large regression suites.
Selenium migration.
Production defect reproduction.

FAQs: Playwright Real-Time Interview Questions

What are Playwright real-time interview questions?

They are scenario-based questions that test how candidates apply Playwright to real automation problems such as dynamic UI behavior, flaky tests, CI failures, authentication, test-data conflicts, API instability, and framework scalability.

What should freshers know for Playwright scenario interviews?

Freshers should understand locators, assertions, navigation, forms, auto-waiting, frames, popups, and basic debugging.

What are common Playwright interview scenarios for experienced testers?

Experienced candidates should prepare for POM, fixtures, authentication, API/UI integration, parallel execution, test-data isolation, CI/CD, Docker, network mocking, and framework architecture.

How should I answer a Playwright scenario-based interview question?

Use this structure:

Problem → Investigation → Root Cause → Solution → Trade-off → Prevention

This demonstrates engineering thinking rather than memorized syntax.

Why do Playwright tests fail only in CI?

Common causes include different browser or Node versions, environment variables, secrets, resource constraints, network differences, test-data conflicts, timing differences, and excessive parallelism.

How do I reduce Playwright test flakiness?

Start by identifying the root cause. Use resilient locators, web-first assertions, isolated test data, proper authentication, deterministic APIs where appropriate, and diagnostic artifacts.

Should I use waitForTimeout()?

Usually no. Prefer waiting for meaningful application conditions through locator actions and assertions.

How do I handle multiple elements matching the same locator?

Narrow the locator using role, accessible name, container, filter(), or a stable test ID. Use positional methods such as nth() only when position is genuinely part of the requirement.

How do I handle authentication in large Playwright suites?

Reuse authenticated state when tests can safely share an account. For tests that modify server-side state in parallel, use isolated accounts or worker-specific authentication.

How do I prepare for Senior SDET Playwright interviews?

Go beyond individual test scripts. Practice framework design, custom fixtures, authentication architecture, API testing, test-data management, parallelism, CI/CD, observability, debugging, scalability, and Selenium migration.