Software Tester interview questions and answers

Equivalence partitioning splits the input into groups the system should treat the same way, so one value from each group is enough. For an age field accepting 18 to 60 there are three groups: below 18 (invalid), 18 to 60 (valid) and above 60 (invalid). So you might test 10, 35 and 70.

Boundary value analysis adds the edges, because that's where developers make mistakes like writing > instead of >=. Test 17, 18 and 19, and 59, 60 and 61. Then add the inputs neither technique covers: blank, letters, decimals like 25.5 and negative numbers.

A test scenario is a one-line statement of what to test, such as "Check that a user can reset a forgotten password." A test case is the detailed, repeatable steps to test one part of it, and one scenario usually becomes several test cases, positive and negative.

A good test case has an ID, a clear title, the requirement or story it covers, preconditions, test data, numbered steps, the expected result, and, during execution, the actual result and status. It should be specific enough that another tester gets the same result. A common mistake is writing "should work properly" as the expected result instead of stating exactly what should happen.

Exploratory testing means learning the application, designing tests and running them at the same time, using what you discover to decide the next test. It works better than scripts for new features with thin requirements, for finding usability problems and unusual paths, and when time is short.

To keep it accountable, I use time-boxed sessions with a charter, for example "Explore the coupon feature at checkout with expired and stacked coupons, 60 minutes." During the session I note what I covered, the bugs and questions I found, and afterwards I turn useful paths into regression test cases. It complements scripted testing rather than replacing it.

You can never test everything, so "enough" means the important risks are covered. I check three things. First, requirement coverage: a traceability matrix maps every requirement or acceptance criterion to at least one test case, so nothing is missed. Second, technique coverage: each input has its partitions and boundaries, and rules with several conditions have a decision table. Third, risk: the areas that handle money, personal data or heavy use get deeper testing and more negative cases.

I also review the cases with the developer or business analyst, since they often spot a missing flow. Saying you prioritise by risk sounds far stronger than quoting a number.

A defect moves through set states from the moment it's found until it's closed. The tester logs it as New. A lead or manager reviews it and Assigns it to a developer, who changes it to Open or In Progress while working on it, then Fixed. The tester retests: if it works it's Closed, and if not it's Reopened and goes back to the developer.

Other outcomes are Rejected (not a bug, or working as designed), Duplicate (already logged), Deferred (to be fixed in a later release) and Cannot Reproduce. The exact names vary by team and tool, so say how your Jira workflow was set up.

Severity is how badly the defect affects the system, and the tester usually sets it. Priority is how soon it must be fixed, which the product owner or lead usually decides based on business need.

High severity, low priority: the application crashes when a user exports a report from a screen that only a handful of admins use once a year; it's serious, but it can wait for the next release. Low severity, high priority: the company's name or logo is misspelt on the home page; nothing breaks, but it must be fixed before release because every customer sees it. Interviewers like candidates who explain who sets each one.

Report it immediately and clearly, not at the end of the day. I log it with exact steps, evidence and its impact on users, then tell the test lead and the developer directly so the team can decide quickly. I also check how widespread it is: does it affect all users or one browser, and is there a workaround?

The decision to fix, delay or release with a known issue belongs to the product owner and managers; my job is to give them the facts. If a fix goes in, I retest it and run focused regression around the changed area. I wouldn't hide or downgrade the bug to protect the date.

Treat it as a process question, not a blame exercise. First confirm the bug and how many users it affects, and make sure it's logged and fixed. Then trace back: was the scenario in the requirements, did a test case cover it, was that case run on the right build and environment, and did the data in production differ from test data?

The answer points to the fix: a missing requirement needs better story reviews, a missing test needs new cases, an environment gap needs a closer copy of production. I add a regression case for the bug, and teams often track defect leakage to see if such escapes are reducing.

STLC is the sequence of testing activities. Requirement analysis: study the requirements, find what's testable and raise doubts early. Test planning: decide scope, approach, effort, resources, schedule and risks, written in the test plan. Test case design: write test cases and prepare test data. Test environment setup: get the servers, builds and access ready, and run a smoke test. Test execution: run the cases, log defects and retest fixes. Test closure: check the exit criteria, report the results and record lessons learnt.

Each phase has entry criteria, deliverables and exit criteria, and mentioning that shows you know it's a managed process.

Verification asks "Are we building the product right?" It checks the work products against their specifications without running the code: reviews of requirements, design walkthroughs, code inspections and test case reviews. Validation asks "Are we building the right product?" It runs the software to check it meets the user's real needs: functional, system and acceptance testing.

Verification is static and happens throughout development; validation is dynamic and needs working software. For example, reviewing a login screen's design document against its requirements is verification, and actually logging in with valid and invalid passwords is validation. Both are needed, because early reviews catch problems far more cheaply.

The V-model pairs each development phase with a test level: requirements with acceptance testing, system design with system testing, architecture with integration testing, and detailed design with unit testing. Test planning starts as each phase is written, which is its main advantage over plain Waterfall.

In Waterfall, testing is a separate phase after development, with a big test cycle and detailed documents; changes are costly late on. In Agile, testers work inside each sprint: they review stories, write tests while code is built, test each story when it's ready and keep regression running every sprint, usually with automation. Say which model your projects followed and what that meant for you.

A test plan is the document that says what will be tested, how, by whom and when. The usual sections are: scope (features in and out of scope), test approach and types of testing, test environment and tools, entry and exit criteria, roles and responsibilities, schedule and effort estimates, deliverables (test cases, reports), risks with their mitigation, and suspension and resumption criteria (when to pause testing, such as a broken build).

Many templates follow IEEE 829 (now replaced by ISO/IEC/IEEE 29119-3), but teams adapt them. In Agile projects the plan is usually shorter and lives in Confluence or the wiki, with sprint-level detail in the stories.

Entry criteria are the conditions that must be met before testing starts; exit criteria are the conditions for saying testing is finished. They stop a team from testing a build that isn't ready, or stopping just because time ran out.

For system testing, entry criteria might be: requirements signed off, test cases reviewed, the build deployed to the test environment and the smoke test passed, and test data ready. Exit criteria might be: all planned test cases run, no open critical or high-severity defects, an agreed pass rate reached, and remaining defects accepted by the product owner. Saying the criteria are agreed with stakeholders up front is a good touch.

Break the work down first. I list the features and estimate the test cases each needs, then the time to design, review and run them, plus environment setup, defect retesting, regression and reporting. Past projects help: if a similar module took a certain number of hours per test case, I use that rate.

For uncertain items I use three-point estimation: (optimistic + 4 × most likely + pessimistic) ÷ 6. I add a buffer for risks like late builds or unstable environments and state my assumptions clearly. Then I review the estimate with the team and track actuals against it, so the next estimate is better.

I report a few metrics that support decisions, not every number the tool produces. Test execution progress: planned versus run, passed, failed and blocked, which shows whether we'll finish on time. Defect counts by severity and status, and the trend of new versus closed defects: if new defects keep rising near the release, the build isn't stable. Requirement coverage from the traceability matrix. After release, defect leakage: bugs found in production as a share of all bugs found, which shows how effective testing was.

I always add a short note on what the numbers mean, because a 95% pass rate means little if the failing 5% are payments.

Scrum has three roles. The product owner decides what to build and orders the product backlog. The Scrum Master helps the team follow Scrum and removes blockers. The developers, which in Scrum includes testers, build and test the product.

The events: the sprint itself, a fixed period of usually two weeks; sprint planning, where the team picks the work for the sprint; the daily scrum, a 15-minute meeting on progress and blockers; the sprint review, where the team shows finished work to stakeholders; and the retrospective, where the team discusses how to improve. Mention what you contributed as a tester in each event.

A user story describes a feature from the user's point of view, usually as "As a [type of user], I want [goal] so that [reason]." For example: "As a customer, I want to save my address so that checkout is faster." Acceptance criteria are the conditions the story must meet to be accepted, such as "A user can save up to five addresses" and "The PIN code must be six digits."

Testers use them as the base for test cases: each criterion gets at least one positive and one negative test. Testers also review stories before the sprint and ask questions when a criterion is vague or missing.

Start testing work on day one, not when the code is finished. In planning, I help estimate stories with testing effort included. While developers build, I write test cases from the acceptance criteria and prepare test data. Developers hand over stories one by one as they finish, not all together, so I test each as soon as it's ready and raise bugs while the code is fresh.

Regression runs through the sprint, mostly automated. The team agrees that a story isn't done until it's tested, so testing time is part of the commitment. If stories still bunch up late, I raise it in the retrospective.

Keep it to about a minute and link everything to testing. Use present, past, future: "I'm a [degree] graduate from [college]. I became interested in testing during my final-year project, when I found that [what you found, for example most of our bugs came from untested edge cases]. Since then I've learnt manual testing, test case design and basic SQL, and I've practised by testing [an app or project] and logging bugs in Jira. I'm now looking for a software tester role where I can [goal], which is why this position interests me."

Mention a tool or certification only if you can answer questions on it.

Give a positive reason for testing, not a negative one about coding. Interviewers worry that you'll leave as soon as a development role appears, so show you value the work itself: "I enjoy finding where things break and thinking like the user. In my project I [example, such as found a payment flow bug that everyone else missed], and I liked that more than writing the feature. Testing also lets me learn the whole product and the business, and I plan to grow into automation and test design."

Never say you chose testing because it needs less coding: it's the answer they're listening for.

Pick a bug with clear business impact and tell it with STAR. "In a [banking or e-commerce] project (situation), I was testing [feature] (task). Beyond the planned cases, I tried [what you did, such as applying a refund twice quickly] and found the customer was credited twice. I logged it with steps, screenshots and the database entries, and explained the impact to the lead (action). It was fixed before release, and we added the scenario to regression and to the test design checklist (result)."

The point is your thinking: why you tried that case. That tells the interviewer more than the bug itself.

Show that you stay calm, prioritise and keep people informed. "First I'd tell the lead early that we can't cover everything, with what's left. Then I'd test by risk: the main user flows, money and data first, the areas changed in this release next, and low-risk screens last. I'd report clearly what was tested, what wasn't and the open defects, so the product owner can decide whether to release, and I'd offer to test the rest straight after."

Avoid saying you'd simply work all night or quietly skip tests: interviewers want judgement and honesty, not heroics.

Show a growth path inside testing that fits the company. "In five years I'd like to be a senior tester who owns the quality of a module: designing the test strategy, automating the regression suite and guiding new testers. I'm already learning [Selenium, Java or Python, API testing with Postman], and later I'd like to move towards a test lead or automation role here."

Naming concrete skills you're working on makes it believable. Don't say you plan to move into development or to another company: it signals that testing is only a stepping stone for you.