36 practice questions with answers for Playwright Testing interviews in Lucknow.
Playwright Testing jobs in Lucknow
Lucknow's tech job market is smaller but growing, led by IT-services delivery centres, government-tech projects and start-ups. Many Lucknow candidates target Noida and Gurgaon roles or remote jobs, so interviews follow the NCR pattern.
Below are 36 questions that match the mix of service, product and domain employers hiring Playwright automation engineers in Lucknow.
Solved for LucknowStart 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 attach a screenshot or log to the report from inside a test?
A worker is a separate operating system process that runs test files. Each worker starts its own browser, and tests inside a worker run one after another, while different workers run at the same time. Workers do not share memory, so you cannot pass variables between them. Worker-scoped fixtures are created once per worker, which is why expensive setup is often placed there.
03
CI runners have 2 CPU cores and workers is set to 8. Tests start timing out randomly. Why?
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.
04
How do you block images and fonts to speed up tests?
Situation: a developer said a failing checkout test was flaky and asked to skip it before release. Task: decide based on evidence. Action: I shared the trace showing the total stayed wrong after a coupon was removed and reproduced it manually. Result: we agreed it was a real bug, it was fixed before release, and we started reviewing traces together.
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.
07
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.
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.
10
How do you run the same visual tests at mobile, tablet and desktop sizes?
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.
11
Where does Playwright store baseline screenshots and how are the files named?
By default baselines go into a folder next to the test file named after it, for example checkout.spec.ts-snapshots. The file name combines the name you give, the project name and the platform, such as home-chromium-linux.png. Because the browser and operating system are part of the name, each project keeps its own baseline. You commit these images to the repository so every run compares against the same files.
12
A worker-scoped fixture holds shared data and some tests see stale values. How do you fix it?
Worker fixtures live across many tests, so any test that changes their data affects the next ones. Keep worker fixtures read-only, such as a connection or a reference catalogue. Move anything a test modifies into a test-scoped fixture that creates fresh data. If sharing is needed for speed, reset the relevant state in the test fixture before use.
13
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.
14
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.
15
What is UI mode and how is it different from --debug?
UI mode, opened with npx playwright test --ui, is a dashboard to run, filter and watch tests, with a trace-like timeline for each one and a watch mode that reruns on file changes. --debug opens the Inspector to step through a single run live. Use UI mode for daily development and --debug for stepping through a specific action.
16
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.
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.
19
What are union types and type narrowing in TypeScript?
A union type allows several types, such as string | number or 'admin' | 'user'. Before using type-specific methods, you narrow the type with checks like typeof, instanceof, in or comparing a literal field. TypeScript then knows the exact type inside that branch. In tests, unions model options like a role parameter that accepts only known values.
20
How do you share one authenticated API context across all tests in a worker?
Create a worker-scoped fixture that calls request.newContext with baseURL and an auth header, or logs in through the API and keeps the cookies. Pass it to use, and dispose it after use returns. Every test in that worker gets the same ready context, so login happens once per worker. Do not store per-test data on it, or tests start depending on each other.
21
A test uses forEach with an async callback and the checks inside never seem to run. Why?
forEach does not wait for async callbacks, so it starts each callback and returns at once. The test may finish before the assertions run, or their errors are lost. Use for...of with await to run steps in order, or Promise.all with map when the steps can safely run in parallel. A lint rule can flag this pattern.
22
How do you validate an API response in Playwright?
Situation: on release day the test job failed for every build after a runner image update. Task: unblock the release safely. Action: I compared logs, found missing browser dependencies, pinned the Playwright Docker image version and reran. Result: tests passed within an hour, the release went out on time, and I added an alert for image changes.
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.
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.
28
What is expect(...).toPass and how is it different from expect.poll?
toPass retries a whole block of code, including several actions and assertions, until it runs without throwing. expect.poll retries only one function that returns a value. Use toPass for flows like 'click refresh, then check the status' that must be repeated together. It has no timeout by default, so always pass a timeout to avoid a hung test.
29
Promise.all vs Promise.allSettled vs Promise.race?
all waits for every promise and rejects on the first failure; allSettled waits for all and reports each outcome; race settles with the first one to finish.
30
How do you test file downloads and verify their content?
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.
--repeat-each=N runs every selected test N times in the same run, spread across workers. It is useful for checking a new or fixed test for flakiness before merging, for example npx playwright test checkout.spec.ts --repeat-each=20. Combined with several workers it also surfaces tests that collide with each other over shared data.
Which companies hire Playwright Testing professionals in Lucknow?
Companies with large offices in Lucknow include HCLTech. Use their company pages below to practise employer-specific sets.
Are Playwright Testing interviews in Lucknow different from other cities?
The questions depend more on the company than the city. Lucknow's mix of employers decides the style: Many Lucknow candidates target Noida and Gurgaon roles or remote jobs, so interviews follow the NCR pattern
How do I find Playwright Testing jobs in Lucknow?
Shortlist companies with Lucknow offices, keep your CV focused on Playwright Testing projects, apply on company career pages and job portals with the Lucknow filter, and practise the questions on this page before each interview.