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 "are we building the product right?" — it checks the work against specifications and design documents, usually through reviews and static analysis. Validation asks "are we building the right product?" — it checks that the finished software actually solves the user's problem, through dynamic testing. Verification happens throughout development; validation happens against real requirements and users.
Equivalence Partitioning splits input data into groups where every value is expected to behave the same way, so testing one value per group is enough. For an age field of 1–120 the partitions are: valid 1–120, invalid below (0 and negatives), invalid above (121+), and invalid types (letters, symbols, empty). That gives four tests instead of 120.
Boundary Value Analysis targets the edges of each partition, because off-by-one errors cluster there. For a 1–100 field you test 0, 1, 2 at the lower edge and 99, 100, 101 at the upper edge. It is almost always used together with Equivalence Partitioning: partitions tell you which groups exist, boundaries tell you where they break.
Severity describes the technical impact of the defect on the system; Priority describes how urgently the business wants it fixed. They are set by different people — Severity usually by the tester, Priority by the product owner or manager. A crash in a rarely used admin export screen is high Severity but low Priority; a typo in the company name on the landing page is low Severity but high Priority.
A defect typically moves New → Assigned → Open (in progress) → Fixed → Retest → Closed. Alternative outcomes are Rejected (not a defect), Duplicate, Deferred (postponed to a later release), and Reopened when a retest shows the fix did not work. The exact statuses vary by team, but the important part is that every bug ends in a terminal state with a documented reason.
Smoke testing is a shallow, broad check that the build is stable enough to test at all — if login is broken, testing stops. Sanity testing is narrow and deep: after a specific fix, it verifies that one area works as expected. Regression testing is broad and repeated: it confirms that new changes did not break previously working functionality, and is the main candidate for automation.
Exploratory testing means designing and running tests at the same time — the tester learns the product and uses what they find to decide what to try next. It is structured: there is a charter, a time box, and notes. Ad-hoc testing is unstructured and undocumented, driven purely by intuition. Exploratory testing is repeatable and reportable; ad-hoc is not.
A usable bug report has a clear summary, environment (build, OS, browser, device), preconditions, steps to reproduce, actual result, expected result, severity, priority, and attachments such as screenshots or logs. Steps to reproduce matter most because a defect a developer cannot reproduce will usually be closed as "cannot reproduce" — the report loses all its value.
A test plan describes how testing will be carried out for a project or release. Typical sections are scope (what is and is not tested), approach and test levels, entry and exit criteria, environments and test data, roles and responsibilities, schedule, risks with mitigation, and deliverables. It is a management document — the goal is that anyone can see what will be tested, by whom, and when testing is considered done.
Positive: valid credentials log in and redirect correctly, "remember me" persists the session, password reset works end to end. Negative: wrong password, non-existent user, empty fields, SQL injection and XSS payloads, leading and trailing spaces, case sensitivity, extremely long input, account lockout after repeated failures. Also check non-functional aspects: the password is masked, the form works on mobile, credentials are sent over HTTPS, and error messages do not reveal whether the username exists.
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 →