Ericsson Playwright Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Ericsson hiring for Playwright Testing roles
Ericsson is a Swedish telecommunications company that provides network equipment, software and services for mobile operators, including 4G and 5G radio, core networks and network management. In India it supports major telecom operators with network deployment and managed services, and runs research and development centres. It hires telecom engineers, software engineers, testers and network engineers.
For Playwright Testing roles, this Ericsson practice set focuses most on Parallel Runs, Sharding & Reporting (8), Visual & Accessibility Testing (5), Debugging and Trace Viewer (5), API Testing (4). It has 17 easy, 20 medium, 3 hard questions, so you can start easy and work up to the harder ones.
Company type
Telecom
Headquarters
Stockholm, Sweden
Main India offices
Gurugram, Bengaluru, Chennai, Noida, Kolkata
Ericsson Playwright Testing interview process
Online assessment (aptitude + technical)
Technical interview
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for EricssonStart 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 share cookies between API login and UI?
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.
It reruns only the tests that failed in the previous run, using the results stored in the test-results folder. It saves time while you fix failures locally because you do not rerun the whole suite. Combine it with --headed or --debug to investigate. Run the full suite again before pushing to confirm nothing else broke.
04
Tell me about a time you explained a failing test report to a non-technical stakeholder.
Situation: a product manager saw a red build and wanted to delay the release. Task: explain what actually failed. Action: I opened the HTML report, grouped failures into one real bug in the coupon flow and two flaky tests, and showed the screenshot of the real bug in plain words. Result: we shipped after the coupon fix, and the manager asked for that short summary on every release.
05
Why should CSS animations be disabled for visual comparisons?
An animation captured at a slightly different frame produces a different image, so the test fails even though nothing is broken. With animations: 'disabled', which is the default for toHaveScreenshot, Playwright fast-forwards finite animations to their end state and resets infinite ones to their start. This gives the same picture every run. Transitions triggered by hover or focus are handled the same way.
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.
07
Write a visual assertion that masks a live clock and an ad banner.
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.
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.
11
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.
12
Write a minimal custom reporter that prints the titles of failed tests at the end.
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.
14
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.
15
How many workers does Playwright use by default, and how do you change it?
By default Playwright uses about half of the logical CPU cores on the machine. You can set workers in playwright.config as a number or a percentage string such as '50%', or override it on the command line with --workers=4. Many teams use process.env.CI ? 2 : undefined so CI runners with few cores are not overloaded while laptops use their full power.
The github reporter prints failures in the format GitHub Actions understands, so each failed test appears as an annotation on the right line of the pull request diff. It is usually combined with the html or blob reporter, for example reporter: process.env.CI ? [['github'], ['html']] : 'list'. It saves reviewers from digging through raw logs.
17
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.
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.
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.
21
How do you create test data through the API before a UI test?
In a fixture or beforeEach, call the API (request.post) to create the user or order, use it in the UI test, then delete it in teardown. It is faster and more reliable than creating data through the UI.
22
How do you test that a modal dialog traps focus and returns it when closed?
Open the dialog with a button and assert the dialog role is visible and focus moved inside it. Press Tab more times than there are controls and check with toBeFocused that focus never leaves the dialog. Press Escape, assert the dialog is hidden, and check that the opening button is focused again. Running the same test with Shift+Tab covers backward navigation as well.
23
What is the Playwright Inspector and how do you open it?
The Inspector is a debug window that lets you step through test actions one by one, see the locator being used and highlight it on the page. Open it with npx playwright test --debug, with PWDEBUG=1, or by calling page.pause(). It runs headed with no timeout, so you can explore the page at each step and edit locators live.
maxFailures stops the run after a set number of test failures, for example maxFailures: process.env.CI ? 10 : undefined. If an environment is down and every test fails, the build stops early instead of burning an hour of CI time. Set it high enough that a few real failures still show their full picture.
The action runs without waiting, so the next step may run first — causing flaky failures or 'Target closed' errors. The @typescript-eslint/no-floating-promises rule catches it.
27
What is the difference between page, context and browser?
It writes an XML file in the JUnit format, with test suites, test cases, durations and failure messages. Most CI servers and test management tools read this format to show test counts, failures and history in their own dashboards. Set outputFile so the path is predictable, and publish that file as a test result in the pipeline.
30
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.
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.
32
Write code to fill a login form using label-based locators.
outputDir, test-results by default, holds per-test artifacts such as screenshots, videos and traces. Playwright creates a separate subfolder for each test and retry, so parallel workers do not overwrite each other's files. testInfo.outputPath gives you a safe path inside it for your own files. It is cleared at the start of every run, so do not store anything permanent there.
36
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.
37
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.
38
Write a fixture that gives each parallel worker its own test account.
Most often an action was not awaited, so the test finished and Playwright closed the page while the action was still running. Other causes are a test timeout closing the page, the code closing the page or context itself, or the browser crashing. Check the stack for the missing await, look at whether a timeout happened first, and turn on the lint rule for floating promises.
Tips to crack the Ericsson Playwright Testing interview
Revise computer networks, TCP/IP, and basics of mobile communication such as LTE and 5G architecture before interviews.
Practise programming in C, C++, Java or Python, and be ready to solve simple coding and debugging problems.
Learn about Ericsson's role in 5G rollouts in India to discuss the industry and your interest in telecom.
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; Ericsson interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Ericsson Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + technical); Technical interview; 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 Ericsson Playwright Testing interview?
This practice set leans on Parallel Runs, Sharding & Reporting (8), Visual & Accessibility Testing (5), Debugging and Trace Viewer (5), API Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Ericsson interviewers ask you to walk through real work.
Are these the exact questions asked at Ericsson?
No. These are curated practice questions that match the skills and difficulty usually tested in telecom interviews like Ericsson's. They are not a leaked or verified list of past questions.
Where does Ericsson hire Playwright Testing professionals in India?
Ericsson has large teams in Gurugram, Bengaluru, Chennai, Noida, Kolkata. Openings and locations change often, so check the Ericsson careers page and filter by city and experience.
Playwright Testing questions for similar companies