HR & Behavioural Playwright Testing Interview Questions

Situation: a suite I joined used long XPath selectors and about ten tests broke after every UI release. Task: make them stable. Action: I rewrote the locators with getByRole and getByLabel, added test ids for two custom grids and moved everything into page objects. Result: locator-related failures dropped to almost zero over the next three releases.

Situation: a checkout test passed, but users saw a blank order summary. Task: find why. Action: I found the test only asserted that the summary container was visible, not its contents. I added assertions on item names, totals and the order id. Result: the test caught the regression, and I reviewed other tests for similar weak assertions.

Situation: a manager wanted 50 tests for a release in one week. Task: deliver without creating a flaky suite. Action: I agreed on the 20 highest-risk flows first, used stable locators and shared fixtures, and listed the rest as follow-ups. Result: the 20 tests ran green in CI from day one and the rest were added next sprint.

Situation: forty test files each repeated twenty lines of login and data setup. Task: reduce duplication and maintenance. Action: I created fixtures for the logged-in page, a test customer and page objects, migrated files in small reviewed pull requests and wrote a short guide. Result: test files became half the size and setup changes now touch one file.

Situation: one morning 300 tests failed in CI. Task: restore the pipeline quickly. Action: the trace showed every test failing inside an auth fixture after a login API change, so I fixed the fixture, added a dedicated setup test that fails fast with a clear message, and alerted the team. Result: the pipeline recovered within an hour and similar outages became easy to spot.

Situation: a teammate proposed mocking all APIs to make the suite fast. Task: keep speed without losing integration coverage. Action: I showed two recent bugs caused by API changes that mocks would have hidden and proposed mocking only third parties and error states, keeping ten real end-to-end journeys. Result: the team agreed and the next contract change was caught before release.

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.

Situation: a search test failed about once in ten runs. Task: find the cause. Action: I ran it with --repeat-each and traces, and saw two search requests return out of order, so the older result replaced the newer one. Result: I proved it was a real race condition in the app, developers fixed it with request cancellation, and the test became stable.

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.

Situation: the UI hid a delete button for normal users, so UI tests passed. Task: check permissions properly. Action: I called the delete endpoint directly with a normal user's token and it returned 204. Result: the team fixed the server-side permission check, and I added role-based API tests for every admin endpoint.

Situation: dozens of tests failed after a field was renamed from user_name to username. Task: fix quickly and prevent repeats. Action: I updated the shared types and helper, so the fix touched two files, and proposed schema checks on key endpoints plus a heads-up in release notes. Result: the next breaking change was caught in the pull request.

Situation: a booking page had a custom calendar, drag-to-select seats and a timer. Task: automate the full booking. Action: I used role locators for the calendar, mouse actions for seat selection and page.clock to control the timer, keeping each part in a page object method. Result: the flow ran reliably in CI and replaced a 20-minute manual check.

I like that automation combines coding with product quality. I learned Selenium first, then moved to Playwright because auto-waiting, tracing and API support let me write stable tests faster. In my college project I automated twenty flows with TypeScript and a CI pipeline. I want a role where I can grow into framework design and CI ownership.

Situation: I joined a team whose Playwright suite was in TypeScript while I knew only basic JavaScript. Task: become productive in two weeks. Action: I studied types, interfaces and generics in the evenings, read the team's page objects, and fixed small compiler errors as practice. Result: by week three I was writing new tests and reviewing simple pull requests.

Situation: on release day the test job failed for every build after a runner image update. Task: unblock the release safely. Action: I compared logs, found missing browser dependencies, pinned the Playwright Docker image version and reran. Result: tests passed within an hour, the release went out on time, and I added an alert for image changes.

Situation: our team ran tests only on laptops before releases. Task: run them automatically on every pull request. Action: I created a CI workflow with browser install, sharding over four machines, merged HTML reports and traces on retry. Result: feedback came within twelve minutes on each pull request, and release-day surprises dropped sharply.

Situation: three interns joined with little automation experience. Task: make them productive without lowering quality. Action: I ran short sessions on fixtures, locators and traces, paired with each of them on a first test, and gave detailed but kind review comments. Result: within a month they each shipped stable tests, and one later improved our reporting script.

Situation: a developer said a failing checkout test was flaky and asked to skip it before release. Task: decide based on evidence. Action: I shared the trace showing the total stayed wrong after a coupon was removed and reproduced it manually. Result: we agreed it was a real bug, it was fixed before release, and we started reviewing traces together.

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.

Situation: the team saw accessibility as a later task. Task: I wanted checks in the pipeline. Action: I ran axe on our top five journeys and showed the results with one short screen reader demo, then proposed a non-blocking report first and blocking only for new violations. Result: within a quarter the main flows reached zero serious issues and the check became a required gate.

Situation: our API helpers returned loosely typed objects and tests often read fields that no longer existed. Task: make helpers safer. Action: I added response interfaces, turned on strict mode and replaced any with unknown plus type guards. Result: the compiler immediately showed eleven tests reading a renamed field, which had been passing because they compared undefined with undefined. We fixed them before the next release.

Situation: during my internship a login test failed only in CI and I could not reproduce it. Task: find the cause. Action: I enabled trace on first retry, downloaded the trace and stepped through the actions, and saw a cookie banner covering the sign-in button in the CI viewport. Result: I added a step to accept the banner, the test became stable, and I shared the method with my team.

Situation: our end-to-end suite took 40 minutes and most failures were in form validation. Task: speed up feedback. Action: I set up Playwright component tests for the form library, wrote ten examples and a short guide, and paired with two developers on their first tests. Result: validation checks moved to component level, the end-to-end suite dropped to 25 minutes and developers began writing component tests themselves.

Situation: a pricing table had many discount rules shown in the UI. Task: decide how to test them. Action: I proposed unit tests for the calculation, component tests for how each rule rendered, and one end-to-end test for buying a discounted plan. I explained the runtime and maintenance cost of each. Result: the team agreed, we covered 30 rules in under a minute, and the approach became our default.

Situation: three product teams each had their own login and data setup code. Task: give them one reliable layer. Action: I built shared worker-scoped auth fixtures, test-scoped data builders with automatic cleanup, and page object fixtures, published them as an internal package with examples and versioned releases. Result: two more teams adopted it within a quarter, duplicate setup code disappeared and onboarding time for new testers dropped from weeks to days.

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.

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.

Situation: our regression suite took 55 minutes, so developers skipped it. Task: bring it under 15. Action: I removed shared test data so fullyParallel could be turned on, split the three slowest files, and ran four shards with blob reports merged into one HTML report. Result: the suite finished in 12 minutes and it became a required check on every pull request.

Situation: managers only heard pass or fail and could not tell flaky tests from real bugs. Task: make results useful. Action: I added a custom reporter that posted a short summary to our team chat with failures, flaky tests and a report link, and a weekly trend of flake rate. Result: flaky tests dropped by half in two months because owners could see them.

Situation: my team moved from another tool to Playwright two weeks before a release. Task: I had to migrate the smoke tests. Action: I spent two evenings on the official docs and codegen, rewrote one test end to end, then asked a senior to review it before converting the rest with the same pattern. Result: all 25 smoke tests ran in Playwright before the release and ran faster than before.