Top 50 QA Engineer Interview Questions and Answers

QA engineering interviews test both technical knowledge and practical judgment. This guide covers the questions you're most likely to encounter, with answers that go beyond surface-level definitions.

Fundamentals

1. What is the difference between testing and debugging?

Testing is the process of finding defects — executing software with the intent of finding failures. Debugging is the process of diagnosing and fixing a known defect — understanding why the software failed and correcting it. Testers find and report defects; developers typically debug and fix them, though the roles can overlap.

2. What are the 7 ISTQB testing principles?

1. Testing shows the presence of defects, not their absence — you can prove bugs exist, not that none remain
2. Exhaustive testing is impossible — you must prioritize and make risk-based decisions
3. Early testing saves time and money — the cost of fixing a bug rises with each phase it survives
4. Defects cluster together — most bugs concentrate in a small number of components (Pareto principle)
5. Tests wear out — running the same tests repeatedly becomes less effective; vary your approach
6. Testing is context-dependent — a safety-critical medical device needs different testing than a social media app
7. Absence-of-errors fallacy — a bug-free system that doesn't meet user needs has still failed

3. What is the difference between verification and validation?

Verification answers: "Are we building the product right?" — checking that the product conforms to specifications (does the code match the design?).

Validation answers: "Are we building the right product?" — checking that the product meets user needs and requirements (does the product do what users actually need?).

4. Explain the test pyramid.

The test pyramid describes an optimal balance of test types:

• Bottom (largest): unit tests — fast, cheap, high coverage of individual functions
• Middle: integration/service tests — verify components work together
• Top (smallest): end-to-end/UI tests — few, slow, expensive, test user-facing behavior

Inverting the pyramid (many E2E tests, few unit tests) leads to slow, flaky, expensive CI.

5. What is the difference between smoke testing and sanity testing?

Smoke testing verifies that the most critical functionality works after a new build — the build is "not on fire." It's wide but shallow.

Sanity testing is a narrow, focused regression test after a small change — verifying that the specific fix or change works correctly without introducing regressions in that area.

6. What is regression testing?

Re-executing previously passing tests after a change to verify that existing functionality hasn't broken. Regression tests should be automated wherever possible — they run on every build.

7. What is exploratory testing?

Simultaneous learning, test design, and test execution where the tester designs and executes tests on the fly based on what they discover. It's structured (guided by charters or risk areas) but not scripted. Effective for finding bugs that scripted tests miss.

8. What is boundary value analysis?

Testing at the boundaries of input domains — where bugs most often hide. For a field accepting 1–100, you'd test 0, 1, 2, 99, 100, 101. Boundaries include the minimum, maximum, and values just outside the valid range.

9. What is equivalence partitioning?

Dividing inputs into partitions where all values in a partition are expected to behave the same. Instead of testing every possible number from 1–100, test one representative value from each partition (e.g., valid range: 50; below range: 0; above range: 150).

10. What is a test case vs a test scenario?

A test scenario is a high-level description of what to test: "user can log in." A test case is a specific, detailed procedure: steps, input data, expected result, pass/fail criteria. One scenario typically maps to multiple test cases (valid credentials, invalid password, account locked, etc.).

Test Management

11. What information should a bug report contain?

• Unique identifier and title
• Environment (OS, browser, version, device)
• Steps to reproduce (precise, numbered)
• Expected result
• Actual result
• Severity and priority
• Screenshots or video
• Logs if relevant
• Reproducibility (always/intermittent)

12. What is the difference between severity and priority?

Severity describes the technical impact of the defect (critical, major, minor, trivial). Priority describes when it should be fixed based on business impact (high, medium, low).

A logo being slightly off-color has low severity but might be high priority before a product launch. A crash that occurs only in an edge case might have high severity but low priority if few users hit that path.

13. How do you decide what to test when time is limited?

Risk-based testing: prioritize test cases by the probability of failure multiplied by the impact of failure. High-value, high-usage, recently changed, and previously bug-prone areas get more test coverage. New, low-usage, or unchanged areas with low business impact get less.

14. What is test coverage and how do you measure it?

Test coverage measures how much of the application or codebase is exercised by tests. Types include:

• Requirements coverage (% of requirements with test cases)
• Code coverage (% of lines/branches executed by tests)
• Risk coverage (% of identified risk areas tested)

High code coverage doesn't guarantee quality — you can have 100% line coverage with tests that don't assert meaningful outcomes.

15. What is a test plan? What does it include?

A test plan documents the scope, approach, resources, and schedule for testing. Key sections:

• Test objectives and scope
• Test strategy and approach
• Resources and responsibilities
• Schedule and milestones
• Entry and exit criteria
• Risk and contingencies
• Deliverables

Automation

16. What factors determine whether a test should be automated?

Good candidates for automation:

• Tests run frequently (regression suites, smoke tests)
• Tests with large data sets
• Stable functionality that doesn't change often
• Performance and load tests
• API-level tests

Poor candidates:

• Rarely run tests
• UI tests on rapidly changing designs
• Exploratory testing
• One-time tests

17. What is the Page Object Model?

A design pattern for UI test automation that abstracts page elements and interactions into reusable classes. Each page/component has a corresponding class with methods representing user actions. Tests use these methods rather than directly manipulating DOM selectors. Benefits: maintainability (change selector in one place, not 30 tests), readability, reduced duplication.

18. What is flaky test and how do you address it?

A flaky test passes sometimes and fails sometimes without code changes. Common causes: timing issues, test data conflicts, network dependencies, race conditions, environment inconsistencies.

Fix approaches: add explicit waits instead of sleeps, ensure test isolation, mock external dependencies, investigate root cause rather than retrying. Never mark a flaky test as "expected flaky" — fix it.

19. What is the difference between a stub and a mock?

Both replace real dependencies in testing.

A stub provides predefined responses to calls — it's a simplified stand-in.

A mock is a stub that also verifies interactions — it checks that specific methods were called with specific arguments.

Use stubs when you just need to control behavior; use mocks when you need to verify that specific interactions occurred.

20. What is continuous testing?

Running automated tests throughout the CI/CD pipeline — not just before release. Tests run on every commit, every PR, and in production (via monitoring). The goal is to get fast feedback on every change, preventing defects from accumulating.

API Testing

21. What HTTP status codes should every tester know?

• 200 OK — success
• 201 Created — resource created
• 400 Bad Request — invalid input from client
• 401 Unauthorized — not authenticated
• 403 Forbidden — authenticated but not authorized
• 404 Not Found — resource doesn't exist
• 409 Conflict — state conflict (duplicate, etc.)
• 422 Unprocessable Entity — validation error
• 429 Too Many Requests — rate limited
• 500 Internal Server Error — server-side failure
• 503 Service Unavailable — service down or overloaded

22. What do you test in API testing?

• Correct response codes for valid/invalid inputs
• Response body structure and data types
• Authentication and authorization
• Error messages and formats
• Edge cases: empty input, maximum values, special characters
• Performance: response time under load
• Rate limiting behavior
• Idempotency (PUT, DELETE should be idempotent)

Agile and DevOps

23. How does testing fit in an agile sprint?

Testing happens throughout the sprint, not just at the end:

• Sprint planning: identify acceptance criteria and edge cases
• During development: test early with developers, write automated tests
• End of sprint: regression testing, exploratory testing, demo prep
• No separate "testing phase" — testing is parallel to development

24. What is shift-left testing?

Moving testing activities earlier in the development lifecycle. Instead of testing after development is complete, testers are involved in requirements, participate in design discussions, and test while code is being written. Catches defects when they're cheapest to fix.

25. What is a definition of done from a QA perspective?

A story is "done" when:

• Acceptance criteria are met and verified
• Automated tests are written and passing
• No known critical or high-priority bugs
• Code is reviewed and merged
• Testing evidence is documented
• Regression suite passes

26. What is shift-right testing?

Testing in production — canary deployments, A/B testing, feature flags, monitoring, and chaos engineering. The complement to shift-left: you verify behavior in production conditions, not just pre-production environments.

Performance Testing

27. What is the difference between load testing and stress testing?

Load testing verifies system behavior under expected load — does it handle normal traffic correctly?

Stress testing pushes beyond expected limits to find the breaking point — at what load does the system fail, and does it fail gracefully?

28. What is a bottleneck and how do you find one?

A bottleneck is the resource or component that limits system performance. Finding it: profile under load, look for the resource with the highest utilization or longest wait times (CPU, memory, database connections, network I/O, lock contention). The fastest way to improve performance is to remove the bottleneck, not optimize non-bottlenecks.

Security Testing

29. What is OWASP Top 10?

The Open Web Application Security Project's list of the 10 most critical web application security risks:

1. Broken Access Control
2. Cryptographic Failures
3. Injection (SQL, etc.)
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery

30. What is SQL injection and how do you test for it?

SQL injection is entering SQL code in user inputs to manipulate database queries. Test by entering values like ' OR '1'='1, '; DROP TABLE users;--, and 1' AND '1'='1 in input fields. A vulnerable application will behave unexpectedly. Prevention: parameterized queries, prepared statements, input validation.

Behavioral / Situational

31. How do you handle disagreement with a developer about whether something is a bug?

Reference the requirements or acceptance criteria. If the spec is ambiguous, involve the product owner. Frame the discussion around user impact rather than "you're wrong." Document the discussion and its resolution. If genuinely unclear, create a story to clarify the requirement.

32. A release is tomorrow and you find a critical bug. What do you do?

Report it immediately with clear severity/priority. Notify the relevant stakeholders — developer, QA lead, product owner. Assess: is there a workaround? Can it be fixed safely in time? Provide enough information to make a ship/hold decision. Don't hide bugs to avoid delay — that decision belongs to stakeholders, not the tester.

33. How do you test something you have no requirements for?

Use exploratory testing guided by:

• User personas and likely use cases
• Similar products you've tested
• Business domain knowledge
• Risk areas (authentication, payments, data handling)
• Common defect patterns from previous projects

Also: the requirement gap is itself a finding — document it and request clarification.

34. How do you prioritize your test cases?

By risk (probability × impact), business criticality, frequency of use, areas of recent change, and previously defect-prone areas. Core user journeys that represent the most business value get highest priority.

35. Describe your approach to testing a login form.

Functional: valid credentials, invalid password, invalid username, both invalid, empty fields, case sensitivity, special characters, max length inputs, remember me functionality.

Security: SQL injection attempts, XSS in input fields, account lockout after N failures, session token handling, password transmission (HTTPS only), browser back button after logout.

UX: error message specificity (don't reveal whether username or password was wrong), accessibility, mobile keyboard behavior, paste functionality.

Performance: response time, behavior under load.

Tools and Technology

36. What test management tools have you used?

Common answers: Jira + Xray, TestRail, Zephyr, Azure DevOps Test Plans, qTest, Testrail. Be ready to discuss how you organized test suites, linked test cases to requirements, and reported test results.

37. What automation frameworks are you familiar with?

Depending on your stack: Selenium, Playwright, Cypress, WebdriverIO, Appium (mobile), Postman/Newman (API), JMeter/k6 (performance), pytest/JUnit (unit). Be specific about languages and versions you've worked with.

38. How do you choose between Cypress and Playwright?

Both are excellent. Cypress is more opinionated, has better developer experience for most teams, excellent debugging. Playwright has broader browser support (Safari/WebKit), multi-tab testing, better parallelization, and native mobile testing support. For most web apps: Playwright edges ahead in 2025 for new projects. For teams already on Cypress: the migration cost is rarely worth it.

Advanced

39. What is mutation testing?

Introducing small changes (mutations) to source code and checking whether tests catch them. If a mutation (e.g., changing > to >=) goes undetected by tests, your tests have a gap. Mutation testing measures test suite quality, not just coverage. Tools: Stryker (JS/TS), PIT (Java), mutmut (Python).

40. What is property-based testing?

Testing with randomly generated inputs rather than specific examples. You define properties that should always hold (e.g., "sorting is idempotent: sorting twice gives the same result as sorting once") and the framework generates hundreds of test cases automatically. Libraries: QuickCheck (Haskell), Hypothesis (Python), fast-check (TypeScript).

41–50. Behavioral Questions (Briefly)

41. Tell me about a bug you found that had significant business impact. 42. Describe a time you improved a test process. 43. How do you keep your testing skills current? 44. Tell me about a time you had to push back on a release date. 45. How do you build relationships with developers? 46. Describe your approach to testing a feature with no documentation. 47. Tell me about a time testing caught something that would have been expensive in production. 48. How do you measure the effectiveness of a test suite? 49. Describe a time you had to test under significant time pressure. 50. Where do you see the QA role evolving in the next 5 years?

For questions 41–50, prepare specific stories from your experience using the STAR method (Situation, Task, Action, Result).

Final Preparation Advice

Before the interview, review the company's tech stack and think about testing challenges specific to their product. Behavioral questions are just as important as technical ones at mid-senior levels. Show that you think about testing strategically, not just mechanically.

Tools change; fundamentals don't. Strong fundamentals combined with demonstrated ability to use modern tools like HelpMeTest for AI-powered test creation show that you can deliver practical value quickly.