Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Siemens hiring for Playwright Testing roles
Siemens is a German technology company working in industrial automation, digital industries software, smart infrastructure, mobility and healthcare through Siemens Healthineers. Its India entities include engineering and technology centres in Bengaluru and Pune. It hires for software engineers, test engineers, data analysts and engineers working on industrial software and IoT.
For Playwright Testing roles, this Siemens practice set focuses most on API Testing (8), Playwright Core (6), Framework Design and CI/CD (5), Fixtures and Hooks (4). It has 2 easy, 30 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Hardware & semiconductors
Headquarters
Munich, Germany
Main India offices
Mumbai, Bengaluru, Pune
Siemens Playwright Testing interview process
Online assessment (aptitude + technical)
Technical round 1
Technical round 2
Managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for SiemensStart 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
Test data is left behind when tests fail midway. How do you guarantee cleanup?
Create the data inside a fixture and delete it after await use(). Fixture teardown runs even when the test fails or times out, so cleanup is reliable. Avoid cleanup steps at the end of the test body, because they never run after a failed assertion. As a safety net, tag test data with a prefix and run a nightly cleanup job.
02
What is the difference between API testing and UI testing?
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.
04
How do you upgrade Playwright safely in a large suite?
Read the release notes for breaking changes and deprecations. Upgrade on a branch, update the browsers and the Docker image to the same version, and run the full suite on all projects several times. Compare visual snapshots, which often change after browser updates. Upgrade regularly in small steps rather than skipping many versions.
JavaScript runs one call stack and uses queues for async work; the event loop pushes callbacks from the microtask (promises) and task queues when the stack is empty.
Start the job and assert the 202 status and the returned job id. Then poll the status endpoint with expect.poll, with sensible intervals and a timeout, until it reports completed. Finally fetch the result and validate it. Also test the failure path, for example invalid input leading to a failed status with a clear error message.
08
An endpoint should reject invalid email addresses. Which negative tests would you write?
Cover empty string, missing field, null, wrong type such as a number, no at sign, no domain, spaces, very long strings and a duplicate existing email. For each, assert a 400 or 422 status, a clear error message naming the field, and that nothing was created. Also check that a valid email with uppercase letters is accepted.
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.
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.
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.
testInfo is passed as the second argument to tests and hooks. It gives the test title, project name, retry number, status and output path. You can attach files, add annotations, change the timeout with testInfo.setTimeout, or skip conditionally. For example, attach extra logs only when testInfo.status differs from testInfo.expectedStatus.
Start from the target wall-clock time and the total test time per machine. If one machine with its workers takes 40 minutes and the goal is under 10, you need about four or five shards, plus some margin for setup like installing browsers. Past a point each shard spends more time on setup than on tests, and the app or test data may become the bottleneck, so measure each change.
18
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.
19
How do you attach axe results to the Playwright HTML report?
Use the blob reporter in each shard job, upload each blob-report folder as an artifact, then in a final job download them all into one folder and run npx playwright merge-reports --reporter html ./all-blob-reports. This gives one HTML report for the whole run instead of one per shard, which makes reviewing failures much easier.
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.
22
Which methods does the Playwright Reporter interface provide?
The main ones are onBegin with the config and full suite, onTestBegin and onTestEnd for each test, onStepBegin and onStepEnd for steps, onStdOut and onStdErr for output, onError for errors outside tests and onEnd with the overall result. onEnd can be async, so you can send results to an API before the process exits. You register the reporter by path in the reporter config.
23
How do you debug a test in VS Code with the Playwright extension?
Install the Playwright Test for VS Code extension. Open the Testing panel to see tests, then set a breakpoint in the test file and click Debug Test. Execution stops at the breakpoint with the browser open, so you can inspect variables. Turn on Show browser to watch runs, and use Pick locator or Record at cursor to add steps.
24
What is the difference between page.route and context.route?
page.route applies only to requests from that page. context.route applies to every page in the browser context, including pop-ups and new tabs opened later. Use context.route when a flow opens new windows, such as a payment pop-up, or when you set up mocks in a fixture before the page exists. Page routes take priority over context routes.
25
How do you manage flaky tests without hiding real failures?
Use retries in CI so one-off failures do not block merges, but treat any test marked flaky in the report as a defect. Track flaky tests on a dashboard, quarantine repeat offenders with a tag and an owner, and set a deadline to fix or delete them. Never retry without investigating, or real intermittent bugs will be missed.
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'.
31
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.
Use the official Playwright image which contains browsers and dependencies, mount the project and run npx playwright test for consistent CI environments.
33
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.
34
What does the DEBUG=pw:api environment variable do?
Setting DEBUG=pw:api prints detailed logs of every Playwright API call to the terminal, including waits and retries inside actions. It helps when a test hangs and you need to see exactly which step is waiting and why. Other channels such as pw:browser show browser process output. It is noisy, so use it only while investigating.
35
Tell me about a time an accessibility check caught a real issue before release.
Situation: a new checkout redesign was ready for release. Task: I had just added an axe scan to our Playwright smoke tests. Action: the scan flagged that the payment form inputs had placeholder text but no labels, and a keyboard test showed the pay button was unreachable with Tab. I raised it with screenshots and the rule links. Result: the developer fixed both in a day and the release went out on time.
36
How do you test conditional GET requests that use ETag and If-None-Match?
Call the endpoint once and read the etag header from the response. Call it again with the If-None-Match header set to that value and assert status 304 with an empty body. Then change the resource, repeat the conditional call and assert 200 with a new ETag. This proves caching works and that updates are not hidden behind stale responses.
37
How do you test a component that reads from a global state store?
Wrap the mounted component in the store provider inside beforeMount, and use hooksConfig to choose the initial state for each test, such as a logged-in user or an empty cart. Build the store in the browser side of index.tsx, not in the test file. Then interact with the component and assert on the rendered output rather than reading store internals.
38
How do you assert an element's CSS class, attribute or value?
Auto-waiting, a built-in test runner, Chromium/Firefox/WebKit with one API, network interception, the trace viewer and parallel runs out of the box — usually faster and less flaky.
Tips to crack the Siemens Playwright Testing interview
Learn basics of industrial automation, PLCs and IoT, which connect to many Siemens software and testing roles.
Read about Siemens Xcelerator and digital twin concepts used in its industrial software.
Revise C++, Java or Python and testing fundamentals depending on the team you are applying to.
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; Siemens interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Siemens Playwright Testing interview?
Candidates usually go through 5 stages: Online assessment (aptitude + technical); Technical round 1; Technical round 2; 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 Siemens Playwright Testing interview?
This practice set leans on API Testing (8), Playwright Core (6), Framework Design and CI/CD (5), Fixtures and Hooks (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Siemens interviewers ask you to walk through real work.
Are these the exact questions asked at Siemens?
No. These are curated practice questions that match the skills and difficulty usually tested in hardware & semiconductors interviews like Siemens's. They are not a leaked or verified list of past questions.
Where does Siemens hire Playwright Testing professionals in India?
Siemens has large teams in Mumbai, Bengaluru, Pune. Openings and locations change often, so check the Siemens careers page and filter by city and experience.
Playwright Testing questions for similar companies