HR & Behavioural Software Testing Interview Questions

Model answer: To me quality means the product does what users need, reliably, and is easy to use, not just that test cases pass. In my final-year project I tested a library app; all features worked, but students struggled to find the search option. I reported it as a usability issue and the team moved search to the home screen. That taught me to test from the user's point of view as well.

Model answer: I enjoy finding how things break and thinking like a user. During my internship I tested a college fee portal and found that a refund was shown twice on the receipt, which the team fixed before launch. Manual testing gives me a strong base in requirements, test design and bug reporting. I plan to add SQL, API and automation skills on top of it as I grow.

Model answer: Situation: before a release of an insurance app, all regression tests had passed. Task: I was doing a final exploratory round. Action: I renewed a policy on the last day of the month and saw that the premium was calculated for 31 days in a 30-day month. I logged it with exact data and the formula difference. Result: the date logic was fixed before release, and I added month-end cases to the suite.

Model answer: Situation: I got a story for 'flexible EMI options' with only one line of description. Task: test it within the sprint. Action: I listed my assumptions on tenure, interest and rounding, reviewed them with the product owner in a 15-minute call, and wrote test cases only after we agreed. Result: three rules were changed before coding finished, and the feature passed UAT without rework.

Model answer: Situation: in my training project, a registration form had age, state and course fields, and my first draft had over 60 test cases. Task: cut effort without losing coverage. Action: I applied equivalence partitioning and boundary values to age and pairwise combinations for state and course. Result: I covered the same rules with 18 cases, my mentor approved them, and execution finished in half the time.

Model answer: Situation: two days before a release, we found 15 new bugs in checkout. Task: help the team decide what to fix. Action: I stayed calm, retested each one quickly, ranked them by user impact, and shared a clear list in triage with must-fix and can-wait items. Result: we fixed five critical bugs, released on time with documented known issues, and no critical issue reached users.

Model answer: Situation: I logged a bug where the invoice PDF showed the wrong GST number, and the developer marked it minor because the screen value was correct. Task: get the right priority. Action: I explained that customers use the PDF for tax filing and showed the requirement. Result: the product owner agreed it was major, it was fixed before release, and we added PDF checks to regression.

Model answer: Situation: a discount was applied twice when users pressed the pay button quickly. Task: I had tested the feature and missed it. Action: I owned it in the retrospective, helped reproduce and verify the fix, and added double-click and slow network cases to our checklist for all payment buttons. Result: similar issues were caught in later sprints, and I learned to always test repeated actions.

Model answer: Situation: in my first project, testers had to verify orders in the database, and I knew only basic SELECT. Task: become useful within a week. Action: I practised joins on a copy of the test database every evening and asked a senior to review my queries. Result: by the second sprint I was validating order data on my own and caught a missing tax column bug.

Model answer: Situation: our sprints kept ending with stories stuck in testing. Task: suggest a fix in the retrospective. Action: I showed that most stories reached QA in the last two days and proposed smaller stories, early test case sharing and developers deploying to QA daily. Result: the team tried it next sprint, and the number of stories carried over dropped from five to one.

Model answer: Situation: our product owner added two small changes to a story mid-sprint, which pushed testing to the last day. Task: protect quality without being rigid. Action: I showed the extra test effort in stand-up and asked the Scrum Master to help decide what to swap out. Result: one change moved to the next sprint, and the team agreed new requests go through the backlog.

Model answer: I follow testing communities and blogs, practise on public demo sites and read release notes of the tools I use. Last month I learned API schema validation from an online course and tried it on a practice API. I also share one new idea in our team chat each week. This keeps me improving and helps the team pick up useful practices without waiting for formal training.

Model answer: Situation: a new leave management module had passed all scripted cases. Task: I had a one-hour exploratory session. Action: I applied leave, then changed my manager in the profile while the request was pending. Result: the request disappeared for both managers and could never be approved. It was fixed before release, and the team added role-change scenarios to the regression suite.

Model answer: Situation: a regulatory change had to go live in ten days. Task: lead four testers. Action: I split work by risk, put our strongest tester on the calculation engine, ran daily 15-minute bug triage with developers and shared a single status dashboard. I also automated the repeated tax checks. Result: we released on the deadline with zero critical defects, and the client used our test evidence for their audit.

Model answer: Situation: a loan app release was planned on Friday, but the EMI schedule showed wrong values for some tenures. Task: give an honest recommendation. Action: I presented the failing cases, the number of affected customers and the compliance risk in the go or no-go meeting, and proposed a three-day delay with a fix plan. Result: management agreed, the fix shipped on Monday, and no complaints came in.

Model answer: Situation: I was supporting two products whose releases fell in the same week. Task: deliver both without dropping quality. Action: I listed tasks by release date and risk, agreed priorities with both leads, blocked focus time for each product and shared daily status. I also asked a teammate to take retesting on one project. Result: both releases went out on time with no critical escapes.

Model answer: Most users in India now use services first on their phones, so mobile quality directly affects customers. In my project I tested a college event app on four phones and found that the registration button was hidden by the keyboard on small screens. Fixing it raised sign-ups. I enjoy the variety of devices, networks and real-life situations that mobile testing involves.

Model answer: Situation: users of one budget phone model reported that the camera upload screen was black. Task: reproduce it. Action: I borrowed the same model, found the issue only appeared when the battery saver was on, and logged the bug with the device model, OS version, logs and a video. Result: the developer fixed the camera initialisation, and we added that model to our device matrix.

Model answer: Situation: a new fresher on my team was writing very long, unclear bug reports. Task: help her improve quickly. Action: I reviewed five of her bugs with her, showed a simple template, paired with her on two exploratory sessions and gave weekly feedback. Result: within a month developers stopped asking her for clarification, and she later found and reported a major session bug on her own.

Situation: a wallet refund screen showed success for every test. Task: I wanted to confirm the balance logic. Action: I queried the wallet_transactions table and saw two refund rows when I double-clicked the submit button, though the UI showed one. I logged it with both query outputs and the steps. Result: developers added an idempotency key, and the team added a database check to our regression checklist.

Focus on impact, not internals. Say who is affected, what they cannot do, how often it happens and what it may cost, for example: 'About one in twenty users paying by UPI see a failure message even though money is debited, which will raise refund complaints.' Then give the options and a recommendation. Avoid jargon like null pointer or race condition unless asked. A short screen recording often helps.

Situation: a new seller onboarding flow was due in a week and only two testers had seen it. Task: I wanted wider coverage quickly. Action: I set up a one-hour bug bash with developers, product and support, shared test accounts, focus areas and a simple bug form, then triaged findings with the lead. Result: we found 18 issues, including two blockers on low-end phones, and fixed them before launch.

Situation: before a release, I found the payment form errors were not announced by screen readers and not reachable by keyboard. Task: the team wanted to defer it. Action: I recorded a short NVDA video showing a user could not finish payment, linked it to WCAG and our customer commitments, and proposed a small fix. Result: the fix took half a day, shipped in the release and we added keyboard checks to our definition of done.

Situation: while testing a leave application form, every test case passed. Task: I still felt the flow was confusing. Action: I noticed the date picker started on Sunday and the half-day option was hidden under 'More', so I asked two colleagues to apply for leave while I watched; both made mistakes. I logged a usability suggestion with notes. Result: product moved the option and support queries dropped.

I treat review comments as free help. I ask for specifics if a comment is unclear, fix valid points quickly and explain my reasoning if I disagree, with the requirement in hand. For example, a senior once said my cases missed negative paths; I added them and also made a personal checklist for future reviews. Repeated comments show me a skill gap I should work on, not a personal attack.

Situation: our regression took three days every release. Task: I wanted to help but knew only manual testing. Action: I spent an hour daily learning Python and Playwright, automated the login and search smoke cases first and asked a developer to review my code each week. Result: in two months my scripts ran in CI on every build, saving about a day per release, and I moved into a hybrid QA role.

Situation: a small tax rounding change was made late on a Friday. Task: no manual regression was planned for pricing. Action: our nightly API suite failed one data-driven case where a 3-item cart was off by one rupee; I checked the trace, reproduced it manually and logged it with the failing input. Result: it was fixed before release, and the team agreed to keep pricing tests in the pull request suite.

I agree the split with the team at sprint planning. Testing new stories manually comes first because it blocks the sprint goal. I then automate the stable flows from the previous sprint, so scripts are not rewritten while features change. For example, I block two afternoons a week for automation and report progress in stand-up. If a release is at risk, I pause automation and tell the lead openly.

Answer with strengths and honesty. For example: I am strong at understanding requirements, designing test cases with techniques like boundary values and finding bugs through exploratory testing, which automation depends on to be useful. I also write SQL and test APIs in Postman. I am learning Playwright and have automated a few smoke tests, so I can grow into automation while adding value from the first week.

Situation: our UI scripts broke almost every sprint because of generated IDs and CSS class changes. Task: as the QA lead I needed stable tests. Action: I showed developers the failure history, proposed adding data-testid attributes and accessible labels to key components and added a short checklist to the pull request template. Result: within two sprints locator-related failures dropped by most of the previous level and maintenance time fell sharply.