Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Infogain hiring for Playwright Testing roles
Infogain is a digital engineering and IT services company serving clients in technology, travel, retail, insurance and healthcare. It offers software engineering, cloud, data and analytics, experience design and customer engagement solutions. It is part of the Apax Funds portfolio and has large delivery centres in India, where it hires developers, testers, data engineers and cloud specialists for global client projects.
For Playwright Testing roles, this Infogain practice set focuses most on Playwright Core (8), Locators and Assertions (6), Framework Design and CI/CD (5), JavaScript and TypeScript (4). It has 20 easy, 20 medium questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
California, USA
Main India offices
Noida, Gurugram, Pune, Bengaluru
Infogain Playwright Testing interview process
Online assessment (aptitude + technical MCQs)
Technical interview
Client or managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for InfogainStart 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
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.
02
What is the difference between the list, line and dot reporters?
All three print to the terminal. list prints one line per test with its status and is the default locally. line shows a single updating line with progress and prints only failures in full, which suits long runs. dot prints one character per test, the most compact output, and is the default on CI. Choose based on how much log noise you want.
Code before await use(value) is setup and runs before the test. use hands the value to the test and waits while the test runs. Code after it is teardown and runs when the test finishes, even if it failed. This keeps setup and cleanup for one resource in one place, which is cleaner than a separate beforeEach and afterEach pair.
toBeAttached only checks that the element exists in the DOM. toBeVisible also needs it to have a non-empty bounding box and no visibility:hidden style. A hidden modal can be attached but not visible. Use toBeVisible for anything a user should see, and toBeAttached for hidden inputs or elements whose presence matters more than appearance.
Main options are testDir for where tests live, timeout, retries, workers, fullyParallel, reporter, and the use block for shared settings like baseURL, trace, screenshot and video. projects define browsers or setups, and webServer can start the app before tests. Most values can depend on process.env.CI so local and CI runs behave differently.
page.pause() stops the test at that line and opens the Inspector, as long as the test is running headed. You can then inspect the page, try locators and resume or step forward. It is useful for checking the state just before a failing step. Remove it before committing, because it would hang a headless CI run.
10
How do you add build details such as the commit and environment to the test 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.
11
How do you send query parameters in an API request?
waitUntil decides when goto considers navigation finished: 'load' waits for the load event and is the default, 'domcontentloaded' waits only for the HTML to parse, 'networkidle' waits for no network for 500 ms, and 'commit' returns when the response starts. Avoid networkidle, which is discouraged and flaky; use assertions on the content you need instead.
Mocking makes tests fast, stable and independent of backend data or third-party outages. It also lets you test states that are hard to create for real, such as empty lists, errors or huge responses. The trade-off is lower confidence that frontend and backend work together, so keep some unmocked end-to-end tests for critical journeys.
14
Your test clicks a button before the page's JavaScript has attached its handler, so nothing happens. What do you do?
This is a hydration problem: the button is visible and enabled but not yet interactive. Wait for a signal that the app is ready, such as a loaded data request or a visible element that only appears after hydration, then click. A better fix is to report it to developers, because real users hit the same issue. Avoid fixed waitForTimeout calls.
Before acting, Playwright waits for the element to be attached, visible, stable, enabled and able to receive events — so manual waits are rarely needed.
17
What does the open option of the HTML reporter control?
open decides whether the report opens in a browser after the run: 'always', 'never' or 'on-failure', which is the default. In CI you set it to 'never' so the process does not try to start a browser or hang waiting. Locally on-failure is convenient. You can also set the PLAYWRIGHT_HTML_OPEN environment variable instead of editing config.
Situation: a search test failed about once in ten runs. Task: find the cause. Action: I ran it with --repeat-each and traces, and saw two search requests return out of order, so the older result replaced the newer one. Result: I proved it was a real race condition in the app, developers fixed it with request cancellation, and the test became stable.
20
How do you run tests on three browsers in parallel?
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.
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.
24
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.
25
Why should the Playwright Docker image version match your package version?
Each Playwright version expects specific browser builds. The official Playwright Docker image tagged v1.x.y-noble contains the browsers for that exact version. If package.json has a different version, tests fail because browsers are missing or mismatched. Pin both together and update them in the same pull request.
26
A toast message disappears after two seconds and the assertion on it is flaky. How do you test it reliably?
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.
27
Describe a time an API changed without notice and broke your tests.
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.
28
How do you structure environment-specific configs in Playwright?
Situation: a booking page had a custom calendar, drag-to-select seats and a timer. Task: automate the full booking. Action: I used role locators for the calendar, mouse actions for seat selection and page.clock to control the timer, keeping each part in a page object method. Result: the flow ran reliably in CI and replaced a 20-minute manual check.
30
What is the difference between toHaveText and toContainText?
toHaveText checks that the element's full text matches the expected string or regex, after normalising whitespace. toContainText passes if the expected text appears anywhere inside it. Use toHaveText for exact labels like a heading, and toContainText for longer messages where only part matters. Both are web-first assertions, so they retry until the timeout before failing.
31
How do you handle token refresh in long API test runs?
getByText matches visible text anywhere on the page, so it suits paragraphs, links and messages. getByLabel finds a form control through its associated label element, aria-label or aria-labelledby, so it is the right choice for inputs such as Email or Password. Using getByLabel for inputs also checks that labels are wired correctly, which getByText cannot do.
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.
36
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.
npx playwright codegen records user actions and generates test code with suggested locators, handy for starting tests.
Tips to crack the Infogain Playwright Testing interview
Revise one programming language, SQL and REST API basics, and be ready to solve a simple coding problem live.
Prepare examples of working in a team, handling deadlines and communicating clearly, since many projects involve direct client interaction.
Read about Infogain's focus on digital engineering and the industries it serves to answer why you want to join.
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; Infogain interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Infogain Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + technical MCQs); Technical interview; Client or 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 Infogain Playwright Testing interview?
This practice set leans on Playwright Core (8), Locators and Assertions (6), Framework Design and CI/CD (5), JavaScript and TypeScript (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Infogain interviewers ask you to walk through real work.
Are these the exact questions asked at Infogain?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like Infogain's. They are not a leaked or verified list of past questions.
Where does Infogain hire Playwright Testing professionals in India?
Infogain has large teams in Noida, Gurugram, Pune, Bengaluru. Openings and locations change often, so check the Infogain careers page and filter by city and experience.
Playwright Testing questions for similar companies