Defect, Configuration, Change and Release Assurance

Introduction and Context

Software quality assurance is not complete when a test case passes. A software product must also be controlled as it evolves, its defects must be managed systematically, and each release must be shown to be safe, traceable, reproducible, and fit for use. Defect assurance, configuration assurance, change assurance, and release assurance are therefore closely connected disciplines.

A defect may originate in requirements, architecture, design, code, test data, infrastructure, documentation, or operational procedures. If defects are recorded inconsistently, their causes are poorly understood and recurring failures become likely. Similarly, uncontrolled changes can invalidate test evidence, create configuration drift, and make it impossible to determine which version caused a production incident. Release assurance integrates these concerns by establishing evidence that a defined product configuration has passed appropriate checks and can be deployed and operated responsibly.

This chapter presents an integrated lifecycle for managing defects and changes. It emphasizes risk-based decision-making rather than administrative compliance. The objective is not to eliminate all defects—an unrealistic goal—but to prevent avoidable defects, detect important defects early, control residual risk, and learn from failures.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the defect lifecycle and distinguish defects, failures, incidents, and problems.

2. Apply severity, priority, impact, and risk in defect decision-making.

3. Select suitable techniques for root-cause and causal analysis.

4. Establish configuration items, baselines, version control, and traceability.

5. Design an effective change-control process for normal, emergency, and standard changes.

6. Assess release readiness using objective evidence and explicit risk acceptance.

7. Plan rollback, roll-forward, production validation, and post-release learning.

8. Evaluate governance, automation, and ethical issues in modern release assurance.

1. Defects as Managed Quality Information

A defect is a condition in a work product that does not satisfy a stated or implied requirement. A failure is the externally observable inability of a system or component to perform a required function. A defect can exist without producing a failure—for example, an incorrect branch may not be executed. An incident is an observed interruption or degradation of service, while a problem is the underlying cause, or a set of causes, of one or more incidents.

These distinctions are operationally important. A defect found during code review may never become a failure. A production failure may result from several interacting defects, environmental conditions, or incorrect operational assumptions. Treating every issue as merely a “bug” loses information needed for prevention and prioritization.

1.1 Defect lifecycle

A typical lifecycle includes:

• Detection: An anomaly is observed through testing, review, monitoring, customer feedback, security assessment, or operations.
• Logging: The issue is recorded with enough information to reproduce, evaluate, and trace it.
• Triage: The team verifies the issue, removes duplicates, assesses impact, and assigns ownership.
• Analysis: The likely cause, affected components, risk, and required correction are investigated.
• Resolution: A correction, workaround, configuration change, or accepted disposition is selected.
• Verification: Testing confirms that the correction works and has not introduced unacceptable regression.
• Closure: Evidence is reviewed, links to requirements and changes are completed, and the record is closed.
• Learning: Trends and significant causes are examined to improve the development system.

A defect record should normally contain a unique identifier, title, environment, build or commit identifier, preconditions, reproduction steps, expected and actual results, evidence, severity, priority, affected configuration items, reporter, owner, status, target release, resolution, verification evidence, and closure authority. The fields should support decisions rather than create unnecessary bureaucracy.

1.2 Severity and priority

Severity describes the magnitude of the effect if the defect occurs. Examples include catastrophic loss, major functional unavailability, data corruption, security exposure, minor degradation, and cosmetic inconsistency. Priority describes the urgency or order in which the organization intends to address the defect. A low-severity issue affecting a contractual deadline may have high priority. A severe defect in an unused experimental feature may be urgent to fix but can sometimes be contained by disabling that feature.

Risk-based triage should consider at least:

• business and customer impact;
• probability or frequency of occurrence;
• safety, security, privacy, and regulatory consequences;
• detectability and availability of workarounds;
• exposure period and number of affected users;
• cost and risk of correction;
• dependencies and release timing.

A simple qualitative risk matrix can classify combinations such as likelihood and impact as low, medium, high, or critical. Such matrices are communication aids, not laws of nature. They should not replace professional judgment, especially where safety, security, or legal obligations impose mandatory action.

1.3 Defect metrics and their limitations

Useful measures include open defects by severity, defect ageing, reopen rate, escape rate, mean time to resolution, and defect density. A common descriptive measure is:

Defect density = Number of confirmed defects / Size of the software product

The size denominator may be thousands of lines of code, function points, story points, or another defined unit. The measure is meaningful only when the numerator, denominator, discovery process, and time period are consistently defined. Comparisons across teams can be misleading because products differ in complexity, test intensity, reporting culture, and operational exposure.

Defect escape rate can be expressed as:

Escape rate = Production defects / (Pre-release defects + Production defects)

This is a descriptive proportion for a defined population and period. It should not be interpreted as a universal quality probability. A sudden increase may indicate poorer quality, improved production monitoring, changed classification rules, or a larger user base.

Metrics should support learning and decisions. If individuals are rewarded for minimizing reported defects, under-reporting becomes rational and the metric becomes harmful.

2. Root-Cause and Causal Analysis

Correction addresses the immediate problem; prevention addresses why the problem was introduced or not detected. Root-cause analysis (RCA) seeks actionable causes that, if controlled, reduce the probability of recurrence. A single failure may have multiple contributing causes, so RCA should avoid simplistic blame-based explanations such as “developer error.” Human error is often a symptom of ambiguous requirements, inadequate tools, time pressure, weak review practices, or organizational incentives.

2.1 Choosing an analysis method

The five-whys technique repeatedly asks why an event occurred until process or system causes are identified. It is useful for straightforward causal chains but can oversimplify complex socio-technical systems.

A fishbone, or Ishikawa, diagram organizes possible causes under categories such as people, process, technology, environment, requirements, and measurement. It supports brainstorming but does not itself prove causation.

Fault tree analysis begins with an undesired top event and uses logical AND and OR relationships to model combinations of causes. It is particularly useful in safety and reliability analysis when system structure and probabilities are sufficiently understood.

Event tree analysis starts with an initiating event and follows possible success or failure paths through safeguards. It is useful for consequence analysis.

Causal factor charts and timeline analysis are valuable in incident investigations because they preserve sequence, conditions, decisions, and barriers. Pareto analysis can identify categories responsible for a large share of observed defects, but the Pareto pattern depends on how categories are defined.

2.2 A disciplined RCA process

A defensible RCA process should:

1. Define the failure in observable terms.

2. Preserve logs, versions, test evidence, and environmental information.

3. Construct a timeline using verified facts.

4. Identify direct, contributing, and systemic causes.

5. Test proposed causes against evidence and alternative explanations.

6. Specify corrective and preventive actions with owners and due dates.

7. Verify that actions reduce risk rather than merely produce documentation.

8. Share lessons without unfairly blaming individuals.

Corrective actions can include code changes, stronger requirements, automated tests, review checklists, monitoring, access controls, training, architectural redesign, or process changes. An action such as “remind developers to be careful” is weak unless accompanied by a change to the system that makes the desired behavior easier and more reliable.

3. Configuration Management and Baselines

Configuration management (CM) establishes and maintains the integrity of products and their relationships throughout the lifecycle. It answers four practical questions: What items exist? Which versions are approved? What changed, when, and why? Can the delivered system be reproduced?

3.1 Configuration items

A configuration item (CI) is a work product placed under configuration control. CIs may include source code, infrastructure-as-code, build scripts, third-party packages, database schemas, test assets, requirements, architecture models, deployment manifests, container images, cryptographic keys or their references, and operational documentation. The appropriate level of granularity depends on risk and change frequency. Controlling every temporary file creates noise; controlling too little prevents reproducibility.

A configuration management plan defines identification rules, repositories, naming and branching conventions, versioning, access rights, review requirements, status accounting, audits, and retention. Modern systems commonly use distributed version control, immutable build artifacts, artifact repositories, environment definitions, and automated pipelines. These tools implement CM practices but do not replace governance.

3.2 Baselines

A baseline is an approved version or set of versions that serves as a reference for further work and change control. Examples include a requirements baseline, design baseline, test baseline, release candidate baseline, and production baseline. A baseline is not necessarily perfect; it is a controlled reference whose changes require defined authorization.

A release baseline should identify, at minimum, application artifacts, dependency versions, database migration versions, configuration parameters, infrastructure definitions, test evidence, deployment instructions, and rollback or recovery procedures. External services and feature flags may also need explicit identification because they can alter behavior without a code change.

3.3 Status accounting and audits

Configuration status accounting records the identity, status, and history of CIs. It should allow an auditor or engineer to answer questions such as:

• Which source revision produced this artifact?
• Which requirements and tests are associated with it?
• Who approved its promotion?
• What differs from the previous production baseline?
• Which environments contain this version?

A functional configuration audit checks whether the product satisfies its specified functional requirements. A physical configuration audit checks whether the delivered product contains the correct components and documentation. Automated checks, checksums, signed artifacts, and reproducible builds strengthen confidence, but audit evidence remains dependent on the integrity of the surrounding process.

4. Change Control and Traceability

Change is inevitable because requirements, threats, technologies, regulations, markets, and operational conditions change. Change control does not mean preventing change; it means making change visible, evaluated, authorized, implemented, and verified.

4.1 Types of change

A standard change is low-risk, repeatable, pre-authorized, and implemented through a documented procedure. A normal change requires assessment and authorization according to its risk. An emergency change is needed to address an immediate threat or serious service impact and may use expedited authorization, but it still requires recording, testing proportional to the urgency, post-implementation review, and retrospective approval where policy requires.

A change request should describe the reason, scope, affected CIs, dependencies, risk assessment, implementation plan, test plan, deployment window, communication plan, monitoring, rollback or recovery approach, and approvers. Segregation of duties may require that the person implementing a high-risk change is not the sole person approving it.

4.2 Change impact analysis

Impact analysis examines direct and indirect effects. It should consider interfaces, data contracts, security controls, performance, accessibility, localization, regulatory obligations, operational procedures, test environments, and downstream consumers. The question is not only “What code changes?” but also “What assumptions could this change invalidate?”

For high-risk systems, an impact analysis may use dependency graphs, architecture models, threat models, failure mode analysis, or controlled experiments. For routine changes, a standard model may be sufficient. Risk-based proportionality is essential: excessive approval delays valuable work, while inadequate analysis creates hidden dependencies and rework.

4.3 Traceability

Traceability links business objectives and requirements to design elements, source changes, tests, defects, approvals, and release artifacts. A traceability matrix is one possible representation, but automated links in issue trackers, version-control systems, test-management tools, and pipelines may provide stronger currency.

Traceability supports change impact analysis, coverage evaluation, auditability, and incident investigation. It does not prove quality by itself. A complete set of links can still connect weak requirements to inadequate tests. Traceability should therefore be interpreted together with test results, review evidence, risk analysis, and operational data.

5. Release Assurance

Release assurance is the structured evaluation of whether a defined product configuration is suitable for deployment to a specified environment. It includes technical verification, operational readiness, governance, and explicit treatment of residual risk.

5.1 Release candidate and readiness evidence

A release candidate is a specific, identifiable build intended for final evaluation. A release decision should normally consider:

• completion and acceptance of planned scope;
• unresolved defects and approved exceptions;
• functional, integration, regression, performance, security, accessibility, and compatibility evidence as applicable;
• data migration and backup validation;
• infrastructure and capacity readiness;
• monitoring, alerting, logging, and support readiness;
• deployment, rollback, and recovery rehearsals;
• privacy, legal, licensing, and regulatory checks;
• stakeholder communication and training;
• traceability from requirements to delivered evidence.

A release gate should have explicit entry and exit criteria. “Testing completed” is weaker than “all critical test suites passed on release candidate RC-17, no open critical defects remain, and two high-risk exceptions have named owners and accepted residual risk.”

5.2 Risk acceptance and go/no-go decisions

Not every defect can be fixed before release. A responsible decision records the defect, affected users, likelihood, impact, compensating controls, expiry or review date, and accountable risk owner. Risk acceptance must be informed and authorized; it should not be disguised as schedule pressure or delegated implicitly to testers.

A release board or accountable product authority may use a go/no-go meeting, but decision quality depends on evidence available before the meeting. A meeting cannot compensate for missing test data, unclear ownership, or an unidentified production configuration.

5.3 Deployment strategies

A big-bang deployment changes all intended users or environments in one operation. It may be simple but has a large blast radius. A blue-green deployment maintains two production-like environments and switches traffic between them, enabling rapid reversal when data compatibility permits. A canary deployment exposes a small, monitored population first. A rolling deployment updates instances incrementally. Feature flags can separate code deployment from feature activation, but flags create configuration complexity and must be governed, tested, and retired.

The appropriate strategy depends on architecture, state management, data migration, observability, traffic control, regulatory constraints, and recovery objectives. No strategy is automatically safe.

6. Rollback, Recovery, and Production Validation

Rollback means returning software or configuration to a previous state. It is not always feasible. Irreversible database migrations, external side effects, consumed messages, and changed data semantics may make restoration unsafe. In such cases, a forward-fix, compensating transaction, feature disablement, or data repair may be preferable.

A rollback plan should define triggers, authority, steps, dependencies, data treatment, communications, validation, and escalation. A technically successful deployment is not enough; the team must know how to detect unacceptable behavior and who can stop or reverse it.

Production validation should begin immediately after deployment and continue for an appropriate observation period. It may include smoke tests, synthetic transactions, health checks, error-rate monitoring, latency and saturation measures, business transaction reconciliation, security monitoring, and customer-support signals. Validation should compare results with a defined baseline rather than rely on subjective impressions.

A useful operational principle is to make deployment and validation observable. Logs should identify release versions, metrics should support comparison, and distributed traces should allow failures to be localized. Monitoring must also protect privacy: logs should not expose unnecessary personal or confidential information.

7. Integrated Assurance Workflow

An effective integrated workflow can be organized as follows:

1. Identify and classify the defect, requirement, change, or incident.

2. Link it to affected configuration items and business or technical objectives.

3. Assess impact, urgency, dependencies, and risk.

4. Define the corrective change, test evidence, deployment method, and recovery plan.

5. Implement the change in a controlled branch or workspace.

6. Review code, configuration, security implications, and test adequacy.

7. Build an immutable, identifiable artifact.

8. Execute automated and targeted exploratory tests.

9. Update traceability and configuration status.

10. Obtain proportionate authorization.

11. Deploy using a controlled strategy.

12. Validate production behavior and communicate status.

13. Close defects and change records only when evidence is complete.

14. Conduct a retrospective or RCA for significant events.

This workflow reflects a feedback loop. Defect patterns should influence preventive engineering; release incidents should improve deployment and monitoring; configuration discrepancies should improve environment management; and change failures should modify impact-analysis practices.

8. Illustrative Case: Payments Platform Release

The following is a fictional illustrative case.

Background

A financial-services organization operates an online payments platform. A release introduces a new fraud-screening service and a database change intended to improve transaction classification. The release is business-critical because a regulatory reporting deadline is approaching.

Problem

During final testing, a test transaction intermittently receives a timeout. The defect is initially classified as medium severity because the transaction is retried successfully. The product manager proposes releasing immediately to meet the deadline.

Analysis

Triage links the issue to a specific release candidate, an API configuration item, and a database migration. Timeline analysis shows that the timeout occurs when the fraud service responds slowly and the application retry logic sends duplicate requests. A staging environment used a different timeout value from production, so ordinary tests did not reproduce the condition reliably.

The issue has a potentially high business and compliance impact: duplicate authorization requests could create inconsistent transaction states. The immediate defect is in retry handling, but contributing causes include configuration drift, incomplete resilience testing, and the absence of an idempotency requirement in the service contract.

Approach and solution

The release is held. Engineers implement idempotency keys and revise retry behavior. Configuration is moved into a version-controlled deployment definition, and staging is aligned with production-relevant timeout values. Tests are added for delayed responses, duplicate requests, partial failures, and recovery. The database migration is rehearsed using a production-sized copy and a verified backup.

The organization chooses a canary deployment limited to internal transactions and a small customer cohort. Monitoring includes authorization duplication, timeout rate, transaction reconciliation, and fraud-service latency. A rollback of application code is prepared, while the database change uses a backward-compatible expansion step so that reversal remains possible during the observation period.

Outcome

The canary operates without duplicate authorizations. A small increase in latency is observed and addressed by adjusting connection-pool limits. After the observation period, traffic is expanded. The change record includes test evidence, approvals, artifact identifiers, monitoring results, and the final production baseline.

Learning points

The case demonstrates that defect severity depends on consequences, not merely frequency. It also shows why configuration is part of the product, why traceability must include infrastructure and database changes, and why rollback feasibility should influence design before implementation. Most importantly, the organization corrected systemic causes rather than treating the timeout as an isolated coding mistake.

9. Challenges, Governance, and Contemporary Practice

9.1 Organizational and technical challenges

Common challenges include excessive defect backlogs, inconsistent classification, weak ownership, unreliable environments, configuration drift, approval bottlenecks, insufficient observability, and pressure to release despite unquantified risk. Distributed systems create additional difficulties because failures may arise from timing, retries, queues, partial availability, or third-party services rather than a single faulty component.

DevOps and continuous delivery reduce batch size and enable rapid feedback, but they do not remove the need for assurance. Control is increasingly implemented through automated policy checks, signed commits or artifacts, infrastructure-as-code, automated testing, progressive delivery, and continuous monitoring. The risk is that teams may confuse pipeline activity with evidence of fitness. Automation must be designed around meaningful quality properties and reviewed when the system changes.

9.2 Security, privacy, and regulatory governance

Defect and change records may contain personal data, credentials, customer identifiers, vulnerability details, or commercially sensitive information. Access must be controlled, retention periods defined, and sensitive data minimized. Security changes may require coordinated disclosure and restricted handling. Auditability should not become indiscriminate surveillance of individual employees.

Safety-critical, medical, financial, and other regulated systems may require formal approvals, validated tools, segregation of duties, electronic records controls, evidence retention, and demonstration of compliance with applicable standards and law. Compliance is a constraint and source of assurance, but it is not identical to product quality.

9.3 AI-assisted assurance

AI can assist with defect clustering, duplicate detection, log summarization, test generation, anomaly detection, impact-analysis suggestions, and release-risk dashboards. These uses can reduce analysis effort, but generated classifications and recommendations require human validation. Models may inherit historical reporting bias, miss rare failures, expose confidential records, or produce plausible but unsupported causal explanations. AI should not autonomously accept safety, security, privacy, or regulatory risk without accountable human governance.

Best Practices

1. Define defect, incident, failure, and problem terminology consistently.

2. Separate severity from priority and document the reasoning behind both.

3. Treat defect records as quality evidence, not individual performance scores.

4. Use RCA to identify controllable systemic causes and verify preventive actions.

5. Place code, infrastructure, dependencies, test assets, and deployment definitions under suitable configuration control.

6. Create explicit baselines and make every release reproducible.

7. Require change impact analysis proportional to risk.

8. Maintain traceability across requirements, changes, tests, defects, and artifacts.

9. Use immutable, identifiable release artifacts.

10. Define release gates, exception handling, rollback triggers, and production validation before deployment.

11. Prefer progressive delivery when it reduces blast radius and is operationally feasible.

12. Monitor business outcomes as well as technical health.

13. Reconcile production behavior with expected results after release.

14. Conduct blameless but accountable learning reviews for significant failures.

15. Regularly test recovery procedures rather than assuming that documented rollback plans work.

Chapter Summary

Defect, configuration, change, and release assurance form one integrated quality system. Defect management provides controlled information about abnormalities and their resolution. Severity, priority, impact, and risk must be distinguished so that attention is directed to the most consequential issues. Root-cause analysis should use evidence, consider systemic contributors, and produce verified preventive action.

Configuration management identifies the components of a product, controls their versions, establishes baselines, and preserves reproducibility. Change control makes modifications visible, assessed, authorized, implemented, and verified. Traceability connects requirements, designs, source changes, tests, defects, approvals, and delivered artifacts.

Release assurance evaluates whether a specific configuration is ready for deployment. Effective readiness decisions include test evidence, unresolved-risk treatment, operational preparation, monitoring, communication, and recovery planning. Rollback is not universally possible, so architecture and migration design must support forward recovery where necessary. Production validation confirms real behavior after deployment and feeds learning back into engineering practice.

Modern automation, DevOps, progressive delivery, and AI can strengthen assurance, but they do not replace judgment, governance, or accountability. High-quality assurance is proportionate to risk, technically grounded, ethically responsible, and oriented toward continuous learning.

Key Terms

Defect: A condition in a work product that fails to satisfy a requirement.

Failure: Observable inability of a system or component to perform a required function.

Incident: An event causing or potentially causing service interruption or degradation.

Problem: The underlying cause or causes of one or more incidents.

Severity: Magnitude of harm or effect associated with a defect.

Priority: Relative urgency or order for addressing an issue.

Root-cause analysis: Systematic investigation of causes and contributing conditions.

Configuration management: Control of product identity, versions, status, and integrity.

Configuration item: A work product placed under configuration control.

Baseline: An approved, controlled reference version or set of versions.

Configuration drift: Unplanned divergence between intended and actual configurations.

Change control: Evaluation, authorization, implementation, and verification of change.

Traceability: Ability to relate requirements, work products, tests, changes, and outcomes.

Release candidate: A defined build intended for final release evaluation.

Release gate: Explicit entry or exit criterion used in a release decision.

Rollback: Returning a system or configuration to an earlier state.

Canary deployment: Progressive release to a limited population before wider deployment.

Feature flag: Runtime control that enables or disables a capability independently of deployment.

Risk acceptance: Formal, informed approval to retain a known residual risk.

Production validation: Post-deployment confirmation that the system behaves acceptably in its operational environment.

Review Questions

Short Answer Questions

1. Distinguish a defect, failure, incident, and problem.

2. Why should severity and priority be recorded separately?

3. What is the purpose of a configuration baseline?

4. Name four items that should be included in a change request.

5. Why may rollback be infeasible after a database migration?

Long Answer Questions

1. Explain the complete defect lifecycle and identify the evidence needed at each major stage.

2. Compare five-whys analysis, fishbone diagrams, fault trees, and timeline analysis.

3. Discuss how configuration management supports release reproducibility and auditability.

4. Explain the relationship between traceability, change impact analysis, and release readiness.

5. Evaluate the advantages and limitations of blue-green, canary, and rolling deployment strategies.

Analytical / Application Questions

1. A critical customer workflow fails only after a third-party service becomes slow. Design a triage, RCA, and release decision process for this situation.

2. A team reports very few defects, but production incidents are increasing. Analyze possible explanations and recommend metrics and governance changes.

3. Design a release-readiness and rollback plan for a system requiring an irreversible data migration and progressive deployment.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes severity from priority?

A. Severity is assigned by developers, while priority is assigned by testers.

B. Severity describes impact, while priority describes urgency or order of action.

C. Severity applies only to production defects, while priority applies only to test defects.

D. Severity measures repair cost, while priority measures code complexity.

Correct Answer: B. Severity describes impact, while priority describes urgency or order of action.

Question 2

What is the primary purpose of a configuration baseline?

A. To eliminate all future changes

B. To provide an approved reference for controlled change

C. To replace all testing activities

D. To identify only production incidents

Correct Answer: B. To provide an approved reference for controlled change

Question 3

Which RCA technique begins with an undesired top event and models logical combinations of causes?

A. Fault tree analysis

B. Five-whys analysis

C. Pareto analysis

D. Checklist review

Correct Answer: A. Fault tree analysis

Question 4

Which item is most essential for reproducing a released software configuration?

A. The names of all project stakeholders

B. An identifiable artifact linked to its source and dependency versions

C. The number of meetings held during development

D. A list of rejected feature ideas

Correct Answer: B. An identifiable artifact linked to its source and dependency versions

Question 5

What is a standard change?

A. A high-risk change requiring a special emergency board

B. A repeatable, low-risk, documented, and pre-authorized change

C. Any change made directly in production

D. A change that has no test requirement under any circumstances

Correct Answer: B. A repeatable, low-risk, documented, and pre-authorized change

Question 6

Which statement about traceability is correct?

A. Traceability alone proves that a system is defect-free.

B. Traceability links requirements and work products to tests, changes, and evidence.

C. Traceability is needed only for regulated systems.

D. Traceability prevents requirements from changing.

Correct Answer: B. Traceability links requirements and work products to tests, changes, and evidence.

Question 7

Why can a database migration make rollback unsafe?

A. Database migrations never affect application behavior.

B. Data transformations or schema changes may be irreversible or incompatible with the previous version.

C. Rollback applies only to infrastructure, never software.

D. Testing cannot be performed on databases.

Correct Answer: B. Data transformations or schema changes may be irreversible or incompatible with the previous version.

Question 8

What is the main characteristic of a canary deployment?

A. All users receive the change simultaneously.

B. The release is first exposed to a limited population and monitored.

C. The release is permanently installed in two environments.

D. The release bypasses production validation.

Correct Answer: B. The release is first exposed to a limited population and monitored.

Question 9

Which is an appropriate production-validation activity?

A. Deleting deployment logs after a successful release

B. Comparing business transaction results and error rates with defined baselines

C. Disabling monitoring to reduce operational noise

D. Closing all defects before observing the release

Correct Answer: B. Comparing business transaction results and error rates with defined baselines

Question 10

Why should AI-generated defect classifications be reviewed by accountable personnel?

A. AI tools cannot process any software data.

B. AI recommendations may reflect bias, miss rare conditions, or expose sensitive information.

C. Human review makes automated testing impossible.

D. AI is legally prohibited from assisting software assurance.

Correct Answer: B. AI recommendations may reflect bias, miss rare conditions, or expose sensitive information.