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. Senior: architecture, trade-offs, mentoring, and decision-making.
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.
Functional testing verifies what the system does — that features behave according to requirements. Non-functional testing verifies how well it does it: performance, load, security, usability, accessibility, compatibility, and reliability. Non-functional defects are often more expensive to fix because they tend to be rooted in architecture rather than in a single line of code.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Senior Manual QA interview →