Course Category: Software Testing
Course Duration: 14 Hours
Hours: 14 PDUs (Professional Development Units)

Select your country

Select your country to access the registration page


Register Now

14 Hours Virtual Course
Course Timing: 8.45 AM to 1.00 PM Malaysia Time


Register Now

14 Hours Virtual Course
Course Timing: 8.45 AM to 1.00 PM Malaysia Time


Register Now

14 Hours Virtual Course
Course Timing: 8.45 AM to 1.00 PM Malaysia Time

All Other Locations

Register Now

14 Hours Virtual Course
Course Timing: 8.45 AM to 1.00 PM Malaysia Time

Processworks Sdn. Bhd. is a registered HRDF Training Provider

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 Syllabus


  • 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

Course Syllabus

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 testing
    • Definition of test levels
    • Component vs. feature integration
    • Stand alone vs. end-to-end testing
  • 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 testing)
      • 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