[[TOC]]

Risk analysis is a technique used to identify factors that may jeopardize the success of a project or achieving a goal

A risk is defined as a potential failure that can affect the objectives of a feature and may contribute to its success or failure. Example of risks are:

• Complex requirements could cause not correct working functionalities
• External dependencies which are out of own control impacting the availability or functioning of our features
• New technologies used, like a new programming language

Risk based testing (RBT) is an organizational principle used to prioritize the tests of features and stories and to determine the scope and coverage of those tests, based on the determined risk.

During the refinement of a feature, when the team is starting to deep dive into the topic, the related risks and risk level of the feature is determined by the PO, DM, BA, UX, QA and Dev.

1. Risk analysis
2. Risk based testing approach

In the Risk Analysis template there are 2 predefined questions which will be answered per feature or User Story: (1) What is the impact on our customers if this feature is not working correctly or not supporting their customer needs?

• Impact: the impact when the feature or US items fails, this could be based on amongst others: impact for customer if not available or not working correctly or as expected, the reliability of us as delivery partner, loss of revenue, legal/compliance/security impact, etc
  • Indicate the impact for this feature when it fails: ranging from 1 (minor) - 5 (severe)

(2) What is the likelihood that the feature is not working correctly?

• Likelihood: the chance the feature or US fails, this could be based on amongst others: complexity of code, frequency of use, dependencies with external apps, etc
  • Indicate the likelihood for this feature to fail: ranging from 1 (little chance) - 5 (very likely)

Score: enter the ourcome of the discussion in the excel template, the score will be automatically calculated:

• Describe in the motivation field what the reason is of the score

• After the score is calculated, determine:

  • What the test mitigation is (see ad. 2 for more clarification)
  • Which types of tests will be performed
  • Which test techniques should be used
  • What type of automated tests should be created

• In addition 2 extra specific questions are being discussed, this to determine if additional mitigations should be in place:

  • Do we expect for this feature a Load and/or Performance issue? If yes: Indicate Load and/or Performance test in the Other mitigations section
  • Do we expect for this feature a Security issue? If yes: Indicate Security test in the Other mitigations section

Determine with the team the risk based testing approach:

• The higher the score, the more test coverage (manual and automated) should be in place by increasing the amount of tests by using different test techniques.
• The higher the score, the more test automation for unit, API, UI and E2E should be in place.

Test coverage level 1: Each path/condition is covered once Test coverage level 2: The combinations of 2 consecutive paths/conditions are covered

If there is a need for Load and Performance test or Security test, add in this section:

• Load and/or Performance test
• Security test

The excel file can be saved per feature as 'risk analysis_feature (US) id_feature (US) name' and attached as document in the feature or user story and/or added on a wiki page.

The risk outcome will also be stored in DevOps Feature/US (NextensNL only), there are 3 risk categories

• Low risk
• Medium
• High

To make sure mitigations will be implemented, it could help to:

• Create tasks on the board for the additional tests like performance test
• Add the risk based testing actions as separate criteria in the DoD like:
  • Test approach High executed
  • Performance test executed
  • Security test executed