Manual Testing Interview Questions (2026)

Manual testing interview questions focus on test design, defect judgment, exploratory testing, clear bug reports, and release risk. Expect practical tasks more than textbook recitation.

45 questions with answers

What Is Manual Testing?

Key Takeaways

  • Manual testing means evaluating software by human observation, test design, and judgment instead of automated scripts.
  • Good interview answers show how you choose cases, spot risk, reproduce defects, and explain bugs clearly.
  • Manual testing is not random clicking. It uses requirements, data, boundaries, personas, and release context.
  • Experienced candidates are judged on prioritization: what to test first when time is short.

Manual testing is the human-led process of checking software against requirements, user goals, and known risks. In interviews, it tests your judgment: how you turn a requirement into test cases, how you find edge cases, how you report a defect, and how you decide whether a release is safe enough. Strong answers use examples from real features, not memorized lists.

45Manual testing questions with direct answers
ISTQBCore vocabulary source
3Common exercises: test cases, bug report, release call
No codeUsually less coding, more judgment

Watch: ISTQB Foundation 4.0 Tutorial: Introduction to Exam

Video: ISTQB Foundation 4.0 Tutorial: Introduction to Exam (TM SQUARE, YouTube)

Test yourself and earn a certificate

6 quick questions. Score 70%+ to download your Manual Testing certificate.

Jump to quiz

All Questions on This Page

45 questions
Manual Testing Advanced Scenarios
  1. 31. Payment fails for one card type on release day. What do you do?
  2. 32. A developer says your bug can't be reproduced. What next?
  3. 33. A requirement changes one day before release. How do you test?
  4. 34. A critical test case is blocked by a test data issue. What do you do?
  5. 35. You find many minor defects near release. How do you present them?
  6. 36. How do you handle a suspected duplicate defect?
  7. 37. A bug appears only in production. What do you check?
  8. 38. How do you test when acceptance criteria are missing?
  9. 39. A developer disagrees with your severity. What do you do?
  10. 40. You have two hours for regression. What do you run?
  11. 41. What is wrong with a bug titled 'Login broken'?
  12. 42. A test case passed but the customer still reports a defect. What do you inspect?
  13. 43. Product keeps adding cases during test execution. What should QA do?
  14. 44. A defect happens one out of ten times. How do you report it?
  15. 45. What makes a manual tester senior?

Manual Testing Fundamentals

Foundational15 questions

Start here. These are the definitions and first-principle checks that open most rounds.

Q1. What is manual testing in practical terms?

Manual testing is human-led checking of software behavior using requirements, observation, and judgment.

It is strongest for new features, usability issues, exploratory work, and cases where human interpretation matters.

manual testing changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Watch a deeper explanation

Video: ISTQB Test Techniques Overview (TM SQUARE, YouTube)

Q2. What should a good manual test case contain?

A good test case has a purpose, preconditions, test data, steps, expected result, priority, and traceability to a requirement.

It should be clear enough for another tester to run without guessing.

test case changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q3. How is a test scenario different from a test case?

A scenario is a high-level condition to test; a test case is the detailed set of steps and expected results.

For login, 'invalid password' is a scenario; entering a specific email and password is a case.

Q4. Explain severity vs priority with an example.

Severity is the technical or user impact of a defect. Priority is how soon it should be fixed.

A crash in a rare admin path can be high severity and lower priority. A typo on the home page logo can be low severity and high priority.

TermMeaningExample
SeverityImpact on the system or userPayment fails after submit
PriorityFix urgencyLegal text typo before launch

Q5. What is the defect life cycle?

The defect life cycle is the path a bug follows from discovery to closure.

Typical states include new, assigned, open, fixed, retest, reopened, deferred, rejected, and closed.

defect life cycle changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Defect life cycle

1New
tester reports
2Triage
team sets severity and priority
3Fix
developer resolves
4Retest
QA verifies
5Close
evidence accepted

Watch a deeper explanation

Video: ISTQB Test Levels and Test Types (TM SQUARE, YouTube)

Q6. What is smoke testing?

Smoke testing is a quick check that the build's critical paths work before deeper testing starts.

It answers: is this build stable enough to test?

smoke testing changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q7. How is sanity testing different from smoke testing?

Sanity testing is a focused check after a specific change or fix.

Smoke is broad and shallow. Sanity is narrow and targeted.

sanity testing changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q8. What is regression testing?

Regression testing checks that existing working behavior still works after a change.

It matters because fixes and new features often break nearby flows.

regression testing changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q9. How is retesting different from regression testing?

Retesting checks whether a specific defect is fixed. Regression checks whether the fix broke other behavior.

Both are often needed before closing a defect.

retesting changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q10. Why do testers use boundary value analysis?

Boundary value analysis tests values at the edge of valid and invalid ranges.

Defects often appear at limits such as 0, 1, max, and max plus 1.

boundary value analysis changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q11. What is equivalence partitioning?

Equivalence partitioning groups inputs that should behave the same, then tests one or a few representatives.

It reduces test count without losing meaningful coverage.

equivalence partitioning changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q12. What makes exploratory testing disciplined?

Exploratory testing is disciplined when it uses a charter, time box, notes, and evidence.

It is not random clicking. It is learning and testing at the same time.

exploratory testing changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q13. Why does test data matter in manual testing?

Test data decides which branches, permissions, limits, and failures you can observe.

A good tester prepares valid, invalid, boundary, duplicate, expired, and permission-based data.

test data changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Watch a deeper explanation

Video: Test Activities, Testware and Test Roles (TM SQUARE, YouTube)

Q14. What is traceability in testing?

Traceability connects requirements, test cases, execution results, and defects.

It helps show what was covered and what remains risky.

traceability changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q15. What are exit criteria?

Exit criteria are agreed conditions for stopping a test phase.

Examples include critical cases passed, no open blocker defects, known risks accepted, and test evidence reviewed.

exit criteria changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Back to question list

Manual Testing Practical Interview Questions

Intermediate15 questions

These questions test whether you can apply the topic to real data, real code, and messy constraints.

Q16. Write test cases for a login page.

Cover valid login, invalid password, unknown user, locked account, empty fields, password masking, remember me, session timeout, rate limit, and recovery links.

Mention security and usability cases after core functional checks.

writing login test cases changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

text
Test case for Manual Testing
Given: known input and environment
When: the target behavior runs
Then: assert the visible result, data change, and failure message

Q17. How would you test file upload manually?

Test allowed type, blocked type, size limit, empty file, duplicate file, cancel, network failure, progress, preview, delete, and virus-scan message if present.

Use real files with known size and extension.

testing file upload changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q18. How would you test a search box?

Check exact match, partial match, no result, case sensitivity, special characters, leading spaces, sort order, filters, pagination, and response time.

Search often fails around empty and special inputs.

testing search changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q19. How would you test checkout?

Cover cart totals, discounts, tax, shipping, address validation, payment success, payment failure, retry, duplicate submit, receipt, and order history.

Payment flows need test cards and clear rollback rules.

testing checkout changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q20. What do you include in a bug report?

Include title, environment, build, steps, expected result, actual result, test data, evidence, severity, priority, and reproducibility.

A clear report lowers back-and-forth.

reporting a bug changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Bug report evidence stack

1Context
build and environment
2Steps
minimal repro
3Impact
actual vs expected
4Proof
screenshots, logs, data

Q21. How do you triage defects?

Group defects by impact, reproducibility, affected users, business date, workaround, and dependency.

Triage is a team decision, not just a QA label.

triaging defects changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q22. How do you retest a fixed bug?

Use the original reproduction steps, the same data when possible, then test nearby paths that could be affected by the fix.

Attach evidence before closing.

retesting a fixed bug changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q23. How do you choose regression cases?

Pick critical user journeys, changed modules, integrations, high-defect areas, and cases tied to business risk.

Regression should be risk-based, not just the whole suite every time.

running regression changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q24. How do you run an exploratory testing session?

Write a charter, time box the session, note coverage, capture defects, and summarize findings.

The session output should be reviewable.

exploratory charter changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q25. How would you test role-based access manually?

Create users for each role, verify allowed actions, blocked actions, direct URL access, API side effects if visible, and audit logs.

Permission bugs often appear outside the main UI path.

testing permissions changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Watch a deeper explanation

Video: ISTQB Foundation Exam Details and Tips (TM SQUARE, YouTube)

Q26. How would you test a localized page?

Check translated labels, date and number formats, text overflow, sorting, currency, directionality if needed, and fallback language.

Use real content, not only short sample strings.

testing localization changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q27. What manual checks matter for mobile web?

Check viewport, touch targets, keyboard behavior, orientation, network changes, scrolling, forms, and device-specific browser issues.

Use actual devices for final checks when risk is high.

testing mobile web changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q28. What goes into a test summary report?

State scope, build, cases run, pass and fail count, blocked items, open defects, risk, recommendation, and evidence links.

Executives need risk, not raw case lists.

test summary report changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q29. What do you do when requirements are unclear?

Ask for examples, acceptance criteria, edge cases, and expected behavior before treating your assumption as truth.

Log assumptions if testing must start before answers arrive.

requirement ambiguity changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q30. How do you decide whether to recommend release?

Use open defect severity, failed critical paths, business impact, workaround quality, test coverage, and accepted risks.

QA provides evidence. Release ownership is shared.

release recommendation changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Back to question list

Manual Testing Advanced Scenarios

Advanced15 questions

Advanced rounds test trade-offs, failure modes, and whether the decision can hold up under production pressure.

Q31. Payment fails for one card type on release day. What do you do?

Reproduce it, confirm card type and gateway response, check workaround, assign high severity, and escalate with evidence.

Business impact decides priority.

payment blocker changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q32. A developer says your bug can't be reproduced. What next?

Recheck environment, data, steps, logs, timing, browser, and user role, then narrow the case and add evidence.

Don't argue from memory. Bring data.

unreproducible bug changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q33. A requirement changes one day before release. How do you test?

Identify impacted flows, update priority cases, run focused regression, and document untested risk.

Time-boxed risk testing beats pretending full coverage happened.

late requirement change changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q34. A critical test case is blocked by a test data issue. What do you do?

Log it as blocked, request data or access, test alternate coverage if possible, and call out release risk.

Blocked is not passed.

blocked test case changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q35. You find many minor defects near release. How do you present them?

Cluster them by area, user impact, and business deadline, then separate blockers from polish items.

A clean summary gets decisions faster.

too many defects changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q36. How do you handle a suspected duplicate defect?

Compare steps, environment, actual result, root area, and affected version before marking it duplicate.

A similar symptom may still have a different cause.

duplicate defect changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q37. A bug appears only in production. What do you check?

Compare config, data volume, permissions, third-party services, logs, and release version.

Production bugs often come from environment differences.

production-only bug changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q38. How do you test when acceptance criteria are missing?

Ask for expected behavior, write assumptions, use comparable flows, and focus on user value and obvious risk.

Don't invent rules silently.

feature without acceptance criteria changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q39. A developer disagrees with your severity. What do you do?

Explain user impact, frequency, data loss, security, and workaround, then let triage decide.

Severity should be evidence-based.

developer rejects severity changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q40. You have two hours for regression. What do you run?

Run smoke paths, changed-area tests, integration touchpoints, and the top business flows.

Uncovered areas must be explicit.

fast regression ask changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q41. What is wrong with a bug titled 'Login broken'?

It is too vague.

A better title says condition and failure, such as 'Locked user can still reach dashboard after password reset'.

bad bug title changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q42. A test case passed but the customer still reports a defect. What do you inspect?

Check case coverage, data, environment, assumptions, and whether the expected result matched real user need.

Passing a weak case doesn't prove the product works.

false pass changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q43. Product keeps adding cases during test execution. What should QA do?

Track new scope separately, assess impact, reprioritize with stakeholders, and protect critical coverage.

Untracked scope makes test reports misleading.

scope creep changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q44. A defect happens one out of ten times. How do you report it?

Report frequency, conditions, logs, data, timing, and any pattern observed.

Intermittent defects still count when impact is high.

intermittent issue changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Q45. What makes a manual tester senior?

They find the important risks early, communicate clearly, mentor others, improve coverage, and influence release decisions with evidence.

Seniority is judgment, not just years.

senior manual tester changes Manual Testing decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Back to question list

Manual Testing vs Exploratory Testing vs UAT

Interviewers often use these terms together. The useful distinction is the purpose of the activity, who performs it, and what evidence it produces.

TypeMain purposeWho usually does itBest interview answer
Manual scripted testingVerify expected behavior from prepared casesQA testersI use it when the requirement is stable and coverage matters.
Exploratory testingLearn the product while testing itQA, product, sometimes developersI use charters, notes, and time boxes so it stays disciplined.
UATConfirm business acceptanceUsers, product owners, client teamsI support it with scenarios and data, but the business decides acceptance.
Ad hoc testingQuick informal checksAnyoneI don't treat it as a substitute for planned coverage.

Manual testing interview scoring weight

Most manual QA rounds reward decision quality more than tool names.

Scale: Hyring editorial score for interview preparation, not an external benchmark.

Test design
92 weight
Bug reports
88 weight
Risk calls
84 weight
Tool usage
58 weight
  • Test design: cases, boundaries, data
  • Bug reports: repro steps and evidence
  • Risk calls: release judgment
  • Tool usage: helpful but secondary

How to Prepare for a Manual Testing Interview

Prepare by doing the work on paper. Pick a login page, shopping cart, file upload, and payment screen. Write cases, then explain which five you would run first and why.

  • Practice severity vs priority, test levels, test types, defect life cycle, smoke, sanity, and regression.
  • Write positive, negative, boundary, data, permission, browser, and recovery cases for common features.
  • One real bug story with steps, expected result, actual result, evidence, severity, priority, and fix verification is useful.
  • Rehearse release judgment: what you would block, what you would accept with known issues, and what evidence you need.

Manual testing thinking flow

1Requirement
identify business rule, user, and risk
2Coverage
positive, negative, boundary, data, permission
3Execution
run, observe, capture evidence
4Decision
defect report, retest, release call

The best manual testing answers show intent before steps.

What Strong Manual Testing Answers Prove

A strong manual testing answer proves that you can think like a user, a tester, and a release owner at the same time. You don't need a long answer. You need the right evidence in the right order.

SignalWeak answerStrong answer
Test case designI will test all scenarios.I will cover happy path, validation, boundaries, permissions, and recovery first.
Bug reportingI found a bug.I include steps, expected, actual, data, environment, screenshots, logs, and severity.
ExplorationI click around.I use a charter, time box, notes, and follow risk.
Release callQA approves release.QA gives risk evidence. Product and business make the release decision.

Test Yourself: Manual Testing Quiz

Ready to test your Manual Testing knowledge?

6 questions, about 4 minutes. Score 70% or higher to earn a shareable certificate.

6 questions Instant feedback Free certificate on 70%+

Frequently  Asked  Questions

What do manual testing interviews usually ask?

They ask you to design test cases, explain severity vs priority, report a defect, compare smoke and sanity testing, plan regression, and handle unclear requirements.

Do manual testers need automation knowledge?

For manual QA roles, basic automation awareness helps, but the core screen is test design and defect judgment. If the job says Selenium, Playwright, API testing, or SDET, expect coding.

How do I answer test case design questions?

the feature purpose, then cover happy path, negative cases, boundaries, permissions, data, failure handling, and recovery comes first. End with the five cases you would run first.

What project should I mention in a manual testing interview?

Choose a feature where you found a meaningful bug or improved coverage. Explain the requirement, risk, cases, bug evidence, and how the team used your report.

How can I sound experienced without overtalking?

Use short evidence-led answers: risk, case choice, defect impact, data, and release recommendation. Avoid saying you would test everything.

Is there a quiz for manual testing?

Yes. The quiz on this page checks core manual testing terms and explains each answer, so you can fix weak spots before the interview.

Practice manual QA answers before the screen

Hyring's AI Video Interviewer scores structured answers, examples, and follow-up reasoning. Use this page to make manual testing answers specific before you face a recorded or live QA round.

Try AI interview prep

Sources

Adithyan RKWritten by Adithyan RK
Surya N
Fact-checked by Surya N
Published on: 14 Jun 2026Last updated: 24 Jun 2026
Share: