PMI (PDU)

Select courses offer Leadership (PDU-L), Strategic (PDU-S) and Technical PMI professional development units that vary according to certification. Technical PDUs are available in the following types: ACP, PBA, PfMP, PMP/PgMP, RMP, and SP.

Testing is far more than finding defects so they can be fixed. Testing can be one of our most potent techniques for managing risk on software projects. While finding and fixing every defect before release is not a reasonable expectation, Risk-Based Testing (RBT) techniques can help us to find the worst defects and ensure that the most critical functionality is high quality.

In addition to being a great strategy for testing, RBT gives us a solid basis for ensuring that we have appropriate time and resources for testing, and for making a strong business case for more when additional allocations are called for.

In this software testing training course, you will walk away with a clear way of communicating the status of testing activities and the readiness of the software for release – one that focuses on the risk and critical functionality that stakeholders care about, rather than numbers of tests run and defects found.

All participants will receive copies of two important white papers on Risk-Based Testing by a leading voice on the topic, James Bach. "Heuristic Risk-Based Testing", and "Troubleshooting Risk-Based Testing (Solutions to Four Common Problems)".

There aren’t any public sessions currently scheduled for this course, but if you fill out the form below, we can tell you about how we can bring this course to you!

Part 1: Understanding Risk

We begin by leveling the playing field. We ensure that all class participants have an accurate understanding of risk and its constituent parts. This will be the foundation upon which we build the rest of the course.

Definition of Risk

Anatomy of a Risk

Software Risks

Testing and Software Risks

Exercise:Understanding Software Risks – We will discuss several risks that are common in software and apply the concepts of this chapter to fully explore and understand them.

Part 2: Risk-Based Testing Overview

There are four steps in fully implemented Risk-Based Testing. In this overview, we will identify each step and discuss how they are related to each other.

Step 1: Identify & Rank Software Risks

Step 2: Risk-Based Test Planning

Step 3: Risk-Based Test Design

Step 4: Risk-Based Test Management

Part 3: Identify & Rank Software Risks

Before we can use Risk as a driver for software testing, we must identify the software risks that are inherent to the project at hand. Then having identified them, we will determine their relative priorities.

Identify Software Risks

Exercise: Brainstorm Software Risks – For our Case Study project, we will brainstorm possible software risks using the techniques just discussed. For each risk, we will identify the vulnerability that may allow it, the trigger that may cause it, and the effect that it may have on the project or the users of the software product if it occurs.

Evaluate Each Risk

Exercise: Evaluate Each Risk – For each risk we just identified for our Case Study project, we will compute its priority by considering the probability that the vulnerability and trigger will coincide, and the severity of its impact if they do.

Evaluate Each Test Suite

Exercise: Evaluate Each Test Suite – For each Test Suite on our Case Study project, we will determine its importance in terms of Risk, and identify those test suites that should be split up to ensure appropriate testing.

Part 4: Risk-Based Test Planning

Risk-Based Test Planning uses the risks inherent in the project as the basis for focusing testing effort and resources. Higher priority risks will receive more focus, while less risky parts of the product receive correspondingly less attention.

Estimate Test Cases by Risk

Exercise: Estimate Test Cases by Risk – For each Test Suite on our Case Study project, we will determine how many Test Cases must be executed to address the identified risks.

Testing Resources Based on Risk

Negotiate Testing Resources

Exercise: Risk-Based Testing Resources – For each Test Suite on our Case Study project, we will use the estimated number of Test Cases to produce ROM (Rough-Order of Magnitude) estimates of effort (e.g. person-days) and calendar time to address the identified risks. We will also identify any special resources (people, equipment, etc) that are required.

Risk-Based Test Activity Planning

Exercise: Risk-Based Test Plan – We will use the principle of testing high-risk items first and our ROMs (from the prior exercise) to prepare a Risk-Based testing activity plan. Then we will compare that plan to the over-all project schedule and identify points to be negotiated.

Part 5: Risk-Based Test Design

Merely focusing appropriate effort on risky Test Suites does not go far enough. That time must be spent doing the right things. In this section, we will use our Risk analysis as the basis for designing the right Test Cases for each Test Suite.

Traditional (Requirements-Based) Test Design

Designing Tests for Risks

Exercise: Risks-Based Test Design – For one of our riskier Test Suites, we will identify every Test Case that must be included to appropriately address all of the identified software risks. Then we will evaluate the entire Test Suite to ensure that it has indeed remained focused on the identified Software Risks.

Part 6: Risk-Based Test Management

Risks are moving targets. Planning our testing based on the risks that can be identified at the beginning of the project is an important first step. But that plan must stay focused on risks, even as those risks evolve. And the evolution of those software risks gives us important insights into the readiness of the software product for release.

Risks Evolve

Risk-Based Testing Must Evolve

Track Known Software Risks

Brainstorm New Software Risks

Adjust Risk-Based Test Plans

Rework Risk-Based Test Designs

Report of Software Risk Changes

Exercise: Risk-Based Test Management – We will use our initial risk assessment to compute the software product's Risk Index. (This Risk Index can be used to track the evolution of software risks throughout the project.)

Part 7: Achieving Success with Risk-Based Testing

Gaining the biggest benefits of Risk-Based Testing requires that testers not only embrace these principles in their own work, but also that they work with the rest of the software development organization to integrate risk-based principles into the way software projects are conceived and managed.

Discussion: Risk Based Testing – Each participant will identify the actions that need to be taken within their organization to take the greatest advantage of Risk-Based Testing.

PMI (PDU)

Select courses offer Leadership (PDU-L), Strategic (PDU-S) and Technical PMI professional development units that vary according to certification. Technical PDUs are available in the following types: ACP, PBA, PfMP, PMP/PgMP, RMP, and SP.