HR & Behavioural Automation Testing Interview Questions

Situation: requirements were often misread, causing rework late in sprints. Task: I proposed BDD for one module. Action: I ran short three-amigos sessions, wrote example scenarios with the BA, automated them with Cucumber and showed them in sprint review. Result: rework on that module dropped noticeably over two sprints, and the team adopted the practice for other complex stories.

Situation: our suite had duplicated locators across 200 tests and each UI release broke many of them. Task: reduce maintenance effort. Action: I introduced page objects and components for the top ten pages, added data-testid attributes with the developers and wrote a short guide. Result: fixing a UI change went from half a day to under an hour, and new joiners wrote tests faster.

Situation: the night before release, every UI test failed in Jenkins. Task: find the cause fast and unblock the release. Action: I checked the console and saw a browser and driver version mismatch after an agent update, pinned the browser image version, reran the suite and shared a short note. Result: the release went out on time and we added image version pinning to the pipeline.

Situation: an API test kept failing intermittently and developers called it a test issue. Task: prove or disprove it. Action: I collected logs from ten failures, showed the same race condition in the order service with request IDs, and reproduced it with a small parallel script. Result: developers fixed a real concurrency bug before it reached customers, and trust in the suite improved.

Situation: a new product had no automation and a three-month release target. Task: I was asked to set up the framework and guide two juniors. Action: I chose Java, TestNG, Selenium with POM and REST Assured, set up Maven, Jenkins and Allure, wrote conventions and reviewed every pull request early on. Result: we had 250 stable tests in CI before release, and the juniors could extend it independently.

Situation: during a sprint, my nightly regression showed checkout failing only for one payment option. Task: confirm if it was a test issue or a real bug. Action: I reproduced it manually, checked the API response and found a wrong tax value, then logged a clear defect with steps, logs and screenshots. Result: developers fixed it before the release and the test was added to the smoke suite.

Situation: I estimated three days to automate a new module, but the UI had complex dynamic tables. Task: still deliver what the sprint needed. Action: I told the lead early on day two, proposed automating the API checks first and the UI flows next sprint, and documented the extra effort. Result: the sprint goal was met, and I now spike unfamiliar screens before estimating.

Situation: I moved from manual testing into an automation team using Java. Task: become productive within a month. Action: I practised core Java daily, focusing on OOP, collections and exceptions, solved small coding problems, and read the existing framework code with a senior's help. Result: in four weeks I was writing page objects and tests that passed review, and I kept learning streams afterwards.

Situation: tools change fast, and my team was still on older Selenium and Java versions. Task: keep myself and the framework current. Action: I follow release notes, try new features in a small personal project, and present one useful change to the team each quarter, such as moving to java.time or Selenium 4 relative locators. Result: we upgraded smoothly and I became the go-to person for upgrades.

Situation: in my first code review, a senior said my tests were hard to read and used Thread.sleep everywhere. Task: improve without getting defensive. Action: I asked for examples, replaced sleeps with explicit waits, extracted helpers and followed the team's naming conventions. Result: my next pull requests were approved faster, and I later used the same checklist to review a junior's code.

Situation: two new joiners from manual testing struggled with framework code. Task: help them contribute within a sprint. Action: I paired with them daily for an hour, gave small tasks like adding a locator then a full test, and reviewed their code with explanations rather than rewriting it. Result: within three weeks both were writing tests independently, and our automation backlog shrank.

Situation: a developer said a rounding difference in invoice totals was expected. Task: resolve it without friction. Action: I checked the requirement, found it specified rounding per line, and brought the document and a test case with expected values to a quick call with the BA. Result: the BA confirmed it was a bug, it was fixed, and we added the rule to the acceptance criteria.

Situation: our app had a drag-and-drop dashboard builder built on canvas. Task: automate the key layout flows. Action: I tried the Actions class, found canvas elements were not in the DOM, and worked with developers to expose test hooks and an API to verify saved layouts. Result: we automated the main flows reliably, combining a few UI actions with API checks.

Situation: in my internship I repeated the same regression checks every release. Task: I wanted to free time for exploratory testing. Action: I learnt Selenium and Java and automated our login and search regression in my spare time. Result: the checks went from two hours to ten minutes, and I realised I enjoy building tools that improve quality, which is why I want this role.

Situation: a manager wanted a one-time data migration check automated in Selenium. Task: give an honest recommendation. Action: I estimated the UI automation effort, showed a SQL comparison plus a manual sample check would finish in a day, and explained the flows would not repeat. Result: we finished faster, and the team now asks for ROI reasoning before automating.

Situation: 60 tests failed the evening before a release. Task: give a clear go or no-go input. Action: I grouped failures by root cause, found most came from one changed locator and one test data issue, fixed those first, and manually checked the three failures that pointed to real bugs. Result: I gave the lead a short report in two hours and one real defect was fixed before release.

Situation: our developers were in another time zone and test failures waited a day for replies. Task: reduce delays. Action: I wrote clear failure reports with screenshots, logs and steps, recorded short videos for complex issues, and set a fixed 30-minute overlap call twice a week. Result: turnaround on defects dropped from two days to about one, and fewer issues bounced back.

Situation: leadership set a goal to automate every manual test case. Task: set realistic expectations. Action: I analysed the cases, showed that some were one-time, visual or exploratory, and proposed covering critical and repetitive flows first with a clear ROI estimate. Result: we agreed on 80 percent of regression cases, delivered it on time, and kept exploratory testing manual.

Situation: a new project team asked whether to keep Selenium or switch tools. Task: recommend an option with evidence. Action: I ran a two-week proof of concept automating the same five flows in both, compared stability, run time, team skills and Grid support, and shared the results. Result: we kept Selenium with Java for the existing team skills and Grid setup, and adopted better waits and parallel runs from the trial.

Situation: a manager questioned why my mobile estimate was nearly double the web one. Task: justify it with facts. Action: I listed the extra work: two platforms with separate locators, device and OS version matrix, slower sessions, app builds and signing, gestures and permissions, and device lab maintenance. I showed timings from a pilot of five tests. Result: the manager accepted a phased plan starting with Android smoke tests, and later estimates were trusted because they were data-backed.

Situation: my team needed Android regression tests and I only knew Selenium. Task: deliver a smoke suite in one month. Action: I learned Appium 2 setup, used Appium Inspector to find locators, asked developers to add accessibility ids, and reused our TestNG, POM and reporting structure with a new driver factory. Result: twenty smoke tests ran nightly on emulators within four weeks, and release smoke testing dropped from half a day to forty minutes.

Situation: a checkout test failed about one run in five and the team started ignoring red builds. Task: fix the root cause, not just rerun it. Action: I added logs and screenshots, found it raced with an async price recalculation, replaced a fixed sleep with a wait on the updated total and asked developers for a loading flag. Result: zero failures in the next sixty runs, and the team trusted red builds again.

Situation: our TestNG regression took three hours, so it only ran nightly. Task: get it under forty minutes to run on every merge. Action: I profiled slow tests, replaced UI login with an API token, made the driver ThreadLocal and enabled parallel classes, moved data setup to APIs and removed duplicate tests. Result: the suite ran in thirty-five minutes on four threads, and defects were caught on the same day they were introduced.

Situation: our tests behaved differently on each tester's laptop and on Jenkins because of browser and driver versions. Task: make results consistent. Action: I built a small demo with Docker Compose running the Grid and the app, showed identical results on three machines and on CI, and wrote a one-page setup guide. Result: the team adopted it within two sprints, works-on-my-machine failures almost disappeared and new joiners were productive on day one.

Situation: three product teams each kept their own unstable Grid VMs. Task: provide one reliable shared Grid. Action: I set up a Docker-based Grid with pinned images, health checks, video for failures and a short onboarding guide, then ran a pilot with one team and fixed their issues before opening it up. Result: all three teams moved within a quarter, VM costs dropped and Grid-related failures fell sharply.

Situation: a story said users get a refund if an order is cancelled early. Task: write scenarios with the product owner and developer. Action: while writing examples I asked what early meant and whether shipped orders counted. The three of us found the story had no time limit and no rule for partial shipments, and we wrote four concrete scenarios. Result: the rules were fixed before coding, avoiding a rework that had happened in a previous sprint.

Situation: before each regression a tester spent an hour deploying the build to QA and seeding data by hand. Task: remove that manual step. Action: I wrote a Jenkins pipeline stage that deployed the build, ran database seed scripts and a smoke check, then triggered the regression job, and documented it for the team. Result: setup dropped to ten minutes without human effort, and regressions could run overnight automatically.

Situation: a product team requested load testing three days before launch. Task: give useful results fast and set expectations. Action: I explained the risk, agreed on the two most critical journeys, reused API scripts and ran a short load and spike test, sharing results daily. I also proposed adding a performance stage to future sprints. Result: we found a missing database index before launch, and the next release included performance tests from the start.

Situation: a new search feature passed functional testing. Task: run a load test at expected peak traffic. Action: at 150 users the 95th percentile jumped from under one second to nine seconds. I correlated it with database metrics, found a full table scan caused by a missing index and shared the query and graphs with developers. Result: after the fix, response time stayed under 800 milliseconds at 400 users, and release went ahead on time.

Situation: a backend team renamed a response field during a refactor. Task: our nightly REST Assured suite had to protect the mobile and web clients. Action: schema validation failed within minutes of the merge, and I shared the failing response and the contract with the developer. Result: the field was restored with a deprecation plan before the UI suite even ran, and the team added our schema tests to their pull request checks.

Situation: a release was blocked by failing tests and the manager wanted to know if it was safe to ship. Task: explain the risk without jargon. Action: I separated the failures into one real bug, where customers could be charged twice, and three environment issues. I showed the bug with a short screen recording. Result: the manager delayed the release by one day, the bug was fixed and the environment issues were assigned to DevOps.