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.
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.
Testing shows the presence of defects but cannot prove their absence; exhaustive testing is impossible; early testing saves time and money; defects cluster in a small number of modules; the pesticide paradox means repeated tests stop finding new bugs; testing is context dependent; and the absence of errors is a fallacy — software with no known defects can still be unusable if it solves the wrong problem.
A Decision Table maps combinations of input conditions to the expected system actions. You use it when behaviour depends on several conditions interacting — for example a discount that depends on customer type, order size, and promo code. It makes missing combinations obvious and converts directly into test cases, which is why it is the standard technique for complex business rules.
A test case describes precise steps, test data, and an expected result — it is repeatable by anyone and suits regulated or complex functionality. A checklist is a list of things to verify without prescribed steps, relying on the tester's judgement. Checklists are faster to write and maintain and fit exploratory work or stable, well-understood areas; test cases fit onboarding, audits, and features where the exact flow matters.
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 →