So you've got a manual testing interview coming up. Maybe it's your first QA role, maybe you're switching teams, or maybe you've been doing this for years and just want to brush up. Either way, the interview room (or video call) has a way of making things you know cold suddenly feel slippery.
This guide covers the questions that actually come up — not the watered-down list you've seen recycled across a dozen sites. We'll go through beginner, intermediate, and advanced levels, with honest answers and some context around why interviewers ask what they ask.
Why Manual Testing Still Matters (and Why Interviewers Care)
Before diving into questions, it's worth acknowledging something: a lot of people assume manual testing is dying out because of automation. It's not. Automation handles repetition well, but it doesn't catch what a human notices — the button that's technically clickable but visually hidden, the flow that works but feels wrong, the edge case nobody thought to write a script for.
Interviewers know this. They're not just checking if you can recite definitions. They want to know if you think like a tester.
Beginner-Level Questions
1. What is manual testing?
Manual testing is the process of testing software by hand — without the use of automated tools — to find bugs, verify behavior, and ensure the application meets its requirements. A tester executes test cases step by step, observes the results, and compares them against expected outcomes.
Why they ask: They want to confirm you understand the basic concept and can articulate it without jargon soup.
2. What's the difference between verification and validation?
- Verification asks: Are we building the product right? It checks that the software conforms to its specifications — think code reviews, inspections, and walkthroughs.
- Validation asks: Are we building the right product? It checks that the final product actually meets the user's needs — think actual testing against real-world scenarios.
A simple way to remember it: verification is about process, validation is about the end result.
3. What are the different types of testing you know?
This is a broad question, and interviewers usually want you to show range without rambling. A solid answer covers:
- Functional testing — does the feature work as specified?
- Regression testing — did recent changes break something that used to work?
- Smoke testing — quick check to see if the build is stable enough to test further
- Sanity testing — narrow check after a fix to confirm it actually fixed the issue
- Exploratory testing — unscripted, experience-driven testing
- Usability testing — is the product easy to use?
- Integration testing — do different modules work together correctly?
If the role involves APIs, you'll also want to mention api testing, which verifies that endpoints behave correctly, return the right data, and handle errors gracefully.
4. What is a test case? How do you write one?
A test case is a documented set of conditions, inputs, and steps used to verify a specific behavior in a system. A well-written test case includes:
- Test case ID — unique identifier
- Test description — what you're testing
- Preconditions — what needs to be true before you start
- Test steps — exactly what to do, in order
- Expected result — what should happen
- Actual result — what actually happened
- Pass/Fail status
Writing good test cases is a skill in itself. Vague steps and fuzzy expected results lead to inconsistent execution and missed bugs. The best test cases are specific enough that anyone on the team can run them and get the same outcome.
5. What's the difference between a bug, a defect, and an error?
- Error — a human mistake (developer writes the wrong logic)
- Defect — the result of that mistake in the code (the wrong logic sitting in the codebase)
- Bug — what we call it when the defect causes the software to behave incorrectly during execution
In practice, people use these terms interchangeably — and that's fine. But if an interviewer is being technical, this is the distinction they're after.
6. What is the software testing life cycle (STLC)?
The STLC is the sequence of activities carried out during the testing process:
- Requirement analysis — understand what needs to be tested
- Test planning — define scope, resources, schedule, and approach
- Test case development — write and review test cases
- Test environment setup — prepare the systems and data needed to test
- Test execution — run the test cases and log results
- Test closure — wrap up, report, and document lessons learned
Each phase has entry and exit criteria, though in practice — especially in agile teams — these phases overlap and repeat.
Intermediate-Level Questions
7. What's the difference between smoke testing and sanity testing?
This one trips people up because the terms sound similar.
- Smoke testing happens at the beginning of a test cycle. It's a shallow, wide pass to check whether the build is stable enough to proceed with further testing. If smoke testing fails, you send the build back without wasting time on deeper tests.
- Sanity testing happens after a bug fix or a small change. It's a narrow, deep check to confirm that the specific fix works and hasn't introduced new problems nearby.
Think of smoke testing as "is this even worth testing?" and sanity testing as "did this fix actually fix it?"
8. How do you approach exploratory testing?
Exploratory testing isn't random clicking — it's structured curiosity. A good answer shows that you come in with a charter (a loose objective), make notes as you go, follow threads when something looks suspicious, and document what you find.
A typical approach:
- Define a session goal (e.g., "explore the checkout flow for a guest user")
- Set a time box (45–90 minutes works well)
- Take notes on what you tested, what you found, and what you skipped
- Log any bugs with enough detail to reproduce them
9. What is boundary value analysis? Give an example.
Boundary value analysis (BVA) is a technique where you test at the edges of valid input ranges, because bugs tend to cluster there.
If an input field accepts values from 1 to 100, you'd test: 0, 1, 2, 99, 100, 101.
You're checking:
- Just below the lower boundary (0)
- At the lower boundary (1)
- Just above the lower boundary (2)
- Just below the upper boundary (99)
- At the upper boundary (100)
- Just above the upper boundary (101)
10. What is equivalence partitioning?
Equivalence partitioning divides input data into groups (partitions) where all values in a group should behave the same way. You then test one value from each partition instead of every possible input.
For a field that accepts ages 18–60:
- Valid partition: 18–60 (test one value, say 35)
- Invalid partition below: less than 18 (test one value, say 10)
- Invalid partition above: greater than 60 (test one value, say 75)
Used together, BVA and equivalence partitioning cover a lot of ground efficiently.
11. What information goes into a good bug report?
A bug report is only as useful as its clarity. A thorough report includes:
- Title — short, descriptive summary of the issue
- Steps to reproduce — numbered, precise, repeatable
- Expected result — what should have happened
- Actual result — what actually happened
- Environment — OS, browser, device, app version
- Severity and priority
- Screenshots or screen recordings — when applicable
- Logs — if relevant and accessible
A bad bug report says "the page crashes sometimes." A good one tells you exactly how to make it crash every time.
12. What's the difference between severity and priority?
- Severity is how badly the bug impacts the system (technical impact)
- Priority is how urgently it needs to be fixed (business impact)
A bug can have high severity but low priority — for example, a crash on a deprecated feature nobody uses anymore. Or low severity but high priority — a typo in the company name on the homepage, which is embarrassing and needs fixing before the press release, even though it doesn't break anything.
13. How do you handle a situation where there isn't enough time to test everything?
This is a real-world scenario question, and they want to see risk-based thinking.
A good answer: prioritize based on risk. Ask which features are most business-critical, which parts of the code changed most recently, and where bugs have historically lived. Test the high-risk areas deeply and do lighter coverage elsewhere. Document what you couldn't get to so the team can make an informed decision about the release.
Advanced-Level Questions
14. How do you test without requirements?
It happens. Specs are missing, outdated, or vague. In those cases:
- Talk to developers, product managers, and stakeholders to extract implicit requirements
- Look at similar features in competing products or previous versions
- Use exploratory testing to understand how the system behaves and form a mental model
- Document your assumptions as you test
The goal is to build enough understanding to test meaningfully, even without formal documentation.
15. What's your approach to regression testing in an agile environment?
In agile, releases happen fast. A good manual tester:
- Maintains a regression suite of high-priority test cases
- Decides which tests to run based on what changed in the sprint
- Flags areas of the codebase that frequently break
- Advocates for automating the most stable, repetitive regression cases over time
The honest answer is that pure manual regression at scale is unsustainable. Good testers understand this and help bridge the gap toward automation where it makes sense.
16. What testing would you do for a login page?
This is a classic, open-ended scenario question. A thorough answer covers:
Functional:
- Valid username and password logs in successfully
- Invalid username shows appropriate error
- Invalid password shows appropriate error
- Empty fields show validation messages
- Case sensitivity behavior (is username case-sensitive?)
- "Remember me" functionality works correctly
- Forgot password link works
Security:
- SQL injection in username/password fields
- Brute force — does the system lock out after repeated failures?
- Password shown in plain text anywhere?
- Session token behavior after logout
UI/UX:
- Tab order is logical
- Password field masks input
- Error messages are helpful but don't expose whether the username exists
Edge cases:
- Very long username/password
- Special characters
- Whitespace-only input
17. How do you test an API manually?
Manual API testing typically involves tools like Postman or similar clients to send requests and inspect responses. You'd check:
- Correct status codes for valid and invalid requests
- Response body structure and data accuracy
- Error messages for bad inputs
- Authentication and authorization behavior
- Edge cases: empty payloads, malformed JSON, missing required fields
- Rate limiting and timeout behavior
Understanding software testing strategies helps here — knowing when to lean on manual API checks versus building automated coverage is a judgment call that separates mid-level testers from senior ones.
18. What's the difference between black-box, white-box, and grey-box testing?
- Black-box testing: The tester has no knowledge of the internal code. Testing is based on inputs and outputs only. Most manual QA is black-box by nature.
- White-box testing: The tester has full access to and knowledge of the code. Tests are designed based on internal logic, paths, and branches.
- Grey-box testing: Partial knowledge — the tester knows some internals (like the database schema or API contracts) but not the full codebase. Common in integration and API testing.
19. How would you test a mobile app differently from a web app?
Mobile testing introduces dimensions that web testing doesn't:
- Device fragmentation — different screen sizes, OS versions, manufacturers
- Network conditions — test on 3G, 4G, wifi, and offline
- Battery and memory — how does the app behave under resource constraints?
- Interruptions — incoming calls, notifications, app backgrounding
- Gestures — swipe, pinch, tap precision
- App store considerations — install/uninstall behavior, upgrade paths
- Permissions — what happens when you deny location, camera, or notification access?
20. How do you stay current with testing practices?
This is a soft question but it matters. Interviewers want someone who grows.
Honest answer: read blogs, follow QA communities, experiment with new tools, and pay attention to how development practices around you evolve. Testing is shifting — AI-assisted testing, shift-left approaches, and the blurring line between manual and automated work are all changing what the job looks like. Staying curious is the job.
A Few Tips Before You Walk In
Think out loud. Interviewers care as much about how you reason as what you conclude. Walking them through your logic is more impressive than landing on the right answer silently.
Use examples from your own experience. Generic answers are forgettable. Specific stories — even short ones — stick.
Ask clarifying questions. When given an open-ended scenario, ask what you'd ask in real life. What's the platform? What's the user profile? What's the risk if this goes wrong? That instinct is exactly what testers need.
Don't oversell automation. If you're interviewing for a manual testing role, they want someone who values the craft. Saying "I'd automate all of this" isn't the flex it might seem.
Manual testing is fundamentally about judgment — knowing what to test, how deeply, and what signals actually matter. The questions above are worth knowing, but the best preparation is building the habit of thinking critically about software before you ever touch a keyboard.
Good luck.
Top comments (0)