The scenario presents two key constraints: a very short test execution period and low confidence in the risk assessment. The goal is to test all product risks, ensuring each gets at least some coverage. A standard depth-first approach (executing all Priority 1 tests, then all Priority 2, etc., as in option A) is risky because if time runs out, lower-priority areas (which may contain high-priority bugs) will receive no testing at all.

The optimal strategy is a breadth-first approach. By executing one test from each priority level in descending order of priority (T1, T3, T5, T7, T9) and then cycling back for the remaining tests, coverage is spread across all risk areas early. This mitigates the risk of a flawed assessment and ensures that if testing is cut short, every risk level has been sampled.

A. This strict, depth-first execution risks leaving entire lower-priority risk areas untested if time runs out, which is unacceptable given the low confidence in the risk assessment.

C. Executing tests in reverse priority order is illogical and inefficient, as it deliberately delays testing the areas initially identified as having the highest risk.

D. This is a breadth-first approach but in reverse priority order, which is counter-intuitive and contradicts the fundamental principle of addressing the highest perceived risks first.

1. Black, R. (2009). Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing (3rd ed.). John Wiley & Sons. In Chapter 7, "Developing the Test Plan," Black discusses risk-based test prioritization. The principle is to order tests to find the most important defects as early as possible. The strategy in option B is an advanced application of this principle, adapted for conditions of high uncertainty and time pressure, ensuring early feedback across all risk categories rather than focusing deeply on a potentially misidentified top-priority area.

2. Ammann, P., & Offutt, J. (2016). Introduction to Software Testing (2nd ed.). Cambridge University Press. Chapter 2, Section 2.4 ("Test Case Selection and Adequacy") discusses criteria for selecting and prioritizing tests. The scenario requires a strategy that maximizes coverage diversity early on, a common heuristic in time-constrained projects to mitigate the risk of poor initial prioritization. The breadth-first approach directly serves this goal.

3. University of Waterloo. (n.d.). ECE 453: Software Testing, Quality Assurance, and Maintenance Course Notes. Lecture on Test Case Prioritization. University courseware on software testing often describes prioritization techniques beyond simple linear ordering. The "round-robin" or breadth-first method is a standard heuristic used to ensure broad coverage and mitigate risks when test execution time is limited or when there is uncertainty about where the most critical defects lie.

A risk-based testing strategy prioritizes test execution based on risk levels, especially when time is limited. The risk level, or Risk Priority Number (RPN), is calculated by multiplying Likelihood and Impact. The correct execution schedule orders the tests from the highest RPN to the lowest.

The RPNs are:

1. Pre-activation: 3 (Likelihood) 5 (Impact) = 15

2. Activation: 2 (Likelihood) 5 (Impact) = 10

3. Charge: 2 (Likelihood) 3 (Impact) = 6

4. IVR transactions: 1 (Likelihood) 2 (Impact) = 2

Therefore, the optimal execution order is Pre-activation, Activation, Charge, and IVR, which corresponds to option D.

A. This option begins with the lowest risk item (RPN=2) and ends with the highest (RPN=15), which is the reverse of a risk-based prioritization strategy.

B. This option incorrectly prioritizes the item with an RPN of 6 (Charge) over the item with an RPN of 10 (Activation), violating the highest-risk-first principle.

C. This option incorrectly starts with the second-highest risk item (Activation, RPN=10) instead of the item with the highest risk (Pre-activation, RPN=15).

1. ISTQB Advanced Level Test Manager Syllabus (Version 2012):

Section 3.3, Risk Mitigation, Page 21: "The results of the risk assessment are used to... define the test strategy, prioritizing the testing of the high-risk items... Test execution may also be prioritized based on risk." This supports executing tests for items with higher RPNs first.

Section 3.2.2, Risk Analysis, Page 20: This section describes the process of determining the level of risk as a combination of likelihood and impact, which is the method used to calculate the RPN in the question.

2. Black, R. (2019). Advanced Software Testing - Vol. 2 (2nd ed.): Guide to the ISTQB Advanced Certification as an Advanced Test Manager. Rocky Nook.

Chapter 3, Section "Risk-Based Prioritization of Tests", Page 105: "In a risk-based approach, we prioritize our tests based on the level of risk... When test execution resources are constrained, we should execute the highest-priority tests first." This directly validates the approach of ordering tests by their calculated risk level.

3. University of Toronto, Department of Computer Science. (2012). CSC444/2108: Software Engineering, Lecture 11: Quality Assurance.

Slide 25, "Risk Exposure": The lecture notes define Risk Exposure (RE) as Prob(Failure) Cost(Failure), which is analogous to Likelihood Impact. It further states that testing should be prioritized to focus on areas with the highest RE, confirming the principle of testing high-risk items first. Available via course archives.

A logical test case must specify the initial state (precondition), the action to be performed, and the expected result for verification. The requirement REG-LOGO-001 states that a user shall be able to logout from the "purchase" page and be returned to the "browse" page.

Option A provides a complete and correct positive test case:

Precondition: On the purchase page (“purchase state”).

Action: Click the logout button.

Expected Result: Verify that the browse page (“browse state”) is displayed.

This test case directly and positively verifies the functionality as described in the requirement, making it the only valid choice.

B. This option is an incomplete test case because it lacks an expected result, which is essential for determining a pass or fail outcome.

C. This describes a negative test case, as it verifies an error condition. The requirement specifies a successful (positive) logout action.

D. This test case is incorrect because the requirement REG-LOGO-001 specifies logging out from the "select" and "purchase" pages, not the "browse" page.

1. Kaner, C., Falk, J., & Nguyen, H. Q. (1999). Testing Computer Software. John Wiley & Sons.

In Chapter 4, "The Elements of a Test," the authors detail that a complete test case must include a clear description of the expected output or result. Option B lacks this critical element. The book also distinguishes between tests that verify functionality (positive tests) and tests that challenge the system's error handling (negative tests), which makes option C incorrect as it describes a negative test for a positive requirement.

2. Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing (3rd ed.). John Wiley & Sons.

Section 2.3, "A good test case is...", emphasizes that a key characteristic of a proper test case is a defined expected output. "If the expected output is not defined, the tester may not notice a subtle error." This principle invalidates option B.

3. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill Education.

Chapter 19, "Software Testing Strategies," discusses requirements traceability as a fundamental principle of validation testing. It states that test cases should be designed to ensure that all functional requirements are satisfied. Option D fails this principle as it tests a scenario (logging out from the "browse" page) that is not specified in the REG-LOGO-001 requirement.

The core issue is the high quality-risk associated with the two new off-the-shelf (OTS) systems due to unprofessional vendor testing. A competent Test Manager must create a plan that directly mitigates this primary risk. The best strategy is a multi-level approach that starts with validating the highest-risk components first.

Option D proposes "adequate re-testing" of the OTS systems, which serves as a rigorous acceptance test to ensure they meet quality standards before being introduced into the larger system. This aligns with the principle of finding defects as early as possible. Following this, system integration testing is essential to verify the interactions between the new and existing systems via the SOA middleware. Finally, end-to-end testing validates the complete business processes, ensuring the overall system meets user requirements. This comprehensive, risk-based approach is the most professional and effective.

A. "Informal and minimal acceptance test" is dangerously insufficient for components with a known high risk of being low-quality. It fails to adequately mitigate the primary risk.

B. Skipping component-level validation and going directly to end-to-end testing is highly inefficient. It makes defect isolation extremely difficult, time-consuming, and costly, violating fundamental testing principles.

C. This option correctly identifies the need for integration and end-to-end testing but omits the crucial first step of validating the high-risk OTS components themselves before integration begins.

1. Sommerville, I. (2011). Software Engineering (9th ed.). Pearson.

Reference: Chapter 8, Section 8.1.3, "Testing commercial-off-the-shelf systems," discusses the specific challenges of COTS/OTS integration. It notes that the integrator must design tests to ensure the COTS component functions as expected within the application. This supports the need for "adequate re-testing" before full integration.

Reference: Chapter 8, Section 8.2, "Testing stages," outlines the logical progression from component testing to system testing (including integration) and finally acceptance testing, which validates the entire system. This structure mirrors the comprehensive approach in the correct answer.

2. MIT OpenCourseWare. (2013). 6.170 Software Studio, Spring 2013. Massachusetts Institute of Technology.

Reference: Lecture 10, "Testing 1," slide 11 ("The V-Model of Development"). This model illustrates that component/unit testing precedes integration testing, which precedes system testing. This fundamental principle dictates that the quality of individual components should be assured before attempting to integrate them, which is precisely what "re-testing" accomplishes in this scenario.

3. Weyuker, E. J. (1998). Testing component-based software: A cautionary tale. IEEE Software, 15(5), 54-59. https://doi.org/10.1109/52.714817

Reference: Page 56, Section "Adequate testing". The article argues that even if a component has been tested by the developer, the acquirer (integrator) must perform their own testing because "a component that is adequately tested for one context is not necessarily adequately tested for another." This directly supports the necessity of "adequate re-testing" by the Pay-TV company.

Given the project's established risk-driven test approach, the most professional and effective response to a shortened schedule is to intensify this strategy. Prioritizing test execution based on the highest product risks ensures that the most critical and impactful areas of the system are validated within the limited time. This maximizes the value of the testing effort by focusing resources where potential failures would have the most severe consequences. Tracking these risks provides essential data to stakeholders, enabling them to make an informed decision about the product's release readiness and to understand the residual risk.

B. Removing testers is counterproductive; it would further reduce the team's capacity to perform essential testing and increase project risk.

C. Automating all remaining manual tests mid-execution is a significant undertaking that requires substantial time and resources, making it unfeasible as a response to a sudden deadline change.

D. Taking no action and simply testing randomly is an unprofessional approach that fails to strategically address the increased risk resulting from the compressed schedule.

---

1. ISTQB® Certified Tester Advanced Level Syllabus, Test Manager, Version 3.1.2 (2023).

Section 3.2.2, Risk-Based Testing: This section explicitly states that a key objective of risk-based testing is to "Prioritize tests during execution, for example, running the most important tests first." It further clarifies its use to "decide which tests to run when there is not enough time to run all planned tests." This directly supports prioritizing tests for the highest product risks when time is constrained.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill Education.

Chapter 20, Software Testing Strategies, Section 20.1.3: The text emphasizes that a realistic view of testing acknowledges that exhaustive testing is impossible. It states, "the tester should prioritize tests that have the highest likelihood of uncovering the most severe errors." This principle is the foundation of risk-based prioritization, which is the core of the correct answer.

3. University of Texas at Austin, Department of Electrical and Computer Engineering. EE382V: Software Testing Course Notes, Lecture 5: Test Selection, Minimization and Prioritization.

Section on Test Case Prioritization: These course materials discuss techniques for ordering test cases when resources are limited. Risk-based prioritization is presented as a key industry practice. The notes explain that test cases targeting higher-risk functionalities are scheduled for earlier execution to provide the most critical feedback as quickly as possible, which is precisely the situation described in the question.

The exit criterion EX1 states, "100% of tests of priority 1 have been executed and passed." By analyzing the provided table, we can identify a total of seven test cases with Priority 1: TC-001, TC-002, TC-003, TC-004, TC-005, TC-006, and TC-007.

The scenario specifies that three of these Priority 1 test cases (TC-001, TC-002, and TC-007) have already been executed and passed. To satisfy the 100% completion requirement of EX1, the remaining Priority 1 test cases must also be successfully executed. The remaining test cases are TC-003, TC-004, TC-005, and TC-006, which amounts to a minimum of 4 test cases.

B. 5: This is an incorrect calculation of the remaining Priority 1 test cases required to meet the exit criterion.

C. 6: This is an incorrect calculation of the remaining Priority 1 test cases required to meet the exit criterion.

D. 7: This represents the total number of Priority 1 test cases, not the number remaining to be executed to meet the criterion.

1. ISTQB® Foundation Level Syllabus (Version 2018 V3.1.1): Section 5.2.4, "Test Plan," defines Exit Criteria as "The set of generic and specific conditions... for permitting a process to be officially completed." The question requires applying this principle by evaluating progress against a specific exit criterion (EX1). The calculation involves determining the remaining work to satisfy the condition of "100% of tests of priority 1 have been executed and passed."

2. Kaner, C., Falk, J., & Nguyen, H. Q. (1999). Testing Computer Software. John Wiley & Sons. In Chapter 8, "Test Planning," the concept of "Release Criteria" or "Exit Criteria" is discussed. The text emphasizes that these criteria are specific, measurable conditions that must be met, such as "all high-priority tests must pass." The problem presented is a direct application of this test management principle.

3. MIT OpenCourseWare, 6.170 Software Studio, Spring 2013: Lecture 10, "Testing," discusses the components of a test plan, including test completion criteria. These criteria define when testing is considered finished, for example, when a certain percentage of test cases have passed. The question assesses the ability to calculate progress towards such a pre-defined completion criterion. (Available at: https://ocw.mit.edu/courses/6-170-software-studio-spring-2013/)

In a scenario where non-functional requirements are not specified, a model-based technique using operational profiles is the most effective method for testing reliability. An operational profile is a quantitative model of how a system will be used in the field, detailing the frequency and probability of various user inputs or operations. By creating and testing against this model, the test team can simulate real-world usage. This allows for the selection and prioritization of test cases that target the most frequently used or critical functions, providing a statistically valid measure of the system's reliability without pre-defined non-functional requirements.

B. Ambiguity reviews are a static analysis technique for finding defects in documentation; they do not select or execute tests for system characteristics.

C. Test condition analysis is a general technique that requires a defined test basis (e.g., requirements), which is explicitly missing for non-functional aspects.

D. Cause-effect graphing is a functional, black-box test design technique for testing complex logical conditions, not for assessing reliability based on usage patterns.

1. Musa, J. D. (1993). Operational profiles in software-reliability engineering. IEEE Software, 10(2), 14–32. In Section "What is an operational profile?" (p. 15), it is defined as a set of operations and their probabilities of occurrence, which is fundamental to guiding test selection for reliability engineering. The entire paper establishes this as the primary technique for the scenario described. DOI: https://doi.org/10.1109/52.199724

2. Lyu, M. R. (Ed.). (1996). Handbook of Software Reliability Engineering. McGraw-Hill. Chapter 5, "The Operational Profile," by J.D. Musa, details the process of developing and using operational profiles to guide test case selection for reliability measurement and improvement (pp. 167-170).

3. Whittaker, J. A., & Voas, J. M. (2000). Toward a more reliable theory of software reliability. IEEE Computer, 33(12), 36-42. This article discusses the importance of usage-based testing and operational profiles (p. 38) as a practical and effective means of assessing software reliability in the absence of complete formal specifications. DOI: https://doi.org/10.1109/2.889088

The development of a custom automation framework for an internal, mission-critical system implies it is proprietary software created for a specific purpose. Management concerns such as testing the framework (as it is software itself), providing adequate documentation for the team, and planning for its ongoing maintenance are all standard, critical activities in such a project.

Option C introduces the concept of a GNU license and communication to "external users." This is highly unlikely because the framework is custom-built for internal use. Placing it under an open-source license like GNU is a separate, strategic decision that is not inherent to the development process itself. Therefore, managing obligations under such a license is the least likely issue the team will face.

A. Proper testing for the custom automation framework must be performed

A custom framework is a software product; it must be thoroughly tested to ensure it is reliable and produces accurate test results for the mission-critical system.

B. The custom automation framework will require an adequate documentation

Documentation is crucial for any software to ensure it can be used, maintained, and understood by current and future team members, maximizing its value.

D. The custom automation framework will need proper maintenance

Like any software, the framework will require ongoing maintenance to fix bugs, adapt to changes in the system under test, and evolve over time.

1. On Maintenance and Evolution of Test Automation:

Garousi, V., & Mäntylä, M. V. (2016). "When and what to automate in software testing? A systematic literature review on the actual practice and benefits." Information and Software Technology, 76, 92-117. This review highlights that maintenance is a primary challenge and cost factor in test automation (supporting D). It implicitly supports the need for robust design and documentation (B) to manage this maintenance.

DOI: https://doi.org/10.1016/j.infsof.2016.04.013

2. On Testing the Testware:

Berner, S., Weber, R., & Kuffner, R. (2005). "A Case Study on a Test Automation Framework." In Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC'05) (pp. 539-545). IEEE. The paper discusses the development of a framework and notes, "The test framework itself has to be tested" (Section 4.2), emphasizing that the automation code is software that requires its own quality assurance (supporting A).

DOI: https://doi.org/10.1109/APSEC.2005.10

3. On Licensing for Internal vs. External Software:

MIT OpenCourseWare. (2016). 6.033 Computer System Engineering, Spring 2018. Lecture 21: Intellectual Property. Massachusetts Institute of Technology. The lecture materials distinguish between proprietary software developed for internal use and software distributed externally under licenses like the GPL. For internal tools, such licensing obligations do not apply unless the organization chooses to release the software, making this an external, non-default concern (supporting C as least likely).

Reference: Available via MIT OCW, course 6.033, lecture notes on Intellectual Property.

The question requires identifying which option is NOT a product risk. Product risks, also known as quality risks, are potential failures of the software to meet specified quality characteristics or user needs (e.g., functional defects, security vulnerabilities, poor performance). Options B, C, and D all describe potential functional or security failures within the authentication system itself. In contrast, option A describes a late delivery of a feature, which impacts the project's schedule and resource allocation. This is a classic example of a project risk, which relates to the management and execution of the project, not the intrinsic quality of the product itself.

B. This is a product risk because the system fails to meet a specified functional requirement (displaying a special warning for a specific user type).

C. This is a critical product risk as it describes a severe security and functional failure where the system incorrectly grants access.

D. This is also a critical product risk, representing a major security flaw and a failure of the core authentication logic.

1. ISTQB® Certified Tester Foundation Level Syllabus V4.0, International Software Testing Qualifications Board, 2023.

Section 5.2.1, "Project and Product Risks": This section explicitly distinguishes between the two types of risk. It defines product risks as the "potential for a work product... to fail to satisfy the legitimate needs of its users" and lists examples like "Software might not perform its intended functions according to the specification." This directly applies to options B, C, and D. It defines project risks as those that "surround the project’s capability to deliver its objectives" and provides "Delays in delivery" as a key example, which directly corresponds to option A.

2. Sommerville, I. (2016). Software Engineering (10th ed.). Pearson.

Chapter 25, Section 25.1.1, "Risk identification": This chapter discusses risk management in the context of the project. It identifies schedule slippage as a primary project risk. The text states, "Schedule risks are risks that the project will take longer to complete than scheduled." This aligns with the scenario in option A. In contrast, product-related risks like security and functional correctness are discussed in chapters on system dependability and specification (e.g., Chapter 8).

The approach described in the system test plan is inconsistent with both declared strategies. A risk-based strategy requires risk analysis to be performed before test execution to guide test design and prioritization. Performing analysis in parallel with execution negates this core principle. Similarly, a regression-averse strategy relies on having a defined set of regression tests ready to be executed to check for unintended side effects of changes. Designing these tests in parallel with execution indicates a reactive, rather than a preventative (averse), approach. The V-model itself implies that test design is completed during the corresponding development phase, well before test execution begins.

A. The approach is inconsistent because performing planning, analysis, and design concurrently with execution fundamentally contradicts the proactive nature of both strategies.

B. The approach is inconsistent with risk-based testing because risk analysis must precede execution to effectively prioritize and guide the testing effort.

C. The approach is inconsistent with a regression-averse strategy because a stable suite of regression tests cannot be systematically executed if it is still being designed.

1. ISTQB Advanced Level Syllabus, Test Manager (Version 2012), International Software Testing Qualifications Board.

Section 3.2, "Risk-Based Testing," outlines the process where risk identification and analysis are used to "guide test planning, specification, preparation and execution." This confirms that analysis is an input to, not a parallel activity with, execution.

Section 2.2.1, "Test Activities and Tasks," describes the V-model, where system test planning and design occur in parallel with the requirements engineering phase, long before the system test execution phase. The plan's approach of running these activities in parallel with execution is a clear deviation.

2. Ammann, P., & Offutt, J. (2017). Introduction to Software Testing (2nd ed.). Cambridge University Press.

Chapter 1, Section 1.4, "The V-model of Testing," (pp. 14-15) illustrates that test design and planning activities for a given level are completed before the execution for that level starts. For system testing, design is based on the system requirements specification.

Chapter 2, Section 2.2, "Test Plan," (pp. 26-28) describes test planning as a preceding activity that defines the scope, approach, and resources. The scenario's parallel execution of planning undermines this structured process, which is essential for both risk-based and regression-averse strategies.