Manual Tester / Test Analyst interview preparation
Use this guide to prepare for Manual Tester / Test Analyst interviews, with a focus on equivalence partitioning, manual testing, decision tables. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
Equivalence partitioning
Manual Testing
Decision tables
Boundary values
State transitions
Exploratory testing
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Technical · Fresher
1. How would you test an age field accepting 18 through 65?
Answer guide
I split the input into equivalence classes, because values in the same class should behave alike. The valid class is 18 to 65, and the invalid classes are below 18 and above 65. Then I pick boundary values around the edges: 17, 18, 65 and 66, since off-by-one mistakes happen there. I also try other kinds of invalid input such as blank, letters, decimals, negative numbers and a very large number. This gives a small set of tests with good coverage, and I confirm the error message is clear and nothing is saved when the entry is rejected.
What this question explores
Whether you can apply equivalence classes and boundaries to derive a small, effective set of tests.
Common mistakes
Testing only one or two typical ages like 30 and 40 and calling the field tested.
Forgetting non-numeric, blank and decimal input and concentrating only on whole numbers.
Practise a follow-up
What would change in your tests if the field accepted decimals?
How would you cover this field in an automated suite?
2. How would you coach a tester who follows scripts accurately but rarely notices unexpected behaviour?
Answer guide
I would start by asking them to explain the purpose of each test, which pushes them to think about what could go wrong, and encourage them to look at side effects and vary meaningful conditions. We would pair on a focused exploratory session and debrief what they noticed. I measure growth through useful findings and reasoning rather than raw bug counts, while keeping the discipline of accurate execution and reproducibility they already have. Some people need time to feel allowed to deviate from a script, so I would make it clear that curiosity is valued.
What this question explores
Whether you coach observation and curiosity through pairing and debriefs while respecting the discipline the tester already shows.
Common mistakes
They tell the tester to just be more careful, with no concrete practice or pairing.
They judge improvement by counting defects raised, which encourages noisy, low value reports.
Practise a follow-up
How would you run a first pairing session with this tester?
How would you handle a tester who is nervous about deviating from the script?
3. How would you test discount rules based on membership, coupon and basket value?
Answer guide
I list the conditions, here membership, coupon validity and basket value bands, and the outcomes such as the discount given. Then I lay out the combinations as rules in a table, mark impossible ones, like a coupon that policy forbids for non-members, and merge rules where a condition does not matter. Each remaining rule becomes at least one test, plus boundary values around the basket threshold. The table also surfaces gaps and conflicts in the requirement, such as two rules giving different discounts, which I raise before testing.
What this question explores
Whether you can turn combinational business rules into a compact table that reveals gaps and conflicts.
Common mistakes
Testing a few favourite combinations by hand and missing rules where conditions interact.
Generating every possible combination without removing impossible ones or merging equivalent rules.
Practise a follow-up
What would you do if two rules in the table give conflicting discounts?
When is pairwise testing a better choice than a full decision table?
4. Why do boundary values find defects that typical examples miss?
Answer guide
Programmers write comparisons such as less than or less than or equal, and a slip in one operator moves the edge by one. Typical mid-range examples never touch that edge, so the bug survives. Boundary testing tries just below, exactly at and just above each meaningful limit, for example 99, 100 and 101 when the rule allows a maximum of 100 items. Boundaries also exist in lengths, dates, sizes and counts, not only in numbers. It is a cheap technique because a few values expose a whole class of mistakes.
What this question explores
Whether you know why errors cluster at limits and can choose the values that expose them.
Common mistakes
Saying boundary values are just the smallest and largest numbers, without testing either side.
Believing a few random mid-range values are enough to prove a rule works.
Practise a follow-up
What are the boundary values for a text field limited to 20 characters?
How do boundaries change for a rule with two ranges, such as tiered discounts?
5. A ticket can be Open, Pending or Closed. What tests would you design?
Answer guide
I draw the states and the events that move between them, then design tests for every valid transition, for example Open to Pending when the customer replies. Just as important are the forbidden ones, such as Closed straight to Pending, which the system should reject clearly. I add repeated actions like closing twice, checks on who is permitted to make each change, and confirmation that the history records each step. Special cases include reopening a closed ticket and an automatic timeout, where the clock and the resulting state must both be right.
What this question explores
Whether you cover allowed and disallowed transitions, permissions and history from a simple state model.
Common mistakes
Testing only the happy path from Open to Closed and ignoring invalid transitions.
Overlooking who is allowed to change the state and whether each change is recorded.
Practise a follow-up
How would you test a timeout that closes a Pending ticket automatically?
What is the difference between all-states and all-transitions coverage?
6. You have two hours to assess a new approval workflow. How would you make the result useful?
Answer guide
With two hours, I would agree with the owner what matters most, such as the consequential rules, roles, transitions and recovery paths. Then I use focused examples and exploration, for instance an approval above the limit, a rejection, and a reassignment, and keep clear evidence. In the report I state what I tested and the exposure that remains, so a short assessment is not mistaken for comprehensive approval. If the owner wants a go or no go, I give a recommendation with confidence level, explaining that unexamined areas could still hide serious defects.
What this question explores
Whether you can prioritise with the owner under time pressure, produce useful evidence and be explicit that a short assessment is not full approval.
Common mistakes
They try to cover every feature superficially and so find only trivial issues in the time given.
They report the workflow as approved after two hours without describing what was not tested.
Practise a follow-up
How would you decide in the first ten minutes what to test first?
What would you say if the sponsor wants a simple pass or fail from two hours of work?
7. How is exploratory testing different from random clicking?
Answer guide
Exploratory testing is structured learning while testing. I begin with a charter that names the area and goal, set a timebox, and then adapt each next step to what I observe, so design and execution happen together. I keep notes of the paths followed, questions raised and defects found, and afterwards debrief on what was covered and what remains uncertain. Random clicking has no goal, no record and cannot be reviewed. Used well, exploration finds surprising problems that scripted cases miss and complements them.
What this question explores
Whether you can describe exploratory testing as a disciplined, accountable activity rather than unplanned poking.
Common mistakes
Describing it as testing without plans, where you click around until something breaks.
Keeping no notes, so nobody can tell what was covered or reproduce the defects found.
Practise a follow-up
How would you write a charter for a new checkout feature?
How do you report exploratory coverage to a manager who wants numbers?
8. What negative tests would you run for a file upload?
Answer guide
For a file upload I try things a normal user should not do: a wrong file type, a file above the size limit, an empty or corrupt file, a very long name or one with special characters, and a duplicate name. I also cut the connection midway, try without permission and upload while another upload is running. In each case the system should show a clear, safe message and leave no half-saved file or record behind. An executable renamed as an image is a useful example, because it shows whether the type is really checked on the server.
What this question explores
Whether you can think of invalid, hostile and interrupted uploads and expect safe failure behaviour.
Common mistakes
Testing only that a valid picture uploads and stopping there, with no invalid cases.
Reading the error message on screen but not looking for a partial file or record left behind.
Practise a follow-up
How would you test the maximum file size limit?
What security risks come with file uploads, and how would you probe for them?
A useful defect report lets someone else reproduce and judge the problem without asking questions. It gives a clear title, the build and environment, preconditions, precise numbered steps, the expected result and the actual result, plus evidence such as a screenshot, log or video. I add the impact and how often it happens, for example every time or one in five tries. The tone stays factual and never blames the developer. A vague report like the page is broken wastes time on both sides.
What this question explores
Whether you write reports that a developer can reproduce and prioritise without a conversation.
Common mistakes
Writing a one-line report such as login fails, with no steps, build or evidence.
Combining several separate problems in one report or using a blaming, emotional tone.
Practise a follow-up
What would you do if the defect happens only sometimes?
How do you decide whether an issue is one defect or two?
10. How do you trace changing requirements to tests?
Answer guide
I keep a living link from each approved requirement or story to its acceptance criteria, the test cases that cover it, the results and any defects, usually in the test management or work tracking tool rather than a spreadsheet. When scope changes, the change updates the requirement, and the links flag which tests need review, retirement or addition. This shows gaps, such as a requirement with no test, and orphans, such as tests with no requirement. The value is impact analysis: I can say what a change touches and what evidence we have.
What this question explores
Whether you maintain requirement-to-test links as scope moves and use them for impact analysis.
Common mistakes
Building a traceability matrix once at the start and never updating it as requirements change.
Treating traceability as paperwork for auditors with no use in planning or impact analysis.
Practise a follow-up
How would you handle a requirement that changes mid-sprint?
What would you do with tests that trace to no requirement?
11. A business user says a function works but rejects the workflow. How do you respond?
Answer guide
I would not argue; I would understand it. I ask the user to walk through the real task and capture the pain point, such as too many steps or a missing approval, in their own words. Then I compare it with the agreed acceptance criteria to see whether it is a defect, a gap in the requirement or a new change request. That classification matters because it decides who pays and when it is fixed. The product decision owner makes the call to change, defer or accept, and I keep the discussion on the business outcome, not on who was right.
What this question explores
Whether you treat user rejection as useful feedback and route it correctly between defect, gap and change.
Common mistakes
Insisting the function meets the specification, so the user must be wrong.
Agreeing to every complaint and changing the workflow without approval from the decision owner.
Practise a follow-up
How would you prevent this kind of rejection earlier in the project?
Who pays for a change discovered during UAT, and how do you record it?
12. What manual checks would you do for an important web form?
Answer guide
Automated scans catch only a portion of accessibility problems, so I add manual checks. I complete the form using the keyboard alone, watching for a logical tab order, a visible focus indicator and no traps. I confirm each field has a proper label, that errors are announced and explained next to the field, and that colour is not the only signal. A quick pass with a screen reader shows whether the reading order and instructions make sense. Zooming to two hundred percent is another cheap test, and findings go to the team as defects with the affected user group.
What this question explores
Whether you know that accessibility needs hands-on checks with keyboard and assistive technology beyond automated tools.
Common mistakes
Running an automated scanner once and declaring the form accessible.
Checking only colour contrast and ignoring keyboard use, labels and error announcements.
Practise a follow-up
How would you test error messages so a screen reader user notices them?
Which accessibility guidelines would you reference in a test plan?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.