Manual testing interviews test something automation questions don't — whether you can reason about a system's behavior on the spot, without a script telling you what to check next. Interviewers mix textbook definitions (STLC, the defect life cycle, black-box vs. white-box) with judgment calls like when to stop testing or how to test without documentation, because that's the actual job. This covers all 55 questions, organized by experience level, with a table or diagram wherever a bare paragraph would bury the comparison.
Manual Testing Basics
Q1. What is manual testing, and why is it still relevant?
Manual testing is a tester walking through the application by hand, the way an actual user would, without a script driving the browser or asserting the result. It's slower and more exposed to human inconsistency than automation, but it's still the only realistic way to judge usability, look-and-feel, and accessibility — a script can confirm a button exists, not that it feels right to click. The standard order is manual first, automate what's worth automating second, because a test needs to be stable and understood before it's worth hardening into a script.
Q2. What are the advantages and disadvantages of manual testing?
Manual testing earns its keep on short-lived projects and loses it fast once a suite grows — the trade-offs run pretty symmetric between the two lists below.
- Cheap and fast to start on a short-lived or one-off check — no framework to build first
- The only reliable way to judge usability, accessibility, and general look-and-feel
- Well suited to exploratory and ad hoc testing, where the next step depends on what you just saw
- A test change is just a wording change in a spreadsheet — no code to update
- Catches awkward, judgment-heavy edge cases that are hard to encode as assertions
- Low barrier to entry — no programming background required to get started
Where it runs out of road:
- Doesn't scale to large regression suites — re-running everything by hand after every change is slow and error-prone
- More exposed to human error and inconsistency between testers and sessions
- Impractical for load or performance testing, which needs simulated concurrent traffic
- Costs more over the long run once a project outlives a handful of releases
Q3. What tools are commonly used to support manual testing?
- Postman / Insomnia — exercising API endpoints and inspecting responses by hand
- A SQL client (DBeaver, pgAdmin) — verifying the database actually reflects what the UI claims
- Message-queue monitors — confirming a message was published and consumed correctly
- Browser dev tools — network tab, console, and DOM inspection during exploratory sessions
- Bug/test-case trackers (Jira, TestRail, Zephyr) — logging and tracking what was found
Q4. What are the different types of manual testing?
- Black-box testing — exercising the app through its inputs and outputs only
- White-box testing — testing with full visibility into the code itself
- Unit testing — one function or class in isolation
- Integration testing — multiple units wired together
- System testing — the whole product, end-to-end
- Acceptance testing — validating it against real business or user needs
Q5. What are the roles and responsibilities of a manual tester?
- Analyzing client and business requirements before a single test case gets written
- Reviewing code and design against the spec for obvious mismatches
- Setting up and maintaining the test environment
- Defining the QA strategy and test approach for the project
- Running review meetings to align testers, developers, and stakeholders
- Executing test cases and analyzing the results
- Logging, tracking, and verifying the fix for every defect found
- Monitoring the system for errors even outside scripted test runs
- Reporting status and risk up to the test manager
Q6. Walk through the manual testing process end-to-end.
The manual testing process, start to finish
Requirement analysis
What needs testing, and to what standard
Test planning
Scope, approach, resources, schedule
Test case design
Scenarios, data, expected results
Test execution
Run the cases, log defects as they surface
Exit evaluation
Check results against exit criteria
Test closure
Wrap-up report, lessons learned
Q7. What are the levels of manual testing?
| Level | What it actually checks |
|---|---|
| Unit testing | One function or class in isolation, usually by the developer who wrote it |
| Integration testing | That independently working units still behave correctly once wired together, with a focus on the interfaces between them |
| System testing | The complete, integrated product end-to-end — functional and non-functional both, including regression and usability |
| UAT | Whether the release is actually ready to ship, judged from the business or end user's perspective |
Q8. What skills does a good manual tester need?
- Precise, professional bug reporting — a vague report wastes everyone's time
- Strong analytical ability to spot what a requirement doesn't say
- Enough technical grounding to read logs, SQL, and basic API responses
- Comfort working inside an Agile/Scrum cadence
- Planning and tracking ability across a full test cycle
- Working knowledge of SDLC, STLC, and core testing techniques
- Familiarity with test management and defect-tracking tools like Jira, TestRail, or Zephyr
Q9. What is test coverage, and what are its main forms?
| Lens | What it measures |
|---|---|
| Product coverage | How much of the product's feature surface has actually been tested |
| Requirements coverage | How many documented requirements have at least one test mapped to them |
| Source code coverage | How much of the actual code executes during testing — a white-box, developer-driven metric |
Q10. What are the main code coverage methods?
- Statement coverage — has every line of code executed at least once
- Decision coverage — has every decision point (if/else) evaluated both ways
- Branch coverage — has every branch out of a control structure actually been taken
- Toggle coverage — has every signal toggled through both states, a term that shows up more in embedded/hardware testing
Q11. What is a latent defect?
A latent defect has been sitting in the system for a long time without anyone noticing it — it's usually low priority precisely because nothing has triggered it yet, and it tends to surface through code inspection rather than through normal test execution. It stays dormant until some unusual combination of input or environment finally exercises the broken path.
Q12. What attributes should a well-written test case include?
| Attribute | Purpose |
|---|---|
| Test Case ID | Uniquely identifies the test case |
| Test Summary | One-line description of what's being tested |
| Description / Precondition | What state the system must be in before running it |
| Test Steps | The exact actions to perform, in order |
| Test Data | The specific input values used |
| Expected Result | What should happen if the software is correct |
| Actual Result | What actually happened when it ran |
| Test Result | Pass or fail |
| Automation Status | Whether this case is automated, manual, or a candidate for automation |
| Date / Executed By | When it ran, and who ran it |
Q13. What's the difference between positive and negative testing?
| Positive testing | Negative testing | |
|---|---|---|
| Goal | Confirm the app does what it should with valid input | Confirm the app correctly rejects or handles invalid input |
| Typical check | Does a valid login succeed? | Does an invalid login show the right error, not a crash? |
| Why it matters | Proves the happy path actually works | Often where real production bugs hide — it's the easiest step to skip under deadline pressure |
Q14. What is User Acceptance Testing (UAT)?
User Acceptance Testing is the last checkpoint before release, run by or on behalf of the actual end user or client rather than the QA team. It only happens after the software has already passed unit, integration, and system testing — UAT isn't where you go looking for functional bugs, it's where you confirm the finished product actually satisfies the business need it was built for.
- Performed by end users, clients, or their representatives — not the dev/QA team
- The final gate before go-live, not an earlier sanity check
- Validates real end-to-end business processes, not isolated features
- Assumes the software has already passed every prior testing level
Q15. What's the difference between a test stub and a test driver?
| Test stub | Test driver | |
|---|---|---|
| Used in | Top-down integration testing | Bottom-up integration testing |
| Simulates | A lower-level module that isn't built yet — the "called" code | A higher-level module that isn't built yet — the "calling" code |
| Purpose | Lets the higher module under test run without its real dependency | Lets the lower module under test be exercised without its real caller |
Q16. What is localization testing?
Localization testing verifies that the software works correctly and feels natural within a specific locale — not just translated text, but date/number formats, currency, cultural conventions, and imagery that make sense for that audience. It still covers the same functionality and GUI checks as any other test pass, just re-run through the lens of a particular language and region.
Q17. What's the difference between baseline testing and benchmark testing?
| Baseline testing | Benchmark testing | |
|---|---|---|
| What it captures | A performance snapshot of the current build, as a reference point | How current performance compares against an industry-standard benchmark |
| Used for | Measuring improvement or regression against that snapshot over time | Comparing performance across releases or against competitors |
| Owned by | Testers, as part of non-functional testing | Developers and DBAs together |
Q18. What is fuzz testing?
Fuzz testing throws large volumes of random, malformed, or unexpected input at the application specifically to surface crashes, unhandled exceptions, and security loopholes that structured test cases would never think to try.
- Works best on larger, more mature codebases — small projects rarely justify the tooling overhead
- Pairs well with beta testing and black-box testing, since neither needs internal knowledge of the code
- Only reliably catches serious, crash-level faults — it's not a substitute for structured functional test design
Q19. What is configuration testing?
Configuration testing evaluates the software against a range of hardware, software, and network configurations to find the setup that gives the best performance and to catch compatibility issues before real users hit them — different OS versions, browsers, screen resolutions, and network conditions all count as configurations worth checking.
Q20. What are defect leakage ratio and defect reject ratio?
| Parameter | How it's calculated | What it tells you |
|---|---|---|
| Defect leakage ratio | Potential rejections ÷ total production defects | How many defects slipped past testing into production |
| Defect reject ratio | Total rejections ÷ total production defects | How many reported defects turned out not to be valid defects |
Q21. What is API testing?
API testing exercises an API directly at the message layer — no GUI involved — checking that requests and responses are reliable, functionally correct, performant, and secure. It's also a core part of integration testing, since it targets the business logic an API exposes rather than how that logic happens to be rendered on screen, which is exactly why it's one of the most automatable layers of testing.
Q22. What is use-case testing?
Use-case testing is a black-box technique that derives test cases from complete, real transactions — start to finish, from the end user's perspective — rather than from isolated functions. Instead of asking "does this field validate correctly," it asks "can a user actually complete this entire task," which tends to surface integration issues that per-field testing misses.
Q23. What is path testing?
Path testing uses a control-flow graph of the program to identify the set of linearly independent execution paths through it, then designs test cases to exercise each one. The goal is maximizing path coverage while avoiding redundant tests that just re-walk a path already covered — it's a white-box technique, so it assumes access to the code's actual logic.
Q24. What is endurance (soak) testing?
Endurance testing runs the system under a realistic, sustained load for an extended period — hours or days rather than minutes — specifically to catch problems that only show up over time, like memory leaks, connection-pool exhaustion, and gradual performance degradation that a short load test would never reveal.
- WebLOAD
- LoadUI
- OpenSTA
- LoadComplete
- Apache JMeter
For Experienced Testers
Q25. What is a testbed?
A testbed is the complete environment a test actually runs in — the OS, database, hardware, network configuration, the application under test itself, and whatever supporting tools or harnesses are wired in. Two testbeds that look identical on paper can still produce different results if something as small as a driver version or a timezone setting differs between them.
Q26. What's the difference between an error, a defect, and a bug?
| Error | Defect | Bug | |
|---|---|---|---|
| When it's found | During coding or compilation | Usually after release, during a later review | During the testing phase itself |
| What it actually is | A programming mistake that stops the code from compiling or running | A mismatch between what the software does and what it was specified to do | A fault affecting functionality or performance, caught by a tester before release |
| Who typically finds it | The developer, immediately | Whoever reviews the shipped behavior later | QA, during test execution |
Q27. What are the phases of the Software Testing Life Cycle (STLC)?
STLC — the fresher's manual testing process, formalized
Requirement analysis
What's testable, and what's ambiguous
Test planning
Strategy, scope, effort, tooling
Test case development
Cases, scripts, and test data
Environment setup
Configure the testbed itself
Test execution
Run cases, raise defects
Test cycle closure
Evaluate results, document, close out
Q28. What is black-box testing, in more depth?
Black-box testing exercises the application purely through its inputs and observable outputs, with zero visibility into how the code inside actually works.
- Performed from the end user's point of view — the same view an actual customer has
- Doesn't require any programming or implementation knowledge
- Good at surfacing real usability and requirement-mismatch issues, since it never gets distracted by internals
- Typically owned by QA and testers rather than developers
Q29. What is white-box testing, in more depth?
White-box testing is the opposite of black-box — full visibility into the source code, typically performed by the developers who wrote it, with the goal of exercising every meaningful branch of logic.
- Also called clear-box or glass-box testing — "closed-box" is a common mislabel; white-box is specifically the open, transparent end of the spectrum, not a closed one
- Requires programming knowledge and access to the implementation
- Enables branch, path, and statement coverage analysis that black-box testing simply can't do
- Usually run by developers as part of unit and integration testing
Q30. What makes a bug "critical"?
A critical bug blocks most or all of the application's functionality outright — testing effectively can't continue until it's fixed, because the broken path sits in the way of everything downstream. A login flow returning a server error on every attempt is a textbook example: nothing else in the app can even be reached to test it.
Q31. What is data flow testing?
Data flow testing is a structural technique that traces how a variable moves through a program's control flow — where it's defined, where it's used, and where it's eventually cleared — to catch a category of bugs that ordinary functional testing usually misses entirely.
- A variable declared but never used afterward
- A variable used before it's ever declared or assigned
- Memory deallocated before its last use
- A variable redefined multiple times before it's ever read
Q32. What does "quality" actually mean in testing?
Quality is genuinely subjective and shifts depending on who you ask. In general it means bug-free, delivered on time and budget, meeting the stated requirements, and easy to maintain going forward — but an end user weighs usability and reliability, while a finance stakeholder might weigh profitability and delivery cost more heavily. Part of a tester's job is knowing which definition matters most for the audience currently in the room.
Q33. What's the difference between QA and QC?
| Quality Assurance | Quality Control | |
|---|---|---|
| Focus | The process used to build the software | The finished product itself |
| When | Throughout development, proactively | After development, reactively |
| Goal | Make sure the process produces good software | Verify the shipped software actually meets the required standard |
| Typical activity | Defining standards, process audits, reviews | Testing, inspection, defect detection |
Q34. What's the difference between monkey testing and performance testing?
| Monkey testing | Performance testing | |
|---|---|---|
| Input style | Random, unstructured, no rules behind it | Structured, simulating real expected or peak load |
| Goal | Surface unexpected crashes from inputs no one thought to script | Measure speed, scalability, and stability under load |
| What it measures | Nothing quantitative — just pass/fail on crash | CPU/memory utilization, throughput, response time, TPS/QPS |
Q35. What role does documentation play in manual testing?
| Document | Purpose |
|---|---|
| Test Plan | The blueprint — what will be tested, when, by whom, and how |
| Test Scenario | A single testable condition or possibility, written from the end user's view, that test cases get derived from |
| Test Case | The detailed steps, data, and expected result for one specific scenario |
| Traceability Matrix | Maps every requirement to the test case(s) that cover it, so gaps are visible at a glance |
Q36. What is a Requirement Traceability Matrix (RTM)?
An RTM tracks and links every project requirement to its delivery artifacts and test cases, end to end — usually laid out as a simple table. It's the fastest way to prove coverage on demand and, just as importantly, the fastest way to spot a requirement that has quietly never been tested at all.
Q37. Why does testing matter so much in Agile development?
Agile testing weaves QA into every iteration rather than saving it for a dedicated phase at the end — testers work from the customer's perspective and test each feature as it's built, not after a backlog has piled up.
- Faster feedback — defects get caught and fixed while the context is still fresh
- Continuous, largely automated regression as new code lands
- Closer day-to-day collaboration between testers and developers
- Lower overall cost, since bugs are cheaper to fix the earlier they're caught
- Faster, more predictable releases
Q38. What's the difference between regression testing and re-testing?
| Regression testing | Re-testing | |
|---|---|---|
| Scope | Broad — re-runs existing tests across the app | Narrow — re-checks the one bug that was just fixed |
| Goal | Confirm a change didn't break anything that used to work | Confirm the specific fix actually works under the conditions that first exposed the bug |
| Automatable? | Yes, and usually is | Less often — it's inherently a targeted, manual re-check |
Q39. What's the difference between system testing and unit testing?
| System testing | Unit testing | |
|---|---|---|
| Scope | The whole integrated product, tested black-box | One function, class, or component in isolation |
| Performed by | Testers, sometimes developers | The developer who wrote the code |
| Checks | Functional and non-functional requirements together | That the smallest piece behaves correctly on its own |
| Weak point | Can't pinpoint exactly which module failed | Doesn't work well for heavily interdependent modules |
Q40. What are the different types of integration testing?
| Approach | How it works |
|---|---|
| Big Bang | Integrate every module at once, then test the whole thing together — simple in concept, but blocked until every piece is ready and hard to isolate failures in |
| Bottom-Up | Test the lowest-level modules first, then progressively integrate and test upward, using drivers to simulate not-yet-built higher modules |
| Top-Down | Test the highest-level modules first, then progressively integrate downward, using stubs to simulate not-yet-built lower modules |
Q41. What are some popular integration testing tools?
- DBUnit
- Mockito
- GreenMail
- REST-Assured
- JUnit 5
- H2 Database
Q42. What's the difference between a test harness and test closure?
| Test harness | Test closure | |
|---|---|---|
| What it is | An automated framework plus test data used to unit-test modules during development | A summary document covering everything tested across the SDLC |
| Made of | A test execution engine and a script repository | A full bug analysis and wrap-up report |
| Used by | Mostly developers, during coding | The test team, near the end of testing |
Q43. What are the stages of the defect life cycle?
The mainline path a defect takes from report to close
New
Defect logged for the first time
Assigned
Routed to a developer
Active
Developer investigates and fixes
Test
Fix is ready for QA to verify
Verified
QA confirms the fix actually works
Closed
Defect resolved and signed off
That's the mainline path — a defect can also branch from Active to Deferred (pushed to a future release) or Rejected (a duplicate, invalid, or not reproducible), and it can branch from Closed back to Reopened if the fix turns out not to hold.
Q44. What is experience-based testing?
Experience-based testing relies on a tester's own judgment and past exposure to similar systems to identify the areas most worth probing, rather than deriving test cases from a formal technique. It's typically reserved for lower-risk systems, where a skilled tester's intuition is an acceptable substitute for a more rigorous, structured derivation process.
Q45. What's the difference between smoke testing and sanity testing?
| Smoke testing | Sanity testing | |
|---|---|---|
| When | Right after a new build, before deeper QA starts | After a small, specific code change |
| Scope | Broad but shallow — does the core functionality work at all | Narrow but focused — does this one change work as intended |
| Scripted? | Usually a fixed, repeatable checklist | Usually unscripted, ad hoc |
| Gates | Whether the build is even worth testing further | Whether that specific fix or feature is good enough to move on |
Q46. What is the pesticide paradox, and how do you counter it?
The pesticide paradox is the observation that running the exact same test suite over and over eventually stops finding new bugs — the software effectively becomes "immune" to tests it has already survived, not because it's actually gotten more correct everywhere else.
- Regularly write new test cases and scenarios instead of just re-running the existing ones
- Target the components whose bug-find rate has visibly flattened
- Add to the suite over time rather than treating it as finished
- Mix in different techniques — exploratory, boundary value, negative testing — to look at the software from a different angle
Real-World Scenarios
Q47. How do you decide between manual testing and automation for a given task?
| Manual wins when… | Automation wins when… |
|---|---|
| The run is short-lived or one-off | The same test needs to run repeatedly, long-term |
| The work is exploratory, ad hoc, or usability-focused | It's load, performance, or large-scale regression testing |
| Judgment and human intuition matter more than exact repeatability | Exact repeatability and a recorded, standardized process matter more |
| The scenario is too complex or subjective to script cleanly | The steps are repetitive, standardized, and well understood |
| Timelines are flexible enough to absorb manual effort | Releases are frequent and timelines are too tight for manual re-checking to keep up |
Q48. How do you know when it's time to stop testing?
- Deadlines are met with no high-priority issues still open
- A target test-case pass percentage has been reached
- The allocated test budget has been used up
- Mean time between failures (MTBF) is high enough for stakeholders to be comfortable
- Automated code coverage has hit its target with no critical bugs outstanding
- The rate of new bug discovery has dropped below an agreed threshold
- A defined alpha or beta period has simply ended
Q49. Can you ever achieve 100% test coverage?
No — genuine 100% coverage isn't realistically achievable, because the space of possible inputs, states, and environments is effectively unbounded. What's realistic is getting as close as the project's risk profile actually justifies.
- Build a real test strategy instead of testing opportunistically
- Enumerate every documented requirement and map tests to each one
- Prioritize the highest-risk, highest-impact areas first
- Identify risk areas explicitly rather than relying on intuition alone
- Automate the parts that fit, so more ground gets covered repeatedly
Q50. Can system testing be performed at any stage of a project?
No — system testing needs every module and unit already integrated and individually working, and it has to happen before UAT. It can't run any earlier than that because there's no complete, end-to-end product yet for it to actually exercise.
Q51. How do you test a feature when proper documentation doesn't exist?
Missing documentation doesn't mean testing stops — it means falling back on whatever evidence is actually available.
- Screenshots, wireframes, or a previous version of the app as a reference point
- Direct conversation with the BA or developer, with the outcome captured over email for a paper trail
- A quick smoke test to surface the obvious, glaring bugs first
- Prior testing experience and judgment, as the last resort once everything else has been exhausted
Q52. What are some best practices for writing good test cases?
- Weigh project risk and deadlines when deciding what to prioritize first
- Apply the 80/20 rule — roughly 20% of test cases should cover 80% of the functionality that matters most
- Don't try to cover everything in a single pass; iterate over multiple rounds
- Group test cases by business scenario or functionality, not arbitrarily
- Aim for modular, granular cases rather than one sprawling script
- Write them so someone else on the team could pick them up and understand them
- Keep the actual customer's needs in view, not just the written spec
- Manage releases through a proper test management tool
- Review and prune test cases regularly to remove duplicates and anything no longer relevant
Q53. How do you test a feature while requirements are still changing?
Where no stable requirement stack exists yet, watch closely for unexpected functionality showing up — that's usually a signal of a deeper process problem, not just a documentation gap — and consider trimming anything clearly irrelevant to the app's core purpose. Where nothing is documented at all, build the test plan against explicitly written-down assumptions about what the product is meant to do, so at least the assumptions themselves are visible and challengeable.
Q54. Why is boundary value analysis considered such a strong testing technique?
Bugs cluster disproportionately at the edges of an input's valid range rather than in the middle — off-by-one mistakes (using < instead of <=, for example) are one of the most common defect categories in real code. Boundary value analysis targets exactly that: the boundary values themselves, one step just inside them, one step just outside them, plus a typical mid-range value for a sanity check.
Input field accepts integers 1-20
Test values to cover:
0 -> just below the lower boundary (invalid)
1 -> lower boundary (valid)
2 -> just inside the lower boundary (valid)
19 -> just inside the upper boundary (valid)
20 -> upper boundary (valid)
21 -> just above the upper boundary (invalid)Q55. How do you know the code actually meets the specification?
Good code is maintainable, readable, and free of obvious defects per whatever coding standard the team has agreed on — that part varies team to team. On the testing side, a traceability matrix (or similar tool) maps every test case back to the requirement it covers, and a requirement is considered met once every test case mapped to it actually passes, not before.
None of this replaces actually sitting with a real application and testing it — but knowing the vocabulary and being able to reason through a scenario out loud, calmly and in order, is what most manual testing interviews are actually screening for.