Test Automation and Continuous Quality Engineering

Introduction and Context

Modern software systems are released through rapidly changing, distributed technology ecosystems. Applications commonly expose APIs, depend on cloud services, use containers and infrastructure as code, and deliver functionality through web or mobile interfaces. In this environment, quality assurance cannot depend primarily on manual regression testing performed near the end of a release. Quality must be engineered continuously through automation, feedback, disciplined change management, and risk-based decision-making.

Test automation is the use of software to control test execution, compare actual and expected results, and report evidence. Continuous quality engineering (CQE) extends this idea. It treats quality as a responsibility shared by development, testing, operations, security, product management, and users throughout the software life cycle. CQE does not mean automating every test or making the pipeline merely faster. It means designing a delivery system in which relevant quality information is produced early, repeatedly, and sufficiently reliably to support release decisions.

This chapter examines maintainable automation architectures for APIs, user interfaces, and services; continuous testing in CI/CD pipelines; quality gates; version control; service virtualization; infrastructure as code; governance; and emerging uses of artificial intelligence.

Learning Objectives

After studying this chapter, the learner should be able to:

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

2. Design maintainable automation for APIs, user interfaces, and distributed services.

3. Select appropriate tests for different stages of a CI/CD pipeline.

4. Define effective quality gates using risk, evidence, and measurable criteria.

5. Integrate source control, build pipelines, service virtualization, and infrastructure as code.

6. Evaluate automation architecture, reliability, maintainability, and governance.

7. Analyze a realistic quality-engineering transformation and justify design decisions.

1. Foundations of Continuous Quality Engineering

1.1 Automation and continuous testing

A test script is not automatically a quality-engineering asset. A maintainable automated test has a clear purpose, deterministic or controlled behavior, readable failure information, appropriate test data, and a lifecycle aligned with the product. Automation is valuable when it provides feedback at a cost and speed that manual execution cannot achieve, while preserving sufficient confidence in the result.

Continuous testing is the repeated execution of suitable tests throughout the delivery pipeline. It includes developer-level checks, component tests, API tests, contract tests, security scans, performance checks, and selected end-to-end tests. The tests are not all executed at the same frequency. Fast, stable checks normally run on every change, whereas expensive resilience or large-scale performance tests may run nightly, before release, or in a production-like environment.

Continuous quality engineering is broader than continuous testing. It includes prevention, testability, observability, quality risk analysis, production feedback, operational readiness, and improvement of the delivery system. For example, adding structured logging and health endpoints may improve diagnosability even though neither is a conventional functional test.

1.2 The test pyramid and its refinement

The classical test pyramid proposes many fast unit tests at the base, fewer service or API tests in the middle, and a small number of slow user-interface tests at the top. Its central principle is economic: tests should be placed at the lowest level that can validly detect the risk. A calculation should normally be tested at unit or component level rather than through a browser.

The pyramid is a heuristic, not a universal law. Systems composed of independently deployed services may require substantial contract testing. Event-driven systems need validation of messages, schemas, ordering assumptions, and eventual consistency. A useful modern model therefore considers several dimensions:

• Test level: unit, component, contract, integration, system, and acceptance.
• Test purpose: functional, security, performance, resilience, usability, and compliance.
• Feedback time: immediate, pipeline-stage, scheduled, or production-based.
• Confidence and cost: the evidence supplied relative to execution and maintenance cost.

A large collection of end-to-end tests can create slow feedback and fragile failures, while too few system-level tests can miss integration defects. Architecture must therefore be based on risk and system boundaries rather than a fixed numerical ratio.

1.3 Quality as a socio-technical property

Quality is not produced by a test tool alone. It depends on requirements, architecture, code review, environments, data, observability, deployment controls, and organizational behavior. A team that measures only test-case count may generate large quantities of low-value automation. More meaningful questions include: Which risks are covered? How quickly are failures diagnosed? How often do tests give false alarms? Can a failed build be reproduced? Does the pipeline prevent unacceptable changes?

2. Architecture for Maintainable Test Automation

2.1 Architectural principles

A maintainable automation system generally follows these principles:

Separation of concerns. Test intent, interaction mechanisms, data, environment configuration, and reporting should not be tangled in every test case.

Explicit abstractions. Reusable client libraries, page objects, domain fixtures, and assertion utilities should hide technical details without hiding test meaning.

Deterministic execution. Tests should control clocks, random seeds, external dependencies, and data state where practical. When nondeterminism is inherent, the test should express acceptable timing and state transitions explicitly.

Isolation. Tests should avoid depending on the order or side effects of other tests. Parallel execution is reliable only when data and resources are isolated.

Observability. Failures should include request and response details, correlation identifiers, screenshots or traces where relevant, logs, and environment information, subject to privacy rules.

Change tolerance. Automation should interact through stable contracts and semantic selectors rather than incidental implementation details.

Fast failure and useful diagnostics. A failure that takes ten minutes to explain is less valuable than one that identifies the violated business rule immediately.

A common layered architecture contains: a test specification layer, domain or workflow layer, protocol or UI interaction layer, data and fixture layer, environment configuration, and reporting/observability services. The layers should have controlled dependencies. For example, business-level tests should not contain raw XPath expressions, database cleanup commands, and environment URLs in the same method.

2.2 API and service automation

API automation is usually more stable and faster than browser automation because it operates at a contract boundary. A mature API test portfolio may include:

• schema and syntax validation;
• positive and negative functional cases;
• authentication, authorization, and boundary checks;
• idempotency and concurrency behavior;
• pagination, filtering, sorting, and error semantics;
• compatibility across API versions;
• contract tests between consumers and providers;
• performance and rate-limit behavior.

A useful API test should verify both the response and relevant state changes. For example, a test for creating an order may validate status code, response schema, business identifiers, persistence, emitted events, and authorization. It should not assert unstable fields such as timestamps exactly unless the requirement specifies them.

Contract testing addresses a particular distributed-systems problem. A consumer defines the interactions it requires, and the provider verifies that it satisfies those expectations. Consumer-driven contracts can reduce reliance on a full integration environment, but they do not replace all integration testing: they may not detect deployment configuration problems, network failures, data-store behavior, or interactions between multiple providers.

For asynchronous services, a test should model eventual consistency rather than assume immediate completion. Polling should have a bounded timeout and an appropriate interval; indefinite waits conceal defects. Message tests should validate schema, required headers, correlation identifiers, and behavior for duplicate or out-of-order delivery when those conditions are possible.

2.3 User-interface automation

UI automation is appropriate for critical user journeys, accessibility checks, visual behavior, and interactions that cannot be validated below the interface. It is expensive because it depends on browsers, rendering, timing, test data, and multiple system components.

Maintainable UI automation uses stable, accessible selectors such as roles, labels, and dedicated test identifiers. It avoids coordinates, brittle CSS chains, and arbitrary sleep statements. Explicit synchronization should wait for a meaningful condition, such as an element becoming enabled or a network operation completing. Test data should be created through supported APIs or fixtures rather than through a long sequence of unrelated UI actions.

Page-object or screen-object designs can centralize locators and interaction methods. However, an abstraction becomes harmful when it reproduces every widget with a large opaque API. Domain-oriented workflow objects often provide better readability: `submitLoanApplication()` expresses intent more clearly than exposing every click and keystroke to every test.

Visual regression testing compares rendered output with an approved baseline. It requires controlled fonts, viewport sizes, localization, and rendering environments. A difference is evidence requiring review, not automatically a defect; dynamic content must be masked or modeled carefully.

2.4 Test data and environment management

Test data is an architectural concern. Shared mutable records create order dependence and parallel-execution failures. Preferred strategies include generated data with unique identifiers, isolated namespaces, transaction rollback where suitable, resettable fixtures, and realistic but anonymized datasets.

Secrets must not be embedded in source code or test reports. They should be supplied through an approved secret-management facility, with least-privilege credentials and rotation. Production data should not be copied into test environments without legal authorization, minimization, masking, and access controls.

3. Continuous Integration and Continuous Delivery

3.1 Version control as a quality mechanism

Version control provides more than backup. It creates a traceable relationship between source code, test code, infrastructure definitions, dependency versions, configuration, and review decisions. A repository should normally contain automation code alongside the product code or in a governed, versioned repository with compatible release practices.

Branching and integration policies influence feedback. Short-lived branches and frequent integration reduce merge complexity. Pull requests can require peer review, static analysis, unit tests, dependency checks, and policy validation before merging. The exact branching model is less important than preserving reproducibility and ensuring that unreviewed changes cannot silently bypass required checks.

3.2 Pipeline stages

A practical pipeline may include the following stages:

1. Pre-commit or local checks: formatting, linting, fast unit tests, and secret detection.

2. Build and package: compilation, dependency resolution, artifact creation, and software bill of materials generation.

3. Static and component validation: code analysis, unit tests, component tests, and mutation or coverage analysis where justified.

4. Deploy to an ephemeral or shared test environment: infrastructure provisioning, configuration validation, and smoke testing.

5. Service and contract testing: API, integration, schema, and consumer-provider checks.

6. System and UI checks: critical journeys, accessibility, and selected cross-service scenarios.

7. Non-functional assessment: security, performance, resilience, compliance, and operational-readiness checks according to risk.

8. Promotion and monitoring: controlled deployment, health verification, telemetry analysis, and rollback or progressive delivery.

Not every stage belongs on every pull request. The design should optimize feedback while ensuring that high-risk changes receive appropriate evidence before release.

3.3 Quality gates

A quality gate is a decision rule that permits, warns on, or blocks progression. Examples include successful critical tests, no unresolved high-severity security findings, verified API compatibility, acceptable performance thresholds, and required approvals.

Good gates have five properties:

• they correspond to a material product or operational risk;
• their data is trustworthy and reproducible;
• thresholds and exceptions are documented;
• failures are actionable;
• bypasses are exceptional, authorized, time-bounded, and audited.

Coverage percentage alone is a weak gate. A project may have high statement coverage while missing critical business paths, authorization failures, or failure handling. Coverage can support analysis, but release decisions should combine risk-based coverage, defect history, test reliability, security evidence, and operational indicators.

A useful distinction is between blocking gates, which stop promotion, and informational signals, which guide improvement without stopping delivery. If every warning blocks the pipeline, teams may normalize bypasses or disable the gate.

3.4 Pipeline reliability and test flakiness

A flaky test produces different results without a relevant product change. Causes include race conditions, shared data, time-zone assumptions, unstable dependencies, resource exhaustion, and poor synchronization. Flakiness weakens trust in the entire pipeline.

Retries can help distinguish transient infrastructure failures, but indiscriminate retries conceal real defects. A retry policy should record the first failure, classify the cause, and impose a limit. Teams should track flaky tests, quarantine them only with ownership and a removal deadline, and prioritize root-cause correction.

4. Service Virtualization and Infrastructure as Code

4.1 Service virtualization

Service virtualization provides simulated behavior for a dependent system that is unavailable, costly, unstable, rate-limited, or unsafe to invoke. A virtual service may return predefined responses, model state transitions, inject latency, produce faults, or emulate protocol behavior.

It is especially useful for testing rare failures, third-party payment providers, unavailable partners, and scenarios difficult to reproduce in a shared environment. Virtualization should be based on an explicit contract and realistic behavior. A mock that returns only ideal responses can create false confidence. The virtual service itself requires tests, versioning, and periodic comparison with the real dependency.

Mocks, stubs, fakes, simulators, and virtual services differ in scope, but the practical distinction is less important than the behavior being represented and the risk of divergence. Real integration tests remain necessary for critical boundaries.

4.2 Infrastructure as code

Infrastructure as code (IaC) defines environments through declarative or programmatic files stored in version control. It can provision networks, databases, containers, identity policies, observability components, and test environments consistently.

IaC supports quality by making environments reproducible, reviewable, and recoverable. A pipeline can create an ephemeral environment for a change, execute tests, collect evidence, and destroy the environment. IaC itself must be tested through syntax validation, policy-as-code, plan review, security scanning, and deployment tests. A successful infrastructure plan does not prove that an application is correctly configured.

State management, secrets, provider versions, drift detection, and destructive changes require governance. The principle of least privilege applies to pipeline identities as well as application identities.

5. Measurement, Evidence, and Decision-Making

Metrics should support decisions rather than reward superficial activity. Useful measures include:

• lead time from approved change to production;
• deployment frequency;
• change failure rate;
• time to restore service;
• defect escape rate by severity;
• automated-test duration and failure classification;
• flaky-test rate;
• mean time to diagnose a failure;
• risk coverage of critical requirements;
• pipeline queue time and environment-provisioning time.

The well-known delivery-performance measures are useful operational indicators, but they do not replace product quality measures. A team can deploy frequently while delivering poor usability or insecure functionality. Metrics must be interpreted together and segmented by service, release type, and risk class.

For a simple illustrative calculation, suppose a pipeline executes 2,000 tests and 18 fail. The raw failure proportion is 18/2,000 = 0.009, or 0.9 percent. This number is not a defect rate unless failures are classified: some may be product defects, some environmental failures, and some flaky tests. Quantification without classification can lead to wrong management action.

A stronger evidence model links each important risk to one or more controls and tests, records the latest result and environment, and identifies residual risk. Release approval is then an engineering judgment supported by evidence, not a mechanical response to a single metric.

6. Governance, Ethics, and Security

Automation can create ethical and regulatory risks. Test data may contain personal, financial, health, or employee information. Access must follow privacy principles such as purpose limitation, minimization, retention control, and authorized use. Accessibility testing is a quality and inclusion responsibility, not an optional cosmetic activity.

Automated security tests should cover dependency vulnerabilities, secrets, authentication, authorization, input validation, and infrastructure policies. Security scanning has false positives and false negatives; findings require triage and risk acceptance by authorized personnel.

Auditability requires traceability from requirement or risk to change, test evidence, approval, deployment, and monitoring. Regulated systems may require electronic records, segregation of duties, validation evidence, and controlled changes. An emergency bypass should preserve an audit trail and require retrospective review.

Artificial intelligence can assist in generating test cases, producing data, classifying failures, detecting visual anomalies, and suggesting selectors. AI-generated tests must be reviewed because generated assertions may be shallow, biased, insecure, or inconsistent with requirements. Sensitive source code and personal data should not be sent to an external model without authorization. AI should augment professional judgment, not become an unexamined quality gate.

7. Illustrative Case Study: Automated Quality Engineering for a Digital Payments Platform

Background

The following is a fictional illustrative case. A digital payments company operates a web portal, mobile application, payment API, fraud service, notification service, and external bank integrations. Releases occur weekly, but regression testing takes four days. Production defects are concentrated in authorization rules and integration behavior.

Problem

The organization has a large browser suite with duplicated setup, shared test accounts, hard-coded waits, and a single shared environment. A failed test often requires manual investigation. External bank services are unavailable in lower environments, and infrastructure changes are performed manually. Management proposes doubling the number of UI tests.

Analysis

The main problem is not insufficient test quantity. The portfolio is concentrated at an expensive level, lacks stable service contracts, and has poor test-data isolation. Manual infrastructure also creates environmental inconsistency. Doubling UI tests would increase execution time and maintenance without addressing the principal risks.

The team maps risks to test levels. Currency calculation and authorization decisions are assigned to unit and component tests. Payment API behavior is covered by API and contract tests. Bank failure, timeout, and duplicate-payment scenarios require service virtualization and selected integration tests. Only critical customer journeys remain as browser tests.

Approach and solution

The team introduces a layered repository structure. Domain-level API clients hide transport details, and generated test data uses isolated merchant and customer identifiers. Consumer-driven contracts are published for the fraud and notification services. A virtual bank service models approval, decline, timeout, duplicate request, and malformed response behavior.

The delivery pipeline runs fast checks on each pull request. Contract and component tests run before deployment to an ephemeral environment created with IaC. Critical UI journeys run after service checks, while broader browser regression runs nightly. Test reports include correlation identifiers, service logs, traces, and sanitized request data.

Quality gates require all critical authorization tests to pass, no unresolved high-severity security findings, contract compatibility, successful environment health checks, and review of performance results for payment changes. A failed noncritical visual check creates a warning and a review ticket rather than blocking every release.

The team also establishes a flaky-test ownership process. A test that fails intermittently is tagged with a defect record and a removal deadline; retries do not erase the original failure evidence. Production monitoring is linked to deployment identifiers so that escaped defects can be traced to changes.

Outcome

After several iterations, the organization reduces the pull-request feedback cycle, removes most duplicated UI setup, and detects incompatible service changes before integration. More importantly, release decisions become explainable: evidence is connected to business risk, environment creation is repeatable, and failures are diagnosed using correlated telemetry. The organization does not eliminate production defects, but it reduces uncertainty and improves recovery when defects occur.

Learning points

1. Automation architecture should reflect system boundaries and risk, not the popularity of a tool.

2. Service virtualization is valuable when it models meaningful dependency behavior, including failures.

3. IaC improves test repeatability but must itself be governed and tested.

4. Quality gates should be selective, trusted, and actionable.

5. Reducing flaky tests and improving diagnostics may produce more quality value than adding test cases.

8. Challenges and Limitations

Automation has significant initial cost. Framework design, test-data services, environment provisioning, reporting, and training require investment. Automated checks can also become obsolete as products evolve. Maintenance must be included in the total cost of ownership.

Automation cannot fully evaluate subjective usability, organizational fitness, exploratory behavior, or ambiguous requirements. Human testing remains important, especially for discovery, accessibility judgment, and novel risks. Conversely, manual repetition is not a substitute for engineering a reliable regression system.

Distributed systems introduce timing, partial failure, and version-skew problems. A green pipeline may still miss production-only behavior, capacity limits, regional failures, or emergent interactions. Progressive delivery, observability, canary analysis, and rapid rollback complement pre-release testing.

Tool selection is another limitation. A tool may support browser automation, API testing, or pipeline integration, but no product automatically supplies good architecture. Selection should consider language support, accessibility, parallelism, diagnostics, licensing, security, community health, vendor dependence, and integration with existing engineering practices.

9. Best-Practice Design Checklist

A professional implementation should be able to answer yes to most of the following questions:

• Are critical risks explicitly mapped to appropriate test levels?
• Are tests isolated, deterministic, and independently executable?
• Are APIs and contracts tested without unnecessary UI dependence?
• Are selectors semantic and synchronization condition-based?
• Is test data generated, controlled, and privacy-compliant?
• Are secrets kept outside source code and reports?
• Are source, tests, configuration, and IaC versioned and reviewed?
• Are pipeline stages ordered according to feedback value and cost?
• Are quality gates risk-based, measurable, and auditable?
• Are flaky tests measured, owned, and corrected?
• Are virtualized dependencies versioned and compared with real services?
• Are security, accessibility, performance, and operational readiness included where relevant?
• Can a failure be reproduced and diagnosed from pipeline evidence?
• Are production monitoring and incident learning connected to quality improvement?

Chapter Summary

Test automation is a means of producing reliable, repeatable evidence; it is not a substitute for quality engineering. Continuous quality engineering extends continuous testing to prevention, architecture, observability, operational readiness, and shared responsibility. Maintainable automation separates test intent from technical interaction, controls data and environments, and uses stable contracts.

The test pyramid remains a useful economic principle, but modern distributed systems require refinement through contract, event, security, performance, and resilience testing. API and service tests generally provide faster and more stable feedback than UI tests, while a small number of critical UI journeys validate end-user integration. CI/CD pipelines should stage tests according to risk and feedback time. Quality gates must be trustworthy, actionable, and auditable rather than based solely on coverage.

Service virtualization enables controlled testing of unavailable or failure-prone dependencies, while infrastructure as code makes environments reproducible and reviewable. Metrics should combine delivery performance, test reliability, defect escape, risk coverage, and operational outcomes. Governance must address privacy, security, accessibility, auditability, and responsible use of AI. The central professional task is to balance speed, confidence, cost, and residual risk through evidence-based engineering decisions.

Key Terms

Test automation: Use of software to execute tests, compare results, and report evidence.

Continuous testing: Repeated execution of suitable tests throughout the delivery life cycle.

Continuous quality engineering: An integrated approach combining testing, prevention, observability, risk management, and operational feedback.

Test pyramid: A heuristic favoring many fast lower-level tests and fewer expensive end-to-end tests.

Contract testing: Verification that a service provider satisfies a consumer’s defined interaction expectations.

API testing: Validation of application programming interfaces, including behavior, schema, security, and state changes.

UI automation: Automated interaction with and validation of a graphical user interface.

Test fixture: Controlled data or environment setup required for a test.

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

Quality gate: A defined rule controlling progression through a delivery pipeline.

Continuous integration: Frequent integration of changes with automated validation.

Service virtualization: Simulation of a dependent service and its relevant behavior.

Infrastructure as code: Versioned, executable definitions used to provision and configure infrastructure.

Ephemeral environment: A temporary environment created for a specific change or test purpose.

Observability: The ability to understand internal system behavior through outputs such as logs, metrics, and traces.

Progressive delivery: Controlled release through techniques such as canary or staged deployment.

Risk-based testing: Allocation of testing effort according to likelihood and impact of failure.

Mutation testing: Evaluation of test effectiveness by checking whether tests detect deliberate code changes.

Software bill of materials: An inventory of components and dependencies in a software artifact.

Residual risk: Risk remaining after controls and tests have been applied.

Review Questions

Short Answer Questions

1. Distinguish continuous testing from continuous quality engineering.

2. Why are stable selectors preferred in UI automation?

3. What is the purpose of a quality gate?

4. State two benefits and one limitation of service virtualization.

5. Why is test coverage percentage insufficient as the only release criterion?

Long Answer Questions

1. Explain how to design a maintainable automation architecture for APIs, services, and user interfaces.

2. Discuss how a CI/CD pipeline should stage tests to balance speed, cost, and confidence.

3. Explain the role of version control and infrastructure as code in continuous quality engineering.

4. Critically evaluate the test pyramid for a distributed, event-driven system.

5. Discuss ethical, security, privacy, and governance issues in automated testing.

Analytical / Application Questions

1. A team has 1,500 UI tests, a three-day regression cycle, and frequent flaky failures. Propose a redesigned test portfolio and justify the placement of tests at different levels.

2. An external payment provider is unavailable in the test environment and occasionally returns delayed or malformed responses in production. Design a service-virtualization and integration-testing strategy.

3. A pipeline reports 98 percent test success, but five critical authorization tests fail intermittently. Decide whether release should be blocked, identify the evidence required, and propose corrective actions.

Multiple Choice Questions with Answers

Question 1

Which principle best explains why critical business logic is usually tested below the UI level?

A. Lower-level tests are generally faster and less fragile

B. UI tests cannot validate business requirements

C. Lower-level tests eliminate the need for integration testing

D. UI tests are always technically impossible to automate

Correct Answer: A. Lower-level tests are generally faster and less fragile

Question 2

What is the primary purpose of consumer-driven contract testing?

A. To measure browser rendering performance

B. To verify that a provider satisfies a consumer’s interaction expectations

C. To replace all production monitoring

D. To generate infrastructure automatically

Correct Answer: B. To verify that a provider satisfies a consumer’s interaction expectations

Question 3

Which practice most directly reduces UI-test flakiness caused by timing?

A. Adding long arbitrary sleep statements

B. Running every test twice

C. Waiting for meaningful application conditions

D. Increasing the number of screenshots

Correct Answer: C. Waiting for meaningful application conditions

Question 4

Which statement about a quality gate is most accurate?

A. It should always block releases when any warning occurs

B. It is a decision rule based on defined quality evidence and risk

C. It is equivalent to a test-case count

D. It removes the need for human release judgment

Correct Answer: B. It is a decision rule based on defined quality evidence and risk

Question 5

A pipeline runs 2,000 tests and 18 fail. What is the raw failure proportion?

A. 0.09%

B. 0.9%

C. 9%

D. 18%

Correct Answer: B. 0.9%

Question 6

Which is an appropriate use of service virtualization?

A. Modeling timeout and decline behavior from an unavailable bank service

B. Proving that the real bank service is always available

C. Replacing all contract tests permanently

D. Removing the need for dependency monitoring

Correct Answer: A. Modeling timeout and decline behavior from an unavailable bank service

Question 7

What is a key quality benefit of infrastructure as code?

A. It guarantees defect-free application code

B. It makes environments more reproducible and reviewable

C. It prevents all security vulnerabilities

D. It eliminates the need for configuration management

Correct Answer: B. It makes environments more reproducible and reviewable

Question 8

Which metric most directly describes a flaky test?

A. A test that changes result without a relevant product change

B. A test that always fails because of a known defect

C. A test that takes less than one second

D. A test that is executed manually

Correct Answer: A. A test that changes result without a relevant product change

Question 9

Why should automated tests avoid embedding secrets in source code?

A. Secrets make tests execute more slowly

B. Secrets cannot be used by APIs

C. Exposure creates security and governance risks

D. Version control cannot store text values

Correct Answer: C. Exposure creates security and governance risks

Question 10

Which statement best describes responsible use of AI-generated tests?

A. Generated tests should be accepted without review

B. AI should replace requirements analysis

C. Generated tests require review for correctness, bias, and security

D. AI-generated tests are valid only for UI systems

Correct Answer: C. Generated tests require review for correctness, bias, and security