ISTQB Advanced Test Manager Mock Chapter 3 Exam

Failure mode and effect analysis (FMEA) is a risk analysis technique that is used to identify and prioritize potential failures in a system, and evaluate their potential effects. It is particularly useful in projects where the system under test is complex and safety critical, as it helps to proactively identify potential failure modes and their effects on the system's safety. In such projects, the consequences of failure can be severe, and therefore it is essential to identify and mitigate risks early on to ensure the safety and reliability of the system.

During a formalized quality risk analysis session using the Failure Mode and Effect Analysis technique, the major factors in calculating risk priorities are severity and priority. Severity refers to the potential impact or harm that could result from a failure, while priority refers to the urgency or importance of addressing the failure. By considering both severity and priority, the analysis can prioritize the risks that pose the highest potential impact and urgency, allowing for appropriate allocation of resources and mitigation strategies.

Based on historical data, the test team has found approximately 12 bugs per person-month of development effort. With five developers working on the project for six months, the expected number of bugs would be 12 * 5 * 6 = 360. However, the convergence chart shows that the cumulative number of bugs has flattened at 351. Therefore, it can be concluded that the team has found roughly the number of defects that would be expected during system test.

In the given scenario, the test manager decides to deviate from the company's test strategy by testing only five configurations instead of all possible combinations. The best option for documenting this deviation is to explain the alternate approach in the master test plan. This is because the master test plan provides an overview of the entire testing process and outlines the approach, objectives, and scope of testing. By documenting the alternate approach in the master test plan, it ensures that all stakeholders are aware of the decision and the reasons behind it, ensuring transparency and clarity in the testing process.

Performing a risk analysis on the final requirements specification and subsequently receiving a draft design specification would likely result in the largest number of new or changed risk items and risk levels. This is because the draft design specification introduces new information and potential changes to the project, which may lead to the identification of new risks or changes to existing risks. The risk analysis helps to identify and assess potential risks, so any significant changes or additions to the project documentation would likely require a reassessment of the risks involved.

Procuring extra test environments in case one fails during testing is a project risk mitigation step that a test manager might take. This step helps to ensure that testing can continue even if one test environment fails, minimizing the impact on the project schedule and allowing for timely completion of testing activities. By having additional test environments readily available, the test manager can quickly switch to an alternate environment and continue testing without significant delays or disruptions. This proactive approach helps to mitigate the risk of potential delays or setbacks caused by test environment failures.

The reason to question the accuracy of the predicted number of defects in this project is likely due to process factors. Since this project is following an iterative lifecycle, it means that the development process is different from the previous project that followed a sequential lifecycle. The change in process could introduce new variables and uncertainties that may impact the accuracy of defect predictions. It is important to consider how the iterative process may affect defect identification, tracking, and resolution, and adjust the prediction accordingly.

Finding a bug during testing is an example of a cost of internal failure because it represents a failure in the internal processes of the organization. When a bug is found during testing, it means that the development and testing phases were not able to identify and fix the issue before it reached the testing stage. This can result in additional time and resources being spent on fixing the bug and retesting the software, leading to increased costs for the organization.

By analyzing the number of defects found that relate to the risk item of compatibility problems between the browser-based application and different PC configurations, the test manager can monitor the effect of testing on the reduction of this risk during test execution. This approach allows the test manager to track the progress in addressing the identified risk and determine if the testing efforts are effectively reducing the number of defects related to compatibility. It provides valuable insights into the effectiveness of the testing strategy and helps in making informed decisions regarding further actions to mitigate the risk.

In the master test plan, it is important to address a strategy for regression testing. Regression testing is performed to ensure that changes or fixes in the software do not introduce new defects or cause existing functionality to fail. It involves retesting previously tested features to ensure their continued functionality. Therefore, a strategy for regression testing needs to be outlined in the master test plan to ensure that this critical aspect of testing is properly planned and executed.

The correct answer suggests that listing the feature that prevents excessive cycling as a feature to be tested is a reasonable way to use an IEEE 829 test plan to direct appropriate testing for the risk of damage to the HVAC system. This approach ensures that the specific feature related to preventing excessive cycling is included in the testing process, allowing for thorough evaluation and validation of its effectiveness in mitigating the risk. By explicitly mentioning it as a feature to be tested, the test plan ensures that this critical quality risk is adequately addressed during the testing phase.

The best example of a technique for controlling test progress in terms of the residual level of quality risk is counting the number of tested risk items without known defects and the number of tested risk items with known defects. This technique focuses specifically on identifying and tracking the risks associated with the tested items. By counting the number of risk items without known defects, it indicates the level of quality achieved so far. On the other hand, counting the number of risk items with known defects helps in monitoring and managing the remaining quality risks.

The suggested improvement to the test process is to have testers check for similar problems with other credit cards and report their findings in defect reports. This is because the five defects reported involve the same problems with cash advances, but with different credit cards. By having testers check for similar problems with other cards, it allows for a more comprehensive testing approach and ensures that any issues related to cash advances are identified and reported, regardless of the specific credit card being tested. This helps in identifying and addressing any potential issues with the cash advance functionality across all supported credit cards.

The features to be tested for which sufficient information is available to proceed with test design are I and III.

Feature I, "All supported credit cards," can be tested by ensuring that the system allows cash advances from the listed credit cards (American Express, Visa, Japan Credit Bank, Eurocard, and MasterCard) within the specified range ($20 to $500).

Feature III, "Valid and invalid advances," can be tested by checking if the system correctly handles cash advances that fall within and outside the specified range, as well as verifying the appropriate error messages are displayed for invalid advances.

Based on the given information, there is no specific information available to proceed with test design for features II, IV, and V (Language localization, Usability, and Response time).

A help desk staffer is best associated with providing input on the impact of a risk item during a quality risk analysis. As they are responsible for handling customer inquiries and issues, they have direct knowledge and experience of the potential impact a risk item can have on the customers and the overall system. They can provide valuable insights into the potential consequences and severity of a risk item, helping the test manager make informed decisions during the risk analysis process.

In the given scenario, the calculation of excessive late-payment penalties for invoices can be identified as a quality risk item. This is because if the system fails to accurately calculate the penalties, it can lead to financial losses for the bank and dissatisfaction among customers. Therefore, it is important to identify this risk and ensure that the testing process includes thorough checks and validations for the calculation of late-payment penalties.

Outsourced testing involves partnering with an external organization to perform testing activities. One risk of outsourced testing is the selection of an improper test partner. This means that the organization may choose a testing partner that is not suitable for their specific testing needs, leading to ineffective or inadequate testing. On the other hand, distributed testing refers to the practice of having testing teams located in different geographical locations. While distributed testing may have its own set of challenges, such as communication problems due to time zone differences and inconsistent test processes across locations, the risk of selecting an improper test partner is specific to outsourced testing.

The approach section should describe how to test the integration of the thermostat with other parts of the HVAC system because it is important to outline the specific steps and procedures for testing the integration between the thermostat and other components of the system.

The schedule section should describe when integration testing should start and when system testing should start because it is necessary to have a clear timeline and sequence of when each type of testing should be conducted in order to ensure proper testing coverage.

The test deliverables section should describe results reporting for each level of testing because it is important to document and communicate the test results for each level of testing to ensure that any issues or defects are identified and addressed.

The correct answer is to not update the system test plan until the final version of the design specification is available. This is because the test plan should be based on the final requirements specification, not an early draft of the design specification. Additionally, it is important to check the design specification for inconsistencies with the requirements specification to ensure that the design aligns with the intended functionality. Lastly, reviewing the quality risk analysis can help identify any additional risk items that may need to be considered in the test plan.

To resolve the problem of inconclusive test results regarding fuel efficiency improvement, the test manager can direct the test analysts to take the following actions: redesign the fuel efficiency tests to ensure they are accurate and reliable, modify the test environment to gather more detailed actual results that can provide clearer insights into fuel efficiency changes, and check for consistency in tested fuel mixtures to ensure that variations in fuel composition are not affecting the results. These actions will help in obtaining more conclusive and reliable data regarding the improvement in fuel efficiency.