Top 30 Testing Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   What is a key advantage of automated testing in modern software development?

   • aIt allows for rapid and confident deployment of code changes by detecting regressions early.
   • bIt primarily assesses subjective user experience and gathers feedback on new features.
   • cIt completely eliminates the need for any manual human testing throughout the development cycle.
   • dIt guarantees that all software shipped to users will be entirely free of any defects or bugs.
   Show the answer

   Answer: a · It allows for rapid and confident deployment of code changes by detecting regressions early.

   The card highlights that automated testing "provides the confidence needed to deploy changes frequently" and is "the foundation for catching regressions." Option B is incorrect because the card explicitly states automated testing is "not suited for exploratory testing... or for assessing subjective user experience."

   Read the full bite: Automated Testing: Catch Bugs Before They Ship

2. Question 2 of 30

   A product team is developing a new user onboarding flow and needs to identify specific areas where users struggle to improve the design before release. Which evaluation approach should they prioritize?

   • aFormative evaluation, to iteratively uncover and address usability issues.
   • bSummative evaluation, to measure the overall success rate of the new flow against a benchmark.
   • cQuantitative A/B testing, to determine which of two complete onboarding flows performs better.
   • dPost-release user surveys, to gather feedback on satisfaction and pain points from a broad audience.
   Show the answer

   Answer: a · Formative evaluation, to iteratively uncover and address usability issues.

   Formative evaluation is used to improve a design in progress by iteratively identifying and fixing flaws. Summative evaluation, on the other hand, judges a finished product's performance, making it unsuitable for diagnosing specific problems during development.

   Read the full bite: Formative vs. Summative Evaluation: Improve vs. Judge

3. Question 3 of 30

   Which scenario best describes a genuine shift-left practice rather than a common misconception?

   • aHiring additional QA staff to write more regression tests executed the day before release
   • bIntegrating static analysis into pull request builds so vulnerabilities are caught before merge
   • cRunning the existing end-to-end suite on faster hardware to cut execution time from hours to minutes
   • dRequiring developers to manually perform user acceptance testing before they commit code
   Show the answer

   Answer: b · Integrating static analysis into pull request builds so vulnerabilities are caught before merge

   Integrating static analysis into pull request builds moves security feedback to the coding phase, which is the essence of shift left. Hiring more QA staff to test before release only increases test volume at the same late stage, confusing more testing with earlier feedback.

   Read the full bite: What does shift left mean in CI/CD, and give two concrete examples?

4. Question 4 of 30

   Which promotion flow best reflects a robust automated testing strategy for a weekly retrained production model?

   • aOffline per-slice thresholds and bias checks, data validation for training-serving skew and drift, shadow deployment comparing latency and prediction distributions, then canary gated on business metrics with automatic rollback
   • bOffline accuracy check, then an A-B test on 50% of users, then manual review of predictions before full rollout
   • cData validation on the training set, then shadow deployment on 100% of live traffic, then promotion if prediction distributions match the incumbent model
   • dCanary deployment on 5% of traffic with predictions logged but not served, followed by offline accuracy validation, then rollout based on offline accuracy exceeding the previous version
   Show the answer

   Answer: a · Offline per-slice thresholds and bias checks, data validation for training-serving skew and drift, shadow deployment comparing latency and prediction distributions, then canary gated on business metrics with automatic rollback

   This option captures the four-layer strategy from the card: offline statistical validation, data validation, shadow deployment, and canary gated on business metrics with automatic rollback. Option D is the most tempting distractor because it uses correct terminology but reverses the order and incorrectly uses offline accuracy as the final promotion gate rather than live business metrics.

   Read the full bite: Design a robust automated testing strategy for ML models before production

5. Question 5 of 30

   Which statement best describes the primary role of Great Expectations within a data pipeline?

   • aIt provides a framework for defining and enforcing data quality assertions.
   • bIt serves as a comprehensive tool for data version control and lineage tracking.
   • cIt orchestrates the execution of data transformations and workflow dependencies.
   • dIt automatically cleanses and transforms raw data into a usable format.
   Show the answer

   Answer: a · It provides a framework for defining and enforcing data quality assertions.

   Option A accurately describes Great Expectations' core function: defining 'Expectations' to assert data properties and validate data quality, acting as a quality gate. Option D is incorrect because Great Expectations identifies data quality issues but does not automatically perform cleansing or transformation; it reports on the issues for users to address.

   Read the full bite: Great Expectations: Unit Tests for Your Data

6. Question 6 of 30

   Why are unit tests placed in the build stage and integration tests in a later CI stage?

   • aUnit tests need real databases and message queues to validate wiring
   • bUnit tests are fast and isolated, while integration tests require real infrastructure and are slower
   • cBoth test types have similar speed and infrastructure cost, so stage placement is arbitrary
   • dIntegration tests check isolated functions with mocked dependencies and belong in the build stage
   Show the answer

   Answer: b · Unit tests are fast and isolated, while integration tests require real infrastructure and are slower

   Unit tests are fast and isolated with mocks, making them ideal for the build stage, while integration tests verify real wiring and need provisioned infrastructure, so they run later. Distractor B swaps the two definitions, which is a common misconception when candidates only memorize names without understanding the speed and isolation differences.

   Read the full bite: Difference between unit and integration tests and CI pipeline placement

7. Question 7 of 30

   Which approach reliably automates blocking a merge when a pull request causes total project coverage to drop by more than two percentage points?

   • aUse a custom shell script in CI to diff two coverage reports locally and fail the build if the drop exceeds 2%
   • bGenerate a coverage report in CI, upload it to Codecov, set the project status threshold to 2 in codecov.yml, and require the Codecov project status in branch protection
   • cPost coverage results as PR comments and rely on reviewers to block the merge manually if the drop exceeds 2%
   • dUpload coverage to Codecov, set a patch coverage target of 2% in codecov.yml, and require the Codecov patch status in branch protection
   Show the answer

   Answer: b · Generate a coverage report in CI, upload it to Codecov, set the project status threshold to 2 in codecov.yml, and require the Codecov project status in branch protection

   This option correctly combines coverage artifact generation, Codecov upload, a project status threshold of 2, and branch protection enforcement. Option D is tempting because it uses the same tools, but patch coverage only measures lines changed in the PR rather than the overall project drop.

   Read the full bite: How would you block merges when PR coverage drops 2%?

8. Question 8 of 30

   Which strategy best balances immediate pipeline unblocking with sustainable reduction of E2E flakiness at scale?

   • aTreat flakiness as purely an infrastructure issue and upgrade CI hardware to eliminate variance
   • bBaseline flakiness rates, auto-quarantine chronic offenders from presubmit, and fix root causes like concurrency
   • cAutomatically retry every failed test up to five times before marking the build failed
   • dRequire developers to manually rerun the pipeline and triage failures before every merge
   Show the answer

   Answer: b · Baseline flakiness rates, auto-quarantine chronic offenders from presubmit, and fix root causes like concurrency

   Baselining metrics and quarantining chronic offenders targets root causes while protecting presubmit integrity. Relying solely on retries masks flakiness, delays detection of real breakages, and never reduces the overall flakiness rate.

   Read the full bite: How would you diagnose, report, and mitigate E2E flakiness at scale?

9. Question 9 of 30

   According to the card, what is the primary pitfall or misconception when using code coverage?

   • aAchieving a high code coverage percentage directly ensures the high quality and correctness of the software.
   • bCode coverage reports frequently fail to highlight areas of the codebase that lack test execution.
   • cIt is too difficult to integrate code coverage tools into continuous integration pipelines effectively.
   • dCode coverage metrics are limited to measuring only line execution and cannot track other aspects like branches or functions.
   Show the answer

   Answer: a · Achieving a high code coverage percentage directly ensures the high quality and correctness of the software.

   The card explicitly warns that the 'footgun is mistaking high coverage for high quality' and that chasing high coverage can 'foster a false sense of security.' Code coverage measures execution, not assertion quality. Option B is incorrect because the card states its 'real value is revealing the unexplored parts of your codebase.'

   Read the full bite: Code Coverage: What Your Tests Don't Tell You

10. Question 10 of 30

    Which benefit best captures why Storybook is treated as design system infrastructure rather than just a playground?

    • aIt replaces the need for a private NPM registry
    • bIt compiles components to native code for mobile platforms
    • cIt serves as a shared surface for isolated development, living docs, and automated testing
    • dIt automatically writes the components' production CSS
    Show the answer

    Answer: c · It serves as a shared surface for isolated development, living docs, and automated testing

    Storybook ties together isolated building, browsable documentation, and visual or interaction testing across teams. It does not compile to native code, replace a registry, or author production CSS, making those options incorrect.

    Read the full bite: Storybook's role in design system infrastructure

11. Question 11 of 30

    What is the primary benefit of using a build matrix in a CI/CD pipeline?

    • aIt defines the exact sequence in which different stages of the CI/CD pipeline must execute.
    • bIt allows for manual selection of specific environment configurations for each test run.
    • cIt ensures comprehensive testing by automatically generating jobs for all specified environment permutations.
    • dIt reduces the total number of CI jobs by combining different test types into one.
    Show the answer

    Answer: c · It ensures comprehensive testing by automatically generating jobs for all specified environment permutations.

    A build matrix's main purpose is to automatically create and run jobs for every combination of defined configurations, ensuring comprehensive compatibility testing. It does not reduce the total number of jobs, but rather increases them to cover all permutations, while reducing manual configuration effort.

    Read the full bite: Build Matrix: Test All The Combinations

12. Question 12 of 30

    When you assign a mock to app.dependency_overrides[get_db] in FastAPI, what happens during the test and what must you do afterward?

    • aFastAPI executes the original dependency and its sub-dependencies, then replaces the final return value with the mock, and the framework automatically resets overrides after every test.
    • bFastAPI injects the mock exclusively, bypassing the original and its sub-dependencies, and you must manually clear overrides after the test.
    • cFastAPI calls the mock but still executes the original dependency's sub-dependencies to preserve the injection chain, and overrides expire at the end of the test session.
    • dMonkeypatching the module containing the dependency is the idiomatic approach because dependency_overrides requires you to manually rebuild the dependency graph.
    Show the answer

    Answer: b · FastAPI injects the mock exclusively, bypassing the original and its sub-dependencies, and you must manually clear overrides after the test.

    FastAPI uses the replacement function exclusively and never executes the original dependency or its sub-dependencies. Option C is tempting but incorrect because sub-dependencies are fully bypassed, not preserved, and overrides persist until you manually clear them.

    Read the full bite: How would you override a FastAPI dependency during testing?

13. Question 13 of 30

    Which statement best describes the primary focus of unit testing?

    • aEnsuring that different modules integrate seamlessly with each other.
    • bConfirming that individual code components work correctly in isolation.
    • cAssessing the performance and scalability of a system under heavy load.
    • dVerifying the end-to-end functionality of an entire application.
    Show the answer

    Answer: b · Confirming that individual code components work correctly in isolation.

    The card explicitly states that unit tests verify "smallest code pieces" and "behave correctly in isolation," using the analogy of testing a single light switch. Options A, B, and D describe system/end-to-end testing, performance testing, and integration testing, respectively, which have broader scopes than unit tests.

    Read the full bite: Unit Testing: Verifying Code's Smallest Parts

14. Question 14 of 30

    Which scenario best illustrates the primary goal of integration testing?

    • aTesting a user can complete an entire purchase flow on a website.
    • bMeasuring the response time of a server under heavy user traffic.
    • cConfirming a single function correctly calculates a tax amount.
    • dVerifying an API endpoint successfully stores data in a database.
    Show the answer

    Answer: d · Verifying an API endpoint successfully stores data in a database.

    Integration testing aims to verify that different software modules, such as an API and a database, interact correctly. Option D directly describes this interaction, while options A, C, and D represent unit, end-to-end, and performance testing, respectively.

    Read the full bite: Integration Testing: Do Your Components Play Well Together?

15. Question 15 of 30

    What is the primary purpose of conducting a smoke test on a new software build?

    • aTo replace the need for extensive regression testing by checking critical paths.
    • bTo quickly assess if the build is fundamentally stable enough to proceed with more detailed testing.
    • cTo guarantee that the build is entirely free of defects before deployment.
    • dTo verify that all new features implemented in the build function correctly.
    Show the answer

    Answer: b · To quickly assess if the build is fundamentally stable enough to proceed with more detailed testing.

    The card emphasizes that smoke tests are a 'rapid, low-cost signal to 'fail fast'' and act as a 'gatekeeper' to determine if a build is worth testing further. Option B directly reflects this goal. Option A is incorrect because the card explicitly states smoke tests are not a replacement for comprehensive regression testing.

    Read the full bite: Smoke Testing: Is This Build Even Worth Testing?

16. Question 16 of 30

    What primary challenge does Storybook address for UI component development?

    • aAutomating the integration of frontend components with backend services and databases.
    • bThe difficulty of developing, testing, and documenting all possible states of individual UI components in isolation.
    • cEnsuring consistent user flows and complex application logic across an entire application.
    • dManaging version control and collaborative development for large component libraries.
    Show the answer

    Answer: b · The difficulty of developing, testing, and documenting all possible states of individual UI components in isolation.

    Storybook's core purpose is to provide an isolated environment for developing, testing, and documenting all possible states of individual UI components, as highlighted by the need to see 'all possible component states at once'. Option C describes end-to-end testing, which the card explicitly states Storybook is not a replacement for.

    Read the full bite: Storybook: A Workshop for Isolated UI Components

17. Question 17 of 30

    What is the primary goal of implementing regression testing in a software development lifecycle?

    • aTo ensure that newly added features function correctly according to specifications.
    • bTo confirm that specific bugs reported by users have been successfully resolved.
    • cTo verify that recent code changes have not adversely affected existing, stable functionalities.
    • dTo measure and improve the application's overall performance and scalability.
    Show the answer

    Answer: c · To verify that recent code changes have not adversely affected existing, stable functionalities.

    Option C accurately describes the core purpose of regression testing: to catch unintended side effects on existing features after changes. Option B describes retesting a bug fix, which is distinct from regression testing's broader scope of checking for unintended side effects across the entire system.

    Read the full bite: Regression Testing: Don't Break What's Already Working

18. Question 18 of 30

    What is the most important step to keep a visual regression pipeline from producing constant false-positive failures?

    • aCapturing screenshots at the highest possible resolution
    • bRunning every test serially to avoid race conditions
    • cEliminating nondeterminism by mocking dates, seeding data, disabling animations, and preloading fonts
    • dStoring baseline images in the same git branch as the code
    Show the answer

    Answer: c · Eliminating nondeterminism by mocking dates, seeding data, disabling animations, and preloading fonts

    Unfrozen dynamic content and animations are the dominant source of flaky visual diffs, so controlling them yields trustworthy results. Higher resolution, serial runs, and baseline storage location do not address nondeterminism.

    Read the full bite: Building a visual regression testing pipeline

19. Question 19 of 30

    What is the primary goal of conducting software performance testing?

    • aTo identify and fix logical errors or bugs within the application's code.
    • bTo ensure the software is secure against external threats and unauthorized data access.
    • cTo confirm that all features and functionalities of the software operate as intended.
    • dTo evaluate the system's stability, responsiveness, and resource utilization under anticipated and extreme user loads.
    Show the answer

    Answer: d · To evaluate the system's stability, responsiveness, and resource utilization under anticipated and extreme user loads.

    Performance testing specifically aims to understand how a system behaves under various loads, measuring its stability, responsiveness, and resource usage to find breaking points. Options A, B, and C describe functional testing, security testing, and general bug fixing, respectively, which are distinct from performance evaluation under load.

    Read the full bite: Software Performance Testing: How a System Behaves Under Stress

20. Question 20 of 30

    What is the primary benefit of using mutation testing over relying solely on traditional code coverage metrics?

    • aIt ensures that every possible execution path in the codebase is covered by at least one test case.
    • bIt provides a precise percentage of the codebase that has been executed by the test suite.
    • cIt assesses the test suite's actual ability to detect functional errors and behavioral regressions.
    • dIt automatically corrects minor logical errors in the code by suggesting fixes for surviving mutants.
    Show the answer

    Answer: c · It assesses the test suite's actual ability to detect functional errors and behavioral regressions.

    Mutation testing's core purpose is to measure a test suite's actual effectiveness at finding bugs and validating behavior, which traditional code coverage often misses. Option B describes code coverage itself, while options A and D misrepresent the scope or function of mutation testing.

    Read the full bite: Mutation Testing: A Fire Drill for Your Test Suite

21. Question 21 of 30

    A security team uses DAST in their CI/CD pipeline. Which vulnerability type is DAST least effective at identifying?

    • aSQL injection in a login form.
    • bA misconfigured web server exposing sensitive data.
    • cA flaw allowing a user to bypass payment for an item.
    • dCross-site scripting (XSS) in a user input field.
    Show the answer

    Answer: c · A flaw allowing a user to bypass payment for an item.

    DAST operates from the outside without seeing source code, making it ineffective at detecting business logic errors, such as a flaw allowing unauthorized transactions. It excels at finding common web vulnerabilities like XSS, SQL injection, and server misconfigurations by attacking the running application.

    Read the full bite: DAST: Probing a Running App for Security Flaws

22. Question 22 of 30

    Which aspect of a UI component cannot be reliably verified using a jsdom-based unit test?

    • aWhether a component's internal state updates correctly after user interaction.
    • bThe actual visual rendering, layout, and applied CSS styles of the component.
    • cIf the component correctly dispatches events when a user interacts with it.
    • dThe presence of specific accessibility attributes on rendered elements.
    Show the answer

    Answer: b · The actual visual rendering, layout, and applied CSS styles of the component.

    jsdom simulates the DOM but lacks a true browser rendering engine, meaning it cannot verify visual appearance, layout, element sizes, or how CSS is actually applied and rendered. The other options (state updates, event handling, accessibility attributes) are all aspects of component logic and behavior that jsdom-based tests are designed to cover.

    Read the full bite: Unit Testing UI Components: Beyond the DOM Mock

23. Question 23 of 30

    The mental model for Test Data Management (TDM) is often compared to 'infrastructure as code' because it:

    • aAutomates the deployment and scaling of test servers and virtual machines.
    • bProvides a framework for writing reusable and modular test automation scripts.
    • cEnsures that all test environments are identical copies of the production environment.
    • dDefines, versions, and automatically provisions exact data states required for tests.
    Show the answer

    Answer: d · Defines, versions, and automatically provisions exact data states required for tests.

    The card states TDM is 'infrastructure as code' but for your test data, meaning it defines, versions, and automatically provisions the exact data states. Option A describes infrastructure as code for infrastructure, not for data, which is the specific focus of TDM.

    Read the full bite: Test Data Management (TDM): Stop Flaky Tests

24. Question 24 of 30

    A development team is using Chromatic. Which of the following scenarios represents an inappropriate use of this tool?

    • aCatching visual regressions in a component library when updating third-party dependencies.
    • bEnsuring that a complex data transformation within a component correctly calculates and displays the final output.
    • cStreamlining the design review process by providing a visual history of UI changes for stakeholders.
    • dVerifying that a refactor of CSS styles doesn't introduce unintended visual side effects across components.
    Show the answer

    Answer: b · Ensuring that a complex data transformation within a component correctly calculates and displays the final output.

    Chromatic is designed to verify what the user sees, not the underlying data calculations or complex business logic. The card explicitly states it is not for testing data transformations. The other options are all appropriate uses of Chromatic as described in the card.

    Read the full bite: Chromatic: Visual Regression Testing for Components

25. Question 25 of 30

    Which statement best describes the primary goal of the Refactor step in Test-Driven Development?

    • aTo implement new features quickly, even if the code is not yet clean.
    • bTo improve the internal design and readability of the code while maintaining its current functionality.
    • cTo fix any bugs discovered during the testing phase before writing new tests.
    • dTo ensure that all test cases are comprehensive and cover every possible scenario.
    Show the answer

    Answer: b · To improve the internal design and readability of the code while maintaining its current functionality.

    The Refactor step's primary goal is to improve the code's internal structure and readability without altering its observable behavior, as stated in the card. Option A describes the Green step, while options B and D are related to general testing quality or bug fixing, not the specific purpose of refactoring in TDD.

    Read the full bite: Describe the TDD Red-Green-Refactor cycle

26. Question 26 of 30

    In TDD, what is the primary purpose of the Green phase?

    • aTo write fully optimized production code that is ready for release
    • bTo write the simplest code that makes the current test pass
    • cTo define method signatures and expected behavior before any implementation exists
    • dTo clean up duplication in both production and test code without changing behavior
    Show the answer

    Answer: b · To write the simplest code that makes the current test pass

    The Green phase is about writing the simplest code that passes the test to get rapid feedback, not to optimize or finalize design. Writing fully optimized code during Green is a common misconception because that work belongs to the Refactor phase.

    Read the full bite: Describe the Red-Green-Refactor cycle in TDD. What is each step's purpose?

27. Question 27 of 30

    In the Red-Green-Refactor cycle, what is the primary objective of the "Green" step after a test has failed?

    • aTo prove that the test is capable of failing before any implementation exists.
    • bTo write the final, production-ready implementation for the feature.
    • cTo improve the code's design by removing duplication and increasing clarity.
    • dTo write the simplest possible code that makes the current failing test pass.
    Show the answer

    Answer: d · To write the simplest possible code that makes the current failing test pass.

    The 'Green' step's goal is to get to a passing state as quickly as possible with minimal code. Improving the code's design is deferred to the 'Refactor' step, and proving the test can fail happens in the 'Red' step.

    Read the full bite: Describe the Red-Green-Refactor cycle in Test-Driven Development

28. Question 28 of 30

    What is the primary strategic reason for the Test Pyramid's shape, which advocates for many unit tests and very few UI tests?

    • aAs you move up from unit to UI tests, tests become exponentially slower, more expensive, and more brittle, impacting feedback speed and maintenance costs.
    • bUnit tests are the best method for achieving 100% code coverage, which is the main objective of the pyramid model.
    • cUI tests provide less business value than unit tests because they only test the 'happy path' and not edge cases.
    • dThis structure allows development teams to write all the tests, removing the need for a separate QA team.
    Show the answer

    Answer: a · As you move up from unit to UI tests, tests become exponentially slower, more expensive, and more brittle, impacting feedback speed and maintenance costs.

    The correct answer explains the core trade-offs: higher-level tests are slower, costlier, and more fragile, so the pyramid strategy minimizes them to optimize for fast, reliable feedback. The 'code coverage' option is a tempting distractor because while unit tests drive coverage, it is not the sole goal of the pyramid model.

    Read the full bite: Explain the Test Pyramid and how it guides your strategy.

29. Question 29 of 30

    Which statement best captures the Test Pyramid's core guidance for testing strategy?

    • aIt recommends eliminating UI tests entirely and relying only on unit and service tests.
    • bIt is a heuristic for maximizing feedback speed by pushing tests to the cheapest, fastest layer that still delivers confidence.
    • cIt suggests verifying most business logic through UI tests because they exercise the full stack.
    • dIt prescribes a fixed ratio such as 70% unit, 20% service, and 10% UI tests for every project.
    Show the answer

    Answer: b · It is a heuristic for maximizing feedback speed by pushing tests to the cheapest, fastest layer that still delivers confidence.

    The Test Pyramid is a heuristic about feedback loops and economic confidence, not a rigid formula, so the correct answer emphasizes pushing tests to the fastest, cheapest appropriate layer. Option D is tempting but wrong because the card explicitly warns against treating the pyramid as a fixed seventy-twenty-ten mandate.

    Read the full bite: Explain the Test Pyramid and how it guides testing strategy

30. Question 30 of 30

    What is the fundamental strategic reason the Test Pyramid advocates for a large number of unit tests and a small number of UI tests?

    • aUnit tests offer rapid feedback, precise fault isolation, and lower cost, whereas UI tests are slow, expensive, and prone to brittleness.
    • bUI tests are primarily for validating the visual presentation and user experience, not the underlying business logic.
    • cUnit tests are simpler to automate and integrate into CI/CD pipelines compared to complex UI test setups.
    • dThe volume of unit tests ensures complete code coverage, making extensive UI testing largely redundant.
    Show the answer

    Answer: a · Unit tests offer rapid feedback, precise fault isolation, and lower cost, whereas UI tests are slow, expensive, and prone to brittleness.

    The Test Pyramid prioritizes unit tests because they are fast, cheap, and effectively isolate failures, providing quick feedback. Conversely, UI tests are minimized due to their slowness, high cost, and brittleness, making them inefficient for broad coverage.

    Read the full bite: Explain the Test Pyramid and its strategic use