3. Test Lifecycle, Strategy and Risk-Based PlanningIntroduction and ContextSoftware testing is often described as the execution of tests to discover defects. That description is incomplete. In a professional software organisation, testing is a managed system of decisions, activities, evidence, communication and control. It begins before test execution, continues through development and deployment, and may extend into production through monitoring, incident analysis and regression testing. The effectiveness of testing therefore depends not only on the skill of individual testers but also on the quality of the test strategy and the way risks are identified, prioritised and managed. A test lifecycle provides the temporal and logical structure for testing work. A test strategy establishes the overall direction: what will be tested, to what depth, by whom, using which environments and under what conditions. Risk-based planning connects these decisions to uncertainty and potential harm. It ensures that limited time, people and infrastructure are concentrated on the product areas where failure is most likely to occur or most damaging. For a postgraduate student of full-stack development, this topic is especially important. A modern application may include a browser interface, mobile clients, application programming interfaces, microservices, databases, cloud infrastructure, third-party services, security controls and data pipelines. Testing each component equally is usually impractical. A credible plan must distinguish business-critical functions from low-impact features, identify dependencies, define evidence of readiness and provide alternatives when assumptions fail. Learning ObjectivesAfter studying this chapter, the reader should be able to: 1. Explain the purpose and stages of a software test lifecycle. 2. Distinguish a master test strategy from level-specific test plans. 3. Analyse product, project and organisational risks and use them to prioritise testing. 4. Develop plans covering scope, objectives, resources, estimates, schedules and environments. 5. Define appropriate entry criteria, exit criteria, deliverables and traceability mechanisms. 6. Design stakeholder communication and contingency arrangements for testing. 7. Evaluate common planning failures and make defensible professional decisions. From Product Risk to Test StrategyA test strategy is a reasoned statement of how testing will provide information about product quality and release risk. It is not merely a calendar of test activities. A strong strategy explains the relationship between business objectives, quality risks, test levels, techniques, responsibilities and release decisions. The strategy usually operates at two connected levels. The master test strategy applies across a product, programme or organisation. It may specify common quality objectives, governance, tools, reporting conventions, environments, automation principles and escalation routes. A level-specific test plan applies these principles to a particular test level or scope, such as component testing, integration testing, system testing, acceptance testing, performance testing or security testing. The master strategy creates consistency without requiring every team to work identically. For example, it may require automated regression tests in continuous integration, risk-based prioritisation, defect severity classification and traceability for regulatory requirements. A system-test plan may then define the exact business scenarios, data sets, environments, staffing and exit criteria for one release. Strategy is shaped by context. A banking transaction service, an online learning platform and an internal reporting dashboard do not require identical testing. Relevant contextual factors include: - the consequences of failure;
- legal, regulatory and contractual obligations;
- architectural complexity and integration density;
- volatility of requirements and code;
- maturity of development and test processes;
- skills, budget and schedule constraints;
- user groups, accessibility expectations and supported devices;
- operational characteristics such as scalability, recoverability and observability.
A strategy should therefore be explicit about assumptions. If performance testing assumes a stable production-like environment, or security testing assumes that a penetration test will be conducted by an external specialist, the assumption should be recorded. Unrecorded assumptions become hidden risks. The Test Lifecycle as a Management SystemThe test lifecycle is commonly represented as a sequence of activities, although in iterative and agile delivery these activities overlap and repeat. A practical lifecycle contains the following connected stages. Test Analysis and PlanningTest analysis begins with understanding the product, its intended users, requirements, architecture and failure consequences. Testers identify test conditions: features, quality attributes, interfaces, rules, data combinations and operational situations that require evaluation. These conditions are then prioritised according to risk and feasibility. Planning translates the analysis into commitments. It identifies scope, objectives, responsibilities, estimates, schedules, environments, tools, data, entry and exit criteria, reporting arrangements and contingency actions. Planning is not a one-time activity. It should be revisited when requirements, architecture, staffing, defects or external dependencies change. Test Design and ImplementationDuring design, test conditions are transformed into test cases, charters, scenarios, scripts or automated checks. The selected technique depends on the nature of the condition. Equivalence partitioning and boundary-value analysis are useful for input domains; decision-table testing helps evaluate combinations of business rules; state-transition testing is appropriate when behaviour changes by status; exploratory testing supports learning in areas where requirements are incomplete. Implementation includes preparing test data, configuring tools, developing automation, creating stubs or service virtualisation and confirming that tests are maintainable. A test that cannot be executed reliably is not a useful test asset. Environment and Data PreparationAn environment includes hardware or cloud resources, operating systems, databases, network configuration, deployed application components, external services, monitoring and access controls. Environment readiness is often a major constraint in full-stack projects. A test plan should state which environment is needed, who controls it, how it will be refreshed and how configuration differences from production will be assessed. Test data requires equal care. Data may be synthetic, masked from production, generated through factories or supplied by controlled fixtures. Privacy laws and organisational policies generally prohibit careless copying of personal data into non-production environments. Data must also represent important business states, error conditions and boundary values. Execution and Defect ManagementExecution produces observations and evidence. Testers record results, logs, screenshots, traces, performance measurements and environment details. A failed test is not automatically a product defect; the cause may be an incorrect test, invalid data, an environment fault or an ambiguous requirement. Triage determines the cause, impact, severity, priority, owner and next action. Defect management should be integrated with development workflow. Defects need sufficient information for reproduction, including preconditions, steps, expected and actual results, evidence and build identification. Severity describes impact, while priority describes urgency. A low-frequency data-display defect may have high severity in a regulated report, whereas a visually minor issue on a rarely used screen may have low priority. These dimensions should not be confused. Evaluation, Reporting and ClosureAt planned points, the test manager or quality lead evaluates progress and product risk. Reporting should communicate more than the number of tests passed. It should address coverage, unresolved high-risk conditions, defect trends, blocked work, environment stability, residual risk and confidence in release objectives. Test closure includes archiving evidence, recording lessons learned, evaluating process and automation quality, identifying unresolved risks and confirming that testware is reusable or appropriately retired. In continuous delivery, closure may be lightweight, but the need for evidence and learning remains. Risk-Based Test PlanningRisk is the possibility of an event or condition causing an undesirable outcome. In testing, risk is often analysed using two dimensions: the likelihood that a failure will occur and the impact if it does occur. A simple qualitative model is: Risk exposure = likelihood × impact This expression is not a precise prediction. It is a decision aid. Likelihood may be influenced by new or complex code, frequent changes, weak engineering practices, unfamiliar technology and many integrations. Impact may involve financial loss, safety, legal exposure, privacy violation, operational disruption, reputational damage or loss of user trust. A useful risk register records an identifier, risk statement, cause, consequence, likelihood, impact, exposure or rating, owner, mitigation, testing response, trigger and current status. A good risk statement is specific. “The system may fail” is too vague. “A duplicate payment may be submitted when a client retries after a network timeout” identifies a condition that can guide test design. Risk analysis should consider three related categories: Product risks concern the quality of the system itself, such as incorrect calculations, insecure authorisation, poor performance, data loss or incompatibility. Project risks threaten the ability to test effectively, including delayed environments, staff turnover, unstable builds, unrealistic schedules and unavailable subject-matter experts. Business or organisational risks arise from strategic and operational context, such as contractual penalties, compliance obligations, market deadlines or dependence on a third-party provider. Risk controls can be preventive, detective or corrective. Preventive controls include code review, static analysis and secure design. Detective controls include functional tests, monitoring and audit logging. Corrective controls include rollback, backup restoration and incident response. Test planning should not attempt to solve every risk through testing alone; testing is one component of a wider quality and risk-management system. Prioritisation and CoverageRisk-based testing does not mean ignoring low-risk areas. It means ordering and allocating effort rationally. High-risk features may receive deeper test design, more independent review, broader data combinations, multiple environments, performance testing and regression automation. Lower-risk features may receive focused checks and exploratory sampling. Coverage should be described in relation to a model. Possible coverage models include requirements coverage, risk coverage, code coverage, feature coverage, interface coverage, browser-device coverage and operational scenario coverage. Code coverage can reveal untested statements or branches, but high code coverage does not prove that business risks or usability problems have been addressed. Coverage metrics are evidence, not guarantees. Constructing a Master and Level-Specific StrategyA master strategy normally contains the following decisions, expressed as connected policy rather than isolated lists. Scope and ObjectivesScope defines what is included, excluded and conditionally included. It should identify product components, interfaces, supported platforms, quality attributes and release boundaries. Objectives should be measurable where possible, such as validating critical payment journeys, demonstrating compliance with specified controls, reducing regression time or providing evidence that agreed acceptance criteria are met. Exclusions require justification. If an organisation excludes legacy browsers, data migration rehearsal or high-volume testing, the rationale and residual risk should be visible to decision-makers. Test Levels and Test TypesA strategy assigns responsibilities across levels. Component tests typically provide rapid feedback on local logic. Integration tests examine interactions among modules and services. System tests evaluate end-to-end behaviour in a realistic product context. Acceptance testing evaluates fitness for business use and may involve customers or operational representatives. Test types address different quality concerns. Functional testing examines behaviour against specified needs. Non-functional testing may address performance, security, usability, accessibility, reliability, compatibility, maintainability and recoverability. The selection should follow risk rather than fashion. For example, load testing is essential for a heavily used public API but may be less urgent than accessibility testing for a public-sector service. Estimation and SchedulingTesting estimates should be based on work products and uncertainty, not on a fixed percentage of development effort. Relevant tasks include analysis, test design, automation, environment preparation, data preparation, execution, defect investigation, regression, reporting and closure. Historical data, expert judgement, analogous projects and three-point estimates can be combined. A three-point estimate uses optimistic, most likely and pessimistic values. A simple expected estimate is: E = (O + 4M + P) / 6 where O is optimistic, M is most likely and P is pessimistic. The value is still an estimate and should include explicit assumptions. Schedule plans should identify dependencies and buffers for retesting, defect fixing, environment recovery and decision-making. Compressing testing by removing high-risk activities is not equivalent to improving efficiency; it transfers risk to production. Resources and ResponsibilitiesResources include people, environments, test data, tools, licences, devices and access to domain experts. Responsibilities should be defined using a responsibility matrix or equivalent agreement. Developers may own component tests and defect correction; testers may own independent system evaluation; product owners may clarify acceptance conditions; operations specialists may validate deployment and recovery; security specialists may assess threats and controls. Independence is valuable because people who build a feature may overlook assumptions embedded in it. However, independence should not become isolation. Effective quality depends on collaboration, early review and shared ownership. Entry and Exit CriteriaEntry criteria define conditions for beginning an activity. Examples include an approved build, available requirements, configured environment, prepared test data, completed unit checks and known installation instructions. Entry criteria should be realistic. If they are treated as rigid administrative gates, teams may hide exceptions rather than manage them. Exit criteria define conditions for completing an activity or making a release decision. They may include completion of planned high-risk tests, acceptable results for critical scenarios, no unresolved defects above an agreed threshold, evaluated residual risks, successful recovery checks and approved business acceptance. A numerical pass rate alone is insufficient because a large number of low-value passing tests cannot compensate for one unresolved critical security weakness. Criteria may be tailored by risk. A medical or financial system may require stronger evidence and formal approval than an internal prototype. Any waiver should identify the unmet criterion, reason, compensating control, residual risk, owner and expiry or review date. Traceability and DeliverablesTraceability links requirements, risks, test conditions, test cases, results and defects. A traceability matrix can demonstrate that important requirements have corresponding tests and that failed results are connected to decisions. Modern tools may maintain these links automatically through work-item identifiers, test-management platforms and continuous-integration records. Typical deliverables include a master strategy, level-specific plans, risk register, estimates, test conditions, test cases or charters, automation code, test data, environment records, defect reports, progress reports, test summary reports and closure records. Deliverables should be proportionate. Excessive documentation can consume effort without improving control; insufficient evidence makes decisions difficult to defend. Communication, Governance and Contingency PlanningTesting produces information that different stakeholders interpret differently. Developers need reproducible technical evidence. Product owners need an understanding of user and business impact. executives need release confidence and residual risk. Operations teams need deployment, monitoring and rollback information. Communication should therefore be audience-sensitive while preserving a consistent source of truth. A communication plan may specify daily team updates, defect triage meetings, weekly risk reviews, milestone reports and release-readiness reviews. Reports should distinguish facts, interpretations and recommendations. For example, “82 of 90 planned tests passed” is a fact; “confidence is insufficient for release” is a judgement that should be supported by risk evidence. Contingency planning addresses foreseeable disruption. Examples include: - If a shared environment is unavailable, execute component tests, contract tests or service-virtualised scenarios while the environment is restored.
- If a critical third-party service is unavailable, use a controlled stub and record the limitation for later confirmation.
- If testing time is reduced, preserve critical-risk tests and obtain an explicit decision on deferred coverage.
- If key personnel leave, use documented procedures, paired work and cross-training.
- If a severe defect is discovered near release, assess containment, rollback, feature disabling, hotfixing and communication rather than simply changing its status.
A contingency plan is credible only when triggers, decision authority, actions and communication paths are specified in advance. Applied Case: A Digital Payment PlatformBackgroundThe following is an illustrative case. A financial-technology company is releasing a web and mobile payment platform. The platform includes authentication, beneficiary management, payment initiation, fraud screening, notification services, a ledger service and connections to external banking systems. The release introduces a retry mechanism intended to improve reliability when network connections are interrupted. Situation and ProblemThe programme has eight weeks before a contractual launch date. Two development teams work on the web application and services, while a separate operations team manages cloud infrastructure. The test environment differs from production in capacity and uses a simulated banking gateway. Requirements for retries are brief, and no formal decision has been made about the maximum retry count or idempotency behaviour. Stakeholders initially request that all features receive the same number of tests. AnalysisA risk workshop identifies duplicate payments, unauthorised payment approval, incorrect ledger entries, delayed notifications and inability to recover after a gateway outage as high-impact risks. The retry feature is technically complex because it crosses the client, API gateway, payment service, ledger and external banking interface. Its likelihood is elevated by new code and incomplete requirements. The simulated gateway also creates an environment risk: passing tests may not demonstrate correct behaviour under real timeout patterns. The team distinguishes product risks from project risks. Product risks concern payment correctness and security. Project risks include limited performance capacity, unavailable banking-system specialists and a fixed launch date. A traceability review reveals that authentication and payment requirements have tests, but recovery and reconciliation scenarios are missing. Strategy and SolutionThe master strategy requires risk-based prioritisation, independent review of critical financial workflows, automated regression at component and API levels, security testing, operational recovery testing and formal approval of residual risk. The level-specific system-test plan prioritises: 1. payment creation, authorisation and ledger consistency; 2. retries, idempotency and duplicate-request handling; 3. authentication, session control and authorisation; 4. gateway timeout, reversal and reconciliation scenarios; 5. notification accuracy and failure recovery; 6. performance of critical API journeys. The team creates explicit requirements for retry behaviour: each payment receives a unique idempotency key, repeated requests must not create additional ledger entries, and uncertain gateway outcomes require reconciliation rather than blind resubmission. These requirements are reviewed by product, engineering, operations and compliance representatives. Testing is distributed across levels. Unit tests examine idempotency logic and error handling. Contract tests check service interactions. System tests use controlled timeout and duplicate-message scenarios. Security tests examine privilege boundaries and token handling. Performance tests focus on critical transaction paths, while recovery tests simulate gateway interruption and service restart. Production-like data volumes are generated synthetically, and all test evidence includes build and environment identifiers. Exit criteria require completion of all high-risk scenarios, no unresolved critical or high-severity payment-integrity defects, successful reconciliation tests, acceptable performance against agreed thresholds, security review completion and an approved residual-risk statement. If the external gateway cannot be tested in time, the release decision must explicitly record that limitation and specify a controlled pilot, monitoring and rollback plan. OutcomeDuring testing, a duplicate ledger entry is discovered when a client retries after receiving a timeout but before the first response reaches the client. The defect is corrected by enforcing idempotency at the service and persistence layers rather than only in the user interface. Recovery testing also identifies that notification retries could send duplicate messages. The team adds a message identifier and deduplication control. The release proceeds after high-risk criteria are met, with a limited rollout, enhanced monitoring of reconciliation mismatches and a documented rollback procedure. The project demonstrates that prioritising risk produced more valuable evidence than distributing equal effort across all features. Learning PointsThe case illustrates five principles. First, high-impact business risks should shape the strategy. Second, cross-service behaviour requires testing at multiple levels. Third, ambiguous requirements are themselves a test risk and must be clarified. Fourth, environment limitations should be made visible rather than silently accepted. Finally, release confidence depends on evidence, monitoring and contingency planning, not merely on a high test count. Challenges, Limitations and Common MistakesRisk-based planning involves judgement and can be affected by bias. Stakeholders may overestimate visible user-interface defects and underestimate data integrity or security risks. Teams may also assign low risk to familiar components even when a recent change has altered their behaviour. Risk workshops should therefore include diverse expertise and revisit ratings when evidence changes. A common mistake is treating the test plan as a static document. In iterative delivery, new information appears continuously. A strategy that does not change when architecture, scope or defect patterns change has ceased to be strategic. Another mistake is equating automation with coverage. Automated checks are valuable for repeatability and fast feedback, but they may miss exploratory, usability, accessibility and emergent integration problems. Other failures include unclear ownership, unrealistic entry criteria, insufficient test data, unstable environments, unreviewed exclusions, weak defect descriptions and reporting that hides blocked tests behind aggregate pass percentages. Test teams should also avoid using severity thresholds as an excuse to ignore clusters of medium defects that collectively undermine usability or operational reliability. Testing cannot prove the complete absence of defects. It samples behaviour under selected conditions. Its purpose is to reduce uncertainty and support informed decisions. The limitations of testing should be communicated honestly, particularly when time, environment fidelity or domain knowledge is constrained. Governance, Ethics and Professional ResponsibilityTest planning has governance implications. Decisions about release readiness may affect privacy, safety, accessibility, financial fairness and public trust. Test data must be handled lawfully and minimally. Personal data should be masked or synthetically generated, and access should be restricted and audited. Security findings should be communicated responsibly, with controlled disclosure and remediation tracking. Accessibility should not be treated as an optional cosmetic concern. Keyboard operation, screen-reader compatibility, colour contrast, focus management and understandable error messages can determine whether people can use a service. Inclusive testing is both a quality responsibility and, in many contexts, a legal or policy obligation. Professional integrity requires accurate reporting. A tester should not mark a blocked test as passed, conceal a serious defect to meet a date or alter evidence after the fact without an audit trail. When release pressure conflicts with risk evidence, the appropriate action is to present options, consequences and mitigations to the authorised decision-maker. Contemporary DevelopmentsModern delivery practices increasingly embed testing in continuous integration and continuous delivery pipelines. Fast component and API checks may run on every change, while broader system, performance and security tests run at scheduled stages or before release. Contract testing helps teams detect incompatible service changes without always requiring a complete integrated environment. Observability also extends the test lifecycle. Logs, metrics, traces and production feedback can reveal untested conditions and guide regression priorities. Feature flags and progressive delivery allow a capability to be exposed to a limited population while monitoring risk. These techniques do not replace pre-release testing; they provide additional controls and faster feedback. Artificial intelligence is being used to generate test ideas, classify defects, identify unstable tests and analyse change impact. Its output requires human review because generated tests may reproduce existing assumptions, omit important risks or create misleading confidence. Organisations should protect confidential code and data, maintain traceability of AI-assisted decisions and ensure that accountability remains with qualified professionals. Best-Practice PrinciplesA durable test strategy should: - begin with business objectives and failure consequences;
- make scope, assumptions and exclusions explicit;
- prioritise by risk rather than by convenience or equal allocation;
- combine preventive quality practices with evaluative testing;
- assign clear ownership while encouraging collaboration;
- define realistic entry and evidence-based exit criteria;
- maintain traceability for critical requirements and risks;
- use environments and data that are sufficiently representative;
- report residual risk, limitations and blocked work honestly;
- review the strategy when evidence, architecture or context changes;
- preserve contingency options for environment, staffing and schedule disruption;
- treat security, privacy, accessibility and recoverability as integral quality concerns.
Chapter SummaryThe test lifecycle is a coordinated set of activities that begins with analysis and planning, continues through design, implementation, environment preparation, execution and defect management, and ends with evaluation, reporting and learning. A master test strategy establishes common direction across a product or programme, while level-specific plans define how particular forms of testing will be performed. Risk-based planning connects testing effort to the likelihood and impact of failure. It requires explicit risk statements, prioritisation, ownership, traceability and review. Effective plans address scope, objectives, test levels, test types, estimates, schedules, resources, environments, data, entry and exit criteria, deliverables, communication and contingencies. Release decisions should be based on evidence and residual risk rather than on test counts alone. For full-stack systems, quality depends on interactions among interfaces, services, data stores, infrastructure and external providers. Consequently, testing must combine multiple levels and techniques. Governance, ethical data handling, accessibility, security, honest reporting and responsible use of automation are essential professional responsibilities. Contemporary practices such as continuous testing, contract testing, observability, progressive delivery and AI-assisted analysis expand the lifecycle but do not remove the need for human judgement. Key TermsRisk-based testing: A testing approach that prioritises effort according to the likelihood and impact of product failure. Master test strategy: A high-level document defining testing direction, governance, principles and common practices across a product or programme. Level-specific test plan: A plan describing scope, methods, resources and criteria for a particular test level or test activity. Test lifecycle: The connected set of activities used to plan, design, implement, execute, evaluate and close testing. Test condition: A feature, risk, rule, interface, quality attribute or situation that requires evaluation. Product risk: The possibility that the delivered system will fail to satisfy a quality or business need. Project risk: A condition that may prevent testing or delivery from being performed effectively. Risk exposure: A qualitative or quantitative representation combining likelihood and impact. Traceability: The ability to relate requirements and risks to test conditions, results, defects and decisions. Entry criteria: Conditions that should be satisfied before a testing activity begins. Exit criteria: Conditions used to determine whether a testing activity or release decision can be completed. Residual risk: Risk that remains after controls and testing have been applied. Test oracle: A source of knowledge used to determine whether an observed result is acceptable. Test environment: The hardware, software, network, data, configuration and services used for testing. Test data: Input and system-state information prepared to exercise test conditions. Defect triage: The process of analysing, classifying, prioritising and assigning reported defects. Severity: The degree of impact a defect has on the system or stakeholders. Priority: The urgency with which a defect should be addressed. Contract testing: Testing that verifies agreed interactions and expectations between software services. Contingency plan: A predefined response to a disruption, constraint or adverse testing event. Review QuestionsShort Answer Questions1. What is the difference between a master test strategy and a level-specific test plan? 2. Distinguish product risk from project risk and provide one example of each. 3. What is the purpose of entry criteria and exit criteria? 4. Why is code coverage not a complete measure of test effectiveness? 5. What information should a useful defect report contain? Long Answer Questions1. Explain the stages of the test lifecycle and show how they operate iteratively in modern software delivery. 2. Describe how a risk-based test strategy can be constructed for a full-stack application. 3. Discuss the role of scope, estimates, resources, environments and test data in a level-specific test plan. 4. Explain traceability, deliverables and stakeholder communication as mechanisms of testing governance. 5. Analyse the ethical and professional responsibilities involved in test reporting, test data management and release decisions. Analytical / Application Questions1. A team has ten days left before release. A payment service has one unresolved high-impact defect, while 35 low-severity interface defects remain. How should the test manager frame the release decision, and what evidence should be requested? 2. An API passes component tests but fails intermittently when an external service times out. Design a risk-based testing response covering test levels, environment strategy, data, exit criteria and contingency actions. 3. A product owner excludes accessibility and recovery testing to meet a deadline. Prepare a concise risk analysis explaining the consequences, possible mitigations and information required for an authorised waiver. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best describes the purpose of a master test strategy? A. It lists every individual test step for one screen. B. It establishes common testing direction, governance and principles across a product or programme. C. It replaces all defect reports after testing is complete. D. It guarantees that no defects remain at release. Correct Answer: B. It establishes common testing direction, governance and principles across a product or programme. Question 2A duplicate payment may occur when a client retries after a timeout. Which risk statement is most useful for test planning? A. The system may fail. B. The interface might be slow. C. A retry after an uncertain gateway response may create a second ledger entry for the same payment. D. Users may dislike the payment feature. Correct Answer: C. A retry after an uncertain gateway response may create a second ledger entry for the same payment. Question 3Which activity is most directly associated with test closure? A. Identifying initial stakeholders B. Creating the first project estimate C. Archiving evidence, recording lessons learned and evaluating residual risks D. Writing the original business requirements Correct Answer: C. Archiving evidence, recording lessons learned and evaluating residual risks Question 4Why should a high test pass percentage not automatically justify release? A. Passed tests are never useful. B. The percentage may hide untested high-risk conditions or serious unresolved defects. C. Only automated tests count as evidence. D. Exit criteria cannot be used in professional testing. Correct Answer: B. The percentage may hide untested high-risk conditions or serious unresolved defects. Question 5A production-like test environment is unavailable. Which response best follows risk-based planning? A. Report all blocked tests as passed. B. Cancel all testing without recording the reason. C. Use suitable alternatives such as service virtualisation, record the limitation and plan confirmation testing. D. Remove the affected feature from the risk register. Correct Answer: C. Use suitable alternatives such as service virtualisation, record the limitation and plan confirmation testing. Question 6What is the principal distinction between defect severity and defect priority? A. Severity concerns impact, whereas priority concerns urgency of correction. B. Severity is assigned by developers and priority by users in every organisation. C. Severity applies only to security defects. D. Priority measures test coverage and severity measures schedule length. Correct Answer: A. Severity concerns impact, whereas priority concerns urgency of correction. Question 7Which test activity is most appropriate for verifying that repeated service requests do not create duplicate effects? A. Checking only colour contrast B. Testing idempotency and retry scenarios across relevant service boundaries C. Measuring code indentation D. Reviewing the project budget only Correct Answer: B. Testing idempotency and retry scenarios across relevant service boundaries Question 8What is the main purpose of traceability in test planning? A. To ensure that every test is manual B. To connect requirements and risks with tests, results, defects and decisions C. To prevent changes to requirements D. To replace stakeholder communication Correct Answer: B. To connect requirements and risks with tests, results, defects and decisions Question 9Which action is an example of an ethical testing practice? A. Copying unrestricted personal data into a test environment B. Marking blocked tests as passed to meet a deadline C. Reporting residual risk and protecting sensitive test data D. Suppressing a security defect until after launch Correct Answer: C. Reporting residual risk and protecting sensitive test data Question 10A team uses AI to generate regression tests. What is the most appropriate control? A. Accept all generated tests without review. B. Use human review, maintain traceability and assess whether important risks are omitted. C. Avoid all other testing because AI is comprehensive. D. Allow confidential production data to be sent to any AI service. Correct Answer: B. Use human review, maintain traceability and assess whether important risks are omitted.
|
