Software Testing interview questions

What a strong answer covers

• Define verification as checking if the software meets specifications (are we building the product right?).
• Define validation as checking if the software meets user needs (are we building the right product?).
• Provide an example: verifying that a login form accepts valid email formats vs. validating that users can actually log in.
• Mention that both are essential and occur throughout the lifecycle.

Where people lose the point

• ×Using the terms interchangeably or confusing them.
• ×Claiming verification is only for developers and validation only for testers.
• ×Omitting the role of user acceptance testing in validation.

What a strong answer covers

• Define equivalence partitioning as dividing input data into partitions where the system behaves similarly; testing one value from each partition.
• Define boundary value analysis as testing values at the edges of partitions (min, max, just inside, just outside).
• Example: a field accepts ages 18-65. Partitions: invalid low (<18), valid (18-65), invalid high (>65). Boundary tests: 17, 18, 65, 66.
• Explain that these techniques reduce test cases while maintaining coverage.

Where people lose the point

• ×Testing only one boundary value instead of both lower and upper.
• ×Confusing equivalence partitioning with random testing.
• ×Forgetting to include invalid partitions.

What a strong answer covers

• Unit testing focuses on individual components (functions, methods) in isolation, often using mocks.
• Integration testing verifies interactions between components (e.g., database, API, modules).
• Unit tests are fast, run frequently, and catch logic errors early; integration tests are slower and catch interface mismatches.
• Both are part of the test pyramid: many unit tests, fewer integration tests, even fewer end-to-end tests.

Where people lose the point

• ×Claiming unit tests replace integration tests.
• ×Writing integration tests that are too broad (e.g., full system tests).
• ×Not using mocks in unit tests, making them dependent on external systems.

What a strong answer covers

• The test pyramid has three layers: unit tests (base), integration tests (middle), end-to-end tests (top).
• Unit tests are numerous, fast, and cheap; integration tests fewer and slower; E2E tests fewest and slowest.
• The pyramid guides investment: write more low-level tests for quick feedback, fewer high-level tests for critical paths.
• An inverted pyramid (too many E2E tests) leads to slow, brittle suites.

Where people lose the point

• ×Thinking the pyramid is a strict ratio rather than a guideline.
• ×Ignoring the middle layer (integration tests) entirely.
• ×Writing E2E tests for every scenario, making the suite slow and flaky.

What a strong answer covers

• A stub provides predefined responses to method calls; it is used to control indirect inputs.
• A mock is pre-programmed with expectations about which calls will be made and can verify interactions (e.g., assert that a method was called with specific arguments).
• Use stubs when you only need to provide data; use mocks when you need to verify behavior.
• Example: stub a database call to return a user object; mock a payment service to verify that charge() is called once.

Where people lose the point

• ×Using the terms interchangeably.
• ×Over-mocking: mocking everything leads to brittle tests.
• ×Using mocks when a stub would suffice, adding unnecessary complexity.

What a strong answer covers

• TDD: write a failing unit test, then write code to pass it, then refactor. Focuses on developer-level correctness.
• BDD: write scenarios in natural language (Given-When-Then) that describe system behavior from user perspective. Focuses on business requirements.
• TDD uses unit tests; BDD uses acceptance tests that can be automated.
• Both promote test-first thinking, but BDD emphasizes collaboration between developers, testers, and business stakeholders.

Where people lose the point

• ×Claiming BDD replaces TDD (they complement each other).
• ×Writing BDD scenarios that are too technical (e.g., 'Given the database has a user').
• ×Not automating BDD scenarios, losing the benefit of living documentation.

What a strong answer covers

• Code coverage measures the percentage of code executed by tests.
• Statement coverage: percentage of executable statements executed.
• Branch coverage: percentage of decision outcomes (e.g., if-else branches) executed.
• Path coverage: percentage of all possible paths through the code executed (often impractical).
• High coverage does not guarantee test quality; it's a metric, not a goal.

Where people lose the point

• ×Assuming 100% statement coverage means no bugs.
• ×Confusing branch coverage with path coverage.
• ×Chasing coverage numbers without meaningful assertions.

What a strong answer covers

• Load testing simulates expected user load to measure performance (response time, throughput).
• Stress testing pushes beyond expected load to find the system's breaking point and how it fails.
• Load testing answers 'can the system handle normal traffic?'; stress testing answers 'what happens under extreme traffic?'
• Both are types of performance testing and use similar tools (JMeter, Gatling).

Where people lose the point

• ×Using the terms interchangeably.
• ×Only doing load testing and ignoring stress testing, missing failure modes.
• ×Not monitoring system resources (CPU, memory) during tests.

What a strong answer covers

• Identify input fields that interact with the database (search, login, forms).
• Inject malicious SQL payloads like ' OR '1'='1, '; DROP TABLE users; --, and UNION SELECT statements.
• Observe error messages, unexpected data, or successful login without credentials.
• Use automated tools like SQLMap or OWASP ZAP for comprehensive scanning.
• Verify that the application uses parameterized queries or prepared statements to prevent injection.

Where people lose the point

• ×Only testing with simple payloads and missing advanced techniques.
• ×Assuming that escaping input is sufficient (parameterization is better).
• ×Not testing all input vectors (URL parameters, headers, cookies).

What a strong answer covers

• Continuous testing means running automated tests at every stage of the pipeline (commit, build, deploy).
• Unit tests run on every commit; integration and acceptance tests run on merge; performance and security tests run on staging.
• Tests must be reliable, fast, and provide quick feedback to developers.
• Failed tests block the pipeline, preventing defective code from reaching production.
• Requires test automation, infrastructure as code, and monitoring.

Where people lose the point

• ×Running all tests on every commit, causing long feedback loops.
• ×Ignoring flaky tests, which erode trust in the pipeline.
• ×Not including non-functional tests (performance, security) in the pipeline.

What a strong answer covers

• Exploratory testing is simultaneous learning, test design, and execution without predefined scripts.
• Testers explore the application, using heuristics and domain knowledge to find unexpected bugs.
• Most effective when: requirements are vague, time is limited, or testing complex scenarios that are hard to script.
• Often used in agile sprints to complement automated tests.
• Requires skilled testers who can think critically and adapt.

Where people lose the point

• ×Confusing exploratory testing with ad-hoc testing (exploratory is structured with charters).
• ×Thinking exploratory testing replaces automated testing.
• ×Not documenting findings or session notes.

What a strong answer covers

• Prioritize tests that are run frequently (regression, smoke tests) and provide high value.
• Automate tests that are time-consuming or error-prone when done manually.
• Consider business criticality: core functionality, high-risk areas, and features with frequent changes.
• Avoid automating tests that are unstable, require human judgment (e.g., visual layout), or are run rarely.
• Use a cost-benefit analysis: automation effort vs. manual execution time saved.

Where people lose the point

• ×Automating everything without considering maintenance cost.
• ×Automating tests that are not stable, leading to flaky results.
• ×Ignoring manual exploratory testing in favor of full automation.

What a strong answer covers

• Identify boundaries: 1 and 100 (inclusive), and just outside: 0 and 101.
• Test values: 0 (invalid low), 1 (valid min), 2 (just above min), 99 (just below max), 100 (valid max), 101 (invalid high).
• Also test typical values like 50 to ensure normal operation.
• Explain that this catches off-by-one errors common in programming.

Where people lose the point

• ×Only testing 1 and 100, missing the boundaries just outside.
• ×Testing only one boundary (e.g., only lower).
• ×Not testing a value inside the range to confirm normal behavior.

What a strong answer covers

• Regression testing re-runs existing tests after code changes to ensure new code hasn't broken existing functionality.
• It is critical for maintaining software quality during iterative development.
• Automated regression suites are essential for continuous integration.
• Selective regression (risk-based) can be used when full regression is too costly.

Where people lose the point

• ×Thinking regression testing is only done before release.
• ×Not updating regression tests when requirements change.
• ×Running full regression manually, which is time-consuming and error-prone.

What a strong answer covers

• Black-box testing focuses on inputs and outputs without knowledge of internal code; uses techniques like equivalence partitioning, boundary value analysis, decision tables.
• White-box testing uses knowledge of internal structure to design tests; techniques include statement, branch, and path coverage.
• Black-box is used for functional testing from user perspective; white-box is used for unit and integration testing to ensure code paths are exercised.
• Both are complementary; a comprehensive test strategy uses both.

Where people lose the point

• ×Claiming one is better than the other.
• ×Using black-box techniques for unit tests (they are white-box by nature).
• ×Not considering gray-box testing (partial knowledge).

What a strong answer covers

• Test case ID, title, description, preconditions, test steps, expected results, actual results, and status.
• Preconditions define the state before execution (e.g., user logged in, database populated).
• Steps are clear, sequential, and unambiguous.
• Expected results are specific and verifiable (e.g., 'User sees error message: Invalid password').
• Test cases should be independent and reusable.

Where people lose the point

• ×Writing vague expected results like 'System works correctly'.
• ×Including steps that depend on previous test case outcomes.
• ×Omitting preconditions, leading to inconsistent execution.

What a strong answer covers

• Penetration testing (pen testing) is a simulated cyberattack to identify exploitable vulnerabilities; it involves manual techniques and creative thinking.
• Vulnerability scanning uses automated tools to identify known vulnerabilities (e.g., outdated libraries, misconfigurations).
• Pen testing goes deeper: it attempts to chain vulnerabilities to achieve a goal (e.g., data exfiltration).
• Both are complementary: scanning finds low-hanging fruit; pen testing finds complex attack paths.

Where people lose the point

• ×Using the terms interchangeably.
• ×Assuming a vulnerability scan is sufficient for security assessment.
• ×Not defining the scope and rules of engagement for pen testing.

What a strong answer covers

• Testing ML models involves data validation, model evaluation (accuracy, precision, recall, F1), and bias detection.
• Challenges: non-deterministic outputs, data drift, lack of oracles for expected behavior, and interpretability.
• Use techniques like A/B testing, shadow deployment, and continuous monitoring in production.
• Test data quality: missing values, outliers, label correctness.
• Model robustness: adversarial testing, edge cases.

Where people lose the point

• ×Testing ML models like traditional software (asserting exact outputs).
• ×Ignoring data quality issues.
• ×Not monitoring for concept drift after deployment.