Skip to content

Texas Instruments Playwright Testing Interview Questions & Answers

Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.

About Texas Instruments hiring for Playwright Testing roles

Texas Instruments is an American semiconductor company that designs and manufactures analog chips and embedded processors used in industrial, automotive, personal electronics and communications products. Its Bengaluru centre, set up in 1985, was one of the first multinational R&D centres in India. It hires analog, digital, verification, embedded software and applications engineers.

For Playwright Testing roles, this Texas Instruments practice set focuses most on Fixtures and Hooks (7), API Testing (6), Playwright Core (5), Network Mocking (5). It has 1 easy, 35 medium, 4 hard questions, so you can start easy and work up to the harder ones.

Company type
Hardware & semiconductors
Headquarters
Dallas, USA
Main India offices
Bengaluru

Texas Instruments Playwright Testing interview process

  1. Online assessment (aptitude + electronics)
  2. Technical interview 1
  3. Technical interview 2
  4. HR round

Typical pattern based on public candidate experiences. Rounds vary by role, team and year.

Solved for Texas InstrumentsStart 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 does visual testing work in Playwright?

Save to ▾
Show answer
await expect(page).toHaveScreenshot('home.png') compares against a baseline image; tune maxDiffPixels and mask dynamic areas like dates.
02

How do you write data-driven API tests with many inputs?

Save to ▾
Show answer
const cases = [ { email: '', status: 400 }, { email: 'bad', status: 400 }, { email: 'ok@test.in', status: 201 }, ]; for (const c of cases) { test(`signup with '${c.email}'`, async ({ request }) => { const res = await request.post('/api/signup', { data: { email: c.email } }); expect(res.status()).toBe(c.status); }); }
03

How do you mock an API response?

Save to ▾
Show answer
await page.route('**/api/users', route => route.fulfill({ status: 200, json: [{ id: 1, name: 'Test' }] }) );
04

interface vs type in TypeScript?

Save to ▾
Show answer
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.
05

What are soft assertions?

Save to ▾
Show answer
await expect.soft(locator).toHaveText('...') records the failure but lets the test continue, so you see every mismatch in one run.
06

What does the failOnStatusCode option do?

Save to ▾
Show answer
By default Playwright API calls do not throw on error statuses, you check them yourself. Setting failOnStatusCode: true on a request or context makes it throw for any status other than 2xx or 3xx. It is useful in setup helpers, where any failure should stop the test immediately with a clear message, instead of continuing with bad data.
07

Where should Playwright tests run in a delivery pipeline?

Save to ▾
Show answer
Run a fast smoke set on every pull request against a preview or test environment, so feedback arrives in minutes. Run the full regression suite on merge to main or nightly, sharded across machines. After a deploy, run a few read-only production smoke checks. Match the suite size to the stage so pipelines stay fast but coverage is complete.
08

What are the options for the trace setting in playwright.config?

Save to ▾
Show answer
Values are 'off', 'on', 'retain-on-failure', 'on-first-retry' and 'on-all-retries'. 'on-first-retry' records only when a failed test is retried, which keeps the normal run fast and gives a trace for flaky failures. 'retain-on-failure' records every test but keeps only failed ones. 'on' records everything and is mainly for local investigation.
09

Write a test that updates a user with PUT and verifies the change.

Save to ▾
Show answer
test('update user', async ({ request }) => { const res = await request.put('/api/users/12', { data: { name: 'Neha', city: 'Jaipur' }, }); expect(res.status()).toBe(200); const get = await request.get('/api/users/12'); expect(await get.json()).toMatchObject({ name: 'Neha', city: 'Jaipur' }); });
10

How do you mock one GraphQL query when all calls go to /graphql?

Save to ▾
Show answer
await page.route('**/graphql', async route => { const body = route.request().postDataJSON(); if (body.operationName === 'GetCart') { return route.fulfill({ json: { data: { cart: { items: [] } } } }); } return route.fallback(); });
11

What are Partial, Pick, Omit and Record used for?

Save to ▾
Show answer
They are built-in utility types. Partial<User> makes all fields optional, handy for override objects in test data builders. Pick<User, 'id' | 'email'> keeps chosen fields, and Omit<User, 'password'> removes some. Record<Role, string> maps every key of a union to a value type, for example storing a credentials file path per role.
12

How do you keep test code, page objects and utilities organised as a repository grows?

Save to ▾
Show answer
Use a clear layout: tests grouped by feature, a pages folder for page objects, a fixtures folder that exposes them, and api and data folders for helpers and builders. Add path aliases in tsconfig, a lint config with the Playwright plugin, and a short contributing guide. Review new helpers in pull requests so duplicate utilities do not spread.
13

Write a custom fixture that gives a logged-in page.

Save to ▾
Show answer
import { test as base } from '@playwright/test'; export const test = base.extend({ loggedInPage: async ({ page }, use) => { await page.goto('/login'); await page.getByLabel('Email').fill('qa@test.in'); await page.getByLabel('Password').fill('Pass@123'); await page.getByRole('button', { name: 'Sign in' }).click(); await use(page); }, });
14

What is the difference between a type annotation and a type assertion with as?

Save to ▾
Show answer
A type annotation such as const user: User = data asks the compiler to check that the value really fits User. A type assertion such as data as User tells the compiler to trust you, so mismatches are not reported. In test code assertions are risky on API responses, because a wrong field passes compilation and fails later. Prefer annotations, type guards or runtime schema validation.
15

Test data is left behind when tests fail midway. How do you guarantee cleanup?

Save to ▾
Show answer
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.
16

What is the difference between test-scoped and worker-scoped fixtures?

Save to ▾
Show answer
A test-scoped fixture is created and torn down for every test, which keeps tests isolated. A worker-scoped fixture is set up once per worker process and shared by all tests that run in it, which suits expensive things like a started server or a seeded account. Declare it with { scope: 'worker' }. Worker fixtures cannot depend on test fixtures.
17

How do you test a flow that needs two user roles, such as an admin and a customer, in one test?

Save to ▾
Show answer
Create two browser contexts in the same test, each with its own storageState file, for example admin.json and user.json made by a setup project. Wrap them in fixtures like adminPage and userPage so tests stay short. The admin approves an order in one context and the customer sees the update in the other, with fully separate cookies.
18

What does the reportSlowTests option do?

Save to ▾
Show answer
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.
19

A toast message disappears after two seconds and the assertion on it is flaky. How do you test it reliably?

Save to ▾
Show answer
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.
20

How do you test a file download?

Save to ▾
Show answer
const [download] = await Promise.all([ page.waitForEvent('download'), page.getByText('Export').click(), ]); await download.saveAs('reports/file.csv');
21

Write a fixture that gives each parallel worker its own test account.

Save to ▾
Show answer
import { test as base } from '@playwright/test'; export const test = base.extend<{}, { account: { email: string; password: string } }>({ account: [async ({}, use, workerInfo) => { const i = workerInfo.parallelIndex; await use({ email: `qa.user${i}@example.test`, password: process.env.QA_PASSWORD!, }); }, { scope: 'worker' }], });
22

How do you assert that a request was sent with the correct payload?

Save to ▾
Show answer
const reqPromise = page.waitForRequest(r => r.url().endsWith('/api/orders') && r.method() === 'POST' ); await page.getByRole('button', { name: 'Place order' }).click(); const req = await reqPromise; expect(req.postDataJSON()).toMatchObject({ qty: 2, sku: 'MOU-01' });
23

How do you locate elements inside a specific row or card?

Save to ▾
Show answer
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.
24

Images load lazily and are sometimes missing from full-page screenshots. How do you make them stable?

Save to ▾
Show answer
Scroll the content into view or remove loading=lazy for the test, then wait until every image has loaded, for example with expect.poll checking that all img elements report complete and a natural width above zero. Serving images from mocked routes removes network timing too. Only after that call toHaveScreenshot, which then waits for two identical frames.
25

What are interfaces and types in TypeScript?

Save to ▾
Show answer
Both describe the shape of data. Interfaces are extendable and suit object contracts; type aliases can also model unions and primitives.
26

Tell me about a time mocking helped you test a hard edge case.

Save to ▾
Show answer
Situation: we could not reproduce a bug where the cart broke when the stock API returned zero for one item. Task: cover it with a test. Action: I mocked only the stock endpoint with route.fetch and changed one item's quantity, then asserted the out-of-stock label. Result: the bug was fixed and the test now protects that case on every run.
27

Write a test that deletes a record and confirms it is gone.

Save to ▾
Show answer
test('delete product', async ({ request }) => { const created = await request.post('/api/products', { data: { name: 'Temp' } }); const { id } = await created.json(); const del = await request.delete(`/api/products/${id}`); expect(del.status()).toBe(204); const get = await request.get(`/api/products/${id}`); expect(get.status()).toBe(404); });
28

A third-party analytics script makes tests slow and flaky. What do you do?

Save to ▾
Show answer
Block it in tests with context.route on its domain and route.abort, or fulfill it with an empty script. Analytics is not what you are testing, and blocking it removes delays and random network errors. If tracking events matter, write a few separate tests that capture the requests with waitForRequest and assert their parameters.
29

What are automatic fixtures?

Save to ▾
Show answer
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.
30

How do you do visual regression testing?

Save to ▾
Show answer
Use expect(page).toHaveScreenshot() to compare with stored baselines, with thresholds and masks for dynamic regions.
31

How do you test how the UI handles a 500 error from the orders API?

Save to ▾
Show answer
Mock the endpoint with route.fulfill({ status: 500, json: { message: 'Server error' } }), then open the page. Assert the user sees a friendly error message and a retry button, and that no broken half-rendered table appears. Then make the retry return 200 and check the data loads. This covers a path that is hard to trigger on a real server.
32

What are web-first assertions?

Save to ▾
Show answer
Assertions like expect(locator).toBeVisible() that retry until they pass or time out, unlike one-off checks.
33

How do you attach a screenshot or log to the report from inside a test?

Save to ▾
Show answer
test('report', async ({ page }, testInfo) => { await page.goto('/reports'); await testInfo.attach('report page', { body: await page.screenshot(), contentType: 'image/png', }); await testInfo.attach('meta', { body: 'build 42', contentType: 'text/plain' }); });
34

How do you fail a test if the page logs any console error?

Save to ▾
Show answer
test('no console errors', async ({ page }) => { const errors: string[] = []; page.on('console', m => { if (m.type() === 'error') errors.push(m.text()); }); page.on('pageerror', e => errors.push(e.message)); await page.goto('/dashboard'); expect(errors).toEqual([]); });
35

How do you validate an API response in Playwright?

Save to ▾
Show answer
Assert the status with expect(res.status()).toBe(200), parse res.json() and check fields, using schema validation for the structure.
36

A test fails with 'Target page, context or browser has been closed'. What usually causes it?

Save to ▾
Show answer
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.
37

How do you test accessibility with Playwright?

Save to ▾
Show answer
Integrate axe-core through @axe-core/playwright, run an analysis on the page and assert that there are no violations.
38

How do you write a Page Object in Playwright?

Save to ▾
Show answer
A class receives page in its constructor, stores locators as properties and exposes actions like login(user, pass). Tests call page objects, not raw locators.
39

How do you capture browser console messages and page errors?

Save to ▾
Show answer
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.
40

What is a fixture option and how do you define one?

Save to ▾
Show answer
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.

Tips to crack the Texas Instruments Playwright Testing interview

  • Revise analog electronics, op-amps, circuit analysis and semiconductor device basics, which are core topics for many TI roles.
  • For digital and embedded roles, revise digital design, microcontrollers and C programming with practical examples from lab work.
  • Be ready to solve circuit problems on paper and explain each step clearly, as interviewers often focus on fundamentals.
  • 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; Texas Instruments interviewers usually ask follow-ups on your first answer.

Frequently asked questions

How many rounds are there in the Texas Instruments Playwright Testing interview?

Candidates usually go through 4 stages: Online assessment (aptitude + electronics); Technical interview 1; Technical interview 2; 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 Texas Instruments Playwright Testing interview?

This practice set leans on Fixtures and Hooks (7), API Testing (6), Playwright Core (5), Network Mocking (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Texas Instruments interviewers ask you to walk through real work.

Are these the exact questions asked at Texas Instruments?

No. These are curated practice questions that match the skills and difficulty usually tested in hardware & semiconductors interviews like Texas Instruments's. They are not a leaked or verified list of past questions.

Where does Texas Instruments hire Playwright Testing professionals in India?

Texas Instruments has large teams in Bengaluru. Openings and locations change often, so check the Texas Instruments careers page and filter by city and experience.

Playwright Testing questions for similar companies