Risk Based Testing: Balancing Acceptable Quality With Schedules and Budgets

Many organisations continually struggle with how to balance aggressive development schedules with the need for quality software.

Coming towards the end of development, when the schedule pressure is often greatest, there never seems to be enough time for testing.

As project deadlines approach, managers often need to choose between delaying the release or accepting a lower level of quality.

This two-day course teaches participants how they can respond to this problem by testing smarter not harder.

Participants will learn how to analyse and respond to risk, allowing them to better prioritise their test activities which in turn maximises the effectiveness of the test effort.

Course Features

  • The course builds on the ISTQB principles of software testing in a highly practical way
  • Shows participants how to apply the formal Failure Mode Effect Analysis (FMEA) technique as well as less formal techniques such as Structured What If Technique (SWIFT), Risk Canvas and Risk Poker
  • Describes both traditional test planning and risk backlog approaches for responding to risk
  • Learning supported by extensive case study and exercises

Participant Benefits

  • Understanding of risk and how it relates to software testing
  • Ability to apply formal and informal risk analysis techniques
  • Ability to identify and analyse potential failures and their underlying causes
  • Ability to better work within aggressive schedules and budgets

Who Should Attend

  • Those who want enhance their careers with the knowledge and skills necessary to perform effective risk based testing such as Test Engineers, Tester Analysts, Quality Assurance Staff, Agile Teams, Business Analysts, Business Systems Analysts, Systems Analysts, Functional Analysts
  • Those who need to approve risk based testing strategies and project plans; as well as those that manage testing staff applying a risk based approach such as Test Managers, Quality Assurance Staff, Project Managers, Program Managers Product Owners, Product Managers, Scrum Masters
  • Those who who want to gain an understanding of UAT and SIT techniques such as Test Managers, Project Managers, Program Managers Software Engineers, User Representatives, Product Owners, Product Managers, Scrum Masters, Requirements Engineers, Requirements Analysts, Human Factors Specialists, Software Developers, Process Engineers, Software Engineering Process Group (SEPG) Staff, Methodologists, Process Improvement Staff

Course Duration

  • 2 days full-time

Course Agenda

Introduction

  • Views of Quality
    • GapsBetween the Views of Quality
    • The Reason For Gaps
    • Closing the Gaps
  • Software Failures
    • Failures Caused By Human Errors
      • Failures In New Software
      • Failure in Modified Software
    • Failures Caused By Configuration Errors
  • Software Testing Objectives
  • Principles of Software Testing
    • Principle 1 - Testing Shows Presence of Defects
    • Principle 2 - Exhaustive Testing is Impossible
    • Principle 3 - Early Testing is Desirable
    • Principle 4 - Defects Tend to Cluster
    • Principle 5 - Pesticide Paradox - Bugs Become Immune
    • Principle 6 - Testing is Context Dependent
    • Principle 7 - Absence of Errors Fallacy

Software Testing and Risk

  • What is Risk?
    • Risk is the possibility of loss or misfortune
    • Dimensions of risk
  • Software and Risk
    • How likely is a failure?
    • How severe is the failure?
  • Principles of Risk Based Testing
    • Principle 1 - Showing the presence of a defect reduces the risk of undiscovered defects
    • Principle 2 - Focus on areas of high risk since exhaustive testing is impossible
    • Principle 3 - Identify and respond to risks early in the development life cycle
    • Principle 4 - Showing the presence of a defect in a component increases the risk of more defects in that component
    • Principle 5 - Bugs become immune so continuously monitor risks and revise risk strategy
    • Principle 6 - A unique risk strategy is required for each testing context
    • Principle 7 - Consider all risk factors
      • Not fit for intended purpose
      • Does not conform to specification
      • Unacceptable values for non-functional attributes
      • Does not provide value
      • Lack of confidence
    • The risk paradox
      • Finding bugs reduces the overall risk of failures
      • Finding bugs in a component increases the risk of more failures in that component
  • Risk based testing activities
    • Risk identification
    • Risk assessment
    • Risk strategy
    • Risk response
    • Risk reporting
    • Risk prediction

Identifying Risks

  • Identifying Risks
    • Risk Driven, Top-Down Approach
    • Solution Driven, Bottom-Up Approach
  • Risk Driven Approach
    • Risk Taxonomies
    • Bug Taxonomies
    • Heuristics
    • Software Quality Characteristics
  • Structured What-If Technique (SWIFT)
    • SWIFT Steps
    • SWIFT Checklist Coverage
    • SWIFT Log Sheet
  • Defining Risks
    • Risk Statement Template
    • Risk Profile
  • Solution Features
    • Identifying Interactive (Front End) Features
    • Identifying Batch (Back End) Features
    • Predicting Feature Failures
    • Features and Constraints
    • Solution Wide Constraints
  • Solution Components
    • Identifying Components
    • Predicting Component Failures
    • Predicting Interface Failures
  • Solution Environment
    • The TOGAF Technical Reference Model
    • Identifying Platforms and Devices
    • Deploying Solution Components to Platforms and Devices
    • Predicting Environmental Failures

Assessing Risks

  • Failure Mode Effect Analysis (FMEA)
    • Failure Modes and Effects
    • FMEA Assumptions
    • Underlying Causes of Failure
  • Analysing Risks
    • Probability - How Likely?
    • Severity - How Bad?
    • Calculating a Risk Level
    • Analysing Feature Risks
    • Analysing Component Risks
    • Analysing Environmental Risks
    • Comparing the Risk Profile of Individuals
  • Fast Track Approaches
    • SWIFT
    • Risk Poker
    • Risk Canvas

Developing a Risk Strategy

  • Risk Management Strategies
    • Accept Risk Because Exhaustive Testing is Impossible
    • Avoid Risk With Early Risk reduction
    • Mitigate Risk
      • Reducing the Probability of Defects
      • Reducing the Severity of Defects
    • Transfer the Risk
      • Technical specialists
      • Consultants
      • Outsourcing
      • Contractors
    • Never Transfer the Risk to
      • Testers
      • Users
      • Customers
  • Mitigating Risks
  • Risk and the Project Schedule
  • Risk Reduction Techniques
    • Software Testing
    • Verification
    • Requirements Validation
  • Risk Reduction Techniques and Types of Failure
  • Software Testing as a Risk Reduction Technique
    • Software Testing Levels
    • Understanding Component Integration
    • Understanding Feature Integration
    • Identifying Test Items
    • Identifying the Test Basis
    • Who Executes the Tests?
  • Risk Strategy Framework
    • Typical Component Risk Strategy
      • Component Risk Assessment
      • Component Testing Strategy
      • Component Test Plan
    • Typical Feature Risk Strategy
      • Feature Risk Assessment
      • Feature Testing Strategy
      • Feature Test Plan

Responding to Risk

  • Test to Pass vs. Test to Fail (Negative Testing)
  • Issue Tracking and Triaging Issue Reports
  • Issue Tracking and Clustering of Defects

Reporting Risks

  • Reporting Progress
  • Issue Tracking and Product Quality
  • Component Defect Density
  • Feature Defect Density

Predicting Risk

  • Analysing Issues
  • Identifying the Root Cause of Failures
  • Risk Heat Map