Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Delhivery hiring for Playwright Testing roles
Delhivery is an Indian logistics and supply chain company that provides parcel delivery, freight, warehousing and fulfilment services for e-commerce and enterprise clients. It runs a large network of hubs and uses technology for route planning, tracking and automation. It hires software engineers, data scientists, data analysts and operations professionals.
For Playwright Testing roles, this Delhivery practice set focuses most on API Testing (8), Network Mocking (7), Playwright Core (7), Component Testing (4). It has 1 easy, 31 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
E-commerce & consumer tech
Headquarters
Gurugram, India
Main India offices
Gurugram, Bengaluru
Delhivery Playwright Testing interview process
Online coding or analytics assessment
Technical round 1
Technical round 2 (design or case)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for DelhiveryStart 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.
Check that the route is registered before the request is sent, usually before goto. Compare the pattern with the real URL in the trace network tab, including query strings and host. Make sure a service worker is not handling the request, and set serviceWorkers: 'block' if it is. Also check that another handler is not matching first or the route was not removed.
02
How do you locate elements inside a specific row or card?
Chain locators: find the container first, then search inside it. Example: page.getByRole('row', { name: 'INV-104' }).getByRole('button', { name: 'Download' }). Each step narrows the search area, so short names like Edit or Download stay unique. Chaining also documents intent clearly and avoids long CSS paths that break when markup changes.
03
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.
04
What does the JSON reporter output and how would you use it?
The JSON reporter writes the full suite tree with every test, its status, retries, duration, errors and attachment paths into one file. Teams parse it in scripts to post a summary to chat, to collect flaky tests that passed on retry, or to push results to a database for trends. Set outputFile so the JSON does not mix with console output.
05
Write an accessibility scan that checks only WCAG 2.1 A and AA rules.
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.
07
A component under test needs a complex class instance as a prop and the test fails to serialise it. What do you do?
Create a small test story component in a separate file that builds the class instance inside the browser and renders the real component with it. The test then mounts the story with simple props, such as an id or a scenario name. This keeps the data creation on the browser side of the boundary and also documents test scenarios as reusable stories.
Set httpCredentials with a username and password in the use block of the config, or pass it to browser.newContext. Playwright then answers the browser's authentication challenge automatically, so no pop-up appears. Read the values from environment variables rather than hard-coding them. You can also limit the credentials to a specific origin with the origin field.
10
An endpoint should reject invalid email addresses. Which negative tests would you write?
Cover empty string, missing field, null, wrong type such as a number, no at sign, no domain, spaces, very long strings and a duplicate existing email. For each, assert a 400 or 422 status, a clear error message naming the field, and that nothing was created. Also check that a valid email with uppercase letters is accepted.
11
A test must confirm that an error banner does not appear, but it always waits the full timeout. How do you fix it?
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.
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.
13
How do you assert that a request was sent with the correct payload?
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.
If the API supports an idempotency key header, send the same POST twice with the same key and assert one order exists and both responses return the same id. Send it with different keys and expect two orders. Also try concurrent requests with Promise.all to check race conditions. Without a key, document the risk to the team.
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.
20
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.
21
How do you filter a list of locators by text or by a child element?
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.
23
Mocked responses drift from the real API and tests pass while production breaks. How do you prevent this?
Generate mock data from the API schema or real recorded responses instead of hand-writing it. Validate mocks against the OpenAPI schema in a unit test. Add contract tests on the backend side and re-record HAR files on a schedule. Keep a few unmocked end-to-end tests that run after each deploy. Treat mock files as code with owners and reviews.
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.
25
Component and end-to-end tests run together and slow down every commit. How do you separate them?
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.
26
Component tests fail because imports like @/utils cannot be resolved, though the app builds fine. How do you fix it?
The app uses a bundler alias that the component test bundle does not know. Add the same alias in ctViteConfig under resolve.alias, or reuse the project's Vite config by importing it. Also make sure tsconfig paths match, so editors and type checks agree. After that, clear the cache folder that the component bundler writes under playwright/.cache so the bundle rebuilds.
27
What are fixtures and how do you create a custom one?
Mock the endpoint with a counter: return Pending for the first two calls and Done after that. Then assert the UI shows Pending and later Done using web-first assertions with a suitable timeout. You can also use page.clock to speed up the polling interval instead of waiting real seconds. This makes a slow real-world process quick and deterministic.
29
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.
30
How do you set baseURL and common headers for API tests?
Put them in the use block of playwright.config: use: { baseURL: process.env.API_URL, extraHTTPHeaders: { Accept: 'application/json', Authorization: `Bearer ${process.env.TOKEN}` } }. The request fixture then sends them on every call, and tests use short paths like /api/users. Keep tokens in environment variables, never in the repository.
Use page.routeWebSocket with a URL pattern. The handler gets a WebSocketRoute: you can reply to messages with ws.onMessage and ws.send without any server, or call connectToServer() to sit in the middle and change messages in both directions. This lets you test live dashboards and chat apps, for example pushing a fake price update.
32
A feature is controlled by a flag served from a config API. How do you test both states?
Mock the config endpoint in a fixture option so each test chooses the flag value, for example featureFlags: { newCheckout: true }. Run the flow with the flag on and off and assert the different UI. Mocking avoids changing shared environment settings that would affect other testers. Also keep one test against the real config to catch wiring mistakes.
33
Write a GitHub Actions job that runs the suite in four shards.
The call log will say another element intercepts pointer events. Find what the overlay is, such as a loading mask, cookie banner or chat widget. Wait for it to disappear with expect(overlay).toBeHidden(), or close it in a fixture. Do not use force: true, because it hides a real issue: a user would also be blocked by that overlay.
37
How do you keep test code, page objects and utilities organised as a repository grows?
Use a clear layout: tests grouped by feature, a pages folder for page objects, a fixtures folder that exposes them, and api and data folders for helpers and builders. Add path aliases in tsconfig, a lint config with the Playwright plugin, and a short contributing guide. Review new helpers in pull requests so duplicate utilities do not spread.
Use response.headers() for an object of lower-cased header names, or headersArray() for duplicates. Assert content-type contains application/json, cache-control matches the policy, and security headers such as strict-transport-security are present. Also check that sensitive headers like server version are not exposed. Header checks catch configuration bugs that body checks miss.
Tips to crack the Delhivery Playwright Testing interview
Learn logistics basics such as first mile, last mile, hub operations and shipment tracking to discuss the domain.
Practise optimisation-style problems and graph algorithms, which connect well to routing and network planning work.
For analyst roles, revise SQL and Excel, and prepare to analyse delivery delays or cost per shipment in a case.
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; Delhivery interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Delhivery Playwright Testing interview?
Candidates usually go through 4 stages: Online coding or analytics assessment; Technical round 1; Technical round 2 (design or case); Hiring manager 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 Delhivery Playwright Testing interview?
This practice set leans on API Testing (8), Network Mocking (7), Playwright Core (7), Component Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Delhivery interviewers ask you to walk through real work.
Are these the exact questions asked at Delhivery?
No. These are curated practice questions that match the skills and difficulty usually tested in e-commerce & consumer tech interviews like Delhivery's. They are not a leaked or verified list of past questions.
Where does Delhivery hire Playwright Testing professionals in India?
Delhivery has large teams in Gurugram, Bengaluru. Openings and locations change often, so check the Delhivery careers page and filter by city and experience.
Playwright Testing questions for similar companies