10. Quality Engineering and Continuous Testing

Introduction and Context

DevOps is often described as a combination of development and operations practices, but its deeper purpose is the reliable delivery of customer value. Quality engineering is central to that purpose. It treats quality not as a final inspection activity performed by a separate testing department, but as a shared organizational capability designed into products, processes, platforms, and feedback systems.

Continuous testing extends this idea across the delivery lifecycle. Automated checks are executed continuously—from code commit and build creation to deployment, production observation, and release evaluation. The objective is not to test everything indiscriminately or to maximize the number of test cases. It is to obtain sufficiently trustworthy evidence about product risk quickly enough to support delivery decisions.

For DevOps teams, testing must therefore address several dimensions of risk. Unit tests examine local behavior; integration and contract tests examine collaboration between components; acceptance tests examine business outcomes; performance tests examine responsiveness and capacity; and resilience tests examine behavior under failure. These activities depend on suitable test data, representative environments, observable systems, and a deliberate approach to technical debt.

This chapter develops a risk-based approach to quality engineering and continuous testing. It connects testing levels with delivery pipelines, explains how test data and environments influence confidence, examines automation and intelligent test selection, and considers the managerial and ethical responsibilities associated with quality decisions.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the relationship between quality engineering, DevOps, and continuous testing.

2. Distinguish among unit, integration, contract, acceptance, performance, resilience, and exploratory testing.

3. Construct a risk-based automated testing strategy.

4. Design appropriate test data and environment-management practices.

5. Interpret test results and pipeline quality gates without confusing pass rates with product quality.

6. Identify technical debt in test automation and prioritize its reduction.

7. Evaluate governance, security, ethical, and operational implications of automated testing.

8. Apply quality-engineering principles to a realistic delivery scenario.

From Quality Assurance to Quality Engineering

Traditional quality assurance commonly emphasizes process compliance and defect detection. Testing is frequently positioned near the end of a sequential development process. Although this approach can identify defects, it creates delayed feedback, expensive rework, and an implicit assumption that a testing group owns quality.

Quality engineering is broader. It combines testing, software design, architecture, observability, automation, data management, and process improvement. Engineers ask how a system can be made easier to test, safer to change, and more observable in operation. Quality is treated as an emergent property of the whole system rather than a certificate attached to a completed feature.

Several principles distinguish quality engineering:

• Shared responsibility: developers, testers, product managers, security specialists, and operations personnel contribute to quality.
• Early and continuous feedback: defects and risks are discovered as close as possible to the activity that introduced them.
• Risk-based investment: effort is concentrated on features and failure modes with the greatest business, safety, security, or operational consequences.
• Automation with judgment: repetitive checks are automated, but human exploration and contextual judgment remain essential.
• Production awareness: real operational behavior, user feedback, incidents, and telemetry influence testing priorities.
• Testability by design: interfaces, modularity, dependency control, logging, and controllability are architectural concerns.

Continuous testing is the operational expression of these principles. A pipeline may compile software, run static analysis, execute unit tests, deploy to an ephemeral environment, conduct integration tests, and evaluate performance or acceptance criteria. Later stages should not merely repeat earlier checks; each should provide new evidence about a different risk.

A Risk-Based Model of Testing

A test strategy begins with risk rather than with a catalog of tools. Risk may be represented conceptually as:

Risk = Probability of failure × Consequence of failure

The formula is not a precise prediction. It is a decision aid for comparing concerns. A minor formatting defect in an internal report may have low consequence, whereas an incorrect financial calculation, privacy breach, or failed safety control may have high consequence even if its probability is relatively low.

A useful risk assessment considers:

• business criticality and revenue impact;
• legal, regulatory, privacy, or safety consequences;
• technical complexity and dependency count;
• frequency and magnitude of expected change;
• novelty of the technology or design;
• historical defect and incident patterns;
• exposure to external users or hostile actors; and
• difficulty of detecting failure after release.

Teams can record these dimensions in a lightweight risk register. Each important capability is assigned a risk level, relevant failure modes, detection mechanisms, mitigation tests, and an accountable owner. The register should be revisited when architecture, usage, regulations, or incident experience changes.

Risk-based testing does not mean ignoring low-risk areas. It means using proportional coverage. High-risk components may require multiple independent forms of evidence, fault injection, performance testing, security testing, and explicit acceptance criteria. Low-risk changes may be adequately supported by unit tests, static analysis, and targeted review.

The Testing Portfolio: Different Questions, Different Evidence

No single test type can establish product quality. Each type answers a different question and has different costs and failure modes.

Unit Testing

A unit test verifies a small, isolated element such as a function, class, or module. Dependencies are commonly replaced with stubs, mocks, or fakes. Unit tests are generally fast and precise, making them suitable for execution on every commit.

Their principal value is localization: when a test fails, the responsible behavior is relatively easy to identify. Well-designed unit tests encourage modularity and clarify business rules. However, excessive mocking can produce tests that pass even when real components cannot collaborate. Unit-test coverage percentages are therefore indicators of exercised code, not proof of correctness.

Component and Integration Testing

Component tests examine a substantial service or application component, sometimes with real databases, message brokers, or file systems. Integration tests examine interactions between components. They can expose schema mismatches, serialization errors, transaction problems, authentication failures, and incorrect configuration.

Integration tests are usually slower and more fragile than unit tests. They should be focused on meaningful boundaries rather than used to reproduce every unit-level rule. Containerized dependencies, service virtualization, and disposable environments can reduce setup cost, but teams must recognize the difference between simulated and real infrastructure behavior.

Contract Testing

Contract testing verifies that an interaction between a provider and a consumer conforms to an agreed contract. A consumer-driven contract may specify request formats, response fields, error behavior, and compatibility expectations. Contract tests are particularly valuable in distributed systems because they provide faster feedback than repeatedly executing large end-to-end suites.

Contracts should be versioned and treated as compatibility agreements. A provider change that preserves existing consumer expectations can be released independently; a breaking change requires coordinated migration or explicit versioning.

Acceptance and End-to-End Testing

Acceptance tests evaluate whether a feature satisfies business and user requirements. They may be automated through user-interface tests, API workflows, or domain-level scenarios. End-to-end tests exercise a complete path through multiple systems.

These tests provide valuable confidence about business workflows, but they are expensive to maintain and often difficult to diagnose. A disciplined suite should contain a small number of high-value end-to-end scenarios, supported by broader unit, component, and contract coverage. Acceptance criteria should be observable and unambiguous—for example, “a suspended account cannot initiate a transfer and receives an auditable reason,” rather than “account suspension works correctly.”

Exploratory Testing

Exploratory testing combines learning, test design, and execution. The tester investigates the product dynamically, following evidence and questioning assumptions. It is especially useful for usability, unusual workflows, ambiguous requirements, and interactions that are difficult to encode in advance.

Automation does not eliminate exploratory testing. Instead, automation removes repetitive regression work and gives specialists more time to examine uncertainty, misuse, accessibility, and emerging risks.

Performance and Capacity Testing

Performance testing examines qualities such as response time, throughput, resource utilization, scalability, and stability. Common forms include:

• Load testing: behavior under expected demand.
• Stress testing: behavior beyond expected demand.
• Spike testing: response to sudden changes in demand.
• Endurance testing: behavior over an extended period.
• Capacity testing: the maximum sustainable workload under stated conditions.

Performance tests require realistic workload models and meaningful service-level objectives. A test that measures only average response time may conceal unacceptable tail latency. Percentiles such as p95 or p99, error rates, saturation indicators, and resource consumption often provide more useful evidence. Results must be interpreted in the context of environment size, data volume, caching, network conditions, and background activity.

Resilience and Recovery Testing

Resilience testing examines whether a system continues to provide acceptable service—or recovers appropriately—when components fail. Scenarios may include network delay, dependency unavailability, expired credentials, database failover, resource exhaustion, corrupted messages, and loss of an availability zone.

Chaos engineering is one approach to resilience testing. It involves controlled experiments that inject failure into a system while observing predefined steady-state indicators. The objective is not random destruction; it is the systematic discovery of weaknesses under controlled conditions. Experiments should have authorization, rollback procedures, monitoring, and a clear hypothesis.

Recovery testing also evaluates backup restoration, disaster recovery objectives, idempotency, replay behavior, and data integrity. A system that remains available but silently loses transactions has not demonstrated adequate resilience.

Building the Continuous Testing Pipeline

A continuous testing pipeline should be organized according to feedback speed, risk, and environment cost. A typical sequence begins with rapid checks and progresses toward broader, more expensive evidence:

1. Commit-stage checks: formatting, linting, static analysis, unit tests, secret detection, and dependency checks.

2. Build-stage checks: packaging, artifact verification, component tests, and security scanning.

3. Integration-stage checks: contract tests, database and messaging tests, and service interactions.

4. Pre-release checks: selected acceptance, performance, resilience, accessibility, and penetration tests.

5. Post-deployment checks: smoke tests, synthetic transactions, telemetry validation, and progressive-release analysis.

This sequence is not universal. A safety-critical or highly regulated system may require additional approvals and evidence before deployment. Conversely, a small internal service may need only a compact pipeline. The governing principle is that pipeline design should make important risk visible before exposure increases.

A quality gate is a rule that controls progression. Examples include “no unresolved critical vulnerabilities,” “contract compatibility must be verified,” or “p99 latency must remain below the agreed threshold under the defined workload.” Gates should be explicit, version-controlled, and explainable. A gate that fails intermittently or has no accountable owner will eventually be bypassed.

Teams should distinguish between a failed test and a failed product condition. A test can fail because of a defective product, a broken test, an unavailable environment, bad data, or an infrastructure problem. Treating every failure as a product defect creates noise; ignoring failures creates false confidence. Failure classification and rapid triage are therefore part of quality engineering.

Test Data as a Product and Governance Concern

Test data strongly influences the validity of test results. Poorly designed data can conceal defects, create false failures, or expose confidential information. Data strategy should address generation, masking, versioning, refresh, ownership, retention, and disposal.

Synthetic data is often preferable for automated testing because it can be generated deterministically and designed to cover boundary conditions. Production-derived data may be useful for realism, but it should be minimized, anonymized or tokenized where appropriate, access-controlled, and handled according to privacy obligations. Simply copying production data into a test environment is not an acceptable default.

Important data characteristics include:

• Representativeness: realistic distributions, relationships, and volumes.
• Determinism: the ability to reproduce a scenario when diagnosing failure.
• Isolation: tests should not unexpectedly alter data used by other tests.
• Boundary coverage: empty values, extremes, duplicates, malformed inputs, and unusual sequences.
• Referential integrity: related records must remain consistent when required.
• Lifecycle control: data must be created and destroyed predictably.

Test data builders, fixtures, database snapshots, and service virtualization can support repeatability. Teams should avoid fixtures that are so large or opaque that nobody understands what behavior they represent.

Environment Engineering

A test environment is not merely a collection of servers. It includes application versions, infrastructure, configurations, feature flags, third-party services, identity systems, network rules, datasets, clocks, and observability tools. Differences between test and production environments create an “environment gap” that weakens confidence.

Infrastructure as code allows environments to be created, reviewed, versioned, and destroyed consistently. Ephemeral environments can be provisioned for a pull request or feature branch, reducing interference between teams. Containers provide packaging consistency, while service virtualization can simulate unavailable or costly dependencies. Neither eliminates the need for representative production-like testing; simulation itself must be validated.

Environment ownership and change management are essential. A shared environment that changes without notice produces nondeterministic results. Teams should record deployed versions, configuration, data state, and dependency health for each test run. Observability—logs, metrics, traces, and test reports—should be available to diagnose failures rather than merely confirm them.

Managing Flaky Tests and Technical Debt

A flaky test passes and fails without a relevant product change. Flakiness may arise from timing assumptions, shared state, unstable dependencies, concurrency defects, random data, clock differences, or inadequate cleanup. It is not harmless. Flaky tests reduce trust, waste investigation time, and encourage teams to rerun pipelines until a pass appears.

Effective responses include quarantining a test temporarily with visible ownership, collecting failure evidence, removing arbitrary waits, controlling clocks and randomness, isolating data, and repairing the underlying defect. Quarantine must not become permanent exemption. A time limit and escalation rule should accompany it.

Testing technical debt includes duplicated tests, obsolete scenarios, brittle selectors, excessive mocks, undocumented fixtures, slow suites, unmaintained tools, and ignored warnings. It should be managed like other technical debt: make it visible, estimate its impact, prioritize it against product and operational risks, and reserve capacity for reduction.

Useful metrics include change-failure rate, escaped defects, mean time to diagnose a failure, test execution time, flaky-test rate, defect age, and coverage of high-risk behaviors. Metrics such as total test count or line coverage can be misleading when used alone. The best measurement systems combine outcome measures with leading indicators and qualitative review.

Automation, Analytics, and Intelligent Test Selection

Automation is most effective when the behavior is repeatable, the expected result is clear, and the cost of manual repetition is high. Automated tests should be readable, independent where possible, fast enough for their pipeline stage, and maintained as production code. Page-object models, API-level testing, data builders, parallel execution, and reusable assertions can improve maintainability.

Analytics can help identify components with high defect density, frequent change, long feedback times, or repeated production incidents. Test-impact analysis may select tests associated with changed code or affected dependencies. Mutation testing deliberately introduces small code changes to determine whether tests detect them, thereby assessing test effectiveness rather than merely test quantity.

Machine-learning tools can assist with test prioritization, visual comparison, anomaly detection, failure clustering, and generation of candidate test cases. Such tools do not remove the need for human review. A model may prioritize historically common failures while overlooking a novel safety or privacy risk. Training data, explainability, false positives, and access to source or customer data must be governed carefully.

Applied Case: Continuous Testing for a Digital Payments Platform

Background

The following is an illustrative case. A financial-technology organization operates a digital payments platform used by merchants and consumers. The platform includes a mobile application, payment APIs, a fraud-detection service, a ledger, notification services, and external banking integrations.

Situation and Problem

The organization released features weekly, but production incidents were increasing. The existing pipeline contained many UI regression tests, most of which ran for several hours. Developers frequently bypassed the pipeline because tests were slow and flaky. Production-like data had been copied into a shared test environment, creating privacy concerns and making tests interfere with one another. The organization also had no systematic performance or recovery testing.

Analysis

A risk workshop identified payment authorization, ledger accuracy, duplicate prevention, authentication, privacy, and recovery from banking-service failure as high-risk capabilities. The team observed that UI tests were attempting to provide evidence about rules that could be tested more quickly at API, component, or unit level. The absence of contract tests allowed changes in banking integrations to reach late-stage testing. Performance risks were hidden because tests used small datasets and unrealistic traffic patterns.

Approach and Solution

The organization introduced a layered strategy. Unit tests covered calculation and validation rules. Component tests used disposable databases and message brokers. Consumer-driven contracts protected interfaces between the payment API, fraud service, and banking adapters. A small set of end-to-end scenarios verified authorization, settlement, refund, and duplicate-payment prevention.

Synthetic, masked datasets were generated through version-controlled builders. Each test run received isolated data and a documented environment manifest. Infrastructure as code created ephemeral environments for major changes. Performance tests used representative transaction distributions and measured p95 and p99 latency, throughput, error rate, and resource saturation. Resilience experiments simulated delayed or unavailable banking services and verified timeout, retry, idempotency, and reconciliation behavior.

Pipeline stages were redesigned so that rapid checks ran on every commit, contract and component tests ran before integration deployment, and selected performance and resilience tests ran before high-risk releases. A quarantine policy was introduced for flaky tests, requiring an owner and repair deadline. Quality gates were linked to risk: critical payment and security failures blocked release, while non-critical test failures generated visible exceptions requiring product and engineering review.

Outcome

The revised process reduced dependence on slow UI suites and made failures easier to diagnose. More importantly, it produced stronger evidence about payment correctness, interface compatibility, capacity, and recovery. The organization did not treat a green pipeline as proof that every risk had disappeared; it combined automated evidence with exploratory testing, security review, operational monitoring, and controlled release exposure.

Learning Points

The case illustrates that continuous testing is an architectural and organizational practice. Faster tests alone would not have solved the problem. Risk analysis, data governance, environment reproducibility, contract protection, and clear release decisions were equally important. It also demonstrates why quality metrics should be interpreted in relation to business consequences rather than treated as isolated targets.

Challenges, Governance, and Professional Responsibility

Continuous testing introduces its own risks. Excessive automation can produce maintenance costs greater than its value. Overly strict gates can slow delivery without reducing meaningful risk, whereas weak gates can normalize unsafe releases. Tests may also expose credentials, personal data, proprietary algorithms, or security vulnerabilities through logs and reports.

Governance should define who may approve exceptions, how evidence is retained, how test data is protected, and how regulated behavior is demonstrated. Traceability may be required between requirements, risks, tests, defects, deployments, and operational outcomes. Access to test environments should follow least-privilege principles, and secrets should be injected through approved mechanisms rather than embedded in source code or fixtures.

Ethically, teams must consider users who are poorly represented by ordinary test data. Accessibility, language, disability, socioeconomic conditions, and unusual usage patterns may be overlooked if teams test only the most common path. Automated decision systems require particular attention to discriminatory outcomes, explainability, and the difference between technical correctness and social acceptability.

Testing also has a professional dimension. Engineers should report uncertainty honestly, resist pressure to suppress inconvenient results, and distinguish evidence from assumption. A release decision may reasonably accept known risk, but that acceptance should be explicit, informed, and accountable.

Emerging Directions and Best Practices

Several developments are shaping quality engineering. Platform teams increasingly provide standardized pipeline templates, ephemeral environments, test-data services, and observability by default. Continuous verification extends testing beyond deployment by analyzing live telemetry, synthetic user journeys, and progressive delivery signals. Feature flags, canary releases, blue-green deployment, and automated rollback reduce the size of each exposure.

Software supply-chain security is also becoming part of continuous testing. Dependency scanning, provenance records, artifact signing, infrastructure validation, and policy-as-code help establish whether software is trustworthy before deployment. AI-assisted testing will continue to support prioritization and analysis, but its outputs require validation and governance.

A mature practice generally follows these principles:

1. Begin with business and technical risk, not tool selection.

2. Test at the lowest effective level and reserve end-to-end tests for complete business risks.

3. Make tests deterministic, observable, isolated, and maintainable.

4. Keep production and test environments sufficiently consistent for the decision being made.

5. Use synthetic or protected data and document its provenance.

6. Treat flaky tests and test debt as delivery risks requiring ownership.

7. Combine automated checks with exploratory, security, accessibility, and operational testing.

8. Define quality gates and exception processes before a crisis occurs.

9. Measure escaped risk and feedback effectiveness, not merely test volume.

10. Use production learning to revise the testing portfolio continuously.

Chapter Summary

Quality engineering makes quality a shared, design-time, and operational responsibility. Continuous testing provides rapid evidence throughout the delivery lifecycle, but its purpose is not to maximize automated test counts. A sound strategy begins with risk and distributes evidence across unit, component, integration, contract, acceptance, performance, resilience, and exploratory testing.

Pipeline stages should provide progressively broader evidence while preserving rapid feedback. Test data must be representative, repeatable, isolated, and governed; environments must be reproducible and sufficiently production-like. Flaky tests and automation debt weaken trust and should be managed explicitly. Metrics must be interpreted carefully, since coverage and pass rates do not directly equal product quality.

Quality engineering also involves professional judgment. Privacy, security, accessibility, regulatory traceability, ethical use of automation, and honest communication of uncertainty are essential. Emerging practices such as ephemeral environments, progressive delivery, supply-chain verification, analytics, and AI-assisted test selection can strengthen quality when governed by human expertise and risk-based decision-making.

Key Terms

Acceptance testing: Evaluation of whether a product or feature satisfies specified business and user needs.

Chaos engineering: Controlled experimentation that tests system behavior under injected failure conditions.

Contract testing: Verification that a service interaction conforms to an agreed provider-consumer interface contract.

Continuous testing: Repeated, automated and human-centered testing integrated throughout the delivery lifecycle.

End-to-end testing: Testing of a complete business workflow across multiple integrated components.

Ephemeral environment: A temporary, reproducible environment created for a particular change or test run.

Exploratory testing: Simultaneous learning, test design, and execution guided by tester observation.

Flaky test: A test whose result changes without a relevant product change.

Infrastructure as code: Definition and management of infrastructure through version-controlled, executable specifications.

Integration testing: Testing of interactions among software components or external systems.

Mutation testing: Deliberate introduction of code changes to evaluate whether tests detect faults.

Performance testing: Evaluation of response time, throughput, scalability, capacity, and resource behavior.

Quality engineering: A systems-oriented discipline that designs, measures, automates, and improves quality across the lifecycle.

Quality gate: A defined condition that controls progression through a delivery pipeline.

Resilience testing: Evaluation of continued service, graceful degradation, and recovery during failures.

Risk-based testing: Allocation of testing effort according to the probability and consequence of failure.

Technical debt: The future cost created by expedient, inadequate, or outdated technical decisions.

Test data management: Governance and engineering of data used to design, execute, reproduce, and analyze tests.

Test environment: The application, infrastructure, configuration, dependencies, data, and tools used for testing.

Unit testing: Testing of a small, isolated software element such as a function or class.

Review Questions

Short Answer Questions

1. How does quality engineering differ from end-stage quality assurance?

2. What is meant by risk-based testing?

3. Why are contract tests valuable in distributed systems?

4. Identify two causes of flaky tests.

5. What characteristics make test data suitable for automated testing?

Long Answer Questions

1. Explain how unit, integration, contract, acceptance, performance, and resilience tests provide different forms of evidence.

2. Describe how a continuous testing pipeline should be structured and governed.

3. Discuss the relationship between test environments, infrastructure as code, and confidence in test results.

4. Analyze the causes and organizational consequences of testing technical debt.

5. Explain the ethical, privacy, security, and regulatory responsibilities involved in continuous testing.

Analytical / Application Questions

1. A team has 2,000 UI tests, a two-hour pipeline, and frequent intermittent failures. Propose a risk-based restructuring of its testing portfolio and justify the order of changes.

2. A service has excellent unit coverage but regularly fails when communicating with a payment provider. Which additional tests and environment practices would you introduce, and why?

3. Design a quality strategy for a cloud application that must remain available during dependency failures. Specify the risk assessment, automated tests, data and environment requirements, quality gates, and production feedback mechanisms.

22. Multiple Choice Questions with Answers

Question 1

Which principle most directly distinguishes quality engineering from end-stage quality assurance?

A. Quality is owned only by an independent testing department.

B. Quality is designed and managed across the product lifecycle by multiple roles.

C. All testing is postponed until after deployment.

D. Manual testing is eliminated completely.

Correct Answer: B. Quality is designed and managed across the product lifecycle by multiple roles.

Question 2

A team is deciding whether to invest in resilience testing for a service. Which factor should receive the greatest weight in a risk-based decision?

A. The number of lines of code in the service

B. The popularity of the testing tool

C. The consequence and likelihood of failure

D. The total number of existing test cases

Correct Answer: C. The consequence and likelihood of failure

Question 3

What is the primary purpose of a consumer-driven contract test?

A. To measure database storage capacity

B. To verify compatibility between a service provider and its consumers

C. To replace all unit tests

D. To test the visual design of a user interface

Correct Answer: B. To verify compatibility between a service provider and its consumers

Question 4

Which test type is generally most appropriate for rapid feedback on a business rule implemented in one class?

A. Unit test

B. End-to-end test

C. Stress test

D. Disaster recovery test

Correct Answer: A. Unit test

Question 5

A performance test reports an acceptable average response time, but the p99 response time is extremely high. What is the best interpretation?

A. The system is necessarily performing acceptably for all users.

B. The average proves that capacity testing is unnecessary.

C. A small but important proportion of requests may experience unacceptable latency.

D. The test must be invalid because percentiles cannot be used.

Correct Answer: C. A small but important proportion of requests may experience unacceptable latency.

Question 6

Which practice most directly reduces the privacy risk of using production-like data in automated testing?

A. Copying the complete production database into a shared environment

B. Using synthetic or appropriately masked data with controlled access

C. Removing all test data after every individual assertion

D. Allowing developers to download production records locally

Correct Answer: B. Using synthetic or appropriately masked data with controlled access

Question 7

A test passes or fails unpredictably without a relevant product change. What is this condition called?

A. Mutation testing

B. Contract drift

C. Flakiness

D. Capacity saturation

Correct Answer: C. Flakiness

Question 8

Why should a continuous testing pipeline contain relatively few end-to-end tests compared with unit and component tests?

A. End-to-end tests cannot test business behavior.

B. End-to-end tests are usually slower, more fragile, and harder to diagnose.

C. End-to-end tests are always less valuable than unit tests.

D. End-to-end tests do not require test data.

Correct Answer: B. End-to-end tests are usually slower, more fragile, and harder to diagnose.

Question 9

Which scenario best demonstrates resilience testing?

A. Checking whether a function returns the expected value for a normal input

B. Verifying that a service handles temporary unavailability of a banking dependency and reconciles safely

C. Checking whether source code follows formatting rules

D. Comparing two user-interface color schemes

Correct Answer: B. Verifying that a service handles temporary unavailability of a banking dependency and reconciles safely

Question 10

Why can high code-coverage percentage fail to demonstrate product quality?

A. Coverage measures exercised code but not necessarily correct assertions or important risks.

B. Coverage is calculated only for infrastructure scripts.

C. Coverage always decreases when tests are automated.

D. Coverage cannot be measured in continuous delivery.

Correct Answer: A. Coverage measures exercised code but not necessarily correct assertions or important risks.