Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Quantiphi hiring for Playwright Testing roles
Quantiphi is an AI-first digital engineering company that builds machine learning, data engineering, cloud and applied AI solutions for enterprises. It is known for close partnerships with major cloud providers and works with clients in healthcare, banking, media and retail. In India it hires machine learning engineers, data engineers, cloud engineers and software developers for global projects.
For Playwright Testing roles, this Quantiphi practice set focuses most on Fixtures and Hooks (7), Parallel Runs, Sharding & Reporting (6), API Testing (5), Component Testing (4). It has 6 easy, 27 medium, 7 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
Marlborough, Massachusetts, USA
Main India offices
Mumbai, Bengaluru
Quantiphi Playwright Testing interview process
Online assessment (aptitude + coding + ML basics)
Technical interview 1
Technical interview 2
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for QuantiphiStart 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 write data-driven API tests with many inputs?
An end-to-end test opens the full deployed app, logs in and goes through pages backed by a real server. A component test mounts one component in isolation with props you control, so there is no backend, routing or login. Component tests are faster and pinpoint the failing piece, while end-to-end tests prove the parts work together. A healthy suite has many component tests and fewer end-to-end journeys.
03
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.
04
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.
05
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.
06
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.
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.
Syntax over Promises: an async function returns a Promise and await pauses until it resolves. Every Playwright action returns a Promise, so you await each step.
Replace class-based selectors with role, label and text locators, and agree on data-testid for widgets without good semantics. Move all locators into page objects so future changes touch one file. Add a code review rule and a lint check that flags raw CSS selectors. Share a short locator guide with developers so they know which attributes tests depend on.
12
How do you run one group of tests serially while the rest of the suite runs in parallel?
Put the group in its own project with fullyParallel: false and limit it to one worker, which recent versions allow with a workers setting on the project, or run it in a separate CI step with --project=serial --workers=1. Inside a file, test.describe.configure({ mode: 'serial' }) keeps order. Use project dependencies if the group must run after the parallel tests.
A fixture defined with { auto: true } runs for every test even when the test does not ask for it. It is useful for cross-cutting work such as attaching console logs on failure, setting a feature flag or checking for leftover data. Keep auto fixtures light, because they add cost to every test in the suite.
14
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.
15
How can you apply extra CSS only while a screenshot is taken?
Pass the stylePath option to toHaveScreenshot or set it in the expect.toHaveScreenshot section of the config. The stylesheet is injected just for the capture, so you can hide scrollbars, freeze a carousel, or set visibility hidden on dynamic widgets without changing the app. It is cleaner than adding test-only classes and also works when a mask box would cover too much of the layout.
16
Tell me about a time you refactored duplicated setup into fixtures.
Situation: forty test files each repeated twenty lines of login and data setup. Task: reduce duplication and maintenance. Action: I created fixtures for the logged-in page, a test customer and page objects, migrated files in small reviewed pull requests and wrote a short guide. Result: test files became half the size and setup changes now touch one file.
17
What do maxDiffPixels, maxDiffPixelRatio and threshold control in a screenshot comparison?
threshold sets how different two pixels can be in colour, from 0 to 1, before they count as different; the default is 0.2. maxDiffPixels allows a fixed number of differing pixels, and maxDiffPixelRatio allows a fraction of the total image. Keep them tight so real regressions fail, and set them in the expect section of the config rather than loosening single tests one by one.
18
How do you combine fixtures from several files with mergeTests?
When teams define fixtures in separate modules, such as dbTest and a11yTest, mergeTests(dbTest, a11yTest) returns one test object that has all their fixtures. mergeExpects does the same for custom matchers. This keeps fixture modules small and owned by different people. Watch for name clashes, because two modules defining the same fixture name will conflict.
19
How do you override options like baseURL or viewport for one file?
Call test.use at the top of the file or inside a describe block, for example test.use({ viewport: { width: 375, height: 812 }, locale: 'hi-IN' }). The options apply only to tests in that scope. Options you can set this way include baseURL, storageState, colorScheme and extraHTTPHeaders. Global defaults stay in the use block of playwright.config.
20
How do you rerun only the tests that failed in a sharded CI run?
--last-failed works only on the machine that kept the .last-run.json file, so it does not help across shards. Instead collect the failed tests from the merged JSON report or the blob reports, then run them in a follow-up job by file and line or with --grep on their titles. Many teams simply rely on retries and treat any test needing a rerun as flaky.
21
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.
22
A beforeAll creates one user and tests in the same file fail randomly in parallel mode. Why?
With fullyParallel, the file's tests run in different workers, so each worker creates its own user, or tests in one worker share one user and change its state. Shared mutable data causes random failures. Give each test its own data through a test-scoped fixture, or create a unique user per worker with workerInfo.workerIndex in the name.
and() returns a locator that matches elements satisfying both locators, for example a button that also has a certain title. or() matches either locator, which helps when the UI may show one of two states, such as a New email button or a security dialog. With or(), wrap the assertion carefully, because if both appear the strict check fails.
25
How do you add or change request headers for only some requests?
Register a route for the matching URLs and call route.continue({ headers: { ...route.request().headers(), 'x-test-mode': 'true' } }). Other requests are untouched. For headers on every request, use extraHTTPHeaders in the config instead. This is useful for feature toggles, tenant ids or bypass tokens that only certain endpoints accept.
26
How do contract tests differ from functional API tests?
Functional tests check behaviour: given this input, the API returns the right data and status. Contract tests check that the shape agreed between consumer and provider, such as field names and types, has not changed. Playwright suits functional tests and simple schema checks. Dedicated contract tools help when many services evolve independently and need consumer-driven agreements.
27
How do you use more than one reporter in the same run?
Create two browser contexts in the same test, each with its own storageState file, for example admin.json and user.json made by a setup project. Wrap them in fixtures like adminPage and userPage so tests stay short. The admin approves an order in one context and the customer sees the update in the other, with fully separate cookies.
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.
31
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.
32
How do you mock API calls made by a component in a component test?
Newer Playwright versions provide a router fixture in component tests. You call router.route with a URL pattern and fulfil it with test data, much like page.route, and it can also use mock handlers written for Mock Service Worker. Alternatively, inject a fake data client through props or a provider in hooksConfig. Mocking keeps component tests fast and independent of any backend.
33
How do test.slow() and longer timeouts help or hurt debugging?
test.slow() triples the timeout for a test that is genuinely long, such as a report export. It is honest and visible in code. But raising timeouts to make a flaky test pass hides the real cause, such as a missing wait or slow backend, and makes failures take longer. Investigate the trace first and change timeouts only with a reason.
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.
35
How do you fail a test if the page logs any console error?
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.
var is function-scoped and hoisted. let and const are block-scoped; const can't be reassigned (though an object it points to can change). Prefer const, then let.
Use locator.press('Enter') for a key on a focused element, or page.keyboard.press('Control+A') for page-level shortcuts. Modifiers combine with a plus sign, and ControlOrMeta picks Ctrl on Windows and Linux and Cmd on macOS. keyboard.down and keyboard.up hold keys. Use pressSequentially only when the app needs real keystrokes, such as autocomplete.
page.clock lets tests control time. clock.install() fakes Date and timers, clock.setFixedTime() freezes the current date, and clock.fastForward() or runFor() moves time ahead. This is useful for session timeouts, countdowns, scheduled banners and date-based logic, without waiting real minutes. Install the clock before the page loads so the app uses fake time from the start.
Tips to crack the Quantiphi Playwright Testing interview
Revise machine learning fundamentals such as regression, classification, evaluation metrics and overfitting, with clear intuitive explanations.
Get hands-on with at least one cloud platform and mention any cloud certifications, since much client work runs on cloud services.
Prepare a deep explanation of one ML or data project, including dataset, model choice, results and deployment approach.
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; Quantiphi interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Quantiphi Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + coding + ML basics); Technical interview 1; Technical interview 2; 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 Quantiphi Playwright Testing interview?
This practice set leans on Fixtures and Hooks (7), Parallel Runs, Sharding & Reporting (6), API Testing (5), Component Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Quantiphi interviewers ask you to walk through real work.
Are these the exact questions asked at Quantiphi?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like Quantiphi's. They are not a leaked or verified list of past questions.
Where does Quantiphi hire Playwright Testing professionals in India?
Quantiphi has large teams in Mumbai, Bengaluru. Openings and locations change often, so check the Quantiphi careers page and filter by city and experience.
Playwright Testing questions for similar companies