Course Duration: 2 Days

Course Category: Software Testing

 

14 PDUs (Professional Development Units)

Risk Based Testing (Balancing acceptable quality with schedules and budgets)

 

Course Overview
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 proper 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 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
 

Available Funding Support

Malaysia

HRDF Logo_02 This course is HRDF SBL & HRDF SBL Khas Approved

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <font color="" face="" size=""> <span style="">

PMI, PMP, PMBOK, CAPM, PMI-ACP and the Registered Education Provider logo are registered marks of the Project Management Institute, Inc.
CMMI®, Capability Maturity Model®, Capability Maturity Modeling®, CMM®, PCMM® and Carnegie Mellon® are registered in the US Patent and Trademark Office by Carnegie Mellon University.
ISTQB® is a Registered Trade Mark of the International Software Testing Qualifications Board.
IIBA®, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP® and CCBA® are registered certification marks owned by International Institute of Business Analysis. Certified Business Analysis Professional, Certification of Competency in Business Analysis, Endorsed Education Provider, EEP and the EEP logo are trademarks owned by International Institute of Business Analysis.
The APMG-International Agile Project Management, AgilePM and Swirl Device logos are trademarks of The APM Group Limited.
PRINCE2®, ITIL®, IT Infrastructure Library®, and MSP® are registered trademarks of AXELOS Limited. The Swirl logo™ is a trade mark of AXELOS Limited.
The ITIL Licensed Affiliate logo is a trademark of AXELOS Limited.
SCRUM Alliance REP SM is a service mark of Scrum Alliance, Inc.