Page History
...
| Info | ||
|---|---|---|
| ||
If you're new to Risk Management and RBT, please check the RBT brief overview section ahead Risk Management and Risk-Based Testing article. |
Where to set the risk
As long as you are able to define a sort-able value for the risk as a custom field in either cover-able issues (e.g. "requirements"/stories) or Test themselves, then you will be able to select and rank Tests for execution, based on risk level. If you have identified global risks at project level as issues, and those risks can be mitigated somehow by testing, then you can also use RBT with them.
...
The following screenshots show risk being defined at different levels, while also using different tools to implement them.
Adding Tests to a Test Plan/Test Executing/Test Set, sorted by risk level
Risk defined at Test level
Whenever adding Tests to an existing Test Execution/Test Plan/Test Set, you may choose to show the impact, probability and risk level related fields.
...
To sort a column (i.e custom field) by descending/ascending order, just click on the column name.
On the left side, you may use filters on the impact, probability and risk level fields. Filtering by risk level is essential but filtering by other related files may prove to be useful.
The way filters are shown depends on their type (i.e. the type of the custom field); therefore, it's important to setup these fields properly.
...
A Test Execution contains a list of tests to be run accordingly with their ranking (i.e. which you may see in the first column, named "Rank").
Tests may be visually ordered ascending/descending by clicking on the column name; this won't affect their ranking, which is the one used as the effective order to run the tests.
If you want to make this order permanent, by setting the rank accordingly, then you can choose "Apply Rank."
Note that you may also sort and re-rank Tests by impact or probability, if you want.
...
- create a dummy entity just for containing the list of tests (e.g. by cloning it or by creating a dummy Test Set with those Tests)
- remove the Tests from the original Test Plan/Test Set, as shown in this example for a Test Set
- search the Tests, using JQL or filters to obtain the previously saved list of Tests from the temporary entity and sort the Tests by Risk Level
- add Tests back to the original Test Plan/Test Set
These instructions assume that Risk is defined at Test level; if it's defined at requirement or project level, then it would need to be adapted accordingly depending on your implementation.
...
The Overall Requirement Coverage Report allows visually grouping of requirements by custom fields, thus you may easily group by risk level related field, for example.
The report also allows you to drill-down on the bar and thus see exactly which requirements have that risk level, for example, and that are on that specific coverage status (e.g. "OK"). This can be quite handy to evaluate the completeness and the failed tests, especially if the requirement is NOK.
Overall Requirement Coverage gadget
If using the Overall Requirement Coverage gadget, then you need to pick a project (and not a saved filter) as the data source; only then Group By will allow you to select specific custom fields to group your requirements, such as the Risk Level related custom field.
Requirements List gadget
...
As this gadget does not provide a grouping mechanism, you need to instantiate it multiple times configuring each instance with a different filter for picking only the requirements having a certain risk level.
Analyzing testing results by risk level
...