Versions Compared

Key

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

...

  • Test level
  • requirement/story level, or any other issue type that can be covered with test cases (i.e. configured as "requirement issue types" on "Issue Type Mapping" settings).
  • project level, using a specific issue type

Each approach has it's own usage scenarios and pros/cons. Throughout this article, most of the examples will be based on risks defined at Test level.

Depending on your approach to Risk Management and to RBT, you will need to configure risk related fields as explained in the configuration section ahead. 

RBT related activities

The whole RBT process has many activities and Xray can be used along the way. 

...

  • use saved filters to group requirements with similar risk level
    1. create several issue filters, each one grouping requirements (or project level risks) having the same risk exposure. Using a nomenclature for the saved filters can help you out (example: "risks_low", "risks_medium", "risks_high")
    2. obtain the related tests using JQL. Example:  issue in requirementTests("risks_high")
    3. add tests, group by group, by descending order of risk; whenever adding tests you may sort them by an additional criteria (e.g. Priority), including risk explicitly associated to it
  • or use a calculated field on Test issues to perform the risk calculation using the risk level(s) of the associated requirement(s). By having this field "replicated" on the tests themselves, will ease handling of test cases during RBT as it will be similar to handling "Risk defined at Test level." Please see ahead a configuration example using ScriptRunner app.

Sort and re-rank Tests in a Test Execution by risk level

...

  • upon a change on a "requirement"/story, enforce related Tests to be rewiewed (i.e. transition the related Tests to a specific workflow status). Check ScripRunner implementation example
  • set "requirement"/story related issue to read-only on a specific workflow transition, to ensure no changes are made without being reviewed; in order to make changes, require a specific workflow transition to be made; to implement this you just need to configure the related Jira workflow
  • enforce workflows on Test and Pre-Condition issues, to make sure the specification is reviewed. More information about using workflows on Xray entities, here


Note: all changes are tracked, directly on the respective issues; in the case of Test Runs, changes also get tracked on the related Activity section.

...

In order to start with RBT, you have to configure the risk management related fields. You may use Jira built-in capabilities or use a risk management or even a customization app instead.

...

As JMCF does not provide a way to implement event listeners, there is currently no viable solution for this. As a possible alternative, please see ahead a possible implementation using ScriptRunnerusing ScriptRunner


Using ScriptRunner

If you already have the ScriptRunner app, you may use it to perform the calculation of risk level.

...