Manual testing interview questions

Interviewers use manual testing questions to find out how you think, not how many definitions you memorised. Where a question has a "textbook" answer, give it in one sentence and then add an example from a project, even a practice one. That second sentence is what they remember.

Basics

1. What is the difference between verification and validation?

Verification asks "are we building the product right?" It checks work products against the specification without running the software: reviews, walkthroughs, inspections of requirements and designs. Validation asks "are we building the right product?" and needs the running software: you execute it and check that it meets what the user actually needs.

Example: reading the login requirement and spotting that it never says what happens after five wrong passwords is verification. Trying five wrong passwords on the built login page is validation.

Likely follow-up: Is testing verification or validation? Both. Static testing (reviews) is verification and dynamic testing (running the code) is validation.

2. Explain the software testing life cycle (STLC).

The usual phases are requirement analysis, test planning, test case design, test environment set-up, test execution, and test closure. Each has an entry and an exit criterion. For example, execution starts when the build is deployed and a smoke test passes, and closure happens when the exit criteria (such as no open critical defects) are met.

The honest part: in agile teams these phases overlap inside a sprint. Say that. It shows you have worked in a real team.

Likely follow-up: Where do you start testing in a sprint? When the story is being refined, by questioning the acceptance criteria, long before there is a build.

3. What is the difference between a test scenario, a test case and a test plan?

A scenario is a one-line idea of what to test ("user logs in with valid credentials"). A test case is the detailed version: preconditions, steps, test data and expected result. A test plan is the document for the whole effort: scope, approach, environments, schedule, risks, who does what.

4. What is the difference between smoke and sanity testing?

Smoke testing is a quick, broad check on a new build to decide whether it is stable enough to test at all: can the app start, can I log in, do the main pages load. Sanity testing is a narrow check after a small change or bug fix to confirm that specific thing works and has not broken its neighbours. See smoke vs sanity for a table.

5. What is regression testing and how do you decide what to include?

Regression testing re-checks existing behaviour after a change to make sure nothing else broke. You cannot rerun everything every time, so you choose by risk: areas that touch the change, areas that broke before, and the business-critical flows (login, payment, order). Over time the stable, repeated part is what you automate.

Likely follow-up: What is the difference between regression and retesting? Retesting runs the exact failed test again after a fix. Regression runs other tests to see if the fix broke something else.

Test design

6. What is boundary value analysis? Give an example.

Bugs cluster at the edges of input ranges, so you test at and around each boundary. If an age field accepts 18 to 60, test 17, 18, 19, 59, 60 and 61. Two-value BVA tests the boundary and its nearest invalid neighbour; three-value adds the value just inside as well.

7. What is equivalence partitioning?

You divide inputs into groups that the system should treat the same, and test one value from each group instead of all of them. For the age field above there are three partitions: below 18 (invalid), 18 to 60 (valid), above 60 (invalid). Add non-numeric input and empty as further invalid partitions. Combine it with boundary values for a small, strong set.

8. How would you test a login page?

Start with the happy path, then go outward: wrong password, wrong username, empty fields, spaces around the email, case sensitivity, password masking, the lockout after repeated failures, "remember me", forgot password link, session timeout, back button after logout, SQL characters in the fields, and how it looks and behaves on a small phone. There is a full list on the login page test cases page.

Interview tip: say the categories out loud (functional, negative, boundary, UI, security, performance). Interviewers listen for structure.

9. How do you test something with no requirements?

Find the requirements indirectly: ask the product owner or developer, check similar features, read old tickets, and look at how production behaves. Explore the feature with time-boxed sessions and write down what you learn as you go (exploratory testing). Then send your understanding back to the team in writing and ask them to correct it. That document becomes the missing requirement.

Defects

10. Describe the bug life cycle.

New, then Assigned (or Open) to a developer, then In Progress, then Fixed, then Retest, and finally Closed if it passes or Reopened if it does not. Side exits are Rejected (not a bug), Duplicate, Deferred (a decision to fix later) and Cannot Reproduce. Names differ between teams and tools; the idea is the same.

11. What goes into a good bug report?

A specific title, environment (build, browser, OS, device), steps to reproduce, expected result, actual result, severity and priority, and evidence: a screenshot, a short video, console or network logs. The test of a good report: a developer who has never seen the feature can reproduce it in two minutes without asking you anything. Use the bug report template.

12. What is the difference between severity and priority?

Severity is how badly the defect damages the product. Priority is how soon the business wants it fixed. A typo in the company name on the home page is low severity but high priority. A crash in a rarely used admin report is high severity but may be low priority. See severity vs priority.

Likely follow-up: Who sets which? Testers usually propose severity; the product owner decides priority.

13. A developer says "it is not a bug, it works as designed". What do you do?

Check the requirement or acceptance criteria first, because you might be wrong. If the behaviour matches the document but is bad for the user, raise it as an improvement or a requirement gap with the product owner, with a screenshot of the user impact. If it does not match the document, point to the exact line. Keep it about the product, not about who is right.

Process and judgement

14. How do you decide when to stop testing?

You never prove there are no bugs, so you stop on agreed criteria: planned test cases executed, no open critical or high defects, defect discovery rate has flattened, coverage targets met, and the deadline and risk are acknowledged by the people who own them. Say that the decision belongs to the stakeholders and your job is to give them the evidence.

15. What do you do when you find a bug the day before release?

Reproduce it reliably, assess the impact (who is affected, is there a workaround, is data at risk), report it with evidence immediately, and tell the product owner and the developer in person instead of only through the ticket. Release or delay is their decision. Offer options: fix and retest, release with a known issue and a workaround, or switch the feature off.

16. What is exploratory testing and when do you use it?

Simultaneous learning, test design and execution, guided by a short charter such as "explore the cart with discount codes and see what breaks", usually in a 45 to 60 minute session with notes. Use it for new features, when requirements are thin, and after scripted tests pass, because it finds the problems nobody thought to write a case for.

Test design in more depth

17. What is the difference between QA, QC and testing?

QA (quality assurance) is about the process: standards, reviews, how the team works, so that defects are prevented. QC (quality control) is about the product: checking that what was built meets the requirements. Testing is the main QC activity, the actual execution of tests to find defects. A tester who also suggests better review habits is doing a bit of QA.

18. What is the difference between static and dynamic testing?

Static testing examines work products without running the software: reviewing requirements, designs, code and test cases. Dynamic testing runs the software. Static testing is cheaper per defect because it happens early. A missing requirement found in refinement costs minutes; the same gap found after release costs a hotfix.

19. What is error guessing and when is it useful?

Using your experience of where bugs usually hide to design tests: empty fields, a space as the only input, very long text, apostrophes in names, dates like 29 February, double clicks, the back button after submitting. It is not a replacement for structured techniques, but it quickly finds problems they miss. Keep a personal list of "bugs I have seen before".

20. What is the difference between exploratory, ad hoc and monkey testing?

Exploratory testing is structured freedom: a charter, a time box and notes. Ad hoc testing has no plan or notes, so it is hard to repeat or report. Monkey testing means random inputs and clicks, often automated, to see whether the app crashes. Only the first is a professional technique you can defend in a report.

21. How do you prioritise what to test when time is short?

By risk: how likely something is to break, multiplied by how much it hurts if it does. Money, personal data and the main user journey come first, then areas that changed in this release, then areas with a history of bugs. Say what you are leaving out and why, and get the product owner to accept it in writing.

22. Which metrics do you use to report testing progress and quality?

Progress: test cases planned, executed, passed, failed and blocked. Quality: defects found by severity, defect density (defects per feature or per thousand lines), and defect leakage (found after release divided by total found). Effort: time per cycle and automation coverage. Add the caveat that numbers need a story: a drop in defects can mean good code or weak testing.

Likely follow-up: What is defect age? The time between a defect being reported and being closed. A growing average usually means a bottleneck in fixing or retesting.

23. What is test coverage, and can you have 100% of it?

Coverage measures how much of something has been tested: requirements covered by test cases, code lines or branches executed, or platforms and browsers. You can reach 100% requirement coverage and still miss defects, because tests might be weak. High code coverage tells you what was never executed; it does not prove that what was executed was checked properly.

24. How do you test for compatibility across browsers and devices?

Decide the support matrix from real usage data (analytics) and the business, not from a wish list: for example the latest two versions of Chrome, Safari, Edge and Firefox, plus a few common Android and iOS devices. Test the main flows on each, with extra attention to layout, forms, date pickers, file upload and payment. Use real devices for touch and performance, emulators for breadth, and automation for the stable flows.

25. How do you test usability and accessibility?

Usability: watch real users try a task and note where they hesitate; check consistent wording, clear errors and sensible defaults. Accessibility: use the keyboard only, check focus order and visible focus, test with a screen reader, check colour contrast, give images text alternatives, and label every form field. Automated tools find roughly the obvious third of problems; the rest needs a human.

26. How is testing done in an agile team?

Continuously, inside the sprint. Testers join refinement to question the acceptance criteria, write test ideas before development, test each story as soon as it is ready, automate regression as they go, and join the demo and retrospective. The "definition of done" includes tested. The anti-pattern to name is mini-waterfall: development in the first week, testing in the last two days.

27. How do you handle test data, especially for systems with personal data?

Create test data with a known purpose and clean up after the test. Never copy production data as it is: mask or generate it (fake names, numbers that only match a format). Keep reusable sets for common situations (a new user, a user with a failed payment, an admin) and document them. Data that breaks the rules (very long, special characters) deserves its own set.

28. How is testing a mobile app different from testing a website?

More variables: device sizes, OS versions, interruptions (calls, notifications, low battery), network changes (Wi-Fi to mobile data, offline), permissions, installation, update and uninstall, orientation, and store rules. Gestures and performance on slow devices matter. Test on real devices for what users really have, and test the update path from the previous version, because that is where data migration bugs live.

29. What goes into a test summary report?

Scope and build tested, dates, what was executed and the results, defects found and their status by severity, the defects still open with their risk, anything not tested and why, the environment, and a clear recommendation (release, release with known issues, or do not release). Keep it to a page: managers read the first paragraph.

30. You are asked to test a "forgot password" feature in five minutes. What do you do?

Request a reset for a real account and check that the email arrives and the link works once and expires. Try an unknown email and check that the page does not reveal whether an account exists. Try a weak new password and mismatched confirmation. Then say aloud what you would add with more time: expiry, reuse, rate limits, and the old sessions ending. The full list is in forgot password test cases.

Quick answers

Keep these two-line answers ready: what is a test environment, what is UAT, what is a test closure report, what is the defect leakage percentage (defects found after release divided by total defects found), and what is traceability (a map from each requirement to the tests that cover it).