Manual Testing Interview Questions: 16 Worked Scenarios
Practise manual testing with 16 worked questions on boundaries, defects, risk, login, uploads, payments and release decisions, using concrete examples.
Good manual testing answers explain what you would check and why. Use these questions to practise selecting evidence, recognising risk and communicating an unresolved problem. They are not an exam answer key or a prediction of a particular company’s interview.
Use examples rather than memorised labels
Choose a familiar feature and explain its users, permissions, states and failure consequences. Then walk through one test with a setup, action and expected result. If a requirement is unclear, state your assumption and the question you would ask.
The applied scenarios below are original practice exercises. Terminology can vary between teams, so define what you mean before relying on a label such as smoke or sanity testing.
Interview questions & answers
Test design
1.What is the difference between a scenario and a test case?
A scenario describes behaviour to investigate, such as cancelling a booking. A test case makes a particular check executable by specifying relevant setup, inputs, actions and expected results. For example, cancelling a confirmed booking before the deadline should change its status and release capacity according to the agreed rule.
2.How would you use boundary value analysis?
For an integer quantity allowed from 1 to 10, useful boundary-focused values include 0, 1, 2, 9, 10 and 11. Explain the technique you chose and the inclusive limits. This does not cover every risk: decimal input, missing values and permission checks may require separate tests.
3.When is a decision table useful?
Use one when combinations of conditions determine an outcome. For a discount, membership status and a valid code might jointly affect eligibility. List feasible combinations and expected outcomes, resolve conflicting rules and choose representative tests. Do not infer the business rule solely from what the current implementation happens to do.
4.What does exploratory testing add?
Exploratory testing combines learning, design and execution. Use a focused charter, record observations and follow new evidence. For example, investigate how a cart behaves when stock changes between adding an item and checkout. It complements scripted checks; it is not simply clicking without a purpose.
5.How do retesting and regression differ?
Confirmation testing checks that a reported defect is fixed. Regression testing checks for unintended effects in relevant existing behaviour after a change. The same fix can need both: confirm a corrected discount calculation, then check totals, returns and other discount types that use the affected logic.
Defects
1.What belongs in a useful defect report?
Include the build or environment, role, relevant data setup, steps, expected result, actual result and evidence. State reproducibility and impact without guessing the root cause. For a disappearing cart item, a timestamp and the product state can be more useful than a screenshot alone. Remove private data from shared attachments.
2.How do severity and priority differ?
Severity describes the impact of a defect; priority describes the urgency of addressing it. Explain the user, frequency and business context rather than assigning labels in isolation. A typo on a major campaign’s launch button may be urgent without causing data loss. A rare data-loss defect remains serious even when a workaround limits immediate exposure.
3.What if a developer cannot reproduce the defect?
Compare the build, account permissions, data state, timing and environment. Re-run with the smallest reliable setup and capture the observed result. If it remains intermittent, report frequency and conditions rather than inventing certainty. Work together to narrow the difference and keep the original evidence available.
Applied scenarios
1.How would you test a login page?
Cover valid and invalid credentials, empty input, account state, reset flow and session behaviour. Check keyboard operation, useful error messages and that the protected page remains protected after logout. Verify rate limiting and security behaviour only within the authorised test scope. Define expected responses with the team rather than assuming every login system has identical rules.
2.How would you test a file upload?
Start with allowed formats, size limits, user permissions and the processing result. Test a boundary-size file, an empty file, an unsupported type, a misleading extension and interrupted transfer. Check that failure leaves a clear state and no unintended duplicate. Use harmless test fixtures and verify the uploaded content is available only to the intended users.
3.How would you test a payment flow?
Use the provider’s test environment and approved test data. Check success, decline, cancellation, delayed confirmation and a repeated submission. Verify order state and receipt behaviour, including the case where payment succeeds but the browser loses its response. A success screen alone does not prove the server recorded one correct payment and one order.
4.How would you test a search feature?
Define matching, filters, sorting and pagination first. Use exact matches, partial text, no results, special characters and combinations of filters. Check that changing a filter resets or preserves page state as specified. Verify results respect the user’s access, and compare displayed counts with the actual filtered data.
5.How would you check that a record was saved?
Confirm the UI result and the persisted state through an approved API or read-only database check. Match the correct record identifier and fields, then reload or revisit the page. Also test validation failure and repeated submission. A toast message or a row-count increase is insufficient when the wrong values or duplicate records could have been saved.
Release decisions
1.You have two days for a much larger test scope. What do you do?
Make the time constraint visible. Rank checks by likely impact, changed behaviour and critical user journeys, then agree the reduced scope with the decision owner. Identify dependencies and reserve time to verify fixes. Report what remains untested and the resulting uncertainty; do not relabel a partial pass as full coverage.
2.What if you find a serious issue just before release?
Provide a reproducible example, affected users, likely consequences and any verified workaround. Explain which release criteria are affected and the evidence still missing. The responsible release owner decides whether to delay, limit or proceed. Record the decision and retest the actual fix instead of treating a promise to repair it as resolution.
3.How do you test when requirements are incomplete?
Gather the available contract, user workflow, existing behaviour and stakeholder expectations. List assumptions and concrete questions, then test high-risk behaviour that is already clear. Use examples to expose ambiguity, such as whether a cancelled booking can be restored. Keep the decision record so future tests reflect agreed behaviour rather than an undocumented guess.
