36 practice questions with answers for Playwright Testing interviews in Delhi.
Playwright Testing jobs in Delhi
Delhi NCR has one of India's biggest pools of IT, consulting, banking and start-up jobs. Delhi itself hosts many corporate, government-tech and consulting offices, and most candidates also apply across Noida and Gurgaon, so interviews here mix service-company and product-company styles.
Below are 36 questions that match the mix of service, product and domain employers hiring Playwright automation engineers in Delhi.
Solved for DelhiStart 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
How do you test geolocation, permissions and time zones?
Each worker has its own copy of module variables, so values set in one worker are invisible to others, and order changes between runs. Tests that pass alone fail in parallel or after a retry. Pass data through fixtures, or store it in an external source like the API. Each test should be able to run alone, in any order.
03
How do you attach axe results to the Playwright HTML report?
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.
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.
Assert immediately after the action that triggers it, using a web-first assertion like toBeVisible and toHaveText, which start checking at once. Do not add sleeps before the check. If the toast is still missed, control time with page.clock so it does not auto-hide, or verify the result through the data it confirms, such as the saved record.
A context created with request.newContext() holds cookies, connections and stored responses in memory. Calling await context.dispose() frees them, and any later call on it fails. Without disposing, long runs can leak memory. The built-in request fixture is disposed automatically, so this matters for contexts you create in fixtures or helpers.
09
Does headless mode behave differently from headed mode?
Modern Chromium headless uses the same browser code as headed, so behaviour is very close. Differences still appear in viewport size, GPU rendering, fonts and some OS dialogs. Tests should set an explicit viewport and not depend on window focus. If something passes headed but fails headless, record a trace and compare screenshots.
10
How do you change a mounted component's props during a test?
Call component.update with new JSX, for example await component.update(<Badge count={5} />). Playwright re-renders the same instance with the new props, so internal state is kept, just like a parent re-rendering it in the app. This lets you test effects that react to prop changes. To test fresh mounting behaviour instead, unmount and mount again.
Run it alone with --project=webkit --headed and record a trace. Compare it with the Chromium trace to see where behaviour differs, such as date input format, scrolling, font rendering or a missing browser API. Check the app's support matrix. If it is a real product bug, raise it, and skip the test for WebKit with a linked ticket until it is fixed.
The HTML reporter creates a playwright-report folder with every test, its steps, errors, attachments, screenshots and trace links. Open it with npx playwright show-report. You can filter by status, project and tags. In CI, upload the folder as an artifact so anyone can download and open it, and the report opens automatically locally when tests fail.
In the Inspector, UI mode and the VS Code extension, Pick locator lets you hover over any element on the page and see the locator Playwright recommends for it, usually a role or label based one. You can copy it into your test. It is a fast way to write locators and to check whether an existing one is unique.
17
How do you exclude a third-party widget or switch off one rule in an axe scan?
// scan the page but skip the chat widget you do not own
const results = await new AxeBuilder({ page })
.include('main')
.exclude('#third-party-chat')
.disableRules(['duplicate-id'])
.analyze();
expect(results.violations).toEqual([]);
// log a ticket for anything you exclude
18
A fixture mocks every /api call, but one test needs a different response for /api/cart. How do you override it?
Register a new page.route for /api/cart inside that test. Handlers run in reverse order of registration, so the newer one runs first. Fulfil the cart request with the special data, and for anything else call route.fallback() so the request moves on to the fixture's general handler. This keeps the shared mock untouched and makes the override local and easy to read.
Worker fixtures and beforeAll run first for the worker. For each test, the test fixtures it needs are set up, then beforeEach hooks run, then the test body. Afterwards afterEach hooks run, then test fixtures are torn down in reverse order. afterAll and worker fixture teardown run when the worker finishes. Fixtures are lazy, so unused ones never run.
It is a lint plugin with rules for common Playwright mistakes, such as missing await on assertions, leftover test.only or page.pause, forced clicks, fixed waits with waitForTimeout and element handles instead of locators. Running it in pull requests stops bad patterns before review. Teams usually enable the recommended rule set and add a few stricter rules over time.
21
Describe a time strict TypeScript types caught a bug in your test code.
Situation: our API helpers returned loosely typed objects and tests often read fields that no longer existed. Task: make helpers safer. Action: I added response interfaces, turned on strict mode and replaced any with unknown plus type guards. Result: the compiler immediately showed eleven tests reading a renamed field, which had been passing because they compared undefined with undefined. We fixed them before the next release.
22
How do you handle a page that opens a browser permission prompt for notifications?
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.
23
Visual tests pass on developers' laptops but fail in CI with tiny font differences. Why, and how do you fix it?
Font rendering, anti-aliasing and installed fonts differ between Windows, macOS and Linux, so the same page produces slightly different pixels. The fix is to generate and compare baselines in one fixed environment, usually the official Playwright Docker image used in CI. Developers update baselines by running that container locally or through a CI job, not from their own machines. Loosening thresholds should be the last resort.
a ?? b returns b only when a is null or undefined. Unlike ||, it keeps valid falsy values such as 0, false and an empty string. In config this matters: process.env.RETRIES ?? '2' keeps a value of 0 if someone sets it, whereas || would wrongly replace it. It is often combined with optional chaining.
25
What is the difference between a type and an enum in TypeScript?
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.
28
What does force: true do on an action, and why should you avoid it?
force: true skips the actionability checks, so Playwright clicks even if the element is hidden, disabled or covered. It can make a test pass while a real user would be blocked. Use it only for special cases like a custom checkbox whose real input is visually hidden by design. Otherwise fix the cause, such as an overlay.
The action runs without waiting, so the next step may run first — causing flaky failures or 'Target closed' errors. The @typescript-eslint/no-floating-promises rule catches it.
30
Why are component tests usually faster than end-to-end tests?
They skip the expensive parts: no full app start, no backend calls, no login and no navigation through several pages. Playwright builds the component bundle once and each test simply mounts into an already loaded page. A typical component test finishes in well under a second, so hundreds can run in a pull request check, while end-to-end flows take several seconds each.
31
How do project dependencies differ from globalSetup?
A setup project is a normal test file that other projects list in dependencies. It shows in the HTML report, can use fixtures, and records traces, so failures are easy to debug. globalSetup is a plain function that runs before everything without fixtures or traces. The docs now recommend project dependencies for login and data seeding.
32
What is the difference between page.route and context.route?
page.route applies only to requests from that page. context.route applies to every page in the browser context, including pop-ups and new tabs opened later. Use context.route when a flow opens new windows, such as a payment pop-up, or when you set up mocks in a fixture before the page exists. Page routes take priority over context routes.
They assert the name and description that assistive technology computes for an element, using the accessibility tree rather than raw attributes. The name may come from a label, aria-label, aria-labelledby or inner text, and the description often from aria-describedby. For example an icon-only close button should have the name Close. These checks catch problems that a plain text assertion would miss.
35
How do access modifiers help in page object classes?
private and protected hide internal locators and helper steps, so tests can only call meaningful public methods such as login or addToCart. This keeps tests readable and lets you change internals without breaking callers. readonly on the page field prevents it from being replaced. TypeScript enforces these at compile time only, not at runtime.
36
When should you choose a component test over an end-to-end test?
Choose a component test when the behaviour lives inside one component: validation messages, disabled states, sorting in a table, keyboard handling in a dropdown or rendering of edge-case data. These are slow and awkward to reach through full flows. Choose end-to-end when the risk is in integration, such as routing, authentication or data saved on the server.
Which companies hire Playwright Testing professionals in Delhi?
Companies with large offices in Delhi include Samsung, Boston Consulting Group. Use their company pages below to practise employer-specific sets.
Are Playwright Testing interviews in Delhi different from other cities?
The questions depend more on the company than the city. Delhi's mix of employers decides the style: Delhi itself hosts many corporate, government-tech and consulting offices, and most candidates also apply across Noida and Gurgaon, so interviews here mix service-company and product-company styles
How do I find Playwright Testing jobs in Delhi?
Shortlist companies with Delhi offices, keep your CV focused on Playwright Testing projects, apply on company career pages and job portals with the Delhi filter, and practise the questions on this page before each interview.