// Interview Prep/Mock Interviews/Manual QA mock interview

📝 Manual QA mock interview

Set a timer, work through each round out loud, then score your answers against the rubric. No one is listening — the goal is honest self-assessment, not a perfect performance.

Beginner⏱ 30 min·Manual QA, Career switcher

// ROUND STRUCTURE

  1. 1
    Warm-up— 5 min

    Intro, background, and what you have tested before.

  2. 2
    Test fundamentals— 12 min

    Test case design, test types, equivalence partitioning, priorities.

  3. 3
    Defect management— 8 min

    Bug reporting, defect lifecycle, priority vs severity.

  4. 4
    Wrap-up— 5 min

    Candidate questions and interviewer summary.

// INTERVIEW QUESTIONS

  1. 01

    What is the difference between verification and validation? Give a concrete example of each.

  2. 02

    Walk me through how you write a test case. What fields do you include and why?

  3. 03

    What is the difference between regression testing and retesting?

  4. 04

    You find a critical bug 30 minutes before a release. What do you do?

  5. 05

    What is exploratory testing, and when do you use it instead of scripted testing?

  6. 06

    Describe the defect lifecycle from discovery to closure.

  7. 07

    How do you prioritise test cases when time is limited?

  8. 08

    What does 'done' mean from a QA perspective on a user story?

// EXPECTED ANSWER POINTS

Compare your answers to these points — one per question, in order.

  1. Verification = checking process and documentation match (are we building it right?); Validation = checking the product meets user needs (are we building the right thing?). Example: Verification reviews the design doc; Validation runs the app against user requirements.

  2. Test case fields: ID, title/objective, preconditions, test data, numbered steps, expected result, actual result, status, priority, severity. Each field prevents ambiguity when someone else executes the test.

  3. Regression testing re-runs existing tests after a code change to confirm nothing previously working is broken. Retesting runs a previously failed test after its defect is fixed to confirm the fix works.

  4. Assess severity and business impact immediately, notify the team lead and product owner, document the bug with full reproduction steps, and get an explicit go/no-go decision from stakeholders — not from QA alone.

  5. Exploratory testing is unscripted and tester-driven, guided by a charter (goal + scope + time-box). Use it for new, poorly-documented features; when scripted tests are passing but instinct says something is wrong; or when time-boxing discovery sessions.

  6. Defect lifecycle: New → Assigned → Open (In Progress) → Fixed → Retest → Closed. Side branches: Rejected (not a bug), Deferred (fix later), Duplicate (already logged). Each state has a clear owner.

  7. Prioritise by risk: critical paths and must-have requirements first, high-revenue or high-traffic flows second, edge cases last. Use a risk matrix if time allows. Communicate trade-offs explicitly to the team.

  8. Done from QA: all test cases written and executed, defects raised with severity, open defects resolved or risk-accepted by the product owner, test sign-off documented (even informally) before release.

// SCORING RUBRIC

Strong (4–5)

Gives concrete examples from real work, uses correct terminology throughout, shows structured process thinking. Can explain trade-offs (e.g., when not to use exploratory testing). Demonstrates collaboration, not gate-keeping.

Acceptable (3)

Answers correctly but abstractly — no examples from actual experience. Terminology is mostly right. Has a sense of process but cannot describe a real defect lifecycle they've used.

Weak (1–2)

Confuses basic concepts (test case vs test scenario, priority vs severity). Cannot name fields in a bug report. Describes testing as 'clicking around to find bugs.' No process awareness.

// RED FLAGS

Answers or behaviours that signal a weak candidate to the interviewer.

  • Cannot distinguish between a test case and a test scenario.

  • Describes QA as 'just clicking around to find bugs' with no structured approach.

  • Cannot name at least five fields in a bug report.

  • Has never written a formal test case document.

  • Blames developers for bugs without demonstrating any collaborative approach.

  • Cannot describe a concrete defect lifecycle — gives a vague 'fix and close' summary.

// FOLLOW-UP QUESTIONS

Questions a strong interviewer adds if you answered the main round well.

  1. 01

    How would you test a feature that has no user interface?

  2. 02

    What would you do if a developer says 'that's not a bug, that's by design' and you disagree?

  3. 03

    How do you test when requirements are incomplete or absent?

  4. 04

    What is boundary value analysis? Give an example using a numeric input field.

// SELF-ASSESSMENT CHECKLIST

Tick these off mentally after the mock. Be honest — this is for you, not for the interviewer.

  • I clearly explained verification vs validation with a concrete example — not just definitions.
  • I named at least five fields in a test case and explained why each exists.
  • I described the full defect lifecycle including the side branches (Rejected, Deferred) without prompting.
  • I gave a specific strategy for prioritising test cases under time pressure.
  • I demonstrated a collaborative response to the bug-near-release scenario, not a unilateral one.
  • I used correct QA terminology throughout — priority vs severity, regression vs retesting, etc.

// RECOMMENDED NEXT MOCK

🗣️ Behavioural QA interview

All levels · 30 min

// STUDY THESE NEXT

Manual QA role track →Manual QA prep plan →All question banks →Practical assignments →