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
  • Test Managers, Test Engineers, Testers, Quality Assurance Staff
  • Business Analysts, Business Systems Analysts, Systems Analysts, Functional Analysts
  • User Representatives, Subject Matter Experts, Project managers, Program Managers
  • Software Engineers, Developers, Requirements Engineers, Requirements Analysts, Human Factors Specialists
  • Process Engineers, Software Engineering Process Group (SEPG) Staff, Methodologists, Process Improvement Staff
 
Course Agenda Introduction

  • Views of quality
  • Software testing objectives
    • Validating that software is fit for its intended purpose
    • Verifying that software conforms to its specification
    • Identifying failures caused by defects
    • Measuring software qualities
    • Confirming the software provides value
    • Building confidence in the reliability of the software
  • What causes software failures
    • Human errors that introduce defects (bugs)
      • Errors in new program code
      • Changes that cause errors in existing program code
    • Environmental factors
  • Review of software testing principles
    • Principle 1 – Testing shows presence of defects
    • Principle 2 – Exhaustive testing is impossible
    • Principle 3 – Early testing
    • Principle 4 – Defect clustering
    • Principle 5 – Pesticide paradox
    • Principle 6 – Testing is context dependent
    • Principle 7 – Absence of errors fallacy

Software testing and risk

  • What is risk
  • Software and risk
  • Exploring the relationship between test effort and risk
    • The relationship between risk and test effort is not linear
    • Prioritising risks minimises the effort required to reduce risk to an acceptable level
  • Principles of risk based software testing
    • Showing the presence of a defect reduces the risk of undiscovered defects
    • Exhaustive testing is impossible so focus on areas of high risk
    • Identify and respond to risks early in the development life cycle
    • Showing the presence of a defect in a component increases the risk of more defects in the component
    • Continuously monitor and report risks
    • A unique risk strategy is required for each testing context
    • An absence of error does not imply low risk for other aspects of software quality
  • Risk and the project schedule
    • Traditional approach
    • Risk based approach
  • Risk based testing activities
    • Risk identification
    • Risk assessment
    • Risk strategy
    • Risk mitigation
    • Risk reporting
    • Risk prediction

Identifying risks

  • Types of risk
    • Product risks
    • Technology risks
    • Project risks
    • Enterprise risks
    • Contract risks
    • External risks (PESTLE)
  • Risk based approaches
    • Risk driven approach
    • Solution driven approach
  • Risk driven approach
    • Risk taxonomies
    • Bug taxonomies
    • ISO 9126 quality characteristics
    • Structured What-If Technique (SWIFT)
      • SWIFT steps
      • Checklist coverage
      • SWIFT log sheet
  • Defining risks
    • Risk statement template
    • Risk profile
  • Solution driven approach
    • Solution components
      • Component failures
      • Interface failures
    • Solution environment
      • TOGAF technical reference model
      • Platforms and devices
      • Platform and device failures
    • Solution features
      • Capabilities
      • Constraints
      • Feature failures

Assessing risks

  • Failure Mode Effect Analysis (FMEA)
    • Overview of FMEA
    • Failure modes and effects
    • FMEA assumptions
    • Causes of failure
  • Analysing risks
    • Probability – how likely?
    • Severity – how bad?
    • Calculating a risk level
      • Components
      • Interfaces
      • Platforms and devices
      • Features
    • Average risk and individual risk profiles
    • Fast track approaches
      • Risk canvas
      • Risk poker

Developing a risk strategy

  • Strategies for managing risks
    • Accept risk
    • Avoid risk
    • Mitigate risk
      • Reduce severity of failure
      • Reduce probability of failure occurring
    • Transfer risk
  • Risk reduction techniques
    • The W model
    • Risk reduction and coverage of failures
  • Early risk reduction techniques
    • Requirements
      • Conduct workshops
      • Specify desired values for non-functional attributes
      • Develop user prototypes
      • Conduct requirements review
      • Error seeding of requirements
      • Analyse requirements risk
    • Design
      • Conduct solution architecture review
      • Conduct solution environment review
      • Develop architecture proof of concept
    • Coding
      • Conduct source code reviews
      • Perform static source code analysis
    • Mapping early risk reduction techniques to types of failure
  • Risk reduction and software testsing
    • Definition of test levels
    • Component vs. feature integration
    • Stand alone vs. end-to-end testsing
  • Test items
    • Component
      • Stand alone
      • Integrated
    • Interface
    • Solution
      • Integrated
      • Deployed
    • Feature
  • Test basis
    • Testing is not black and white!
    • Defining a test basis
      • Testing and/or subject matter experience
      • Requirements specification
      • Other documents
      • Models (model based testing)
      • Existing system (A-B testsing)
      • Program code
  • Who (or what) executes the tests?
    • Developer
    • Technical specialist
    • Test analyst
    • Business analyst
    • Subject matter expert
    • Automation
  • Risk strategy framework
    • Test items
    • Risk level
    • Test basis
    • Test objectives
    • Testers
  • Applying the risk strategy framework
    • Typical UAT strategy
    • Typical SIT strategy
    • Developing a custom risk strategy

Responding to risk

  • Traditional test planning and specification
    • Plan and execute tests in risk priority order
    • Develop test cases to induce predicted failures
    • Traditional SIT responds to risk of
      • Non compliance with the requirements specification
      • Failures
        • New failures
        • Regression failures
      • Unacceptable values for non-functional attributes
        • In normal use
        • Under stress
      • Lack of confidence prior to UAT
    • Traditional UAT responds to risk of
      • Not fit for intended purpose
      • Providing poor value
      • Lack of confidence prior to deployment
    • Thorough component testing is the most effective way to respond to the risk of failures
  • Risk backlog management
    • Choosing a risk backlog when the volume of risks exceeds the capacity and time available to respond
    • Replacing test plans and test specifications with a risk backlog
    • Prioritising the risk backlog by risk level
    • Revising and reprioritising the risk backlog

Reporting risks

  • Tracking progress of test execution
  • Tracking the defect backlog
  • Revising the risk strategy based on defects discovered
  • Providing feedback to risk assessment and risk strategy activities
  • Monitoring changes and growth of the risk backlog

Predicting risks

  • Root cause analysis of defects
  • Using root cause analysis to predict future risk
  • Providing feedback to risk identification activities
 

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.