This course can be tailored to your needs for private, onsite delivery at your location.
ASPE is an IIBA Endorsed Education Provider of business analysis training. Select Project Delivery courses offer IIBA continuing development units (CDU) in accordance with IIBA standards.
This course offers 7.00 IIBA CDUs.
NASBA continuing professional education credits (CPE) assist Certified Public Accountants in reaching their continuing education requirements.
This course offers 8.00 NASBA CPEs.
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.
This course offers:
6.00 PMP/PgMP Technical PDUs
2.00 PMI-PBA Technical PDUs
6.00 PMI-RMP Technical PDUs
1.00 PMI Strategic PDUs
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.
RBT also provides testers 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)"
- Upcoming Dates and Locations
Guaranteed To Run
- Course Outline
I. 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.
- A. Definition of Risk
B. Anatomy of a Risk
C. Software Risks
D. 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.
II. 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.
- A. Step 1: Identify & Rank Software Risks
B. Step 2: Risk-Based Test Planning
C. Step 3: Risk-Based Test Design
D. Step 4: Risk-Based Test Management
III. Step 1: 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.
- A. 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.
- 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.
- 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.
IV. Step 2: 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.
- A. 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.
C. 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.
- 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.
V. Step 3: 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.
- A. Traditional (Requirements-Based) Test Design
B. 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.
VI. Step 4: 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.
- A. Risks Evolve
B. Risk-Based Testing Must Evolve
C. Track Known Software Risks
D. Brainstorm New Software Risks
E. Adjust Risk-Based Test Plans
F. Rework Risk-Based Test Designs
G. 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.)
VII. 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.
- A. Definition of Risk
- Who should attend
This course is designed for participants who plan, manage and perform software testing. It would be beneficial for:
- Managers of Software Development organizations
- Software Project Managers and Team Leads
- Testing Managers and Team Leads
- Software testing professionals
- Business Analysts