1 The Technical Test Analyst’s Tasks in Risk-Based Testing

Wild Dog … said, “I will go up and see and look, and say; for I think it is good. Cat, come with me.”

“Nenni!” said the Cat. “I am the Cat who walks by himself, and all places are alike to me. I will not come.”

Rudyard Kipling, from his story “The Cat That Walked by Himself,” a colorful illustration of the reasons for the phrase “herding cats,” which is often applied to describe the task of managing software engineering projects.

The first chapter of the Advanced Technical Test Analyst syllabus is concerned with your role as a technical test analyst in the process of risk-based testing. There are four sections.

1. Introduction

2. Risk Identification

3. Risk Assessment

4. Risk Mitigation

While the Advanced Technical Test Analyst syllabus does not include K3 or K4 learning objectives related to risk-based testing for technical test analysts in this chapter, in Chapter 4 you’ll have a chance to identify quality risks related to various nonfunctional quality characteristics.

There is a common learning objective that we will be covering in each applicable section. Therefore, we list it here to avoid listing it in each section.

Let’s look at these four sections now.

1.1 Introduction

The decision of which test strategies to select is generally the purview of the test manager, and thus this topic is covered in detail in Advanced Software Testing: Volume 2. It is often the case that a test manager will select a strategy called analytical risk-based testing. Specifically, the test manager will usually select one of the techniques described in that book to implement risk-based testing, such as Pragmatic Risk Analysis and Management (PRAM), which we will use for examples in this chapter.

If such a technique has been selected, as a technical test analyst, you will need to understand risk-based testing and the selected technique for implementing it very well because you will play a key role in it. In this chapter, you’ll learn how to perform risk analysis, to allocate test effort based on risk, and to sequence tests according to risk. These are the key tasks for a technical test analyst doing risk-based testing.

Risk-based testing includes three primary activities:

• Risk identification; i.e., figuring out what the different project and quality risks are for the project

• Assessing the level of risk—typically based on likelihood and impact—for each identified risk item

• Risk mitigation via test execution and other activities

In some sense, these activities are sequential, at least in when they start. They are staged such that risk identification starts first. Risk assessment comes next. Risk mitigation starts once risk assessment has determined the level of risk. However, since risk management should be continuous in a project, the reality is that risk identification, risk assessment, and risk mitigation are all recurring activities. In agile projects, risk identification, risk assessment, and risk mitigation occur both during release planning and during iteration planning.

Everyone has their own perspective on how to manage risks on a project, including what the risks are, the level of risk, and the appropriate ways to mitigate risks. So, risk management should include all project stakeholders.

In many cases, though, not all stakeholders can participate or would be willing to do so. In such cases, some stakeholders may act as surrogates for other stakeholders. For example, in mass-market software development, the marketing team might ask a small sample of potential customers to help identify potential defects that might affect their use of the software most heavily. In this case, the sample of potential customers serves as a surrogate for the entire eventual customer base. Or, business analysts on IT projects can sometimes represent the users rather than involve them in potentially distressing risk analysis sessions with conversations about what could go wrong and how bad it would be.

Technical test analysts bring particular expertise to risk management due to their defect-focused outlook, especially with respect to their knowledge of the technical risks that are inherent in the project, such as risks related to security, system reliability, and performance. So, they should participate whenever possible. In fact, in many cases, the test manager will lead the quality risk analysis effort, with technical test analysts providing key support in the process.

If you plan to take the Advanced Level Technical Test Analyst exam, remember that all material from the Foundation syllabus, including material related to risk-based testing in Chapter 5, section 4 of the Foundation syllabus, is examinable.

1.2 Risk Identification

Risk is the possibility of a negative or undesirable outcome or event. A risk is any problem that may occur that would decrease customer, user, participant, or stakeholder perceptions of product quality or project success.

In testing, we’re concerned with two main types of risks. The first type of risk is a product or quality risk. When the primary effect of a potential problem is on product quality, such potential problems are called product risks. A synonym for product risk, which we use most frequently ourselves, is quality risk. An example of a quality risk is a possible reliability defect that could cause a system to crash during normal operation.

The second type of risk is a project or planning risk. When the primary effect of a potential problem is on project success, such potential problems are called a project risk. (By project success, we mean complete achievement of all objectives for the project, not simply delivering software at the end.) Some people also refer to project risks as planning risks. An example of a project risk is a possible staffing shortage that could delay completion of a project.

Of course, you can consider a quality risk as a special type of project risk. While the ISTQB definition of project risk is given earlier, we like the informal definition of a project risk as anything that might prevent the project from delivering the right product, on time and on budget. However, the difference is that you can run a test against the system or software to determine whether a quality risk has become an actual outcome. You can test for system crashes, for example. Other project risks are usually not testable. You can’t test for a staffing shortage.

For proper risk-based testing, we need to identify both product and project risks. We can identify both kinds of risks using the following techniques:

• Expert interviews

• Independent assessments

• Use of risk templates

• Project retrospectives

• Risk workshops

• Risk

• Brainstorming

• Checklists

• Calling on past experience

These techniques can be combined; for example, you can have product experts involved in risk brainstorming sessions as part of a risk workshop.

The test manager will usually organize the specific risk identification activities relevant for the project. As a technical test analyst with unique technical skills, you will be particularly well suited for conducting expert interviews, brainstorming with co-workers, and analyzing current and past experiences to determine where the likely areas of product risk lie. In particular, technical test analysts work closely with their technical peers (e.g., developers, architects, operations engineers) to determine the areas of technical risk. You should focus on areas like performance risks, security risks, reliability risks, and other risks relating to the software quality characteristics covered in Chapter 4.

Conceivably, you can use a single integrated process to identify both project and product risks. Rex usually separates them into two separate processes because they have two separate deliverables. He includes the project risk identification process in the test planning process, and you should expect to assist the test manager in the test planning project, as discussed in Chapter 4. In parallel, the initial quality risk identification process occurs early in the project, and in agile projects, they occur during iteration planning.

That said, project risks—and not just for testing but also for the project as a whole—are often identified as by-products of quality risk analysis. In addition, if you use a requirements specification, design specification, use cases, and the like as inputs into your quality risk analysis process, you should expect to find defects in those documents as another set of by-products. These are valuable by-products, which you should plan to capture and escalate to the proper person.

In the introduction, we encouraged you to include representatives of all possible stakeholder groups in the risk management process. For the risk identification activities, the broadest range of stakeholders will yield the most complete, accurate, and precise risk identification. The more stakeholder group representatives you omit from the process, the more risk items and even whole risk categories you’ll miss.

How far should you take this process? Well, it depends on the technique. In lightweight techniques, which we frequently use, such as Pragmatic Risk Analysis and Management, risk identification stops at the risk items. Each risk item must be specific enough to allow for identification and assessment to yield an unambiguous likelihood rating and an unambiguous impact rating.

Techniques that are more formal often look downstream to identify potential effects of the risk item if it becomes an actual negative outcome. These effects include effects on the system—or the system of systems, if applicable—as well as potential users, customers, stakeholders, and even society in general. Failure Mode and Effect Analysis is an example of such a formal risk management technique, and it is sometimes used on safety-critical and embedded systems.

Other formal techniques look upstream to identify the source of the risk. Hazard analysis is an example of such a formal risk management technique. We’ve never used this technique ourselves, but Rex has talked to clients who have used it for safety-critical medical systems.¹

1.3 Risk Assessment

The next step in the risk management process is risk assessment. Risk assessment involves the study of the identified risks. We typically want to categorize each risk item appropriately and assign each risk item an appropriate level of risk.

In categorization of risk items, we can use ISO 9126 or other quality categories to organize the risk items. In our opinion—and in the Pragmatic Risk Analysis and Management process described here—it doesn’t matter so much what category a risk item goes into, usually, as long as we don’t forget it. However, in complex projects and for large organizations, the category of risk can determine who is responsible for managing the risk. A practical implication of categorization such as work ownership will make the categorization important.

The other part of risk assessment is determining the level of risk. There are a number of ways to classify the level of risk. The simplest is to look at two factors:

• The likelihood of the problem occurring; i.e., being present in the product when it is delivered for testing.

• The impact of the problem should it occur; i.e., being present in the product when it is delivered to customers or users after testing.

Note the distinction made here in terms of project timeline. Likelihood is the likelihood of a problem existing in the software during testing, not the likelihood of the problem being encountered by the user after testing. The likelihood of a user encountering the problem influences impact. Likelihood arises from technical considerations, typically, while impact arises from business considerations. As such, technical test analysts usually focus on supporting the evaluation of likelihood, while test analysts focus on evaluation of impact.

So, what technical factors should we consider? Here’s a list to get you started:

• Complexity of technology, architecture, code, and database(s)

• Personnel and training issues, especially those that relate to absence of sufficient skills to solve the technical challenges of implementation

• Intra-team and inter-team conflict, especially in terms of disagreement about technical and nonfunctional requirements

• Supplier and vendor contractual problems

• Geographical distribution of the development organization, as with outsourcing, or other complex team structures (such as those associated with large systems-of-systems development projects), particularly when unresolved communication barriers or disagreements about processes and product priorities exist

• Legacy or established designs and technologies that must integrate with new technologies and designs

• The quality—or lack of quality—in the tools and technology used

• Bad managerial or technical leadership

• Time, resource, and management pressure, especially when financial penalties apply

• Lack of earlier testing and quality assurance tasks in the life cycle, resulting in a large percentage of the defects being detected in higher levels of testing, such as system test, system integration test, and acceptance test

• High rates of requirements, design, and code changes in the project without adequate structures or processes in place to manage those changes

• High defect introduction rates, including large rates of regression associated with bug fixes during test execution

• Complex interfacing and integration issues

While impact, being based on business factors, is typically the focus of the test analyst, here are some of the factors that the test analyst should consider:

• The frequency of use of the affected feature

• Potential damage to image

• Loss of customers and business

• Potential financial, ecological, or social losses or liability

• Civil or criminal legal sanctions

• Loss of licenses, permits, and the like

• The lack of reasonable workarounds

• The visibility of failure and the associated negative publicity

When determining the level of risk, we can try to work quantitatively or qualitatively. In quantitative risk analysis, we have numerical ratings for both likelihood and impact. Likelihood is a percentage, and impact is often a monetary quantity. If we multiple the two values together, we can calculate the cost of exposure, which is called—in the insurance business—the expected payout or expected loss.

While it will be nice someday in the future of software engineering to be able to do this routinely, typically the level of risk is determined qualitatively. Why? Because we don’t have statistically valid data on which to perform quantitative quality risk analysis. So, we can speak of likelihood being very high, high, medium, low, or very low, but we can’t say—at least, not in any meaningful way—whether the likelihood is 90, 75, 50, 25, or 10 percent.

This is not to say—by any means—that a qualitative approach should be seen as inferior or useless. In fact, given the data most of us have to work with, use of a quantitative approach is almost certainly inappropriate on most projects. The illusory precision thus produced misleads the stakeholders about the extent to which you actually understand and can manage risk. What Rex has found is that if he accepts the limits of his data and applies appropriate lightweight quality risk management approaches, the results are not only perfectly useful, but also essential to a well-managed test process.

Unless your risk analysis is based on extensive and statistically valid risk data, it will reflect perceived likelihood and impact. In other words, personal perceptions and opinions held by the stakeholders will determine the level of risk. Again, there’s absolutely nothing wrong with this, and we don’t bring this up to condemn the technique at all. The key point is that project managers, programmers, users, business analysts, architects, and testers typically have different perceptions and thus possibly different opinions on the level of risk for each risk item. By including all these perceptions, we distill the collective wisdom of the team.

However, we do have a strong possibility of disagreements between stakeholders. So, the risk analysis process should include some way of reaching consensus. In the worst case, if we cannot obtain consensus, we should be able to escalate the disagreement to some level of management to resolve. Otherwise, risk levels will be ambiguous and conflicted and thus not useful as a guide for risk mitigation activities—including testing.

1.4 Risk Mitigation or Risk Control

Having identified and assessed risks, we now must control them. The Advanced Technical Test Analyst syllabus refers to this as risk mitigation, which is accurate if we’re referring to using testing to deal with quality (or product) risks. However, for risks in general, including project risks, the better term is risk control. We have four main options for risk control:

• Mitigation, where we take preventive measures to reduce the likelihood of the risk occurring and/or the impact of a risk should it occur. Testing prior to release is a form of mitigation for quality risks.

• Contingency, where we have a plan or perhaps multiple plans to reduce the impact of a risk should it occur. Having a technical support team in place is a form of contingency for quality risks.

• Transference, where we get another party to accept the consequences of a risk should it occur. Delivering a potentially buggy product effectively transfers quality risks onto users.

• Finally, ignoring or accepting the risk and its consequences should it occur. For trivial or highly unlikely risks, this is the most common option, sometimes unconsciously taken.

For any given risk item, selecting one or more of these options creates its own set of benefits and opportunities as well as costs and, potentially, additional associated risks.

Analytical risk-based testing is focused on creating quality risk mitigation opportunities for the test team, including for technical test analysts. Risk-based testing mitigates quality risks via testing throughout the entire life cycle.

Testing can mitigate quality risk in various ways, but there are two very common ones:

• During all test activities, test managers, technical test analysts, and test analysts allocate effort for each quality risk item proportionally to the level of risk. Technical test analysts and test analysts select test techniques in a way that matches the rigor and extensiveness of the technique with the level of risk. Test managers, technical test analysts, and test analysts carry out test activities in risk order, addressing the most important quality risks first and only at the very end spending any time at all on less important ones. Finally, test managers, technical test analysts, and test analysts work with the project team to ensure that the repair of defects is appropriate to the level of risk.

• Test managers, technical test analysts, and test analysts report test results and project status in terms of residual risks. For example, which tests have not yet been run or have been skipped? Which tests have been run? Which have passed? Which have failed? Which defects have not yet been fixed or retested? How do the tests and defects relate back to the risks?

When following a true analytical risk-based testing strategy, it’s important that risk management not happen only once in a project. Quality risk mitigation should occur throughout the life cycle. Periodically in the project, we should reevaluate risk and risk levels based on new information. This might result in our reprioritizing tests and defects, reallocating test effort, and performing other test control activities.

One metaphor sometimes used to help people understand risk-based testing is that testing is a form of insurance. In your daily life, you buy insurance when you are worried about some potential risk. You don’t buy insurance for risks that you are not worried about. So, we should test the areas and test for bugs that are worrisome and ignore the ones that aren’t.

One potentially misleading aspect of this metaphor is that insurance professionals and actuaries can use statistically valid data for quantitative risk analysis. Typically, risk-based testing relies on qualitative analyses because we don’t have the same kind of data insurance companies have.

During risk-based testing, you have to remain aware of many possible sources of risks. There are safety risks for some systems. There are business and economic risks for most systems. There are privacy and data security risks for many systems. There are technical, organizational, and political risks too.

As a technical test analyst, you might need to assist the test manager with identifying, assessing, and suggesting control options for test-related project risks as part of test planning. As technical test analysts, we’re particularly concerned with test-affecting project risks like the following:

• Test environment and tools readiness

• Test staff availability and qualification

• Low quality of work products delivered to testing

• Overly high rates of change for work products delivered to testing

• Lack of standards, rules, and techniques for the testing effort

While it’s usually the test manager’s job to make sure these risks are controlled, the lack of adequate controls in these areas will affect the technical test analyst.

One idea discussed in the Foundation syllabus, a basic principle of testing, is the principle of early testing and QA. This principle stresses the preventive potential of testing. Preventive testing is part of analytical risk-based testing. We should try to mitigate risk before test execution starts. This can entail early preparation of testware, pretesting test environments, pretesting early versions of the product well before a test level starts, ensuring requirements for and designing for testability, participating in reviews (including retrospectives for earlier project activities), participating in problem and change management, and monitoring the project progress and quality.

In preventive testing, we take quality risk mitigation actions throughout the life cycle. Technical test analysts should look for opportunities to control risk using various techniques:

• Choosing an appropriate test design technique

• Reviews and inspections

• Reviews of test design

• An appropriate level of independence for the various levels of testing

• The use of the most experienced person on test tasks

• The strategies chosen for confirmation testing and regression testing

Preventive test strategies acknowledge that quality risks can and should be mitigated by a broad range of activities. Many of these activities are static tests rather than dynamic tests. For example, if the requirements are not well written, perhaps we should institute reviews to improve their quality rather than relying on tests that we will run once the badly written requirements become a bad design and ultimately bad, buggy code.

Dynamic testing is not effective against all kinds of quality risks. In some cases, you can estimate the risk reduction effectiveness of testing in general and for specific test techniques for given risk items. There’s not much point in using dynamic testing to reduce risk where there is a low level of test effectiveness. For example, code maintainability issues related to poor commenting or use of unstructured programming techniques will not tend to show up—at least, not initially—during dynamic testing.

Once we get to test execution, we run tests to mitigate quality risks. Where testing finds defects, testers reduce risk by providing the awareness of defects and opportunities to deal with them before release. Where testing does not find defects, testing reduces risk by ensuring that under certain conditions the system operates correctly. Of course, running a test only demonstrates operation under certain conditions and does not constitute a proof of correctness under all possible conditions.

We mentioned earlier that we use level of risk to prioritize tests in a risk-based strategy. This can work in a variety of ways, with two extremes, referred to as depth-first and breadth-first. In a depth-first approach, all of the highestrisk tests are run before any lower-risk tests, and tests are run in strict risk order. In a breadth-first approach, we select a sample of tests across all the identified risks using the level of risk to weight the selection while at the same time ensuring coverage of every risk at least once.

As we run tests, we should measure and report our results in terms of residual risk. The higher the test coverage in an area, the lower the residual risk. The fewer bugs we’ve found in an area, the lower the residual risk.² Of course, in doing risk-based testing, if we only test based on our risk analysis, this can leave blind spots, so we need to use testing outside the predefined test procedures to see if we have missed anything, such as using experience-based and defect-based techniques.

If, during test execution, we need to reduce the time or effort spent on testing, we can use risk as a guide. If the residual risk is acceptable, we can curtail our tests. Notice that, in general, those tests not yet run are less important than those tests already run. If we do curtail further testing, that property of risk-based test execution serves to transfer the remaining risk onto the users, customers, help desk and technical support personnel, or operational staff.

Suppose we do have time to continue test execution? In this case, we can adjust our risk analysis—and thus our testing—for further test cycles based on what we’ve learned from our current testing. First, we revise our risk analysis. Then, we reprioritize existing tests and possibly add new tests. What should we look for to decide whether to adjust our risk analysis? We can start with the following main factors:

• Totally new or very much changed quality risks

• Unstable or defect-prone areas discovered during the testing

• Risks, especially regression risk, associated with fixed defects

• Discovery of unexpected bug clusters

• Discovery of business-critical areas that were missed

So, if you have time for new additional test cycles, consider revising your quality risk analysis first. You should also update the quality risk analysis at each project milestone.

1.5 An Example of Risk Identification and Assessment Results

In Figure 1–1, you see an example of a quality risk analysis document. It is a case study from an actual project. This document—and the approach we used—followed the Pragmatic Risk Analysis and Management approach.

In this table, you can see some examples of quality risk items in three nonfunctional categories: performance, reliability/robustness, and resource utilization. These quality risk items were identified and assessed for a mainframe operating system management tool called Sysview, a mission-critical data center operations utility.³

Figure 1–1 An example of a quality risk analysis document using Pragmatic Risk Analysis and Management, focusing on nonfunctional risk areas

Example: Plan to Execution, Risk Based

We’ve mentioned that, properly done, risk-based testing manages risk throughout the life cycle. Let’s look at how that happens, based on our usual approach to a test project.

During test planning, risk management comes first. We perform a quality risk analysis early in the project, ideally once the first draft of a requirements specification is available. From that quality risk analysis, we build an estimate for negotiation with and, we hope, approval by project stakeholders and management.

Once the project stakeholders and management agree on the estimate, we create a plan for the testing. The plan assigns testing effort and sequences tests based on the level of quality risk. It also plans for project risks that could affect testing.

During test control, we will periodically adjust the risk analysis throughout the project. That can lead to adding, increasing, or decreasing test coverage; removing, delaying, or accelerating the priority of tests; and other such activities.

During test analysis and design, we work with the test team to allocate test development and execution effort based on risk. Because we want to report test results in terms of risk, we maintain traceability to the quality risks.

During implementation and execution, we sequence the procedures based on the level of risk. We ensure that the test team, including the test analysts and technical test analysts, uses exploratory testing and other reactive techniques to detect unanticipated high-risk areas.

During the evaluation of exit criteria and reporting, we work with our test team to measure test coverage against risk. When reporting test results (and thus release readiness), we talk not only in terms of test cases run and bugs found but also in terms of residual risk.

1.6 Risk-Aware Testing Standard

An interesting example of how risk management, including quality risk management, plays into the engineering of complex and/or safety-critical systems is found in the ISO/IEC standard 61508. This standard applies to embedded software that controls systems with safety-related implications, as you can tell from its title, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems.

The standard is very much focused on risks. Risk analysis is required. It considers two primary factors as determining the level of risk, likelihood, and impact. During a project, we are to reduce the residual level of risk to a tolerable level, specifically through the application of electrical, electronic, or software improvements to the system.

The standard has an inherent philosophy about risk. It acknowledges that we can’t attain a level of zero risk—whether for an entire system or even for a single risk item. It says that we have to build quality, especially safety, in from the beginning, not try to add it at the end. Thus, we must take defect-preventing actions like requirements, design, and code reviews.

The standard also insists that we know what constitutes tolerable and intolerable risks and that we take steps to reduce intolerable risks. When those steps are testing steps, we must document them, including a software safety validation plan, software test specification, software test results, software safety validation and verification report, and software functional safety report.

The standard addresses the author-bias problem. As discussed in the Foundation syllabus, this is the problem with self-testing: the fact that you bring the same blind spots and bad assumptions to testing your own work that you brought to creating that work. Therefore, the standard calls for tester independence, indeed insisting on it for those performing any safety-related tests. And since testing is most effective when the system is written to be testable, that’s also a requirement.

The standard has a concept of a safety integrity level (or SIL), which is based on the likelihood of failure for a particular component or subsystem. The safety integrity level influences a number of risk-related decisions, including the choice of testing and QA techniques.

Some of the techniques are ones we’ll cover in this book and in the companion volume for test analysis (Advanced Software Testing – Volume 1) that address various functional and black-box testing design techniques. Many of the techniques are ones that are described in subsequent chapters, including dynamic analysis, data recording and analysis, performance testing, interface testing, static analysis, and complexity metrics. Additionally, since thorough coverage, including during regression testing, is important in reducing the likelihood of missed bugs, the standard mandates the use of applicable automated test tools, which we’ll also cover here in this book.

Again, depending on the safety integrity level, the standard might require various levels of testing. These levels include module testing, integration testing, hardware-software integration testing, safety requirements testing, and system testing.

If a level of testing is required, the standard states that it should be documented and independently verified. In other words, the standard can require auditing or outside reviews of testing activities. In addition, the standard also requires reviews for test cases, test procedures, and test results along with verification of data integrity under test conditions.

The standard requires the use of structural test design techniques. Structural coverage requirements are implied, again based on the safety integrity level. Because the desire is to have high confidence in the safety-critical aspects of the system, the standard requires complete requirements coverage not once, but multiple times, at multiple levels of testing. Again, the level of test coverage required depends on the safety integrity level.

Now, this might seem a bit excessive, especially if you come from a very informal world. However, the next time you step between two pieces of metal that can move—e.g., elevator doors—ask yourself how much risk you want to remain in the software that controls that movement.

1.7 Sample Exam Questions

To end each chapter, you can try one or more sample exam questions to reinforce your knowledge and understanding of the material and to prepare for the ISTQB Advanced Level Technical Test Analyst exam. The questions in this section illustrate what is called a scenario question.

Scenario

Assume you are testing a computer-controlled braking system for an automobile. This system includes the possibility of remote activation to initiate a gradual braking followed by disabling the motor upon a full stop if the owner or the police report that the automobile is stolen or otherwise being illegally operated. Project documents and the product marketing collateral refer to this feature as emergency vehicle control override. The marketing team is heavily promoting this feature in advertisements as a major innovation for an automobile at this price.

Consider the following two statements:

I. Testing will cover the possibility of the failure of the emergency vehicle control override feature to engage properly and also the possibility of the emergency vehicle control override engaging without proper authorization.

II. The reliability tests will include sending a large volume of invalid commands to the emergency vehicle control override system. Ten percent of these invalid commands will consist of deliberately engineered invalid commands that cover all invalid equivalence partitions and/or boundary values that apply to command fields; ten percent will consist of deliberately engineered invalid commands that cover all pairs of command sequences, both valid and invalid; the remaining invalid commands will be random corruptions of valid commands rendered invalid by the failure to match the checksum.

1. If the project is following a risk-based testing strategy, which of the following is a quality risk item that would result in the kind of testing specified in statements I and II above?

A. The emergency vehicle control override system fails to accept valid commands.

B. The emergency vehicle control override system is too difficult to install.

C. The emergency vehicle control override system accepts invalid commands.

D. The emergency vehicle control override system alerts unauthorized drivers.

2. Assume that each quality risk item is assessed for likelihood and impact to determine the extent of testing to be performed. Consider only the information in the scenario, in question 1, and in your answer to that question. Which of the following statements is supported by this information?

A. The likelihood and impact are both high.

B. The likelihood is high.

C. The impact is high.

D. No conclusion can be reached about likelihood or impact.