Testing Strategy, Levels and Test Management

Introduction

Software quality assurance (SQA) is not achieved by testing alone, yet testing remains one of the most important empirical activities through which quality risks are identified, evaluated and controlled. In modern software systems, testing must be treated as a managed, risk-based engineering discipline rather than as a final inspection performed immediately before release. A sound testing strategy connects business objectives, architectural risks, quality attributes, development practices, regulatory obligations and operational realities.

This chapter examines the principal levels of testing—unit, integration, system, acceptance and regression testing—and explains how they are organized into a coherent strategy. It also addresses test planning, risk prioritization, test environments, test data, entry and exit criteria, coverage, defect management and independent testing. The emphasis is on postgraduate-level analysis: selecting an appropriate combination of techniques, understanding trade-offs, interpreting evidence and making defensible release decisions.

Testing provides evidence, not proof, of software correctness. A test suite can reveal failures, but passing tests cannot demonstrate that no undiscovered defect exists. Consequently, test management must combine structured test design with professional judgment, traceability, measurement and continuous learning.

Learning Objectives

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

1. Explain the purpose and relationship of unit, integration, system, acceptance and regression testing.

2. Design a risk-based testing strategy aligned with business and technical risks.

3. Define test objectives, scope, prioritization, coverage, entry criteria and exit criteria.

4. Plan and govern test environments, test data and test execution.

5. Evaluate the benefits and limitations of independent testing.

6. Interpret test metrics without confusing activity measures with quality evidence.

7. Apply testing principles to a realistic software project and make a reasoned release recommendation.

1. Testing Strategy as a Quality Decision Framework

A testing strategy is a deliberate, documented approach for obtaining evidence about whether a system is fit for its intended purpose. It answers questions such as:

• What could fail, and what would be the consequence?
• Which quality attributes matter most?
• At what level should each risk be tested?
• Which techniques, tools and people are required?
• What evidence is sufficient for release?
• How will changes affect the required regression scope?

A strategy is broader than a test plan. A test plan normally specifies activities for a release, iteration or project. A strategy establishes the principles and priorities that guide those plans. For example, a safety-critical system may require requirements traceability, independent verification, structural coverage evidence and formal acceptance, whereas a low-risk internal dashboard may emphasize exploratory testing and rapid feedback.

1.1 Testing principles

Several established principles shape effective testing:

• Testing shows the presence of defects, not their absence. A failed test proves that at least one problem exists; a passed test only demonstrates that the tested condition behaved as expected.
• Exhaustive testing is generally impossible. The input space, execution paths and environmental states are usually too large to test completely.
• Early testing is economically valuable. Defects discovered near their source are usually easier to diagnose and correct than defects discovered after integration or deployment.
• Defects cluster. A small number of components often contain a large proportion of discovered failures. Test effort should therefore be informed by historical and architectural evidence rather than distributed uniformly.
• Pesticide paradox. Repeating an unchanged test suite eventually produces diminishing returns because it exercises familiar conditions. Tests must evolve as risks and implementations change.
• Testing is context dependent. The appropriate strategy depends on system purpose, risk, technology, development model and regulatory environment.
• Absence-of-errors fallacy. A system may conform to its specification and still fail to meet user needs if the requirements are incomplete or inappropriate.

These principles discourage both false confidence and indiscriminate testing. The goal is not to maximize the number of tests, but to maximize useful risk reduction for the available time and resources.

1.2 Verification, validation and quality assurance

Verification asks whether the product is being built correctly against specified requirements, designs and standards. Validation asks whether the right product is being built for its users and operational context. Unit and integration tests often provide strong verification evidence, whereas acceptance testing contributes substantially to validation. SQA encompasses the broader planned and systematic activities—process definition, reviews, audits, metrics, improvement and testing—that provide confidence in both product and process quality.

2. Test Levels and Their Relationships

Test levels represent different scopes of the software under test. They are complementary rather than competing alternatives. A defect may be easiest to detect at one level but most meaningful at another.

2.1 Unit testing

Unit testing examines the smallest independently testable component, such as a function, class, module or service operation. The objective is to verify local logic, boundary conditions, error handling, data transformations and contracts.

Effective unit tests are usually fast, deterministic and isolated from external systems. Test doubles—stubs, drivers, mocks, spies and fakes—may replace databases, network services or hardware. Isolation improves diagnostic value: when a test fails, the likely fault is localized. However, excessive mocking can create tests that verify assumptions about implementation rather than behavior.

Typical unit test design includes:

• normal and exceptional inputs;
• lower and upper boundaries;
• null, empty and malformed values;
• equivalence classes of inputs;
• state transitions;
• invariant and contract checks; and
• concurrency or timing behavior where relevant.

Unit testing is particularly suitable for test-driven development and continuous integration. Its limitation is scope: passing unit tests cannot reveal a mismatch between components, a deployment error or an unusable workflow.

2.2 Integration testing

Integration testing examines interactions among components, services, subsystems or external interfaces. It targets interface defects such as incorrect data formats, protocol assumptions, transaction boundaries, authentication failures, timing problems and inconsistent error semantics.

Common integration approaches include:

• Big-bang integration: components are combined at once. It may be simple to organize but provides poor fault localization.
• Incremental integration: components are integrated in controlled stages. This supports earlier diagnosis and is generally preferable.
• Top-down integration: higher-level components are tested with lower-level stubs.
• Bottom-up integration: lower-level components are tested with higher-level drivers.
• Thread-based integration: a complete vertical business capability is integrated end to end.
• Contract testing: independently developed services are tested against agreed interface contracts.

The choice depends on architecture and delivery model. In a microservice environment, contract tests and service virtualization may be more practical than maintaining a complete integrated environment for every developer.

2.3 System testing

System testing evaluates the complete integrated system against specified functional and non-functional requirements. It is normally conducted in an environment resembling production and may include end-to-end workflows, security, performance, usability, reliability, compatibility, recovery and installation testing.

System testing must examine interactions that are invisible at unit level. For instance, a payment calculation may be correct in isolation while the complete workflow fails because a message queue duplicates requests or a timeout causes a transaction to be committed twice.

Non-functional testing should not be treated as optional decoration. A function that returns correct results but takes several minutes, exposes confidential information or fails under realistic load is not fit for purpose.

2.4 Acceptance testing

Acceptance testing determines whether the system is acceptable to its sponsor, customer, operational owner or other authorized stakeholder. It is usually based on business scenarios, acceptance criteria, contractual obligations and operational readiness conditions.

Forms include:

• User acceptance testing (UAT): representative users evaluate business fitness and usability.
• Operational acceptance testing: operations teams evaluate backup, monitoring, deployment, recovery and supportability.
• Contract acceptance testing: evidence is assessed against contractual requirements.
• Regulatory acceptance testing: compliance obligations are verified.
• Alpha and beta testing: controlled internal or limited external use generates feedback before broad release.

Acceptance testing should not be used as a substitute for lower-level testing. Business users are poorly positioned to diagnose every technical defect, and late discovery of basic failures wastes stakeholder time.

2.5 Regression testing

Regression testing checks that changes have not adversely affected previously working behavior. Changes include new features, defect corrections, refactoring, configuration updates, infrastructure changes, dependency upgrades and security patches.

Regression testing has both a functional dimension—existing behavior remains correct—and a non-functional dimension—performance, security, reliability and compatibility remain acceptable. A regression suite should be risk-based and change-aware rather than a mechanically repeated collection of every test ever written.

Regression selection may use:

• direct impact analysis from changed components;
• dependency and call-graph analysis;
• requirements and defect history;
• business criticality;
• risk of change;
• pairwise or combinatorial configuration selection; and
• a small stable smoke suite followed by broader suites.

Automation is valuable for frequent regression execution, but automated tests can become expensive to maintain, brittle or misleading if they test implementation details.

3. Designing a Risk-Based Testing Strategy

Risk-based testing allocates effort according to the likelihood and consequence of failure. A useful risk statement identifies a condition, an uncertain event and its effect—for example: “If duplicate payment requests are processed during network retry, a customer may be charged twice.”

A qualitative risk score is often represented as:

Risk priority = likelihood × impact

This is a prioritization model, not a universal law or a precise probability calculation. Likelihood and impact must be defined using an agreed ordinal scale, such as 1 to 5, and the resulting score should not be interpreted as a mathematically exact expected loss. The model is useful when applied consistently and supplemented by expert judgment.

Risk identification should consider:

• business-critical workflows;
• safety, security, privacy and financial consequences;
• complexity and novelty;
• architectural coupling and external dependencies;
• volatility of requirements;
• team experience and staff turnover;
• defect history;
• deployment and operational complexity; and
• legal, contractual and regulatory obligations.

A risk-based strategy maps each significant risk to an evidence-producing activity. For example, unauthorized access risk may require unit tests for authorization logic, integration tests for identity-provider interaction, system security testing and independent penetration testing. No single test level is sufficient.

3.1 Prioritization under constraint

When time is limited, tests should be ordered by expected value. High-priority tests generally concern critical business paths, severe failure consequences, recently changed areas, complex interfaces and historically unstable components. A practical sequence is:

1. run build verification or smoke tests;

2. test critical-path and high-severity failure conditions;

3. test changed and dependent areas;

4. test major integrations and recovery behavior;

5. execute broader functional and non-functional suites; and

6. conduct exploratory testing focused on residual uncertainty.

Prioritization must not silently exclude legally required tests or create unacceptable risks for less visible user groups.

3.2 The test pyramid and its limitations

The test pyramid is a heuristic recommending many fast, focused unit tests, fewer integration tests and a smaller number of broad end-to-end tests. It reflects cost, speed and diagnostic trade-offs. However, it is not a rigid numerical prescription. Systems with substantial integration risk may appropriately require more contract and integration testing; user-interface-heavy systems may require a different distribution. The underlying principle is to place each check at the cheapest level that can provide credible evidence, while retaining tests at higher levels for emergent behavior.

4. Test Planning and Management

Test management converts strategy into controlled execution. A test plan should define scope, objectives, assumptions, dependencies, responsibilities, schedule, environments, data, tools, risks, reporting arrangements and completion conditions.

4.1 Requirements traceability

A requirements traceability matrix links requirements to test conditions, test cases, defects and evidence. Traceability supports impact analysis, auditability and coverage assessment. It should not become a clerical exercise in which every requirement is marked “covered” without evaluating the quality or adequacy of the associated tests.

For agile teams, traceability may be implemented through links among user stories, acceptance criteria, automated tests, defects and deployment records. The form may vary, but the underlying accountability remains important.

4.2 Entry and exit criteria

Entry criteria define conditions that should be met before a test activity begins. Examples include:

• an approved baseline of requirements;
• a deployable build;
• completed code review or unit testing;
• an available and verified environment;
• prepared test data;
• trained personnel; and
• resolved blocking defects from the previous level.

Exit criteria define conditions for completing a test activity. They may include:

• planned high-priority tests executed;
• required coverage achieved;
• no open critical defects;
• agreed limits on unresolved major defects;
• acceptable performance and security results;
• known residual risks documented; and
• stakeholder approval or waiver.

Exit criteria should be established before execution where possible. Otherwise, teams may unconsciously redefine “done” after observing inconvenient results. Criteria should be risk-sensitive: a cosmetic defect may be tolerable in one release, while a minor-looking privacy defect may be unacceptable.

4.3 Test environments

A test environment includes hardware, operating systems, application builds, databases, network configurations, middleware, external services, credentials, monitoring and configuration parameters. Environment inconsistency is a major source of false failures and escaped defects.

Environment management should address:

• version and configuration control;
• infrastructure reproducibility, including infrastructure as code where appropriate;
• service virtualization for unavailable dependencies;
• isolation of test data and credentials;
• observability through logs, metrics and traces;
• environment reset and cleanup;
• production-like topology for system and performance testing; and
• documented differences between test and production.

A single environment rarely serves all purposes. Developers need fast isolated environments, integration teams need shared dependency environments, and performance teams need controlled infrastructure. Shared environments require booking, ownership and change coordination to prevent misleading results.

4.4 Test data management

Test data should represent meaningful equivalence classes, boundary conditions, invalid conditions, historical states and realistic relationships. It must also be governed. Production data may contain personal, financial or confidential information and should not be copied casually into non-production environments.

Controls may include masking, tokenization, synthetic data generation, minimization, access restrictions, retention limits and audit logging. Masking must preserve required structural and behavioral properties; merely replacing names may not protect identities if combinations of fields remain unique.

Data generation should support repeatability. A test that depends on an undocumented database state is difficult to reproduce and weak as evidence. At the same time, excessive determinism can conceal defects that emerge only from varied data distributions, timing and state history.

4.5 Defect management

A defect report should include a concise title, environment, build, preconditions, reproduction steps, expected result, actual result, evidence, severity and business impact. Severity describes the effect of the defect; priority describes the urgency of addressing it. These dimensions should not be conflated. A low-frequency security vulnerability may have high severity even if its immediate priority depends on exposure and release context.

The defect lifecycle should support triage, assignment, correction, retesting, regression assessment and closure. Root-cause analysis is especially valuable for recurring failures. A defect taxonomy—requirements, design, code, data, environment, deployment and test—can reveal process improvement opportunities.

5. Coverage and Test Effectiveness

Coverage is an indicator of what has been exercised, not a direct measure of quality. Common forms include:

• Requirements coverage: proportion of relevant requirements linked to tests.
• Code coverage: statements, branches, conditions or paths executed by tests.
• Risk coverage: proportion of identified risks addressed by evidence.
• Interface coverage: interfaces, message types and error conditions exercised.
• Configuration coverage: supported operating systems, devices, browsers or deployment modes tested.
• Data coverage: equivalence classes, boundaries and important data combinations exercised.

A simple requirements coverage percentage can be calculated as:

Requirements coverage = (requirements with at least one mapped test ÷ total in-scope requirements) × 100%

This measure assumes that requirements are clearly identified, in scope and mapped consistently. It says nothing about whether the tests are adequate, independent or effective. Similarly, 100% statement coverage does not imply 100% branch coverage or absence of defects.

Coverage should be interpreted alongside defect detection, escaped defects, risk exposure, test quality and operational evidence. Mutation testing, in which controlled code changes are introduced to assess whether tests detect them, can provide evidence about test sensitivity, although it adds cost and does not model every real defect.

6. Independent Testing and Organizational Roles

Independent testing reduces confirmation bias and provides a perspective different from that of the implementer. Independence exists on a continuum:

1. the developer tests the code;

2. another developer or peer tests it;

3. a separate test team tests within the project;

4. an independent organizational test group tests across projects; and

5. an external or accredited organization performs evaluation.

Greater independence can improve objectivity, but it may reduce speed, domain understanding or communication if poorly integrated. Independence should therefore be proportional to risk and balanced with collaboration. Developers remain responsible for quality; an independent test team is not a “quality gatekeeper” that absolves engineering teams of responsibility.

For high-risk systems, independent security assessment, safety review, usability evaluation or regulatory audit may be required. Independence must also address conflicts of interest, access to evidence and authority to report unfavorable results without retaliation.

7. Worked Application: Digital Claims Platform

The following is an illustrative case.

Background

An insurance company is replacing a legacy claims platform with a web and mobile system. Customers submit claims, upload evidence and receive status updates. The system integrates with identity management, payment services, document storage, fraud analytics and external repair networks.

Problem

The release deadline is fixed. The project has limited test capacity, rapidly changing interfaces and a history of duplicate payment incidents. Management initially proposes executing every available test in sequence, but the test manager argues that this will delay the release without necessarily reducing the most important risks.

Analysis

A risk workshop identifies the following high-priority risks:

• duplicate or incorrect payments: high impact and moderate likelihood;
• unauthorized access to claim documents: very high impact;
• loss of uploaded evidence: high impact;
• incorrect claim status synchronization: moderate impact and high likelihood;
• poor mobile usability on older devices: moderate impact and high likelihood; and
• inaccurate fraud scores: potentially high business impact but lower release likelihood.

The strategy maps these risks to levels and techniques. Unit tests target payment idempotency, authorization rules, validation and status-transition logic. Contract and integration tests target payment, identity, storage and repair-network interfaces. System tests cover complete claim submission, retries, upload recovery, notification and payment workflows. Security testing examines access control and document exposure. Performance testing evaluates peak claim submission and upload volumes. Acceptance testing uses realistic scenarios with claims staff and selected customers.

Approach and solution

The team defines a smoke suite that verifies deployment, authentication, claim creation and basic document upload. It then prioritizes high-risk tests before lower-risk cosmetic and secondary workflows. Test environments are provisioned from version-controlled configuration. Synthetic claims data is generated, while a masked subset of historical data is used only where realistic distribution is necessary.

Entry criteria for system testing require a deployable build, completed critical unit tests, available dependent services or approved virtualizations, and a verified database baseline. Exit criteria require all critical workflows executed, no open critical defects, no unresolved unauthorized-access findings, successful payment-retry tests, documented residual risks and acceptance-owner approval.

The project uses dashboards displaying test execution by risk category, open defects by severity and evidence for exit criteria. Managers are warned not to interpret a high pass rate as sufficient evidence because many tests are low risk and several high-risk scenarios remain pending.

Outcome

Testing finds that a network retry causes a payment request to be submitted twice. Unit tests had verified the calculation but not the interaction with the payment provider. An integration test exposes the failure, and a system test confirms the customer-visible consequence. The team introduces an idempotency key, adds contract and retry tests, and performs focused regression testing across payment, notification and reconciliation workflows.

A second finding shows that masked document data can be re-identified when combined with dates and claim categories. The release is delayed until stronger masking and access controls are implemented. Although the delay is inconvenient, the risk-based evidence supports the decision because the potential impact is severe.

Learning points

The case demonstrates that testing levels expose different classes of risk. Unit testing is necessary but insufficient; integration behavior and operational conditions can create failures that local tests cannot reveal. Risk-based prioritization focuses scarce capacity on consequential uncertainty. Test data and environment governance are quality concerns, not administrative details. Finally, release decisions should consider residual risk and evidence quality rather than pass percentages alone.

8. Challenges, Limitations and Contemporary Practice

8.1 Automation and maintenance

Automation improves repeatability, speed and regression feedback, but it introduces maintenance cost. Tests may fail because of unstable timing, changing interfaces, poor test isolation or environment problems rather than product defects. Teams should automate tests that are frequent, deterministic, valuable and technically suitable. Exploratory testing remains important for discovery, usability, unusual interactions and questions not anticipated during scripted design.

8.2 Continuous delivery and shift-left/right

Continuous integration moves feedback toward code commit through automated unit, static, security and integration checks. “Shift-left” is useful when it means early quality involvement, not merely moving testing work onto developers without resources. “Shift-right” complements it through production monitoring, canary releases, feature flags, synthetic monitoring, resilience experiments and analysis of real user behavior. Production experimentation requires safeguards, rollback capability, privacy protection and explicit consent where applicable.

8.3 Cloud, distributed systems and AI-enabled systems

Cloud systems require testing elasticity, configuration, observability, failure recovery and dependency behavior. Distributed systems add nondeterminism, eventual consistency, clock differences, retries and partial failure. These conditions require resilience, contract, chaos and recovery testing in addition to conventional functional tests.

AI-enabled systems create additional concerns: data and model versioning, drift, robustness, bias, explainability, privacy, adversarial inputs and human oversight. Traditional pass/fail tests may be insufficient because outputs can be probabilistic. Evaluation should define acceptable behavior ranges, representative and edge-case datasets, fairness criteria where relevant, and monitoring after deployment. AI tools may assist in generating tests or analyzing logs, but generated tests require human review because they can reproduce bias, miss domain risks or create false confidence.

8.4 Ethical and governance responsibilities

Test professionals have obligations to protect personal data, report material risks honestly and avoid manipulating metrics to create an impression of quality. They should not suppress severe defects because of schedule pressure, nor should they obstruct delivery by applying unexplained criteria. Accessibility testing is an ethical and, in many jurisdictions, legal concern. Security findings must be handled responsibly, with controlled disclosure and protection of sensitive evidence.

Best-Practice Guidance

A mature testing strategy should:

• begin with business, technical and regulatory risk;
• combine preventive activities with multiple test levels;
• make assumptions, environments and data reproducible;
• prioritize tests by consequence, change and uncertainty;
• define entry and exit criteria before execution;
• distinguish severity, priority and residual risk;
• measure meaningful coverage rather than chasing arbitrary percentages;
• automate stable, high-value regression checks;
• retain exploratory and human-centered testing;
• use independent assessment proportionally to risk;
• connect defects to root causes and improvement actions; and
• communicate evidence and limitations transparently to decision-makers.

Chapter Summary

Testing strategy is a risk-based framework for deciding what evidence is needed to support quality and release decisions. Unit testing examines local behavior; integration testing examines interfaces and interactions; system testing evaluates the complete product; acceptance testing evaluates business and operational fitness; and regression testing checks the effects of change. These levels overlap in purpose but differ in scope, diagnostic value and cost.

Effective test management includes requirements traceability, risk prioritization, environment and test-data governance, defect management, entry and exit criteria, coverage analysis and transparent reporting. Coverage indicators must be interpreted cautiously because execution does not equal adequacy. Independent testing strengthens objectivity, but quality remains a shared responsibility.

Contemporary systems require testing for distributed behavior, cloud configuration, resilience, security, accessibility and AI-related risks. The strongest strategies combine automation with exploratory judgment, early feedback with production learning, and quantitative indicators with professional evaluation. A release decision should be based on residual risk and credible evidence—not merely on the number of tests executed or passed.

Key Terms

Risk-based testing: Allocating test effort according to likelihood, impact and uncertainty.

Unit testing: Testing an isolated function, class, module or component.

Integration testing: Testing interactions among components, services or external systems.

System testing: Testing a complete integrated system against functional and non-functional requirements.

Acceptance testing: Evaluating whether a system is acceptable to authorized business or operational stakeholders.

Regression testing: Testing to detect unintended effects of changes.

Test strategy: High-level principles and priorities governing testing.

Test plan: A controlled description of testing scope, resources, activities and conditions.

Test oracle: A source of expected results used to judge test outcomes.

Test double: A substitute for a real dependency, such as a stub, mock, fake or spy.

Entry criteria: Conditions required before a test activity begins.

Exit criteria: Conditions required before a test activity is considered complete.

Requirements traceability: Linking requirements to tests, defects and evidence.

Test coverage: An indicator of the conditions, requirements or code exercised by tests.

Severity: The effect or consequence of a defect.

Priority: The urgency or order in which a defect should be addressed.

Independent testing: Testing performed with a degree of organizational or personal separation from implementation.

Test environment: The controlled technical context in which testing is executed.

Test data masking: Transforming sensitive data to reduce disclosure risk while preserving useful properties.

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

Review Questions

Short Answer Questions

1. What is the principal difference between a test strategy and a test plan?

2. Why can passing unit tests not establish that a complete system is correct?

3. Distinguish defect severity from defect priority.

4. What are entry and exit criteria, and why should they be defined in advance?

5. Why is test coverage an indicator rather than a direct measure of software quality?

Long Answer Questions

1. Explain the purposes, strengths and limitations of unit, integration, system, acceptance and regression testing.

2. Describe how a risk-based testing strategy can be constructed for a system with financial and privacy consequences.

3. Discuss the management of test environments and test data in a modern distributed application.

4. Evaluate the benefits and potential disadvantages of independent testing.

5. Explain why automation, exploratory testing and production monitoring should be treated as complementary practices.

Analytical / Application Questions

1. A payment service is changed to support retries. Design a prioritized regression strategy, identifying tests at unit, integration, system and acceptance levels.

2. A project reports 98% test pass rate and 85% statement coverage, but has not tested recovery after database failure. Assess the evidence and recommend release actions.

3. Design entry criteria, exit criteria, test data controls and independent assessment activities for a cloud-based healthcare appointment system.

Multiple Choice Questions with Answers

Question 1

Which testing level primarily focuses on interactions among components and external interfaces?

A. Unit testing

B. Integration testing

C. Acceptance testing

D. Exploratory testing

Correct Answer: B. Integration testing

Question 2

What does the pesticide paradox imply for a regression suite?

A. The suite should never be automated

B. The same tests should be repeated without modification

C. Tests should evolve as risks and implementations change

D. Only performance tests are affected

Correct Answer: C. Tests should evolve as risks and implementations change

Question 3

Which statement best describes an exit criterion?

A. A condition required before coding begins

B. A condition required before a test activity is considered complete

C. A measure of developer productivity

D. A method of generating test data

Correct Answer: B. A condition required before a test activity is considered complete

Question 4

A defect has low urgency but could cause severe financial loss if exploited. Which distinction is most relevant?

A. Severity and priority are different dimensions

B. Severity and priority always have identical values

C. Priority measures code coverage

D. Severity applies only to usability defects

Correct Answer: A. Severity and priority are different dimensions

Question 5

Which is the main purpose of a smoke test suite?

A. To prove that all requirements are satisfied

B. To verify basic build and deployment viability

C. To replace acceptance testing

D. To measure organizational independence

Correct Answer: B. To verify basic build and deployment viability

Question 6

Requirements coverage is 45 out of 60 in-scope requirements mapped to at least one test. What is the coverage percentage?

A. 60%

B. 70%

C. 75%

D. 80%

Correct Answer: C. 75%

Question 7

Which practice best reduces the privacy risk of using production-like data in a test environment?

A. Copying all production data without changes

B. Removing only database indexes

C. Masking or synthesizing sensitive data with access controls

D. Disabling test execution logs

Correct Answer: C. Masking or synthesizing sensitive data with access controls

Question 8

What is a principal benefit of independent testing?

A. It eliminates the need for developer testing

B. It reduces confirmation bias and adds a different perspective

C. It guarantees that no defects remain

D. It always makes testing faster

Correct Answer: B. It reduces confirmation bias and adds a different perspective

Question 9

Why are contract tests especially useful in service-based architectures?

A. They test only screen colors

B. They verify agreed interactions between independently developed services

C. They eliminate the need for system tests

D. They replace all security testing

Correct Answer: B. They verify agreed interactions between independently developed services

Question 10

Which release decision is most defensible?

A. Release whenever the pass rate exceeds 90%

B. Release when all tests, regardless of risk, pass

C. Release based on documented residual risk and evidence against agreed criteria

D. Release when the schedule is exhausted

Correct Answer: C. Release based on documented residual risk and evidence against agreed criteria