QA Interview Preparation Checklist: Everything You Need to Know

If you are preparing for a QA or SDET interview, here is the truth: most candidates do some studying, but very few prepare in a structured way. That is why interviews often feel unpredictable. One round asks manual testing fundamentals, another asks automation architecture, and suddenly you are expected to explain SQL joins or CI pipelines under pressure.

This guide gives you a complete checklist you can follow step by step. Think of it like a coaching plan from a senior engineer: what to focus on, how deep to go, and how to convert knowledge into interview performance.

1) Understand What Round You Are Facing

Before you start studying random topics, identify exactly what type of interview round you are entering. This one move saves a lot of wasted effort.

HR Screening: What they actually check

HR screening is less about deep technical skill and more about fit, communication, expectations, and consistency. Recruiters are evaluating whether your resume story matches what you say, whether your salary and location expectations are realistic, and whether you can clearly explain your current role. They also look for signals of reliability: notice period clarity, role motivation, and professionalism in communication.

Prepare concise responses for: “Tell me about yourself,” “Why are you looking for a change?”, and “Why this company?” Keep answers honest and structured. Avoid sounding like you are applying to every job equally.

Technical Round 1: Manual concepts and test design

This round usually checks testing fundamentals. Expect questions on SDLC/STLC, test levels and types, defect reporting, severity vs priority, and practical test case writing. Interviewers often give a feature (for example, login page, search box, shopping cart) and ask you to design test scenarios live. They want to see whether you can think in coverage, risk, and edge cases—not whether you memorized definitions.

Technical Round 2: Automation, coding, and sometimes system design

This round validates depth. You may be asked to write code, explain your automation framework, debug flaky tests, design a Page Object Model, or discuss API/database validation strategy. For SDET-focused roles, interviewers may include low-level design topics such as building test utilities, handling parallel execution, and integrating tests with CI/CD.

Managerial round: Behavioral + process maturity

This round evaluates ownership, collaboration, conflict handling, and quality mindset. Managers look for how you prioritize testing in tight timelines, escalate risks, work with developers, and drive release decisions. You should be ready with real examples from past projects using a clear structure (situation, action, result).

Always ask the recruiter this question

Ask directly: “Can you share what each interview round covers and what depth is expected?” This question is simple, professional, and powerful. It helps you target preparation and shows you are intentional.

2) Manual Testing Concepts to Know Cold

Even automation-heavy roles evaluate manual reasoning. If you cannot design good tests conceptually, your automation code will only automate weak coverage.

Start with SDLC and STLC. You should understand where QA contributes in requirement analysis, planning, design, execution, defect triage, and closure—not just “testing after development.” Then master key testing types and when to use each.

Smoke testing is a narrow, high-value check to confirm build stability before deeper testing. Sanity testing is focused verification after small changes or bug fixes. Regression testing ensures existing functionality still works after changes. UAT validates whether the product meets business/user expectations in realistic workflows. Interviewers often ask for real examples; avoid textbook-only answers.

Test case writing is a core differentiator. Be ready to create positive, negative, boundary, and exploratory scenarios on the spot. Positive tests verify expected behavior with valid input. Negative tests validate resilience with invalid or missing input. Boundary tests target edge limits where defects cluster. Exploratory testing uses informed investigation to uncover issues not captured by scripted tests.

You should also explain defect lifecycle clearly: New, Assigned, In Progress, Fixed, Retest, Reopened, Closed (or equivalent variants). More importantly, show that you understand workflow ownership—who triages, who verifies, and what makes a bug report actionable.

Severity vs priority is a frequent trap question. Severity is technical impact; priority is business urgency. A cosmetic typo on the homepage may be low severity but high priority before launch. A rare backend crash in an admin-only flow may be high severity but lower immediate priority depending on release risk.

Finally, clarify Agile QA expectations. In Agile teams, QA is involved early in story refinement, defines test strategy per sprint, collaborates with developers on acceptance criteria, and contributes to automation and release quality signals continuously.

Manual Testing Checklist (12 items)

• I can explain SDLC and STLC with one real project example each.
• I can clearly differentiate smoke, sanity, regression, and UAT.
• I can write positive, negative, boundary, and exploratory test cases for a new feature.
• I can design test scenarios from a user story with clear acceptance criteria.
• I can explain defect lifecycle stages used in my current/last team.
• I can differentiate severity vs priority using realistic bug examples.
• I can write a high-quality bug report (steps, expected, actual, evidence, environment).
• I can explain risk-based testing and how I prioritize under time pressure.
• I can discuss Agile QA responsibilities across the sprint lifecycle.
• I can describe when to stop testing and what “exit criteria” means.
• I can explain traceability between requirements, test cases, and defects.
• I can walk through one feature and present complete manual test coverage.

3) Automation and Technical Skills

This is where many candidates either stand out or get exposed. Your goal is not to claim every tool; your goal is to demonstrate credible depth in the tools you list.

Selenium or Playwright: What depth is expected

At minimum, you should be able to set up a project, organize tests, and execute stable scenarios. You must understand locators, waits, assertions, and reusable architecture like Page Object Model (POM). If you use Playwright, know auto-waits, fixtures, and trace/debug tools. If you use Selenium, know explicit waits, WebDriver lifecycle, and common flakiness causes.

Depth target: enough to build and explain a small framework end-to-end on your own GitHub, including folder structure, test data strategy, and CI execution basics.

Programming basics (Java or Python): What depth is expected

You do not need to be a competitive programmer for most QA interviews, but you do need practical coding confidence. Be comfortable with loops, conditionals, functions, collections, OOP basics (class, object, inheritance/composition), and exception handling. Interviewers may ask you to process arrays/strings, parse response data, or design helper methods used in automation.

Depth target: you can write small working functions live without copying from memory aids and can explain trade-offs in readable code.

API testing (Postman or REST Assured): What depth is expected

Know request methods, status codes, headers, authentication basics, schema/field validation, and chaining calls via variables or extracted IDs. With Postman, understand environments and collections. With REST Assured (or equivalent), know how API tests integrate into code pipelines.

Depth target: you can design a small set of API validations for one workflow (create, fetch, update, delete) and discuss negative cases.

SQL: What depth is expected

SQL is a common weak spot, and interviewers know it. You should be comfortable writing SELECT, filtering with WHERE, joining tables with JOIN, aggregating with GROUP BY, filtering aggregates with HAVING, and handling NULL conditions correctly.

Depth target: you can write and explain medium-complexity validation queries from testing scenarios, not just textbook employee-table examples. If needed, review our SQL Interview Questions guide for focused practice before technical rounds.

CI/CD basics: What depth is expected

You are not expected to be a DevOps engineer for many QA roles, but you should explain what CI/CD does and how automated tests fit in. For example, GitHub Actions is a workflow automation platform that can run linting, tests, and reports on pull requests or schedules.

Depth target: you can explain a simple pipeline flow—code push triggers build, tests run, status checks gate merges, and artifacts/reports are generated.

4) What to Practice, Not Just Study

Reading alone creates false confidence. Interviews reward execution. Do these four exercises and you will be better prepared than most candidates.

Exercise 1: Write 20 test cases for Amazon search bar

Pick a familiar feature like Amazon search and create 20 high-quality cases covering functionality, input validation, boundary values, suggestions, filters, no-results behavior, and mobile responsiveness assumptions. Include both positive and negative scenarios. This builds real-time test design fluency.

Exercise 2: Build one Selenium/Playwright project on GitHub

Create a small but clean automation project with README, setup steps, test structure, and at least a few meaningful scenarios. Focus on clarity over scale. Interviewers trust candidates more when they can discuss code they actually built.

Exercise 3: Run 5 API tests against JSONPlaceholder

Use JSONPlaceholder (or similar public API) to design five tests that include status code checks, response body assertions, and at least one negative scenario. Practice explaining why each validation matters. This improves your ability to speak in test intent, not only tooling syntax.

Exercise 4: Write 10 SQL queries without looking up syntax

Set a timer and write queries from memory. Include joins, grouping, null handling, and one query that validates a business condition. This quickly exposes weak spots and builds interview-time confidence.

If you want extra practice after these, continue with question-based preparation such as our API Testing Interview Questions and SDET Roadmap posts to deepen both breadth and narrative confidence.

5) How to Answer Technical Questions

Strong candidates do not always know every answer immediately—they communicate their reasoning effectively.

Think out loud

Interviewers are evaluating process, not just final output. Say what you are checking, why you chose that approach, and what assumptions you are making. Silent thinking can look like confusion even when you are on the right path.

Ask clarifying questions

If a prompt is ambiguous, clarify scope before answering. Example: “Should I optimize for readability or runtime?” or “Do you want API-level tests or full UI workflow coverage?” Clarifying shows maturity and avoids solving the wrong problem.

Use this structure: define + example + edge case

A reliable answer pattern is: first define the concept clearly, then give a practical example, then mention one edge case or trade-off. This structure makes your responses sound complete and senior.

Never fake knowledge

If you have not used a tool deeply, say so directly and then explain what you do know plus how you would learn it quickly. Interviewers usually forgive gaps; they do not forgive bluffing.

6) Day-Before and Day-Of Checklist

Consistency beats last-minute panic. Use these checklists exactly.

Day-Before Checklist (10 items)

• Re-read the job description and map required skills to your preparation notes.
• Review your resume and be ready to explain every listed tool/project honestly.
• Prepare a 60–90 second self-introduction tailored to the role.
• Revise core manual concepts and one complete test design example.
• Revise one automation project architecture you can confidently explain.
• Practice 5 API and 5 SQL questions without external help.
• Prepare 3 behavioral stories (conflict, failure, ownership) with outcomes.
• Confirm interview timing, timezone, meeting link, and recruiter contact.
• Set up your laptop: IDE, browser, mic, camera, charger, stable internet backup.
• Sleep on time; cognitive clarity is a competitive advantage.

Morning-Of Checklist (5 items)

• Do a quick tech check (audio, camera, screen share permissions).
• Keep your resume, notebook, water, and interview notes ready.
• Review your intro and one project summary aloud once.
• Join 10 minutes early and settle before the interviewer arrives.
• Start calm, listen carefully, and answer with structure.

7) Common Reasons QA Candidates Fail

Knowing these failure patterns helps you avoid them deliberately.

1) They can define terms but cannot write test cases live

Interviewers often ask for immediate scenario design. Candidates who memorized theory but never practiced applied test writing struggle quickly.

2) They listed tools they have never really used

If your resume says Selenium, API, SQL, and CI/CD, expect follow-up depth questions. Overstating experience creates credibility gaps fast.

3) They have no project evidence to show

Even one small GitHub project can make a major difference. Without practical artifacts, claims remain abstract.

4) They give up when pushed back

Interviewers may challenge your approach intentionally. Strong candidates stay composed, evaluate feedback, and iterate.

5) They cannot explain their own project test strategy

A frequent red flag: candidates describe tools but cannot explain why they chose specific tests, what risks they prioritized, and how they measured quality.

Final Coaching Advice

Treat interview prep like a mini sprint plan: define scope, schedule focused practice, and review outcomes weekly. If you do that, you will enter interviews with clarity instead of anxiety. Your goal is not to sound perfect; your goal is to sound credible, structured, and execution-ready.

And remember: the best preparation is visible practice. Build one project, write real test cases, run real API checks, and solve SQL prompts by hand. That combination consistently separates shortlisted candidates from selected candidates.