Software Testing Interview
Questions and answers (2026)

Software testing is the process of checking that a software product meets its requirements and works as expected. It finds defects, verifies that the build is stable, and gives the team confidence to release.

Testing is not only about finding bugs — it also checks that the product is usable, secure, performant, and that it behaves correctly for valid and invalid inputs. In modern Agile teams, testing happens continuously from the first sprint, not only at the end.

Verification asks "are we building the product right?" It checks documents, designs and code against the specification — reviews, walkthroughs and static analysis. It is done without running the software.

Validation asks "are we building the right product?" It runs the actual software and checks it against user needs — functional testing, UAT and end-to-end testing.

SDLC (Software Development Life Cycle) is the end-to-end process of building software: requirement gathering, design, development, testing, deployment and maintenance.

STLC (Software Testing Life Cycle) is the testing portion inside SDLC. Its phases are: requirement analysis, test planning, test case design, environment setup, test execution, defect logging and test closure.

SDLC is the whole project; STLC is the testing workstream inside it. Every STLC phase has a deliverable — for example, requirement analysis produces the RTM, test planning produces the test plan.

In Agile teams, unit and integration tests run on every commit, while system and UAT happen before release.

Functional testing checks what the system does — whether each feature behaves according to the requirements. Examples: login, search, checkout, password reset.

Non-functional testing checks how well the system does it — performance, load, security, usability, compatibility and reliability. Examples: response time under 1,000 users, HTTPS enforcement, browser compatibility.

Both matter. A feature can be functionally correct but unusably slow — that is still a release blocker.

Smoke testing is a shallow, broad check that the build is stable enough to test. It covers the critical paths — login, main navigation, key flows. If smoke fails, the build is rejected and returned to development.

Sanity testing is a narrow, deep check after a small change or bug fix. It confirms that the fix works and did not break the nearby functionality.

Simple way to remember: smoke = "is the build alive?"; sanity = "does this fix work?"

Retesting checks whether a specific defect has been fixed. You re-run the exact test case that failed earlier, against the new build.

Regression testing checks whether the change broke anything else. You re-run related test cases — often the entire critical suite — to confirm the build is still stable.

Retesting is targeted and one-time. Regression is broader and repeated with every build. Both are needed after a bug fix.

• Black box testing — the tester has no knowledge of the internal code. Tests are designed from requirements and observed behaviour. Used by manual testers and UAT.
• White box testing — the tester sees the code and tests internal paths, branches and conditions. Mostly done by developers (unit testing, code coverage).
• Grey box testing — the tester has partial knowledge of the internals. Common in API testing and integration testing, where you know the database or interface structure but test through the public layer.

A test plan is a project-specific document describing scope, objectives, approach, resources, schedule, entry/exit criteria and risks for a particular release or feature.

A test strategy is organisation-wide. It sets the general testing approach — types of testing, tools, environments, reporting standards — and changes rarely.

Simple comparison: strategy is "how we test here"; plan is "how we will test this release".

A test scenario is a one-line statement of what to test — "verify login with a valid password". It gives coverage in one line.

A test case is the detailed version — test ID, preconditions, steps, test data, expected result, actual result, status. Several test cases usually belong to one scenario.

Scenario: "verify login with valid, invalid, blank and locked credentials". Test cases: TC-01 valid login, TC-02 wrong password, TC-03 blank email, TC-04 locked account, and so on.

An RTM is a table that maps each requirement to the test cases that cover it — and often to the defects raised against it.

It shows two things: that every requirement has at least one test case (no gaps), and that no test case exists without a requirement (no scope creep). In interviews, mentioning RTM shows you understand coverage, not just testing.

The bug life cycle is the set of states a defect passes through from the moment it is raised until it is closed.

1. New — the tester logs the defect.
2. Assigned — the lead assigns it to a developer.
3. Open — the developer starts working on it.
4. Fixed — the developer has made the change.
5. Retest — the tester re-runs the test case.
6. Closed — the fix is verified.

Other states: Rejected (not a bug), Deferred (fix pushed to a later release), Duplicate (already reported), Reopen (fix did not work).

Severity is how badly the defect affects the system — technical impact. Values: Critical, High, Medium, Low.

Priority is how urgently it should be fixed — business impact. Values: P1 (highest) to P4 (lowest).

Severity is set by the tester; priority is set by the business or product owner.

Boundary Value Analysis (BVA) tests the edges of an input range, because most defects occur at the boundaries. For a range 1–100, you test 0, 1, 2, 99, 100 and 101.

For an age field 18–60, BVA test values are 17 (invalid), 18 (valid), 19 (valid), 59 (valid), 60 (valid) and 61 (invalid). BVA finds off-by-one errors that internal values miss.

Equivalence partitioning divides input data into groups (partitions) where all values are expected to behave the same way. You test one value from each partition instead of every possible value.

For a "marks 0–100" field, the partitions are: below 0 (invalid), 0–100 (valid), above 100 (invalid). Three test cases cover the rule; testing every number from -1 to 200 would be a waste.

Exploratory testing is simultaneous learning, test design and execution. The tester does not follow pre-written test cases; they explore the application and design tests as they go.

It is useful when requirements are thin, when time is short, or when you want to find defects that scripted tests miss. Time-boxed exploratory sessions (say 60 minutes) with a clear charter produce the best results.

Alpha testing happens at the developer's site by internal teams before release to customers. It is controlled and followed by a formal bug report.

Beta testing happens at the customer's site after alpha, with real users in a real environment. Feedback is unstructured and often collected through a portal or survey.

Alpha catches bugs before users see them; beta catches environment and real-usage issues that internal testing cannot reproduce.

UAT is the final testing phase where the end user or client validates that the product meets their business requirements and is ready for production.

UAT is done in a UAT environment with real or realistic data. There are two common types: alpha UAT at the vendor's site and beta UAT at the customer's site. The outcome is a formal sign-off.

• Error — a mistake a human makes while writing code, reviewing a requirement or entering data. Example: developer writes if (age > 18) instead of if (age >= 18).
• Defect — the flaw in the software that results from the error. Example: 18-year-old users are rejected at signup.
• Bug — the defect as observed by the tester or user. Example: "A user aged exactly 18 cannot register."

Error is the cause, defect is the flaw, bug is the visible symptom.

Test closure is the final phase of STLC. The team confirms that all planned tests have run, all critical defects are closed, and the exit criteria are met.

Deliverables usually include a test summary report, metrics (defects by severity, test execution status, defect leakage), lessons learned, and archived test artifacts for the next release.

A decision table lists combinations of input conditions and the expected action for each combination. It is used when business rules depend on several conditions together — for example, loan approval based on age, income and credit score.

It makes coverage visible: every rule has at least one test, and there are no untested combinations.

Entry criteria are the conditions that must be true before testing starts. Example: requirements signed off, test cases ready, environment available, build deployed and smoke passed.

Exit criteria are the conditions that must be met before testing is considered done. Example: 100% of critical test cases executed, 95% pass rate, no open critical defects, and UAT sign-off.

Both should be written in the test plan. They remove opinion from "are we ready to test?" and "are we ready to release?".

• Test case execution status — pass, fail, blocked, not run.
• Defect density — defects per module or per 1,000 lines of code.
• Defect removal efficiency — defects found in testing vs defects found after release.
• Defect leakage — defects that reached production that testing should have caught.
• Defect age — time from defect raised to defect closed.
• Test coverage — requirements covered by test cases, from the RTM.
• Pass rate — percentage of executed tests that passed.

Metrics should drive decisions, not just fill a status report. High defect leakage means the test design or the coverage has a gap.

Defect leakage (also called escape rate) is the number of defects found in production that should have been caught during testing, usually expressed as a percentage of total defects.

A high leakage rate points to gaps in coverage, weak test data, a rushed regression, or a missed scenario. Tracking it helps the team improve test design over time.

Agile testing means testing is continuous and collaborative, not a phase at the end. Testers work with developers and the product owner to define acceptance criteria, review design and test throughout the sprint.

Scrum roles:

• Product Owner — prioritises the backlog and defines value.
• Scrum Master — removes blockers and facilitates the process.
• Development team — includes testers, who build quality in.

Scrum ceremonies:

• Sprint planning — pick and estimate work for the sprint.
• Daily stand-up — 15 minutes, blockers and progress.
• Sprint review — demo the increment to stakeholders.
• Sprint retrospective — improve the process for the next sprint.
• Backlog refinement — prepare upcoming stories.

Shift-left testing means starting testing activities earlier in the delivery cycle — during requirements and design, not after coding.

Examples of shift-left activities:

• Reviewing user stories for testability before development.
• Writing acceptance criteria with the product owner.
• Testers pairing with developers on unit and integration tests.
• Running automated tests in CI on every commit.

Defects found earlier cost far less to fix than defects found in production.

API testing sends requests directly to the service layer and checks the response — status code, body, headers, schema and timing — without going through the browser.

Most teams test at the API layer first because it is faster and more reliable, then keep a focused set of UI tests for critical journeys.

Testers use SQL to verify data and set up test scenarios. The most common patterns:

-- verify a record exists
SELECT * FROM users WHERE email = 'ravi@example.com';

-- count records by status
SELECT status, COUNT(*) FROM orders GROUP BY status;

-- join two tables
SELECT o.id, u.email
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at >= '2026-10-01';

-- update test data
UPDATE users SET status = 'locked' WHERE email = 'ravi@example.com';

-- delete test data
DELETE FROM users WHERE email LIKE 'test_%@example.com';

Focus on SELECT with WHERE, GROUP BY and JOIN. UPDATE and DELETE are used only in test environments. LIMIT works on MySQL and PostgreSQL; SQL Server uses TOP.

In a CI/CD pipeline, testing is automated and triggered on every commit or pull request. The pipeline typically runs:

1. Unit tests — seconds, on every commit.
2. API tests — minutes, on every merge.
3. Smoke UI tests — critical journeys, per merge.
4. Full regression — nightly or before release.

A red pipeline blocks the merge. Testers work with DevOps to keep the suite fast and stable — slow or flaky tests get skipped, which defeats the purpose.

Automate when:

• The test runs repeatedly — regression, smoke, data-driven checks.
• The scenario is stable and unlikely to change every sprint.
• The test is tedious or error-prone for a human.
• You want fast feedback in CI.

Keep manual when:

• The value comes from human judgement — exploratory, usability, visual design.
• The feature is still changing every sprint.
• The test runs once or twice and never again.
• Automation cost exceeds the long-term benefit.

Aim for a healthy test pyramid — many unit tests, a solid API layer, and a focused UI suite for critical journeys.

1. Try to reproduce it again with the exact same build, environment and data recorded in the bug report.
2. Check the log for the timestamp of the failure. If the environment or data has changed, the defect may need the original conditions.
3. Record a screen capture — a video removes all doubt.
4. Share the exact steps, data and build number with the developer. Often they are using a different build or have cached data.
5. Escalate if the disagreement continues. A defect that cannot be reproduced is often a timing, data or environment issue — not a fake bug.

A test summary report is written at the end of a test cycle. It records:

• Scope and what was tested.
• Execution status — planned vs run vs passed vs failed vs blocked.
• Defects by severity — open, closed, deferred, rejected.
• Metrics — pass rate, defect density, defect leakage.
• Risks and open items.
• Recommendation — release, release with known issues, or do not release.

It is the document stakeholders read before signing off a release.

AI-assisted testing uses AI tools to help with testing tasks — not to replace testers. Common uses at a concept level:

• Test case generation — tools suggest test cases from user stories or requirements.
• Visual testing — AI compares screenshots and flags layout differences that pixel comparison would miss.
• Self-healing locators — automation tools update locators when the DOM changes.
• Defect triage — grouping similar defects and predicting severity.
• Test data generation — producing realistic, varied test data quickly.

A tester still decides what to test, what data to use, and whether a result is a real defect.

Common estimation techniques:

• Work breakdown — split testing into requirement analysis, test design, execution, regression and closure. Estimate each.
• Test case count — average time per test case (write + execute + retest) × number of cases. Add time for bug logging and retest.
• Function point or story point based — use past data: how many story points of testing did the last release need?
• Three-point estimation — optimistic, most likely, pessimistic for each task, then average.

Always add contingency for defect retests, environment issues and scope changes. Historical data from previous releases is the best input.

The regression suite should be the smallest set of tests that gives confidence the release did not break existing functionality.

Selection criteria:

• Business critical paths — login, checkout, payment, signup.
• Recently changed areas — where development work happened.
• High-risk modules — where past defects clustered.
• Integration points — between modules, services and third parties.
• Data-heavy features — where a small change can have wide impact.

Review the suite each release. Tests that no longer add value should be removed — a bloated suite runs slowly and gets skipped, which is worse than no regression at all.

1. Ask the product owner and business analyst — clarify the intent, not just the wording.
2. Look at the existing system — how is a similar feature implemented elsewhere? That often reveals the expected behaviour.
3. Write assumptions down in the test plan or a shared document and get them confirmed.
4. Use exploratory and session-based testing to cover what you cannot specify in advance.
5. Raise a defect against the requirement if the ambiguity leads to a production risk.

Documenting assumptions is critical — it turns an unclear requirement into a tested contract.

1. Assess impact — is the defect in a critical path? How many users are affected?
2. Document workarounds — if the defect can be lived with, and the workaround is clear, the release can proceed.
3. Escalate the decision — the product owner or business sponsor decides whether to release with known issues. QA provides the risk; it does not take the business decision alone.
4. Get formal sign-off — written confirmation that the business accepts the known issues.
5. Plan the fix — a defined release for the fix, with a regression plan.

A tester's job is to make the risk visible, not to hide it and not to take the release decision single-handedly.

• Use a sandbox — most payment, SMS and KYC providers give a test environment with test keys.
• Stub or mock the service — for unit and integration tests, replace the third-party call with a mock that returns predictable responses.
• Test the failure modes — timeout, 4xx, 5xx, malformed response. What happens to the user's order if the payment gateway returns 500?
• Contract tests — verify the request and response shape matches what the provider expects.
• Test in production-like conditions before release — sandbox behaviour sometimes differs from production.

Testing is never "complete" — you stop when the risk of releasing is acceptable. Practical signals:

• All critical and high-priority test cases executed with a defined pass rate.
• No open critical or high-severity defects.
• Exit criteria from the test plan are met.
• Defect discovery rate is falling — new runs are finding fewer new defects.
• Risk areas have been covered and the business accepts residual risk.

The decision is based on risk, not on running out of test cases.

• Pairing — sit with juniors while they design tests, and review their test cases constructively.
• Teach test design — equivalence partitioning, BVA, decision tables and scenario writing. These are transferable skills.
• Bug report review — feedback on severity, priority and clarity. A good bug report saves hours of developer time.
• Domain knowledge sharing — walk them through the business flow, not just the screens.
• Exposure to automation and API testing — build a path from manual to technical testing.
• Retrospective feedback — discuss coverage and misses openly, without blame.

Risk-based testing means you prioritise testing effort by risk — the higher the impact and the higher the chance of failure, the more testing that area gets.

Applying it:

1. List features and modules.
2. Score each on impact (business, financial, legal) and likelihood (complexity, change frequency, defect history).
3. Multiply to get a risk score.
4. Allocate more test time and more test depth to high-risk areas; keep low-risk areas on smoke coverage.

Risk-based testing is how you test thoroughly without testing everything.

• Link test cases to requirements via the RTM. When a requirement changes, the affected test cases are visible immediately.
• Review test cases each sprint during backlog refinement for upcoming stories.
• Version control test cases in the same repository as code where possible (Git, test management tool with history).
• Retire obsolete cases — a test case for a removed feature costs time every regression run.
• Automate what is stable so the manual test case list stays small and current.

1. Capture the traffic — use browser DevTools, Postman interceptor or a proxy like Charles or Fiddler to observe the calls the front end makes.
2. Inspect the response shape — the fields, the data types, the status codes.
3. Talk to the developer — ask for the endpoint list, required headers, auth method and known error codes.
4. Probe common patterns — GET by id, list with pagination, POST to create, PUT/PATCH to update, DELETE to remove.
5. Test boundary and error cases — missing auth, wrong content type, invalid body, non-existent id, oversized payload.
6. Document what you find — that becomes the API test reference for the team.

• Fault — an incorrect step, process or data definition in the code. It is the defect in the software. Example: the boundary check uses > instead of >=.
• Failure — the observable deviation from expected behaviour when the faulty code executes. Example: an 18-year-old user cannot register.
• Defect — the term used to describe the fault as recorded in a bug tracker. Defect and fault are often used interchangeably.

A fault does not always cause a failure — it may be on a code path that never executes. A failure is the visible symptom.

Selection criteria, roughly in order of importance:

• Fit with the team's process — does it support the test case, execution and defect workflow the team already uses?
• Integration — JIRA, CI/CD, automation frameworks, version control.
• Reporting — dashboards, traceability, metrics without manual Excel work.
• Cost and licensing — per-user fees add up in large teams.
• Migration effort — how much data and process has to be moved from the current tool?
• Team adoption — a tool the team will not use has zero value.

Common choices in Indian teams: JIRA with Zephyr or Xray, TestRail, Azure Test Plans and qTest.

Step 1 — Reproduce the defect with a clear, minimum set of steps. Confirm it is not a false positive.

Step 2 — Assess impact — how many users, how critical is the affected flow, is there a workaround?

Step 3 — Report immediately to the release manager and product owner with the severity, priority and impact.

Step 4 — Check whether the fix can be small and safe. If yes, get it in, then run retest and a focused regression around the changed area.

Step 5 — If the fix is risky, do not block the release on your own. Escalate the decision — the business decides whether to release with the known issue.

Step 6 — Document the outcome and add a test case so the same defect is caught earlier next time.

Step 1 — List the critical paths and rank by risk. What breaks the business if it fails?

Step 2 — Focus on positive flows for the top scenarios, then add the highest- value negative cases. Skip low-risk edge cases.

Step 3 — Use exploratory testing for the remaining time — it covers more ground than writing detailed cases for every path.

Step 4 — Reuse automated regression for existing functionality instead of retesting manually.

Step 5 — Document what you did not test and why, in the test summary. The stakeholder decides whether to accept the risk.

Step 1 — Do not argue. Compare environments: OS, browser version, database version, config file, build number.

Step 2 — Share the exact test steps, test data and a screen recording of the failure.

Step 3 — Ask the developer to reproduce on the test environment with the same data, not on their local machine.

Step 4 — Check for cached data, local configuration overrides, or an environment-specific feature flag.

Step 5 — If the behaviour differs and the code is identical, the difference is environmental. The defect is real and the environment needs fixing.

Step 1 — Do a root cause analysis. Was the scenario not covered, the test data wrong, or the test skipped under time pressure?

Step 2 — Identify the gap — no test case, test case not executed, or executed against a different build.

Step 3 — Add the missing test case to the suite so the defect is caught next time.

Step 4 — Check whether the same gap exists in related features. A single missed defect often signals a pattern.

Step 5 — Share the learning in the retrospective. Focus on the process gap, not on blaming the tester.

Cover these categories:

• Positive — valid email and password, correct redirect, session created.
• Negative — wrong password, unregistered email, blank fields, invalid email format.
• Boundary — minimum and maximum allowed password length, email length.
• Security — SQL injection in email, XSS in input, HTTPS enforced, password masked, no credentials in URL.
• Account state — locked account, disabled account, first-time login, password expired.
• UI/UX — tab order, Enter key submits, error messages clear, "show password" works.
• Session — "Remember me" persists correctly, logout clears the session, back button does not expose a logged-in page.

The practical round below shows eight test cases for a login page in table form.

Add to cart — single item, multiple items, same item twice (quantity updates), out-of-stock item, item removed while in cart.

Cart view — items, quantity, unit price, subtotal, tax, shipping, discount, grand total. Recalculate after every change.

Update and remove — change quantity, remove item, remove all, cart empty state.

Persistence — cart survives page refresh, browser close, and login on another device.

Checkout — guest vs logged-in, address selection, coupon, payment, order confirmation, inventory reduced, email sent.

Edge cases — quantity 0, negative quantity, very large quantity, currency rounding, expired coupon.

Failure types to test:

• Insufficient funds
• Card expired
• Wrong CVV
• 3-D Secure authentication failed
• Payment gateway timeout
• Network dropped mid-transaction

Expected behaviour for each failure:

• A clear error message that does not expose card details.
• The user stays on the payment page — cart is not cleared.
• No order is created in the database, or it is created in a "failed" state.
• No money is debited; if debited, an automatic refund is triggered.
• A retry option is available.
• The failure is logged for support.

Always test the double-submit scenario — the user clicking Pay twice must not create two orders.

Step 1 — Compare data volume. Production has more data; a query that is fast on 1,000 rows may be slow on 10 million.

Step 2 — Compare infrastructure. Production may have more traffic, different server sizes, or a CDN that staging does not.

Step 3 — Check third-party calls — analytics, payment gateway, CDN — that may be slow or blocked in production.

Step 4 — Use browser DevTools and server logs to find the actual bottleneck — backend, database, network or front-end rendering.

Step 5 — Escalate with the evidence. Slow production pages are a real performance defect, not a staging issue.

Step 1 — Classify fields: text, number, date, email, phone, dropdown, checkbox, radio, file upload.

Step 2 — For each type, write a small reusable set: valid, blank, wrong format, boundary values, special characters.

Step 3 — Test field-level validation first — the error appears, focus goes to the field, message is clear.

Step 4 — Test form-level validation — submit with multiple invalid fields, check the messages and that the form does not submit.

Step 5 — Test positive flow — all valid inputs, form submits, data saved correctly in the database.

Step 6 — Test cross-field rules — password confirmation matches, end date after start date, at least one contact method selected.

Step 7 — Test UI/UX — tab order, Enter submits, autofill, mobile keyboard type per field.

Step 1 — Capture the CI screenshot and logs from the failing step. Compare against the local run.

Step 2 — Check the environment — URL, database, credentials and feature flags in CI vs local.

Step 3 — Check for timing issues. CI machines are slower; wait for the element instead of a fixed sleep.

Step 4 — Check viewport size. Headless CI browsers may render differently, which changes which elements are visible.

Step 5 — Check for parallel execution conflicts — shared data, shared sessions or shared browser instances between tests.

Step 6 — Reproduce the CI environment locally (same Docker image, same headless mode) to close the gap.