EY Playwright Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About EY hiring for Playwright Testing roles
EY is one of the Big Four professional services networks, offering assurance, tax, strategy and transactions, and consulting services. In India, EY GDS and EY member firms support global clients with technology consulting, data analytics, cybersecurity and risk work. It hires for analyst and consultant roles in data analytics, BI, testing, ERP and risk.
For Playwright Testing roles, this EY practice set focuses most on Playwright Core (7), Framework Design and CI/CD (6), API Testing (6), Visual & Accessibility Testing (5). It has 4 easy, 28 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Consulting
Headquarters
London, United Kingdom
Main India offices
Bengaluru, Kolkata, Gurugram, Hyderabad, Kochi
EY Playwright Testing interview process
Online assessment (aptitude + technical)
Technical interview
Managerial or case round
Partner or HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for EYStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
Write a test that checks keyboard Tab order through a login form.
Mock the endpoint with route.fulfill({ status: 500, json: { message: 'Server error' } }), then open the page. Assert the user sees a friendly error message and a retry button, and that no broken half-rendered table appears. Then make the retry return 200 and check the data loads. This covers a path that is hard to trigger on a real server.
04
How do you check that a product list on the page is sorted by price?
const texts = await page.getByTestId('price').allTextContents();
const prices = texts.map(t => Number(t.replace(/[^0-9.]/g, '')));
const sorted = [...prices].sort((a, b) => a - b);
expect(prices).toEqual(sorted);
// wait for the list first with toHaveCount
A trace contains every action with its timing, DOM snapshots before and after each action, screenshots in a filmstrip, console messages, network requests with headers and bodies, the source line of each step and the error. Because the DOM snapshots are real, you can inspect elements after the run. It is usually the fastest way to understand a CI failure.
06
Write a GitHub Actions job that runs the suite in four shards.
Subscribe to events: page.on('request', r => ...), page.on('response', r => ...) and page.on('requestfailed', r => ...). You can log URLs, collect API calls or count failures. Unlike route, listeners only observe and cannot change traffic. They are handy for checks like 'no request returned a 5xx status during this flow'.
09
The app logs in through a third-party OAuth pop-up. How do you automate it?
For most tests, avoid the pop-up: get a session through a test login API or a test identity provider and save it with storageState. Keep one test for the real flow, using const popup = page.waitForEvent('popup') before clicking, then fill the provider's form inside popup. Third-party pages can change and add captchas, so limit how often you depend on them.
Situation: dozens of tests failed after a field was renamed from user_name to username. Task: fix quickly and prevent repeats. Action: I updated the shared types and helper, so the fix touched two files, and proposed schema checks on key endpoints plus a heads-up in release notes. Result: the next breaking change was caught in the pull request.
14
A product list uses infinite scroll. How do you test that more items load?
Count the items, then scroll the last item into view with lastItem.scrollIntoViewIfNeeded() or page.mouse.wheel. Assert with expect(items).toHaveCount greater than before, for example using expect.poll on items.count(). Repeat until an end-of-list message appears. Also check no duplicates appear and that a loading indicator shows while fetching.
test.slow() triples the timeout for a test that is genuinely long, such as a report export. It is honest and visible in code. But raising timeouts to make a flaky test pass hides the real cause, such as a missing wait or slow backend, and makes failures take longer. Investigate the trace first and change timeouts only with a reason.
18
What is an ARIA snapshot and how does toMatchAriaSnapshot work?
An ARIA snapshot is a YAML description of the accessibility tree for a part of the page: roles, names and states such as checked or level. toMatchAriaSnapshot compares the live tree of a locator against that template, and partial templates or regular expressions can be used for changing text. It tests structure and semantics, so it survives styling changes that would break a pixel screenshot.
19
What is the difference between page.goto and page.waitForURL?
page.goto starts a navigation to a URL and waits for the load state you choose. page.waitForURL does not navigate; it waits until the current page reaches a URL that matches a string, glob or regular expression, which is useful after a click that redirects, such as a login followed by a jump to the dashboard. Pair it with the click instead of adding fixed sleeps.
20
Design a Playwright framework for a 500-test suite.
TypeScript + POM + custom fixtures, environment configs, API helpers for test data, tags like @smoke, sharding across CI machines, retries with traces, HTML/Allure reports, lint and review rules.
Functions that take other functions as arguments or return them, such as map, filter and reduce, or a helper that wraps retry logic around a test step.
22
How can you run only the tests affected by a code change?
Use npx playwright test --only-changed=origin/main. It looks at files changed against that git reference and runs the test files that changed or that import changed files. It suits fast pull request feedback in a large suite. It cannot see backend or config changes that tests do not import, so still run the full suite before release.
23
Describe a time you convinced developers to add accessible labels or test ids.
Situation: many inputs had no labels, so our tests relied on long CSS selectors that broke often. Task: get stable hooks without slowing developers. Action: I listed the worst screens, showed how getByLabel tests read and how the same labels help screen reader users, and offered to raise small pull requests myself. Result: the team added labels to new work as a rule and locator breakages dropped sharply.
24
How do you verify that an API returns consistent data across two versions of an endpoint?
Call both versions, for example /v1/orders/42 and /v2/orders/42, with the same test data. Map the fields that should match, since names may differ, and compare them with toEqual. Also assert that fields removed in v2 are really absent and new ones have correct types. Running this during a migration catches breaking changes before clients switch.
25
How would you design a visual testing strategy for a large web application?
Snapshot stable, high-value screens and shared components, not every page. Render baselines only in a pinned Docker image, mask or mock dynamic data, and disable animations. Keep visual tests in their own project or tag so they can run on pull requests touching UI code. Define owners for baseline reviews and keep thresholds strict in config. Combine with functional assertions, because pictures alone do not tell you why something broke.
26
How do you test the difference between 401 and 403 responses?
401 Unauthorized means the caller is not authenticated, such as a missing or expired token. 403 Forbidden means the caller is known but lacks permission. Test 401 by calling without a token or with an invalid one. Test 403 by calling an admin endpoint with a normal user's token. Assert the status and that no data leaks in the body.
27
How do you attach axe results to the Playwright HTML report?
Set the metadata field in playwright.config, for example metadata: { commit: process.env.GIT_SHA, env: process.env.TEST_ENV }, which reporters can read and recent HTML reports show. Inside tests use testInfo.annotations.push for per-test details like a ticket id. Custom reporters can read config.metadata in onBegin and include it in messages or uploads.
Do not depend on records that happen to exist in a shared environment. Each test or fixture creates what it needs through the API and cleans up after. Read environment-specific values such as base URL and credentials from config. For reference data that must exist, seed it in a setup project and verify it before tests run.
Run npm init playwright@latest -- --ct and choose React. It installs @playwright/experimental-ct-react, creates playwright-ct.config.ts and adds a playwright folder containing index.html and index.tsx. index.html hosts the mounted component and index.tsx is where global styles, themes and providers go. Tests then live in files such as Button.spec.tsx and run with npx playwright test -c playwright-ct.config.ts.
33
Test data is left behind when tests fail midway. How do you guarantee cleanup?
Create the data inside a fixture and delete it after await use(). Fixture teardown runs even when the test fails or times out, so cleanup is reliable. Avoid cleanup steps at the end of the test body, because they never run after a failed assertion. As a safety net, tag test data with a prefix and run a nightly cleanup job.
34
How do you test a page in dark mode or with reduced motion?
Set colorScheme: 'dark' or reducedMotion: 'reduce' in the context options or test.use. You can also switch during a test with page.emulateMedia({ colorScheme: 'dark' }). Then assert the right styles or take a screenshot comparison. Reduced motion also helps stability, because many apps skip animations when that preference is set.
35
How would you structure a large Playwright framework for a team?
Separate tests, page objects, fixtures, utilities, test data and config; use tags, projects, shared auth setup, linting, code review and a CI pipeline with sharding and reports.
36
How do you publish the Playwright HTML report from a CI pipeline?
Keep the html reporter in the config. After the test step, add an upload-artifact step that runs even when tests fail, using a condition like always(), and upload the playwright-report folder with a retention period. Team members download and open it with npx playwright show-report. Some teams also publish it to static hosting for direct links.
37
A test passes locally but fails in CI with a timeout on a click. How do you use the trace?
Open the CI trace and go to the failed click. Check the action log, which shows what Playwright waited for, such as the element not being visible or another element intercepting pointer events. Compare before and after snapshots and the network tab for slow or failed calls. Common causes are a slower environment, a cookie banner or different screen size.
38
A locator matches three Delete buttons and the test fails with a strict mode violation. How do you fix it?
First scope the locator to the item you mean, for example the row that contains the user's name: page.getByRole('row', { name: 'Ravi Kumar' }).getByRole('button', { name: 'Delete' }). Do not reach for first() or nth() as a quick fix, because the order can change and the test may delete the wrong record. Scoping by meaningful context is stable and readable.
39
What are the options for the trace setting in playwright.config?
Values are 'off', 'on', 'retain-on-failure', 'on-first-retry' and 'on-all-retries'. 'on-first-retry' records only when a failed test is retried, which keeps the normal run fast and gives a trace for flaky failures. 'retain-on-failure' records every test but keeps only failed ones. 'on' records everything and is mainly for local investigation.
Scanners like axe find rule-based problems such as missing labels, bad contrast or invalid ARIA, which is roughly a third to a half of real issues. They cannot judge whether alt text is meaningful, whether focus order makes sense, whether error messages are understandable, or whether a screen reader user can actually finish the task. So automated scans are combined with keyboard tests and periodic manual checks with screen readers.
Tips to crack the EY Playwright Testing interview
Practise explaining a data project in business terms, focusing on the problem, approach and recommendation for the client.
Revise Excel, SQL and Power BI, which appear frequently in EY analytics and consulting job descriptions.
Read about EY's service lines and its focus on technology, AI and sustainability consulting for fit questions.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; EY interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the EY Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + technical); Technical interview; Managerial or case round; Partner or HR round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the EY Playwright Testing interview?
This practice set leans on Playwright Core (7), Framework Design and CI/CD (6), API Testing (6), Visual & Accessibility Testing (5). Revise those first, then practise explaining one or two of your own projects end to end, because most EY interviewers ask you to walk through real work.
Are these the exact questions asked at EY?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like EY's. They are not a leaked or verified list of past questions.
Where does EY hire Playwright Testing professionals in India?
EY has large teams in Bengaluru, Kolkata, Gurugram, Hyderabad, Kochi. Openings and locations change often, so check the EY careers page and filter by city and experience.
Playwright Testing questions for similar companies