QA Engineering Interview Questions

Question 1

What are the 7 principles of software testing?

Accepted Answer

Testing shows defects exist; exhaustive testing is impossible; early testing saves cost; defects cluster; pesticide paradox; testing is context-dependent; absence-of-errors fallacy. 1. Testing shows the presence of defects, not their absence — testing reduces the probability of undiscovered defects but cannot prove the software is defect-free. 2. Exhaustive testing is impossible — test everything is impractical; risk-based and priority-based testing is used instead. 3. Early testing saves time and money — defects found in requirements cost 1× to fix; in coding 10×; in production 100×. 4. Defects cluster — a small number of modules typically contain most defects (Pareto principle: 80% of defects in 20% of modules). 5. Pesticide paradox — repeating the same tests stops finding new defects; test cases must be reviewed and updated regularly. 6. Testing is context-dependent — testing a medical device requires different rigor than an e-commerce site. 7. Absence of errors fallacy — finding and fixing defects is useless if the system is unusable or doesn't meet user needs.

Question 2

What is the difference between verification and validation in QA?

Accepted Answer

Verification checks 'are we building the product right?' (process, documentation); validation checks 'are we building the right product?' (user needs, actual behavior). Verification is the process of evaluating work products (requirements, design, code, test plans) to ensure they conform to specified requirements — it's done WITHOUT executing the software. Activities: reviews, inspections, walkthroughs, static analysis. Example: verifying that a test plan covers all requirements in the RTM. Validation is the process of evaluating the finished software by executing it to ensure it meets user needs and business requirements. Activities: functional testing, UAT, exploratory testing. Example: having actual end-users run the payment flow and confirm it meets their real-world needs. A product can pass verification (built to specification) but fail validation (specification was wrong). Both are necessary — a well-specified wrong product and a poorly-specified right product are both failures.

Question 3

What is the STLC (Software Testing Lifecycle) and what are its phases?

Accepted Answer

STLC is the structured testing process: Requirement Analysis → Test Planning → Test Case Design → Test Environment Setup → Test Execution → Test Closure. 1. Requirement Analysis: QA reviews requirements for testability, identifies ambiguities, creates RTM draft, and raises clarifications. Output: testability assessment, QA requirement questions. 2. Test Planning: Define scope, strategy, resources, schedule, entry/exit criteria, and risk register. Output: Test Plan document. 3. Test Case Design: Write test cases with steps, expected results, test data; design equivalence partitions, boundary values. Output: Test Case Specifications, RTM. 4. Test Environment Setup: Configure test environments, prepare test data, install builds, verify environment readiness. Output: Environment readiness report. 5. Test Execution: Execute test cases, log defects, retest fixes, run regression. Output: Test Logs, Defect Reports. 6. Test Closure: Evaluate exit criteria, analyze lessons learned, archive test artifacts, produce Test Summary Report. Output: Test Completion Report, metrics summary.

Question 4

What is the difference between a test case, test scenario, and test script?

Accepted Answer

Test scenario: high-level 'what to test'. Test case: detailed 'how to test' with steps and expected results. Test script: automated code that executes a test case. Test Scenario: a high-level description of a functional area to be tested — 'Test user login functionality.' One scenario generates multiple test cases. Used in early planning when full detail isn't available. Test Case: a detailed, step-by-step procedure including preconditions, test steps, test data, expected result, actual result, and pass/fail status. Example: Precondition: User is on login page. Step 1: Enter valid email. Step 2: Enter correct password. Step 3: Click Login. Expected Result: User is redirected to /dashboard within 2 seconds. Test cases are traceable to specific requirements. Test Script: the implementation of a test case as automated code (Selenium, Cypress, Playwright). The script programmatically executes the steps and asserts the expected result. A test case can exist without a script (manual testing); a script always has a corresponding test case as its specification.

Question 5

What is the difference between severity and priority in defect management?

Accepted Answer

Severity is the technical impact of the defect on system functionality; priority is the business urgency to fix it. High severity doesn't always mean high priority. Severity (set by QA): measures how badly the defect affects the software. Levels: Critical (system crash, data loss, complete feature failure), High (major feature not working, no workaround), Medium (feature partially working, workaround exists), Low (cosmetic, minor inconvenience). Priority (set by Business/PM): measures how urgently the defect needs to be fixed relative to other work. Combinations: High Severity, High Priority — payment processing crash on checkout (fix immediately). High Severity, Low Priority — crash in rarely-used admin-only feature (fix next sprint, low user impact). Low Severity, High Priority — CEO's name spelled wrong on homepage (cosmetic but visible in tomorrow's demo). Low Severity, Low Priority — minor tooltip text error (backlog, fix whenever). QA sets severity objectively based on user impact; the business/PM sets priority based on release context, customer impact, and roadmap.

Question 6

What is the Requirements Traceability Matrix (RTM)?

Accepted Answer

An RTM is a document mapping each requirement to its test cases, ensuring every requirement is tested and every test case has a requirement basis. The RTM is a QA's accountability document — it proves that all requirements have been tested. Structure: rows are requirements (REQ-001, REQ-002...), columns include requirement description, test case IDs, execution status, and defect IDs. Forward traceability: from requirements to test cases (are all requirements covered?). Backward traceability: from test cases to requirements (does every test case have a requirement?). Bidirectional RTM: both directions — the gold standard. Uses: requirement coverage analysis (find untested requirements), impact analysis (requirement change → which tests are affected?), audit evidence (show auditors every requirement is covered), and test case maintenance (find orphaned test cases with no requirement basis). In Jira, RTM is implemented through requirement links on test issues. In TestRail, through requirement IDs on test cases. In Excel, a matrix with conditional formatting for status visibility.

Question 7

What are equivalence partitioning and boundary value analysis?

Accepted Answer

EP divides input data into valid/invalid partitions and tests one value per partition. BVA tests values at the boundaries of each partition where defects cluster. Equivalence Partitioning: divides the input domain into classes of values where the software behaves identically. Only test one representative from each class. For an age field accepting 18-65: Valid partitions: {18-65}. Invalid partitions: {<18}, {>65}, {non-numeric}. Test cases: 30 (valid), 10 (too young), 80 (too old), 'abc' (non-numeric) — 4 tests instead of infinite possibilities. Boundary Value Analysis: tests values at and around partition boundaries — this is where most defects occur. For 18-65 age: test 17 (just below min), 18 (min), 19 (just above min), 64 (just below max), 65 (max), 66 (just above max). The combination of EP and BVA provides maximum defect detection efficiency — EP reduces test cases, BVA targets the most defect-prone values within each partition.

Question 8

What is a Test Plan and what sections does it contain?

Accepted Answer

A Test Plan is the master QA document that defines the approach, scope, resources, schedule, and strategy for testing a project. It follows IEEE 829 standard. Standard sections: 1. Test Plan Identifier — unique ID and version. 2. Introduction and Objectives — what this plan covers. 3. Test Scope — in-scope (what will be tested) and out-of-scope (what won't be tested). 4. Test Strategy — testing levels (unit, integration, system, UAT), types (functional, performance, security), and approaches (risk-based, exploratory). 5. Resource Plan — team roles, responsibilities, required skills. 6. Schedule — test phases, milestones, dependencies. 7. Entry and Exit Criteria — conditions to start and end each test phase. 8. Risk Register — identified risks with probability, impact, and mitigations. 9. Test Deliverables — test cases, defect reports, test summary report. 10. Requirements Traceability Matrix reference. A Test Plan is signed off by QA Lead, PM, and Engineering Lead before testing begins — making quality standards explicit and agreed before a line of code is tested.

Question 9

How do you write an effective bug report?

Accepted Answer

A good bug report includes: summary, environment, preconditions, reproduction steps, actual vs expected result, severity, priority, and attachments. It must be reproducible and unambiguous. Essential fields: (1) Summary: concise, specific — 'Login fails with error ERR-401 when using Facebook OAuth on iOS 17' not 'Login doesn't work.' (2) Environment: OS, browser/device, app version, test environment (staging/UAT). (3) Preconditions: what must be true before executing the steps. (4) Reproduction Steps: numbered, precise, atomic — one action per step. Anyone following these steps should reproduce the defect. (5) Expected Result: what SHOULD happen per the requirement/acceptance criteria. (6) Actual Result: what DID happen — the defect behavior. (7) Severity and Priority. (8) Attachments: screenshot, video recording (essential for UI defects), log files. The 3-step test for a good bug report: Can a developer reproduce it without asking you any questions? Can a new team member understand what the expected behavior should be? Is there enough information to assess risk without more context? If yes to all three, it's a good report.

Question 10

What is exploratory testing and when is it most effective?

Accepted Answer

Exploratory testing is simultaneous test design, execution, and learning — no pre-written test scripts. It's most effective for finding defects that scripted tests miss through creative investigation. Exploratory testing (ET) is defined by James Bach as 'simultaneous learning, test design, and execution.' The tester uses domain knowledge, curiosity, and analytical thinking to investigate the application — deciding in real-time which areas to test and which test approaches to use. It is NOT unstructured: session-based ET uses time-boxed sessions (60-90 minutes) with a specific charter defining the target and approach. Charter format: 'Explore [target area] using [approach] to discover [risk/vulnerability/behavior].' Most effective when: testing a new feature for the first time (scripted tests only cover planned scenarios), investigating defect clusters (one bug found → explore nearby area), time is limited (ET finds more impactful defects per hour than scripted testing), and when the specification is informal or evolving. ET finds approximately 35% of all defects that scripted testing would miss — it is a professional QA technique, not an excuse to avoid test case writing.

QA Engineering Course 2026 - From Fundamentals to Strategy

Who This Course Is For

Prerequisites

What You'll Learn

Career Opportunities

Course Completion Certificate

Course Modules Overview

QA Fundamentals and Quality Thinking

Software Development Lifecycle (SDLC)

Software Testing Lifecycle (STLC)

Test Planning and Test Strategy

Test Documentation and Reporting

Defect Management and Bug Lifecycle

QA in Agile and Scrum

Quality Metrics and KPIs

Risk-Based Testing and Quality Risk

QA Collaboration and Communication

Compliance, Standards and Audits

QA Strategy, Maturity and Career

Course Curriculum

QA Fundamentals and Quality Thinking

Software Development Lifecycle (SDLC)

Software Testing Lifecycle (STLC)

Test Planning and Test Strategy

Test Documentation and Reporting

Defect Management and Bug Lifecycle

QA in Agile and Scrum

Quality Metrics and KPIs

Risk-Based Testing and Quality Risk

QA Collaboration and Communication

Compliance, Standards and Audits

QA Strategy, Maturity and Career

Your Learning Roadmap

Tools & Technologies

Jira

TestRail

Confluence

Zephyr

Bugzilla

Excel / Sheets

qTest

Ready to Start Learning?