Page History
...
- immediate information/no handoffs: Xray provides immediate information visibility right within your work item. This way, you don't have to ask someone to know about results, testing progress, or what is the coverage status of an Epic/Story. For example, you can see how a user story is from a QA standpoint, right from the Story issue screen; likewise, you can see QA feedback in your existing Scrum Boards
- collaboration: everyone is invited to collaborate, no matter their role; therefore, anyone can interact and collaborate on user stories, test cases, test planning, test execution. This is because Xray works inside Jira and uses different issue types as an abstraction of its own entities, meaning you can collaborate inside Jira, the Jira way
way 😃
In short, after successful installation & setup, we advise you to:
- have create a Test Plan(s) per sprint
- configure your existing Agile Boards (i.e. Scrum Board of active sprint) to show Test Plans and (Sub) Test Executions assigned to your Sprints and to show the coverage status on the covered issues
...
| Info | ||
|---|---|---|
| ||
As Xray is a flexible tool, and every team has its own demands, we highly recommend to you start simple and explore some of the possibilities offered by the tool. Following the Agile principles, your processes should be reviewed often by the team and adapted accordingly with the team's needs. You should also not dictate long and very strict processes, as you want to promote "individuals and interactions over processes and tools". Therefore, you need to find the right balance. |
...
- review the user stories with your team (remember: testers are part of the team)
- create Tests for each user story
- organize the Tests
- create one or more Test Plans (see above) and add the relevant Tests
- schedule multiple Test Executions, from the Test Plan or directly from each Story as Sub-Test Executions
- track overall, consolidated progress at the Test Plan level
- use reports to assess additional information, such as...
- Overall Coverage Report, for evaluating the current coverage status of the coverable entities (e.g. user stories)
- Traceability Report, to quickly filter out relevant entities based on their coverage, check the runs of related Tests and reported defects
- Test Executions Report and/or Test Plans Report, as a means to see the results obtained on different environments, on different revisions of the SUT, and to check the reported defects if they're still to be resolved or not
- use Jira dashboards to share information about your project, including testing progress; use some you can use specific gadgets for that this later
What belongs to a release?
...
On 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. (it's not very clear what this is)
| 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.) |
...
Note that you can create and/or link a Test explicitly with an Epic, if you wish to cover it directly.(do you mean exclusively?)
Creating Test cases
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.
...
Organization is essential to easily find the finding Tests later on. For example, whenever you need to perform regression testing, for example.
Addressing the Tests directly related with some sprint (i.e. with the stories or any other entity tested and assigned to the scope of the sprint) is relatively easy: you just need to link the Tests to the stories. You don't need to organize the Tests in any special , or structured way.
However, later on, you'll need to find the Tests by some sort of criteria:
...
There is no single answer that can suffice all sorts of team needs; the best is trying out the different approaches and choosing the one that makes your team more "comfortable" and effective. If your team loves JIRA and is keen on JQL, they'll probably prefer using flat lists (i.e. Test Sets). On the other hand, if your team has no deep Jira knowledge, are is coming from legacy tools, or if they aim to manage thousands of Tests per project, then the hierarchical organization provided by the Test Repository may be the best approach.
In big enterprise scenarios , following SAFe or similar frameworks for "Agile at Scale", the Structure app may cover more complex needs; please check the Test Repository approach first and go with Structure only if you need more advanced scenarios where you want to show Tests alongside other entities.
...
| Expand | ||
|---|---|---|
| ||
|
...
By having the Test Plan being handled as an artifact to be handled in the scope of the sprint, similar to what happens with Stories, Tasks, Bugs and other issue types, you deal with it in the same way as you deal with other entities: it is something that you have to address/manage during the sprint. You can even take advantage of the workflow status of the Test Plan as a means to identify in which what status it is (e.g. if it is in "To Do", "In Progress" or "Done").
...
Of course, this may lead to some additional management overhead and thus you should choose wisely the how many Test Plans exactly you want to have.
The following diagram shows an example of possible different criteria for creating Test Plans.
...