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. Middle: deeper understanding, optimization, and real-world situations.
You select by risk, not by coverage. That means what changed in this release and what touches it, the flows that lose money if broken — auth, checkout, payment — and the areas with the most defect history. Then you say out loud what you did not run, so the decision to ship is the team's and not silently yours.
You do not decide that alone, but you frame it: how many users hit it, how often, is there a workaround, what does the fix risk breaking. A cosmetic misalignment on a rarely used screen with a release tomorrow is a legitimate "not now". What is not legitimate is quietly closing it — it goes in the backlog with the reasoning, otherwise the same bug gets refound every quarter.
Start by assuming the environments differ, not that the test is wrong. Compare data, configuration, feature flags, versions, and timing — staging is usually slower, which exposes race conditions and implicit waits. Then check whether the test depends on state another test left behind. Declaring it flaky and rerunning is what turns a real environment bug into a permanently ignored red.
Status codes for both success and failure, the response schema and types, required versus optional fields, and what happens with missing, extra, or wrong-typed fields. Then authorisation — the same request without a token and with someone else's token. Finally the boundaries: empty arrays, huge payloads, and repeated calls, since idempotency is where API bugs hide.
You do not wait for perfect requirements, you make the ambiguity visible. Write down how you interpreted it, list the cases the spec does not answer, and take those to the analyst or product owner before you build cases on a guess. Questions asked before development is finished cost a conversation; the same questions asked after cost a rework.
It says most checks should be fast unit tests, fewer integration tests, and very few slow end-to-end ones. For manual QA the consequence is that your time is wasted re-running things a unit test already covers. Manual effort belongs where humans are better than machines: exploratory testing, usability, and scenarios nobody thought to automate.
A bug is behaviour that contradicts a requirement, a specification, or reasonable user expectation. A feature request asks for behaviour that was never agreed. The grey zone is the third case — the spec is silent and the behaviour is bad — and arguing about the label there wastes time. Describe the impact, let the product owner decide the label, and make sure it is not lost either way.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle Manual QA interview →