IBM Playwright Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About IBM hiring for Playwright Testing roles
IBM is a global technology company offering hybrid cloud, AI through watsonx, software such as Red Hat, infrastructure and IBM Consulting services. Its India Software Labs and IBM Consulting teams form one of its largest workforces outside the US. It hires in India for software developers, test engineers, data engineers, data scientists and consultants.
For Playwright Testing roles, this IBM practice set focuses most on Fixtures and Hooks (7), Locators and Assertions (5), JavaScript and TypeScript (5), API Testing (4). It has 13 easy, 24 medium, 3 hard questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Armonk, New York, USA
Main India offices
Bengaluru, Pune, Hyderabad, Kolkata, Gurugram
IBM Playwright Testing interview process
Online assessment (cognitive games + coding)
English language test
Technical interview
Managerial or HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for IBMStart 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.
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.
03
How do you run a single test or file in Playwright?
HAR stands for HTTP Archive. It is a JSON file that records the requests and responses a browser made, including URLs, headers, bodies and timings. Browsers can export one from DevTools, and Playwright can record and replay them. In testing it is used for mocking whole sets of API calls and for sharing network evidence in bug reports.
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.
In the Inspector, UI mode and the VS Code extension, Pick locator lets you hover over any element on the page and see the locator Playwright recommends for it, usually a role or label based one. You can copy it into your test. It is a fast way to write locators and to check whether an existing one is unique.
09
What happens the first time toHaveScreenshot runs and no baseline image exists?
Playwright cannot compare anything, so it captures the screenshot, saves it as the new baseline in the snapshots folder and marks the test as failed with a message that the snapshot was missing. On the next run the test compares against that file. This is why you review new baselines before committing them, and why baselines should be generated in the same environment that CI uses.
The blob reporter writes a compact archive of everything about a run, including results, attachments and traces, into the blob-report folder. It is meant for machines rather than people. Each shard produces one blob, and npx playwright merge-reports later combines them into a single HTML, JUnit or JSON report. Without it, every shard would produce its own separate HTML report.
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.
await expect(locator).toHaveText('Paid') is a web-first assertion: it retries until the element matches or the timeout ends. expect(value).toBe('Paid') is a generic assertion that checks a value once, immediately. Use web-first assertions for anything on the page and generic ones for plain data such as an API JSON field you already have.
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.
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.
21
Component and end-to-end tests run together and slow down every commit. How do you separate them?
Give them separate configs, such as playwright-ct.config.ts with its own testDir for component specs and playwright.config.ts for end-to-end tests, because component tests also need the bundler options and framework test import. In CI, run component tests on every commit as a fast job and end-to-end tests later or in parallel. Shared settings like reporters can live in a common module both configs import.
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.
23
Why should you start waitForResponse before the action that triggers it?
If you click first and then wait, the response may already have arrived, so the wait misses it and times out. Create the promise first, then act, then await it: const resp = page.waitForResponse('**/api/cart'); await addButton.click(); await resp. waitForRequest works the same way for outgoing requests.
The first argument can be a glob string, a regular expression or a function that receives a URL object. Globs like '**/api/users*' are simple but * does not cross slashes and ** does. Regex gives precise control over query strings. A predicate function suits complex rules, for example matching host plus a specific search parameter.
25
Describe a time you convinced developers to add accessible labels or test ids.
Situation: many inputs had no labels, so our tests relied on long CSS selectors that broke often. Task: get stable hooks without slowing developers. Action: I listed the worst screens, showed how getByLabel tests read and how the same labels help screen reader users, and offered to raise small pull requests myself. Result: the team added labels to new work as a rule and locator breakages dropped sharply.
26
Show a config with a setup project and a browser project that reuses its login.
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.
beforeAll runs once before the tests in its file or describe block, and afterAll runs once after them. In Playwright they run once per worker, so if tests are spread over workers they can run more than once. They suit cheap shared setup. They cannot use test-scoped fixtures like page, so open your own page from the browser fixture if needed.
a ?? b returns b only when a is null or undefined. Unlike ||, it keeps valid falsy values such as 0, false and an empty string. In config this matters: process.env.RETRIES ?? '2' keeps a value of 0 if someone sets it, whereas || would wrongly replace it. It is often combined with optional chaining.
30
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.
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.
Playwright runs outside the browser and controls it through a persistent connection using each engine's own protocol, such as CDP for Chromium and patched protocols for Firefox and WebKit. It can watch DOM, network and events directly, so it waits on real state instead of polling from inside the page. This gives reliable auto-waiting, multi-tab and network control.
35
How do you pass slots and listen to events in a Vue component test?
With the Vue package you can mount with an options object: mount(Button, { props: { label: 'Save' }, slots: { default: 'Click me' }, on: { click: handler } }). The on map receives emitted events, so you can push payloads into an array and assert on them. JSX syntax is also supported if the project is configured for it.
Each worker is a separate process with its own state. When tests from a file are split across workers, or a worker restarts after a failure, beforeAll runs again in the new worker. So never assume it runs only once globally. For one-time setup across the whole run, use a setup project with dependencies or globalSetup.
38
What is the difference between unknown and any in TypeScript?
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.
test('drag a file onto the upload zone', async ({ page, browserName }) => {
test.skip(browserName === 'webkit', 'Known WebKit drag issue, ticket QA-123');
await page.goto('/upload');
// rest of the test
});
Tips to crack the IBM Playwright Testing interview
Practise IBM's game-based cognitive assessments, which test pattern recognition, memory and numerical reasoning quickly.
Learn basics of hybrid cloud, Red Hat OpenShift and watsonx, which IBM promotes as core strategic areas.
Revise SQL, Python or Java fundamentals and be ready to explain one project in depth.
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; IBM interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the IBM Playwright Testing interview?
Candidates usually go through 4 stages: Online assessment (cognitive games + coding); English language test; Technical interview; Managerial or 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 IBM Playwright Testing interview?
This practice set leans on Fixtures and Hooks (7), Locators and Assertions (5), JavaScript and TypeScript (5), API Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most IBM interviewers ask you to walk through real work.
Are these the exact questions asked at IBM?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like IBM's. They are not a leaked or verified list of past questions.
Where does IBM hire Playwright Testing professionals in India?
IBM has large teams in Bengaluru, Pune, Hyderabad, Kolkata, Gurugram. Openings and locations change often, so check the IBM careers page and filter by city and experience.
Playwright Testing questions for similar companies