Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About ZS Associates hiring for Playwright Testing roles
ZS is a management consulting and technology firm known for its work with pharmaceutical and life sciences companies on sales, marketing and analytics. Its India offices in Pune, Gurugram and Bengaluru handle analytics, data engineering and technology delivery. It hires for business analysts, decision analytics associates, data engineers and data scientists.
For Playwright Testing roles, this ZS Associates practice set focuses most on Playwright Core (6), Framework Design and CI/CD (6), JavaScript and TypeScript (5), API Testing (5). It has 3 easy, 32 medium, 5 hard questions, so you can start easy and work up to the harder ones.
Company type
Consulting
Headquarters
Evanston, Illinois, USA
Main India offices
Pune, Gurugram, Bengaluru
ZS Associates Playwright Testing interview process
Online assessment (aptitude + analytics)
Case interview
Technical interview
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for ZS AssociatesStart 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.
Both describe object shapes. Interfaces can be extended and merged; type aliases can also describe unions and primitives. Use interfaces for page or test-data shapes, types for unions.
02
How do you handle token refresh in long API test runs?
Each worker is a separate process with its own state. When tests from a file are split across workers, or a worker restarts after a failure, beforeAll runs again in the new worker. So never assume it runs only once globally. For one-time setup across the whole run, use a setup project with dependencies or globalSetup.
Situation: a payment test failed randomly and blocked three release builds. Task: unblock releases without hiding a real problem. Action: I quarantined it with a tag and a ticket, kept it running in a separate job, and used traces from twenty runs to find a missing wait on a redirect. Result: it was fixed in two days and releases continued meanwhile.
Browser permission prompts are not part of the page, so you cannot click them. Instead grant the permission up front with the permissions option in the config or context, for example permissions: ['notifications'], or call context.grantPermissions. To test the denied path, create a context without the permission and assert that the app shows its fallback message.
09
A test fails with 'Target page, context or browser has been closed'. What usually causes it?
Most often an action was not awaited, so the test finished and Playwright closed the page while the action was still running. Other causes are a test timeout closing the page, the code closing the page or context itself, or the browser crashing. Check the stack for the missing await, look at whether a timeout happened first, and turn on the lint rule for floating promises.
10
An API returns 200 but the body contains an error field. How should your test catch this?
Never trust status alone. Assert the body structure, for example that error is absent and data has the expected fields, ideally with a schema check. Report the issue, because returning 200 for errors breaks clients and monitoring. Add a helper that validates both status and body shape so every test checks it consistently.
Situation: our team ran tests only on laptops before releases. Task: run them automatically on every pull request. Action: I created a CI workflow with browser install, sharding over four machines, merged HTML reports and traces on retry. Result: feedback came within twelve minutes on each pull request, and release-day surprises dropped sharply.
12
How do you validate an API response in Playwright?
Create one project per size in playwright.config, for example using devices['Pixel 7'], devices['iPad Mini'] and a desktop viewport, and point them at the same visual test files with testMatch or a tag. Because the project name is part of the baseline file name, each size keeps its own images automatically. This keeps the test code identical while covering responsive layouts.
Import devices from @playwright/test and spread a profile into a project or test.use, for example use: { ...devices['Pixel 7'] }. This sets viewport, user agent, device scale factor, touch support and isMobile. It emulates the browser, not a real phone, so it is good for responsive layout tests but not a replacement for real-device testing.
15
An API test fails randomly because another test changes the same record. How do you fix it?
Make each test own its data. Create the record inside the test or a fixture with a unique name, such as one using a timestamp or the worker index, and delete it in teardown. Avoid shared seed records for anything that gets modified. Shared read-only reference data is fine. This also lets tests run fully in parallel.
Give them separate configs, such as playwright-ct.config.ts with its own testDir for component specs and playwright.config.ts for end-to-end tests, because component tests also need the bundler options and framework test import. In CI, run component tests on every commit as a fast job and end-to-end tests later or in parallel. Shared settings like reporters can live in a common module both configs import.
22
Tell me about a time an accessibility check caught a real issue before release.
Situation: a new checkout redesign was ready for release. Task: I had just added an axe scan to our Playwright smoke tests. Action: the scan flagged that the payment form inputs had placeholder text but no labels, and a keyboard test showed the pay button was unreachable with Tab. I raised it with screenshots and the rule links. Result: the developer fixed both in a day and the release went out on time.
Use the blob reporter in each shard job, upload each blob-report folder as an artifact, then in a final job download them all into one folder and run npx playwright merge-reports --reporter html ./all-blob-reports. This gives one HTML report for the whole run instead of one per shard, which makes reviewing failures much easier.
24
Retries make the build green, but nobody notices flaky tests. How do you surface them?
Playwright already marks tests that passed on retry as flaky in the HTML and JSON reports. Read the JSON report in a small script after each run, post flaky test names to the team channel, and fail the build if the flaky count crosses a threshold. Over time you can track trends per test and per area.
Run in parallel with sharding, reuse authentication state, set up data through APIs, avoid unnecessary waits, run smoke on every commit and the full suite nightly.
Eight browsers compete for two cores and limited memory, so pages render slowly, actions hit timeouts and the app under test may also be overloaded. More workers than cores rarely helps. Set workers to match the runner, such as 2, and scale out with shards on more machines instead. Watch CPU and memory metrics in CI to confirm.
Record once with page.routeFromHAR('data/orders.har', { url: '**/api/**', update: true }) while running against a real server. Later runs replay the saved responses from the HAR instead of hitting the backend. You can edit the stored JSON to create edge cases. Re-record when the API changes, otherwise the replay drifts from reality.
31
How do you verify a page's URL and title after navigation?
await page.getByRole('link', { name: 'Orders' }).click();
await expect(page).toHaveURL(/\/orders$/);
await expect(page).toHaveTitle('My Orders | Shop');
// both retry, so no need to wait for navigation manually
32
How many workers does Playwright use by default, and how do you change it?
By default Playwright uses about half of the logical CPU cores on the machine. You can set workers in playwright.config as a number or a percentage string such as '50%', or override it on the command line with --workers=4. Many teams use process.env.CI ? 2 : undefined so CI runners with few cores are not overloaded while laptops use their full power.
33
What is the difference between a type annotation and a type assertion with as?
A type annotation such as const user: User = data asks the compiler to check that the value really fits User. A type assertion such as data as User tells the compiler to trust you, so mismatches are not reported. In test code assertions are risky on API responses, because a wrong field passes compilation and fails later. Prefer annotations, type guards or runtime schema validation.
Use a web-first negative assertion such as await expect(banner).toBeHidden() or not.toBeVisible(); they pass as soon as the element is absent, so they do not wait the full timeout. The real problem is timing: assert after a positive signal, such as the success message appearing, otherwise the banner may simply not have rendered yet and the check passes too early.
36
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.
reportSlowTests makes Playwright list test files that took longer than a threshold at the end of the run. You set max, the number of files to show, and threshold in milliseconds, for example { max: 5, threshold: 60000 }. It is a cheap way to find files worth splitting, because one slow file can hold up a worker or a whole shard.
39
How do you organise tests with page object model in Playwright?
Use page.frameLocator('#frame').getByRole(...) so actions work inside the iframe with auto-waiting.
Tips to crack the ZS Associates Playwright Testing interview
Learn pharma commercial basics like sales force effectiveness, market share and prescriber data for case questions.
Practise case interviews and guesstimates with a clear structure, as consulting rounds are central at ZS.
Revise Excel, SQL and basic statistics, since associate roles involve heavy data analysis.
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; ZS Associates interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the ZS Associates Playwright Testing interview?
Candidates usually go through 5 stages: Online assessment (aptitude + analytics); Case interview; Technical interview; Managerial round; 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 ZS Associates Playwright Testing interview?
This practice set leans on Playwright Core (6), Framework Design and CI/CD (6), JavaScript and TypeScript (5), API Testing (5). Revise those first, then practise explaining one or two of your own projects end to end, because most ZS Associates interviewers ask you to walk through real work.
Are these the exact questions asked at ZS Associates?
No. These are curated practice questions that match the skills and difficulty usually tested in consulting interviews like ZS Associates's. They are not a leaked or verified list of past questions.
Where does ZS Associates hire Playwright Testing professionals in India?
ZS Associates has large teams in Pune, Gurugram, Bengaluru. Openings and locations change often, so check the ZS Associates careers page and filter by city and experience.
Playwright Testing questions for similar companies