Page History
...
In the other hand, Test Executions, Sub-Test Executions and Test Plans represent work targeted for a given release and/or a given sprint. Thus, they can be tracked as any other issue that needs to be handled in the scope of your release/sprint. If you have these issues assigned to some release through the FixVersion/s field, then they will appear in the summary information of the Releases project page.
| Info | ||
|---|---|---|
| ||
As of Xray v3.4, Tests created from the "requirement"/story screen will inherit the FixVersion/s from the parent issue. The version assigned to the Test case has no special meaning, unless you want to handle it as specification work that you need to address in the context of that release. If that's not the case, you can simply ignore. Xray may change this behaviour in the future. |
...
| Info | ||
|---|---|---|
| ||
Please make sure you have the Epic<=>Story relation enabled under Xray "Issue Type Mappings" administration section. |
Note that you can create and/or link a Test explicitly with an Epic, if you wish to cover it directly.
...
Tests can be created right from the Epic/Story screen. That way, they will be automatically linked with the respective issue.
Otherwise, if you create Tests using the Create button from the top navigation bar, or from a Test Set, or from a Test Repository folder action, then you have to specify the covered issue.
You can do that at the moment of creation...
or later on, by using the More > Link action available from the Test issue screen (or from the Story/Epic issue screen, but using the "tested by" issue link in that case).
Organizing the Test cases
...
Test Executions created from the Test Plan will also, by default, inherit the Test Plan assigned version (i.e. FixVersion/s).
Test Plans for RT and NRT
...
Thus, you can create one Test Plan containing all Tests that cover the "requirements" (i.e. user stories) and use it to track their progress along with another distinct Test Plan for all the regression related tests.
You can analyze your coverage (i.e. how your "requirements"/user stories are) from the release perspective or from each Test Plan perspective.
...
The following diagram shows an example of possible different criteria for creating Test Plans.
Using Sub-Test Executions
Xray provides the ability to easily create Test Executions containing all the Tests that cover some "requirement"/Story as a sub-task of it.
This may provide a quick way for you to schedule the execution of certain Tests; you can also link that Sub Test Execution to an existing Test Plan.
...
Including in the board Test Executions coming from automated testing (i.e. during CI), may not be recommended as it will overload the board and not provide any real added value. Instead, you may include only Test Plan(s) as means to group and show the consolidated results coming from automation.
Xray in Kanban based teams
...
- We're not really adopting Scrum perfectly... can we use these approaches in our case?
- Yes, you may follow these same principles and adapt them to your methodology.
- We have a hardening/clean-up sprint where we wish to test thoroughly, including deep regression testing. How can this be handled?
- Hardening sprints are normally a sign that Agile is not fully being embraced. Having said that, you can have a Test Plan to track the testing performed in the scope of that sprint, adding all Tests related with user stories and other issues "implemented" on previous sprints, and thus consider the results performed in the scope of this Test Plans as being the relevant ones
- Are Test Plans, Test Executions or Sub-Test Executions child issues of an Agile board? In other words, do they belong to some Agile board?
- No. All those issues, first of all, belong to some project. They can optionally be assigned to a release (through the FixVersion/s field) and to a sprint (through the Sprint custom field).
- A different thing is showing whatever issues you want in your existing boards; as those entities are implemented as issues, you can configure boards to show them. In fact, the same issues can be included (i.e. shown) in different boards.