Testing Interview Questions

Software testing interview questions assess your understanding of quality assurance principles, testing methodologies, and practical testing skills. Whether you are interviewing for a QA engineer role or a developer position, testing knowledge is essential — modern development practices require all team members to understand and participate in quality assurance.

Fundamental Testing Concepts

Q: What is software testing and why is it important?

A: Software testing is the process of evaluating a system to identify differences between expected and actual behavior. It is important because: defects found in production cost 100 times more to fix than those found during development, testing builds confidence that the system meets requirements, it identifies security vulnerabilities before exploitation, and it validates that changes do not break existing functionality. Testing cannot prove software is defect-free (proving a negative is impossible), but it can demonstrate the presence of defects and increase confidence in quality.

Q: What is the difference between verification and validation?

A: Verification asks "Are we building the product right?" — it confirms the software correctly implements specifications through activities like reviews, inspections, walkthroughs, and testing against design documents. Validation asks "Are we building the right product?" — it confirms the software meets actual user needs through user acceptance testing, prototyping, and beta testing. A system can pass verification (implements the spec correctly) but fail validation (the spec itself was wrong and does not meet real user needs).

Q: Explain the testing pyramid.

A: The testing pyramid is a model for balancing test types. At the base are numerous unit tests (fast, isolated, testing individual functions — 70% of tests). In the middle are integration tests (testing component interactions, API contracts, database queries — 20% of tests). At the top are end-to-end tests (testing complete user workflows through the full stack — 10% of tests). The pyramid shape reflects that lower-level tests are faster, cheaper, more reliable, and provide more specific feedback, while higher-level tests are slower, more expensive, and more brittle but catch different categories of defects.

Test Design Techniques

Q: What is equivalence partitioning? Give an example.

A: Equivalence partitioning divides input data into groups (partitions) where all values within a partition are expected to be treated identically by the software. You test one representative value from each partition rather than every possible input. Example: An age field accepts values 18-65. Partitions are: invalid low (below 18), valid (18-65), and invalid high (above 65). Test with one value from each: 15, 35, and 70. This reduces the number of test cases while maintaining coverage of distinct behaviors.

Q: What is boundary value analysis and why is it important?

A: Boundary value analysis tests at the edges of equivalence partitions, where defects most commonly occur. Programmers frequently make off-by-one errors with boundary conditions (using less-than instead of less-than-or-equal). For the age field accepting 18-65, test: 17 (just below minimum), 18 (minimum boundary), 19 (just above minimum), 64 (just below maximum), 65 (maximum boundary), and 66 (just above maximum). Studies consistently show that boundary values account for a disproportionate number of defects compared to mid-range values.

Q: Explain decision table testing.

A: Decision table testing handles situations with multiple conditions that combine to produce different outcomes. Create a table listing all conditions (inputs/states) as rows and all possible combinations as columns, then specify the expected action/output for each combination. Example: an insurance claim is approved if the policy is active AND the claim amount is within limits AND the documentation is complete. The decision table covers all eight combinations of these three boolean conditions (2^3 = 8), ensuring no combination is missed.

Q: What is state transition testing?

A: State transition testing verifies that a system transitions correctly between defined states based on specific events. It is modeled using state diagrams showing states, transitions, events triggering transitions, and guards (conditions). Example: An order moves through states: Created → Confirmed → Shipped → Delivered. Test valid transitions (Created + payment received → Confirmed) and invalid transitions (Shipped → Created should fail). This technique is particularly useful for testing workflows, protocol implementations, and UI navigation.

Testing Levels

Q: What is the difference between unit testing, integration testing, and system testing?

A: Unit testing verifies individual functions or methods in isolation, typically mocking dependencies. It answers "does this function produce correct output for given inputs?" Integration testing verifies that multiple modules work together correctly — data passes between components properly, API contracts are honored, and database interactions work as expected. System testing validates the complete, integrated system against requirements in an environment resembling production. Each level catches different defect types: unit tests find logic errors, integration tests find interface mismatches, and system tests find environmental and configuration issues.

Q: What is regression testing and when do you perform it?

A: Regression testing verifies that previously working functionality has not been broken by recent changes. It is performed: after every code change (automated regression suite in CI/CD), before every release (full regression run), and after bug fixes (ensuring the fix does not introduce new problems). Regression test suites grow over time as new tests are added for each fixed bug and new feature. Managing large regression suites requires prioritization — run high-priority tests first for fast feedback, complete suite overnight.

Practical Testing Questions

Q: How do you write a good test case?

A: A good test case includes: a unique identifier for tracking, a clear title describing what is being tested, preconditions (system state before testing), explicit step-by-step instructions (anyone should be able to execute it), specific expected results (not vague "system works correctly"), test data (exact values to use), and postconditions (cleanup needed). Each test case should test one thing — if it fails, the reason should be immediately obvious. Example: "TC-LOGIN-003: Verify login fails with correct username but incorrect password. Precondition: User account 'testuser@example.com' exists with password 'ValidPass123'. Steps: Navigate to login page, enter email, enter wrong password 'WrongPass456', click Login. Expected: Error message 'Invalid credentials' displayed, user remains on login page."

Q: How do you decide what to test when time is limited?

A: Apply risk-based testing: prioritize tests for high-risk areas (critical business functions, recently changed code, historically buggy modules, complex logic). Consider: what would cause the most damage if it fails? (Payment processing, security authentication.) What has failed before? (Areas with previous defects tend to have more.) What changed recently? (New code is most likely to contain defects.) Use the Pareto principle — 80% of defects are found in 20% of modules. Test those modules most thoroughly.

Q: What is test-driven development (TDD)?

A: TDD is a development practice where you write a failing test before writing the implementation code. The cycle is: Red (write a test that fails because the functionality does not exist yet), Green (write the minimum code to make the test pass), Refactor (improve the code while keeping tests green). TDD produces thoroughly tested code by design, serves as living documentation, encourages simple design (you only build what tests require), and catches regressions instantly. It requires discipline and changes how developers think about design — starting from usage rather than implementation.

Q: How do you test non-functional requirements?

A: Non-functional requirements require specialized testing approaches: Performance testing (load testing with tools like JMeter to verify response times under expected load), Stress testing (pushing beyond normal limits to find breaking points), Security testing (penetration testing, vulnerability scanning, authentication testing), Usability testing (user observation, task completion rates, satisfaction surveys), Reliability testing (running the system continuously to measure MTBF), and Scalability testing (increasing load to verify the system handles growth). Each non-functional requirement needs quantifiable acceptance criteria — "the system should be fast" is untestable, "95% of API calls complete within 200ms under 1000 concurrent users" is testable.

Q: What is mutation testing?

A: Mutation testing evaluates the quality of your test suite by introducing small changes (mutations) to the source code — like changing a greater-than operator to less-than or replacing a variable with a constant — and checking whether existing tests catch the change. If tests pass despite a mutation, they are not adequately covering that code. Mutation testing provides a more meaningful quality measure than simple code coverage — code can be "covered" by tests that never assert anything meaningful. It is computationally expensive but valuable for critical code paths.