Mu Sigma Playwright Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Mu Sigma hiring for Playwright Testing roles
Mu Sigma is a decision science and analytics company with its main delivery centre in Bengaluru. It works with large enterprises on analytics problems in areas like marketing, supply chain and risk. It typically hires freshers as trainee decision scientists, with a selection process known for aptitude, puzzles and group discussions.
For Playwright Testing roles, this Mu Sigma practice set focuses most on Framework Design and CI/CD (5), Locators and Assertions (5), Playwright Core (4), Parallel Runs, Sharding & Reporting (4). It has 7 easy, 24 medium, 9 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
Northbrook, Illinois, USA
Main India offices
Bengaluru
Mu Sigma Playwright Testing interview process
Online assessment (aptitude + reasoning)
Video or written communication test
Group discussion
Technical and HR interview
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Mu SigmaStart 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 does Playwright compare with Selenium and Cypress?
Playwright supports multiple browsers, tabs, languages and has auto-waiting and tracing; Selenium has the widest ecosystem; Cypress runs in-browser with a great UI but has more limits across tabs.
Generate unique data per test, for example by adding testInfo.testId, the parallel index or a random suffix to the email, or by using a data builder that creates a fresh user through the API. Avoid hard-coded shared records in test files. Clean up created users in a fixture teardown so the database does not fill up over time.
05
Describe how you convinced a team to adopt accessibility testing.
Situation: the team saw accessibility as a later task. Task: I wanted checks in the pipeline. Action: I ran axe on our top five journeys and showed the results with one short screen reader demo, then proposed a non-blocking report first and blocking only for new violations. Result: within a quarter the main flows reached zero serious issues and the check became a required gate.
Component testing mounts a single UI component, such as a React or Vue button or form, in a real browser page and tests it with the normal Playwright API. Playwright bundles the component with Vite, serves it on a small page and gives you a mount fixture. You get real browser rendering and events, which unit tests in jsdom cannot give, while staying much faster than full end-to-end flows. The feature is still marked experimental.
07
How do you publish the Playwright HTML report from a CI pipeline?
Keep the html reporter in the config. After the test step, add an upload-artifact step that runs even when tests fail, using a condition like always(), and upload the playwright-report folder with a retention period. Team members download and open it with npx playwright show-report. Some teams also publish it to static hosting for direct links.
08
How does this behave in arrow functions compared with regular functions?
A regular function gets this from how it is called, so passing a class method as a callback can lose this. An arrow function has no own this and uses the value from the surrounding code. In page objects, arrow functions in callbacks such as map keep access to this.page, which avoids undefined errors.
09
What does getByRole do and why is it the first-choice locator?
getByRole finds elements by their ARIA role and accessible name, the same way screen readers and users see the page. For example getByRole('button', { name: 'Save' }) keeps working when CSS classes or DOM structure change. It also pushes the team towards accessible markup. The trade-off is that badly built components without proper roles may need a test id instead.
10
A component test passes alone but fails when the full component suite runs. What do you check?
Look for state that leaks between mounts: global stores or singletons created at module level in index.tsx, timers or listeners not cleaned up on unmount, and shared mock data mutated by one test. Make the providers create fresh state in beforeMount each time and reset mocks per test. Running with --repeat-each and a single worker often reproduces the leak quickly.
11
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.
12
What is the difference between TypeScript and JavaScript?
TypeScript adds static types on top of JavaScript and compiles to it. Types catch errors early and give better autocomplete, which helps in larger test suites.
13
How do you verify a page's URL and title after navigation?
await page.getByRole('link', { name: 'Orders' }).click();
await expect(page).toHaveURL(/\/orders$/);
await expect(page).toHaveTitle('My Orders | Shop');
// both retry, so no need to wait for navigation manually
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.
17
How do you test file downloads and verify their content?
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.
20
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.
21
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.
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.
test.describe groups related tests under one title, which shows up in reports. Hooks and test.use inside the group apply only to those tests. You can nest groups, for example Checkout then Guest user. Groups are only for organisation, they do not make tests share a page or state, so each test still gets fresh fixtures.
25
CI fails with an error saying the browser executable does not exist. How do you fix it?
The browsers are not installed on the CI machine. Add a step that runs npx playwright install --with-deps after npm ci, which downloads the browsers and the OS libraries they need. Or run inside the official Playwright Docker image that matches your Playwright version. Cache browsers to speed this step up.
26
How do you filter a list of locators by text or by a child element?
any switches off type checking, so any property access compiles even if it crashes at runtime. unknown accepts any value but forces you to narrow or validate it before use. For API JSON in tests, typing it as unknown and then validating or asserting a type is safer than any, because mistakes appear at compile time.
28
How do you use more than one reporter in the same run?
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.
30
Write a minimal custom reporter that prints the titles of failed tests at the end.
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.
32
Describe a time you had to decide which testing level a feature belonged to.
Situation: a pricing table had many discount rules shown in the UI. Task: decide how to test them. Action: I proposed unit tests for the calculation, component tests for how each rule rendered, and one end-to-end test for buying a discounted plan. I explained the runtime and maintenance cost of each. Result: the team agreed, we covered 30 rules in under a minute, and the approach became our default.
33
How do you run tests on three browsers in parallel?
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.
35
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.
36
How do you test that duplicate POST requests do not create duplicate orders?
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.
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.
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.
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.
Tips to crack the Mu Sigma Playwright Testing interview
Practise puzzles, logical reasoning and quantitative aptitude, which feature prominently in Mu Sigma assessments.
Prepare for group discussions by practising structured arguments on business and analytics topics.
Learn basic analytics concepts and show curiosity about solving ambiguous problems, which Mu Sigma emphasises.
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; Mu Sigma interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Mu Sigma Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + reasoning); Video or written communication test; Group discussion; Technical and HR interview. 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 Mu Sigma Playwright Testing interview?
This practice set leans on Framework Design and CI/CD (5), Locators and Assertions (5), Playwright Core (4), Parallel Runs, Sharding & Reporting (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Mu Sigma interviewers ask you to walk through real work.
Are these the exact questions asked at Mu Sigma?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like Mu Sigma's. They are not a leaked or verified list of past questions.
Where does Mu Sigma hire Playwright Testing professionals in India?
Mu Sigma has large teams in Bengaluru. Openings and locations change often, so check the Mu Sigma careers page and filter by city and experience.
Playwright Testing questions for similar companies