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

🎓 Graduate 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·Graduate, Career switcher, Junior QA

// ROUND STRUCTURE

  1. 1
    Warm-up— 5 min

    Motivation, background, and what drew you to QA.

  2. 2
    Fundamentals— 12 min

    Basic testing concepts, test case writing, and bug reporting.

  3. 3
    Soft skills and learning— 8 min

    Collaboration, handling disagreement, and how you pick up new skills.

  4. 4
    Wrap-up— 5 min

    Candidate questions and interviewer summary.

// INTERVIEW QUESTIONS

  1. 01

    Why do you want to work in QA? What drew you to testing rather than another tech role?

  2. 02

    Write a bug report for a Submit button that does nothing when clicked. What fields do you include and what do you write in each?

  3. 03

    What is the difference between a test case and a test scenario? Give an example of each for a login page.

  4. 04

    You are given a registration form to test but there is no requirements document. How do you decide what to test?

  5. 05

    What is the difference between black-box testing and white-box testing? Give a concrete example of each.

  6. 06

    A developer tells you your bug report is wrong — the feature is working as intended. How do you respond?

  7. 07

    How do you stay organised when you are testing multiple features at the same time?

  8. 08

    Tell me about something you taught yourself recently. How did you go about learning it, and how do you know you understood it?

// EXPECTED ANSWER POINTS

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

  1. Demonstrates genuine interest in quality, user outcomes, or problem-solving — not 'could not get a developer role.' Strong answers name a specific moment: using software with a frustrating bug, discovering QA as a discipline, or caring about the end-user experience. Motivation anchored in craft signals longevity.

  2. Bug report fields: Title (specific — e.g. 'Submit button on registration form does not respond to click on Chrome 124/macOS 14'), Steps to reproduce (numbered, self-contained, starting from a clean state), Expected result, Actual result, Environment (browser, OS, device), Severity, Attachments (screenshot or recording). Each field has a purpose — the title tells a developer where to look; the steps let them reproduce without asking questions.

  3. Test scenario: a high-level user goal or journey (e.g. 'User can successfully log in'). Test case: a specific, step-by-step procedure with exact inputs and a clear expected result (e.g. 'Enter email: test@example.com, password: Correct1 — expected: redirect to dashboard'). One scenario maps to many test cases: valid login, wrong password, locked account, empty fields, very long inputs.

  4. Start from first principles: list all inputs, outputs, and user interactions visible on the form. Apply equivalence partitioning (valid input class, invalid input class) and boundary value analysis for length-limited fields. Consider security basics: SQL injection in name fields, very long inputs. Prioritise by risk — required fields and submission errors matter most for a registration form.

  5. Black-box: testing via the interface against expected behaviour, with no knowledge of the internal code. Example: submitting a login form and checking the redirect. White-box: testing with knowledge of internal code paths or logic. Example: a unit test that checks every branch of a password-validation function. Most manual QA is black-box; unit tests are typically white-box. Both add value at different layers of the test pyramid.

  6. Do not capitulate immediately or become confrontational. Ask a clarifying question: 'Can you point me to where the intended behaviour is documented, so I can understand what I missed?' If the documentation supports the developer, update and close the report. If it does not, or documentation is absent, escalate through the agreed process — QA lead or product owner — with evidence. The goal is shared understanding, not winning an argument.

  7. Prioritise by risk and deadline: most critical or blocked features first. Use a tracking tool or spreadsheet with status columns. Break work into focused sessions with a defined goal (e.g. 'test the happy path of feature A'). Communicate blockers and scope risks to the team early rather than quietly falling behind. Ask for help when genuinely overloaded.

  8. Strong answers name a specific topic, describe the learning method (documentation, tutorials, deliberate practice, a small project), and articulate what they now understand that they did not before. The topic itself does not matter — the process and self-awareness are the signal. 'I watched some YouTube videos' with no follow-through is a weak answer.

// SCORING RUBRIC

Strong (4-5)

Gives concrete examples even without professional experience. Demonstrates structured thinking — approaches unfamiliar problems systematically rather than guessing. Shows curiosity about quality and a genuine collaborative instinct. Has already done self-directed study: a course, a personal project, or hands-on practice with a testing tool.

Acceptable (3)

Understands core vocabulary and explains concepts correctly. Has engaged with at least some self-study. Shows no red-flag attitudes toward developers or quality processes. Answers are correct but mostly abstract — no personal examples from practice or real projects.

Weak (1-2)

Cannot write a basic bug report or names fewer than three fields. Confuses test case with test scenario. Becomes defensive when challenged. Has done no self-directed learning since deciding to pursue QA. Describes testing as 'clicking around to find problems' with no structure behind it.

// RED FLAGS

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

  • Cannot name even three fields in a bug report without prompting.

  • States their motivation for QA is 'could not get a developer role' with no positive interest in quality.

  • Becomes defensive or dismissive when told a bug report might be wrong.

  • Has done no self-directed learning — no courses, no projects, no reading — since deciding to pursue QA.

  • Cannot explain the difference between an expected result and an actual result in a bug report.

  • Describes testing as purely clicking around with no structure or documented output.

// FOLLOW-UP QUESTIONS

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

  1. 01

    What QA-related project, course, or book have you engaged with since deciding to pursue this career?

  2. 02

    If you found a critical bug 30 minutes before a scheduled release, what would you do?

  3. 03

    How would you test a vending machine? Walk me through your thinking from the beginning.

  4. 04

    What is boundary value analysis? Give me an example using a quantity input field on a shopping page.

// SELF-ASSESSMENT CHECKLIST

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

  • I explained my motivation for QA with a specific example or moment, not a generic statement about liking computers.
  • I included at least five named fields in the bug report and wrote a specific, actionable title for the button example.
  • I gave an example of both a test scenario and a test case for the login page — not just definitions.
  • I described a structured approach to testing with no requirements document, using risk to decide where to start.
  • I responded to the developer pushback scenario collaboratively — asking for documentation, not escalating immediately or caving.
  • I described a real learning approach in question 8 with a specific topic, method, and outcome.

// RECOMMENDED NEXT MOCK

📝 Manual QA mock interview

Beginner · 30 min

// STUDY THESE NEXT

Manual QA role track →Start here guide →All question banks →Practical assignments →