Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About BrowserStack hiring for Playwright Testing roles
BrowserStack is a cloud-based software testing platform that lets teams test websites and mobile apps on real browsers and devices. Its products include Live, Automate, App Automate, Percy and Test Observability. It hires for software engineers, SDETs, support engineers and data analysts, many working on test infrastructure at scale.
For Playwright Testing roles, this BrowserStack practice set focuses most on Visual & Accessibility Testing (6), Playwright Core (5), Network Mocking (5), Fixtures and Hooks (4). It has 33 medium, 7 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Mumbai, India
Main India offices
Mumbai, Bengaluru
BrowserStack Playwright Testing interview process
Online coding assessment
Technical round 1 (DSA or coding)
Technical round 2 (design or debugging)
Hiring manager round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for BrowserStackStart 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 wrap a component in a theme or router provider using hooksConfig?
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.
04
How do you attach axe results to the Playwright HTML report?
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.
06
How do you inspect a specific network request in the trace viewer?
Open the Network tab in the trace viewer, which lists every request in the test. Click one to see method, URL, status, request and response headers and bodies, and timing. Selecting an action filters the list to requests around that step. This shows whether a UI failure came from a failed API, a slow response or unexpected data.
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.
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.
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.
12
How do you filter a list of locators by text or by a child element?
Subscribe to events: page.on('request', r => ...), page.on('response', r => ...) and page.on('requestfailed', r => ...). You can log URLs, collect API calls or count failures. Unlike route, listeners only observe and cannot change traffic. They are handy for checks like 'no request returned a 5xx status during this flow'.
14
The app polls a status endpoint every few seconds. How do you test the change from Pending to Done?
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.
15
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.
16
What is a fixture option and how do you define one?
An option is a fixture whose value is configured rather than computed, declared with { option: true } and a default, for example defaultUser: ['standard', { option: true }]. Projects or test.use can override it, so one suite can run as admin in one project and as a viewer in another. Other fixtures can read the option to decide what to set up.
17
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.
18
What happens before and after await use() in a fixture?
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.
19
How do you integrate Playwright with Allure or other reports?
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.
21
How can you run only the tests affected by a code change?
Use npx playwright test --only-changed=origin/main. It looks at files changed against that git reference and runs the test files that changed or that import changed files. It suits fast pull request feedback in a large suite. It cannot see backend or config changes that tests do not import, so still run the full suite before release.
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.
25
How do you exclude a third-party widget or switch off one rule in an axe scan?
// scan the page but skip the chat widget you do not own
const results = await new AxeBuilder({ page })
.include('main')
.exclude('#third-party-chat')
.disableRules(['duplicate-id'])
.analyze();
expect(results.violations).toEqual([]);
// log a ticket for anything you exclude
26
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.
27
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.
28
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.
29
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.
30
A test checks a price that is formatted differently per locale. How do you make the assertion robust?
Fix the locale for the test with the locale and timezoneId options so the format is predictable. Build the expected string with Intl.NumberFormat using the same locale, rather than hard-coding it. If you test several locales, run them as projects or parameterised tests. For business logic, also assert the raw number through the API response.
31
A locator matches three Delete buttons and the test fails with a strict mode violation. How do you fix it?
First scope the locator to the item you mean, for example the row that contains the user's name: page.getByRole('row', { name: 'Ravi Kumar' }).getByRole('button', { name: 'Delete' }). Do not reach for first() or nth() as a quick fix, because the order can change and the test may delete the wrong record. Scoping by meaningful context is stable and readable.
32
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.
Turn on trace: 'on-first-retry', open the trace viewer, check network and timing, replace hard waits with web-first assertions, isolate test data and check for sharding conflicts.
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.
35
How do you test geolocation, permissions and time zones?
It works badly for highly dynamic pages such as live feeds, personalised dashboards or content managed by editors, where most diffs are expected. It is also costly when the design changes every sprint, because baseline reviews eat time. In those cases use functional assertions, ARIA snapshots or component-level screenshots of fixed states instead of full-page pictures.
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.
40
How do you read environment variables safely in a TypeScript test project?
Load a .env file with a package like dotenv in playwright.config, then read process.env.BASE_URL. Values are string | undefined, so validate them early and throw a clear error if a required one is missing. Keep .env out of git and commit an .env.example instead. In CI, set the same names as secret variables.
Tips to crack the BrowserStack Playwright Testing interview
Learn Selenium, Appium and Playwright basics, since BrowserStack products are built around these testing frameworks.
Try a BrowserStack free trial and run an automated test to understand the user experience.
Practise debugging and system design questions related to running many parallel tests on real devices.
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; BrowserStack interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the BrowserStack Playwright Testing interview?
Candidates usually go through 5 stages: Online coding assessment; Technical round 1 (DSA or coding); Technical round 2 (design or debugging); Hiring manager 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 BrowserStack Playwright Testing interview?
This practice set leans on Visual & Accessibility Testing (6), Playwright Core (5), Network Mocking (5), Fixtures and Hooks (4). Revise those first, then practise explaining one or two of your own projects end to end, because most BrowserStack interviewers ask you to walk through real work.
Are these the exact questions asked at BrowserStack?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like BrowserStack's. They are not a leaked or verified list of past questions.
Where does BrowserStack hire Playwright Testing professionals in India?
BrowserStack has large teams in Mumbai, Bengaluru. Openings and locations change often, so check the BrowserStack careers page and filter by city and experience.
Playwright Testing questions for similar companies