A Manual QA interview checks your grasp of testing theory, test design techniques, and your ability to write bug reports a developer can actually act on. Below are the questions asked most often at Junior and Middle level, each with a model answer. Junior: core theory, definitions, and simple practical cases.
Verification asks whether we built the product right — does it match the specification, the design, the agreed requirements. Validation asks whether we built the right product — does it actually solve the user's problem. A feature can pass verification completely and still fail validation, which is how teams ship something that matches the spec and nobody wants.
You split the input into classes where every value should behave the same, then test one value from each instead of all of them. Here that gives three partitions: below 18, from 18 to 65, and above 65, plus the invalid classes — letters, empty, negative. The point is coverage without redundancy: if 30 passes, 31 tells you nothing new.
Bugs cluster at the edges of a range, because that is where off-by-one errors and wrong comparison operators live. For a field accepting 18 to 65 you test 17, 18, 19 and 64, 65, 66. Partitioning tells you which ranges exist; boundary analysis tells you where inside them the defects actually are.
A usable report has a title that says what is broken, exact reproduction steps, expected versus actual result, environment, and evidence — a screenshot, video, or log. What makes a report useless is a missing precondition or a step the reporter did without noticing, because the developer cannot reproduce it and closes it as "works on my machine".
Severity is technical impact, priority is how soon it should be fixed, and they are set by different people — severity by the tester, priority by the product owner. A typo in the company name on the landing page is low severity and top priority. A crash in an admin screen used twice a year is high severity and low priority.
No, and this is one of the seven ISTQB principles. Testing can show that defects are present; it can never show that none remain, because exhaustive testing of every input and path is impossible for any real system. What testing gives you is evidence to decide whether the risk is acceptable — not a guarantee.
A test case spells out preconditions, steps, and expected result, so anyone can run it identically. A checklist just names what to cover and leaves the how to the tester. Test cases are worth their cost for regulated or high-risk flows and for people new to the product; checklists win for exploratory work and for a team that knows the system, where full cases become documentation nobody updates.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Junior Manual QA interview →