Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Zoho hiring for Playwright Testing roles
Zoho is an Indian software company offering a suite of business applications including Zoho CRM, Zoho Books, Zoho Mail and Zoho Creator. It is privately held and builds most of its technology in-house. It hires for software developers, QA engineers and technical support roles, with a selection process known for programming-heavy rounds.
For Playwright Testing roles, this Zoho practice set focuses most on Playwright Core (6), Debugging and Trace Viewer (5), Locators and Assertions (5), Network Mocking (5). It has 1 easy, 30 medium, 9 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Chennai, India
Main India offices
Chennai, Tenkasi
Zoho Playwright Testing interview process
Written test (aptitude + C programming output)
Basic programming round
Advanced programming round
Technical interview
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for ZohoStart 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.
Mocking makes tests fast, stable and independent of backend data or third-party outages. It also lets you test states that are hard to create for real, such as empty lists, errors or huge responses. The trade-off is lower confidence that frontend and backend work together, so keep some unmocked end-to-end tests for critical journeys.
It is a lint plugin with rules for common Playwright mistakes, such as missing await on assertions, leftover test.only or page.pause, forced clicks, fixed waits with waitForTimeout and element handles instead of locators. Running it in pull requests stops bad patterns before review. Teams usually enable the recommended rule set and add a few stricter rules over time.
05
How do you locate elements inside a specific row or card?
Chain locators: find the container first, then search inside it. Example: page.getByRole('row', { name: 'INV-104' }).getByRole('button', { name: 'Download' }). Each step narrows the search area, so short names like Edit or Download stay unique. Chaining also documents intent clearly and avoids long CSS paths that break when markup changes.
06
How do you simulate a slow API to test a loading spinner?
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.
readonly and as const stop test data from being changed by accident, for example one test editing a shared user object and breaking the next. as const also keeps literal types, so ['admin', 'viewer'] as const gives the type 'admin' | 'viewer'. That lets TypeScript reject invalid roles at compile time instead of during a run.
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.
all waits for every promise and rejects on the first failure; allSettled waits for all and reports each outcome; race settles with the first one to finish.
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.
18
A worker-scoped fixture holds shared data and some tests see stale values. How do you fix it?
Worker fixtures live across many tests, so any test that changes their data affects the next ones. Keep worker fixtures read-only, such as a connection or a reference catalogue. Move anything a test modifies into a test-scoped fixture that creates fresh data. If sharing is needed for speed, reset the relevant state in the test fixture before use.
19
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.
20
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.
21
A designer changes the primary button colour and 300 visual tests fail at once. How do you handle it?
First confirm the change is intended and check a sample of diffs to make sure nothing else moved. Then regenerate baselines in the CI Docker environment in a separate commit, so reviewers can see only image changes. Longer term, reduce the count: most of those tests should not snapshot full pages. Keep a few page-level shots and move detail checks to component-level screenshots of key states.
22
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.
23
Tests pass with one worker but fail with eight. How do you debug this?
This usually means tests share something: the same user account, the same records or a global server setting. Run the failing file with --workers=8 and --repeat-each to reproduce it. Look at which tests run at the same time in the report. Fix it by giving each test unique data, using workerIndex in names, or isolating shared settings per worker.
24
Show a config with a setup project and a browser project that reuses its login.
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.
26
Component tests fail because imports like @/utils cannot be resolved, though the app builds fine. How do you fix it?
The app uses a bundler alias that the component test bundle does not know. Add the same alias in ctViteConfig under resolve.alias, or reuse the project's Vite config by importing it. Also make sure tsconfig paths match, so editors and type checks agree. After that, clear the cache folder that the component bundler writes under playwright/.cache so the bundle rebuilds.
27
Describe how you handled a flaky test that was blocking releases.
Situation: a payment test failed randomly and blocked three release builds. Task: unblock releases without hiding a real problem. Action: I quarantined it with a tag and a ticket, kept it running in a separate job, and used traces from twenty runs to find a missing wait on a redirect. Result: it was fixed in two days and releases continued meanwhile.
Call context.setOffline(true) to cut all network access for the context, then check that the app shows an offline banner or queues actions. Switch back with setOffline(false) and verify it syncs. You can also set offline: true in the context options. For a single failing endpoint, use route.abort instead of going fully offline.
29
How do you capture browser console messages and page errors?
Listen with page.on('console', msg => ...) for console.log, warnings and errors, and page.on('pageerror', err => ...) for uncaught exceptions. Collect them in an array and attach them to the report on failure. Traces also show console output. Uncaught page errors often explain why a button did nothing or a page stayed blank.
30
Visual tests pass on developers' laptops but fail in CI with tiny font differences. Why, and how do you fix it?
Font rendering, anti-aliasing and installed fonts differ between Windows, macOS and Linux, so the same page produces slightly different pixels. The fix is to generate and compare baselines in one fixed environment, usually the official Playwright Docker image used in CI. Developers update baselines by running that container locally or through a CI job, not from their own machines. Loosening thresholds should be the last resort.
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.
33
How do you write a custom matcher with expect.extend?
expect.extend takes an object of matcher functions. Each receives the received value and arguments, and returns { pass, message, name, expected, actual }. For example a toHaveAmount matcher can read a locator's text, strip the currency symbol and compare numbers, retrying with expect.poll inside. Export the extended expect from a shared fixtures file so all tests use the same version.
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.
36
How do you assert an element's CSS class, attribute or value?
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.
38
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.
39
How do you test a page in dark mode or with reduced motion?
Set colorScheme: 'dark' or reducedMotion: 'reduce' in the context options or test.use. You can also switch during a test with page.emulateMedia({ colorScheme: 'dark' }). Then assert the right styles or take a screenshot comparison. Reduced motion also helps stability, because many apps skip animations when that preference is set.
40
How do you test geolocation, permissions and time zones?
Set them in the context options (geolocation, permissions, timezoneId, locale) to simulate users from other regions.
Tips to crack the Zoho Playwright Testing interview
Practise C programming output and pointer questions, which commonly appear in Zoho's written test.
Prepare for advanced programming rounds where you build a small application, such as a booking system, without external libraries.
Learn about Zoho's privacy-focused, in-house product approach and its rural offices in places like Tenkasi.
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; Zoho interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Zoho Playwright Testing interview?
Candidates usually go through 5 stages: Written test (aptitude + C programming output); Basic programming round; Advanced programming round; Technical interview; 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 Zoho Playwright Testing interview?
This practice set leans on Playwright Core (6), Debugging and Trace Viewer (5), Locators and Assertions (5), Network Mocking (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Zoho interviewers ask you to walk through real work.
Are these the exact questions asked at Zoho?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like Zoho's. They are not a leaked or verified list of past questions.
Where does Zoho hire Playwright Testing professionals in India?
Zoho has large teams in Chennai, Tenkasi. Openings and locations change often, so check the Zoho careers page and filter by city and experience.
Playwright Testing questions for similar companies