Versions Compared

Old Version 1

changes.mady.by.user Sergio Freire

Saved on

compared with

New Version 2

changes.mady.by.user Sergio Freire

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Overview

This article provides an overview of Risk Management and Risk-Based Testing (RBT).

RBT is built on top of Risk Management and thus the same concepts and principles apply.

Concepts and Terminology

Risk

...

The level of risk, sometimes just simply called "risk value" or "risk", can be defined as a combination of the probability/likelihood and the impact/consequence of an event on the objectives.


Risk = Probability (of event) * Impact
Also know as:(Level of Risk / Risk Score / Risk Exposure) (Likelihood/Frequency)(Consequence/Damage/Revenue/Business Criticality)


Probability / Likelihood

Probability of an event occurring.

...

This is an example of a risk matrix with the calculated risk levels. You may also use colours to quickly depict the higher risks.







Probability

(likelihood)

4

(very high)

0481216

4

(high)

0

3

6

912

2

(medium)

0

2

4

68

1

(low)

012

3


4

0

(none)

000

0


0


0 (none)

1 (low)

2 (medium)

3 (high)

4
(very high)

Impact

(consequence)


1.3. Risk Evaluation

Per ISO 31000, it corresponds to the "process of comparing the results of risk analysis with risk criteria to determine whether the risk and/or its magnitude is acceptable or tolerable. Risk evaluation assists in the decision about risk treatment".

...

However, sometimes "requirements" may not exist at all, defined explicitly as such. This may be common in scenarios where teams inherit legacy projects, that have few or no "requirements" but that have Tests that validate the intended behaviour.



Project level

"Requirement" / User Story level

Test level

Pros

  • some risks may simply be project wide
  • most common approach
  • allows to decide whether a story should be addressed and how based on its risk
  • shapes the tests definition on the Test Design phase taking into account the risk
  • allows distinct priorization of Test cases for the same requirement
  • allows RBT in projects without requirements (e.g. legacy projects)

Cons

  • misses a more granular way of assessing risks and addressing them
  • not differentiates between Tests for the same story, although some additional criteria (e.g. ”priority”) could be used for that
  • not applicable to projects without requirements
  • a lot of effort to evaluate Risk for tons of test cases
  • Tests are not specified taking into account requirement risk; applies only to existing test cases and not to new ones (at the acceptance criteria would probably be a better approach)

RBT Process

RBT is much more besides selecting what Tests to execute and their order; RBT affects test planning, authoring and execution.

...