Manual Testing — 30 Interview Questions (Answers & Examples)¶
Cover the answer with your hand, read the question, and say it aloud. The bold words are exactly what the interviewer is listening for — hit those and the rest is just support.
Q1. What is Software Testing?¶
Software Testing is the process of evaluating an application to verify that it meets the specified requirements and to detect defects before it reaches the end user. In plain words: it's checking whether the software does what it's supposed to do, and doesn't do what it isn't. It has two goals — demonstrating the software works for valid cases (building confidence), and finding where it breaks for invalid or unexpected ones. For example, on a login page I test that correct credentials log the user in, and also that wrong credentials show a proper error instead of crashing. Testing reduces risk and builds confidence, but it can never prove software is 100% bug-free.
Q2. What is the difference between Verification and Validation?¶
Verification asks "Are we building the product right?" (reviewing work against specs, no code execution), while Validation asks "Are we building the right product?" (actually running the software to check it meets user needs).
| Verification | Validation |
|---|---|
| Are we building it right? | Are we building the right thing? |
| Static — reviews, walkthroughs, inspections | Dynamic — actual test execution |
| Done on documents/design/code | Done on the running application |
| Catches defects early, cheaply | Catches defects the user would feel |
In plain words: verification is checking the blueprint; validation is checking the finished house. Example: verifying a login page means reviewing the design doc to confirm the "Forgot Password" link is specified; validating it means clicking that link in the live app and confirming the reset email arrives. Remember: Verification = static/documents, Validation = dynamic/execution.
Q3. What is the SDLC and what is its role in testing?¶
SDLC (Software Development Life Cycle) is the structured sequence of phases — requirements, design, development, testing, deployment, and maintenance — that a software product moves through from idea to release. In plain words: it's the full roadmap of how software gets built and shipped. Testing's role is that it isn't a single late phase — following the "shift-left" idea, testers get involved from the requirements phase onward, reviewing specs and designs so defects are caught early when they're cheapest to fix. For example, if I review requirements for an e-commerce checkout and spot that "guest checkout" is missing, fixing that at the requirement stage costs almost nothing versus finding it after release.
Q4. What is STLC (Software Testing Life Cycle)?¶
STLC is the sequence of testing-specific phases followed to plan, design, and execute testing in a structured way. In plain words: it's the SDLC for the testing side. Its phases are: Requirement Analysis, Test Planning, Test Case Design, Test Environment Setup, Test Execution, and Test Closure. Each phase has entry and exit criteria and clear deliverables — for example, Test Case Design produces test cases and the traceability matrix. For an e-commerce checkout, I'd analyze the requirements, plan scope and risk, write the test cases, set up the test environment, execute, log defects, and finally do closure with a summary report and lessons learned.
Q5. What are the different levels of testing?¶
The four main levels are Unit Testing, Integration Testing, System Testing, and Acceptance Testing, moving from the smallest piece of code up to the whole product from the user's view. In plain words: we start tiny and zoom out. Unit tests a single function or component (usually by developers); Integration tests that modules talk to each other correctly; System tests the complete, integrated application against requirements; Acceptance (UAT) confirms the business/customer is happy to accept it. For a banking app: unit tests the "calculate interest" function, integration tests that the transfer module calls the balance module, system tests an end-to-end fund transfer, and UAT is the client confirming the whole flow meets their needs.
Q6. What is the difference between Functional and Non-Functional Testing?¶
Functional Testing checks what the system does (features and behavior against requirements), while Non-Functional Testing checks how well the system does it (performance, security, usability, etc.).
| Functional | Non-Functional |
|---|---|
| Tests what the system does | Tests how well it does it |
| Based on functional requirements | Based on quality attributes |
| E.g. login, checkout, fund transfer works | E.g. speed, load, security, usability |
| Answer is pass/fail on a feature | Answer is measured against a benchmark |
In plain words: functional is "does the button work?"; non-functional is "does it still work with 10,000 users hammering it?" Example: functionally testing an ATM transfer confirms money moves between accounts; non-functionally testing it checks the transfer completes within 3 seconds and can't be exploited by a security attack.
Q7. What is the difference between Regression and Retesting?¶
Retesting re-runs the exact same test on a defect that was reported fixed to confirm the fix works; Regression testing re-runs other tests around the change to confirm nothing else broke.
| Retesting | Regression Testing |
|---|---|
| Confirms a specific bug is fixed | Confirms nothing else broke |
| Same test, same data, on the fixed defect | Broader set of existing tests |
| Only for failed test cases | For passed/related areas too |
| Cannot be automated blindly (needs the fix) | Ideal candidate for automation |
In plain words: retesting is "is this exact bug gone?"; regression is "did fixing it accidentally break my working features?" Example: a bug let negative amounts through on a fund transfer. Retesting = try that negative amount again and confirm it's now blocked. Regression = re-check that valid transfers, balance display, and transaction history still work. Remember: Retest = same bug; Regression = surrounding features.
Q8. What are Positive and Negative Testing?¶
Positive Testing verifies the system works correctly with valid inputs; Negative Testing verifies the system handles invalid inputs gracefully without crashing. In plain words: positive is "does it work when I do the right thing?"; negative is "does it fail nicely when I do the wrong thing?" Both are essential — a login that accepts valid credentials but crashes on a wrong password is only half-tested. Example on an age field that accepts 18–60: positive testing enters 25 and expects acceptance; negative testing enters 5, 70, "abc", or leaves it blank and expects a clear validation error rather than a crash.
Q9. What is the difference between Severity and Priority?¶
Severity is the impact of the defect on the system's functionality; Priority is the order/urgency in which it should be fixed.
| Severity | Priority |
|---|---|
| Impact on the system | Urgency of the fix |
| Set by the tester | Set by product/business |
| Technical measure | Business measure |
| High severity, low priority possible | And vice versa |
In plain words: severity = how bad the damage is; priority = how soon we care. They're independent. Example: a spelling mistake in the company name on the homepage is low severity (nothing breaks) but high priority (embarrassing, customer-facing, fix now). A crash in a rarely used admin report is high severity (feature dead) but low priority (almost nobody uses it). Remember: Severity = impact on the system; Priority = order of fixing.
Q10. What is a Test Case? What are its components?¶
A Test Case is a set of conditions, inputs, and expected results designed to verify a specific feature or requirement. In plain words: it's a step-by-step recipe that tells anyone exactly how to test one thing and what "correct" looks like. Its core components are: Test Case ID, Title/Description, Preconditions, Test Steps, Test Data, Expected Result, Actual Result, and Status (Pass/Fail). For example, a login test case has ID TC_Login_01, precondition "user is registered", steps to enter valid email/password and click Login, test data (a valid account), and expected result "user lands on the dashboard." A good test case is clear enough that a new tester could run it without asking questions.
Q11. What is a Test Plan and what does it include?¶
A Test Plan is a formal document that describes the scope, approach, resources, schedule, and objectives of the testing effort for a project. In plain words: it's the master strategy document that answers what we'll test, how, who does it, and by when. It typically includes: scope (in-scope/out-of-scope), test objectives, test strategy and types, entry and exit criteria, environment and tools, roles and responsibilities, schedule, and risks with mitigation. For an e-commerce release, the test plan would state that checkout and payment are in scope, performance testing is out of scope this cycle, list the browsers to cover, and define when testing is considered "done." It's usually owned by the Test Lead or QA Manager.
Q12. What are the different types of testing? (Smoke, Sanity, Ad-hoc, Exploratory)¶
These are lightweight test types used at different moments: Smoke checks the build is stable enough to test, Sanity checks a specific fix or area, Ad-hoc is unplanned random testing, and Exploratory is simultaneous learning-and-testing. In plain words: smoke is "is the build even alive?", sanity is "does this one area work after a change?", ad-hoc is "let me poke it randomly", exploratory is "let me investigate as I go." Smoke testing on an e-commerce site quickly confirms login, search, add-to-cart, and checkout all open — if any fails, the build is rejected before deeper testing. Sanity testing after a discount-code bug fix just checks the promo flow. Exploratory testing is structured curiosity: I set a goal, explore the feature, and design tests on the fly based on what I find.
Q13. What is Boundary Value Analysis (BVA)?¶
Boundary Value Analysis is a black-box technique that tests the values at the edges of an input range, because defects most often hide at boundaries. In plain words: bugs love the edges, so we test right at and around them. For a range, we test min-1, min, min+1, max-1, max, and max+1. Example: for an age field that accepts 18–60, BVA tests 17 (invalid), 18 (valid), 19 (valid), 59 (valid), 60 (valid), and 61 (invalid) — this quickly catches off-by-one mistakes like a developer coding age < 18 versus age <= 18. Remember: BVA = the edges (min-1, min, min+1 … max-1, max, max+1).
Q14. What is Equivalence Partitioning?¶
Equivalence Partitioning is a black-box technique that divides input data into valid and invalid classes (partitions), assuming all values in a class behave the same, so we test just one value per class. In plain words: instead of testing every number, we group them and test one representative from each group to save effort without losing coverage. Example: for an age field accepting 18–60, the partitions are: below 18 (invalid), 18–60 (valid), above 60 (invalid), and non-numeric (invalid). We pick one value from each — say 10, 30, 75, and "abc" — instead of testing all possible values. Remember: EP = one value per valid/invalid class; it pairs perfectly with BVA (EP picks the group, BVA hits its edges).
Q15. What is the difference between Static and Dynamic Testing?¶
Static Testing examines the software without executing it (reviewing documents and code), while Dynamic Testing executes the software to observe its behavior.
| Static Testing | Dynamic Testing |
|---|---|
| Code is not executed | Code is executed |
| Reviews, walkthroughs, inspections | Running test cases on the app |
| Done early (docs, requirements, code) | Done after build is available |
| Finds defects in documents/logic | Finds defects in behavior/output |
In plain words: static is reading and reviewing; dynamic is running and observing. Example: statically testing a login feature means reviewing the requirement doc and code for the password rules; dynamically testing it means actually typing credentials into the live page and checking the result. Static catches issues cheaply and early; dynamic catches what only shows up at runtime.
Q16. What is the Defect Life Cycle?¶
The Defect Life Cycle is the set of states a bug moves through from discovery to closure. In plain words: it's the journey of a bug from "found" to "gone." The typical states are: New → Assigned → Open (being fixed) → Fixed → Retest → Verified → Closed, or Reopened if the retest fails (which loops the bug back to the developer). Along the way a defect can also be Rejected (not a valid bug), Duplicate, or Deferred (valid but fixed later). For example, I log a defect on a broken checkout (New); the lead assigns it to a developer (Assigned/Open); they fix it (Fixed); I retest it (Retest); it works, so I mark it Verified and Closed — but if it still failed I'd mark it Reopened. If it were a repeat of a known issue, it'd be marked Duplicate instead. Remember: "Retest" is a tester activity; the states an interviewer listens for are Verified/Closed on pass and Reopened on fail.
Q17. What is a Traceability Matrix?¶
A Requirements Traceability Matrix (RTM) is a document that maps each requirement to its corresponding test cases to ensure every requirement is covered by testing. In plain words: it's a checklist that proves nothing was missed, linking "what the customer asked for" to "what we tested." It maps requirements → test cases → defects, so coverage gaps become obvious. For an e-commerce project, the RTM would show that requirement REQ-05 "apply discount code at checkout" is linked to test cases TC-20 and TC-21 — if a requirement has no linked test case, that's an immediate red flag that it's untested. It also helps with impact analysis when a requirement changes.
Q18. How do you prioritize test cases?¶
I prioritize test cases based on risk, business impact, and usage frequency — testing the most critical and most-used functionality first. In plain words: I test what would hurt the most if it broke, and what customers touch the most. My factors are: core business flows (payment, login), high-risk or recently changed areas, features with a history of defects, and customer-facing/high-traffic paths. For an e-commerce site with limited time, I'd rank checkout and payment above the "About Us" page, because a broken checkout directly loses revenue. I'd also fold in any defect-prone modules that developers flag as risky.
Q19. What is Risk-Based Testing?¶
Risk-Based Testing is an approach that prioritizes testing effort on the features with the highest risk — those most likely to fail and most damaging if they do. In plain words: we spend our limited time where a failure would hurt the most. Risk is judged by two factors: likelihood of failure and impact of failure. Features that score high on both are tested first and most thoroughly. For a banking app, the fund-transfer and authentication modules are high-risk (financial and security impact), so they get deep testing, while a rarely used "change theme color" setting gets minimal coverage. This ensures the most valuable testing happens even when time runs out.
Q20. What are Entry and Exit Criteria in testing?¶
Entry Criteria are the conditions that must be met before testing can begin; Exit Criteria are the conditions that must be met before testing is considered complete. In plain words: entry is "are we ready to start?"; exit is "are we done and safe to ship?" Entry criteria might include: requirements finalized, test cases reviewed, test environment ready, and a stable build deployed. Exit criteria might include: all planned test cases executed, no open critical/high defects, required coverage achieved, and the test summary report signed off. For an e-commerce release, I won't start until the build passes smoke testing (entry), and I won't sign off until every critical checkout bug is closed (exit).
Q21. What would you do if you find a bug in the production environment?¶
Here's how I'd handle it, calmly and in order. First, I'd stay composed and reproduce it to confirm it's real and understand the exact steps. Then I'd assess the impact and severity — how many users are affected, is data or money at risk — because that decides how loud I need to be. Next, I'd log a detailed defect with steps, screenshots, environment, and logs, and immediately notify the right people — the lead, developer, and if it's critical, escalate right away rather than sitting on it. I'd suggest a workaround for users if one exists while the fix is being worked on. Finally, once it's fixed, I'd retest in production, run regression on nearby areas, and do a root-cause review so we understand why our pre-release testing missed it and add a test case to prevent a repeat.
Q22. How do you handle missing requirements or unclear documentation?¶
I treat ambiguity as something to resolve early, not a blocker. First, I'd go back to the source — the Business Analyst, Product Owner, or client — and ask specific questions rather than assuming. If I can't get answers immediately, I'd look at reference points: similar existing features, older versions of the app, wireframes, or industry standards for how that feature normally behaves. I'd document my assumptions clearly and share them so anyone can correct me before I test on the wrong premise. In the meantime, I'd start exploratory testing to learn how the feature actually behaves, which often surfaces the very questions that need answering. And I'd raise the gap in stand-up or the requirement review so it's fixed at the source, not just worked around by me.
Q23. If the developer is not agreeing with your bug, what will you do?¶
I keep it professional and evidence-based — it's never personal. First, I'd make sure the bug is reproducible and re-verify it myself, so I'm confident it's real. Then I'd share clear proof: exact steps, test data, screenshots, a screen recording, and logs, so there's nothing to argue with. I'd tie it back to the requirement or acceptance criteria — "the spec says the age field should reject 17, and it's accepting it" — because that shifts it from opinion to fact. If we still disagree, I'd discuss it calmly, maybe pair on it live, since sometimes it's an environment or data difference. And if we genuinely can't reach agreement, I'd escalate to the lead or BA to make the call — not to win, but to let the person who owns the requirement decide. Throughout, I stay respectful; the goal is a quality product, not being right.
Q24. How do you report a bug effectively?¶
An effective bug report is clear, reproducible, and complete enough that a developer can fix it without asking me anything. In plain words: the report should tell the whole story on its own. I include: a concise, specific title; steps to reproduce; expected vs actual result; test data and environment (browser, OS, build version); severity and priority; and evidence like screenshots, videos, or logs. For example, instead of "login broken," I'd write "Login fails with valid credentials on Chrome 120 — Build 2.3: after entering a valid email/password and clicking Login, a 500 error appears; expected: redirect to dashboard," with a screenshot attached. A good report saves round-trips and gets the bug fixed faster.
Q25. Have you ever participated in a requirement review meeting? What was your role?¶
Yes, and I see it as one of the highest-value things a tester does. In those meetings, my role is to review the requirements from a testing and end-user perspective before a single line of code is written. I'd look for ambiguity, missing scenarios, and untestable statements — for example, flagging a requirement that says "the system should be fast" and asking, "fast meaning what — under 2 seconds?" I'd ask about edge cases and negative flows the requirement doesn't mention, like what happens on an e-commerce checkout when a discount code is expired. I'd also start forming my test scenarios and note testability concerns so I'm ready when development finishes. This is the shift-left principle in action — catching a defect in a requirement is far cheaper than catching it in production.
Q26. What will you do if you have limited time to test?¶
When time is tight, I get ruthless about priorities. First, I'd apply risk-based testing — focus on the critical, high-impact, and most-used features first, like payment and login, and deprioritize low-risk areas. I'd run smoke and sanity tests to confirm the core flows are stable before going deeper. I'd use techniques that maximize coverage with fewer tests, like equivalence partitioning and boundary value analysis, instead of exhaustively testing every input. I'd lean on any existing automation for regression to free up my manual time for the risky new areas. And critically, I'd communicate clearly with stakeholders about what was tested, what wasn't, and the residual risk — so the go/no-go decision is made with eyes open, not blindly.
Q27. How do you perform exploratory testing?¶
Exploratory testing is simultaneous learning, test design, and execution — I explore the application while designing tests on the fly based on what I discover. In plain words: I investigate the app like a curious user, and each thing I learn shapes my next test. I usually work in a time-boxed session with a charter — a clear goal like "explore the checkout discount flow for 45 minutes." As I go, I take notes on what I try, what I observe, and any anomalies, and I follow interesting threads — if a discount code behaves oddly, I dig into expired, stacked, and case-sensitive variations. It's not random; it's structured curiosity guided by my domain knowledge and risk sense. It's especially valuable when requirements are thin or when I want to find defects that scripted test cases would never think to try.
Q28. How do you ensure 100% test coverage?¶
I ensure coverage by systematically mapping every requirement to test cases and using coverage techniques, though I'm honest that "100%" means covering all requirements and key paths, not literally every input. In plain words: I make sure nothing in the spec goes untested. I use a Requirements Traceability Matrix to link each requirement to test cases so gaps are visible. I apply equivalence partitioning and boundary value analysis to cover input ranges efficiently, and I cover both positive and negative scenarios. I also consider code and branch coverage metrics with the dev team where relevant. For an age field 18–60, "full coverage" means valid, invalid-low, invalid-high, boundaries, and non-numeric inputs — all requirement-driven scenarios covered, even though testing every possible number is impossible.
Q29. How do you test without requirements or documentation?¶
I've been in this spot, and I don't let the absence of docs stop me. First, I'd gather knowledge from whatever sources exist — talk to the BA, developers, or product owner, look at the actual application behavior, and check any older version, emails, or user stories. Then I'd rely on exploratory testing to learn the app hands-on and build a mental model of how it should work. I'd apply domain knowledge and common sense — a login page, a checkout, or an ATM flow all have well-understood expected behaviors, so I test against those industry norms. I'd document my findings and assumptions as I go, effectively creating the missing documentation, and share it for confirmation. So the requirements become the baseline for the future while I keep testing in the present.
Q30. What are some common challenges you face during testing?¶
Common challenges include unclear or changing requirements, tight timelines, unstable test environments, and late or incomplete builds. In plain words: most testing problems come from things outside the test itself. Requirements that are ambiguous or shift mid-cycle make it hard to know what "correct" is; compressed schedules force tough prioritization; flaky environments and test data issues waste time and cause false failures; and getting builds late squeezes the testing window. There's also the human side — developers disagreeing on bugs, or pressure to sign off before quality is truly ready. I handle these by communicating early, applying risk-based prioritization, documenting assumptions, and keeping evidence-based, professional conversations so quality doesn't get quietly sacrificed to the deadline.