Page tree

Looking for documentation of older versions of Xray? Check them here

.

Skip to end of metadata
Go to start of metadata

Since Xray for JIRA 2.0, Xray integrates with Agile giving you a flexible way of viewing, managing and reporting some Xray issue types.

Agile boards are an excellent way for visualy keeping track of the progress of project's related tasks.

Usualy, you use Agile boards for managing Sprint's related issues, such as user stories, tasks and defects.

You can extend the usage of Agile boards to make them also testing aware.

Agile boards are great but they do not replace other types of reports where more information may be consulted and analyzed.


 

Using Xray issues in Agile boards

Since Xray uses JIRA issue types for most of its entities, in theory you're able to include them in your boards. However, the reason to include each one of them may be different.

Having in mind that Tests and Pre-Conditions are like test case templates, including them in a board does not make sense unless you want to track the specification progress, in case you have a specific workflow implemented for that purpose. The same applies in fact to Test Sets. Some may prefer to use one, or more, Task issue(s) for dealing with the specification effort of Tests and/or Test Sets.

Including individual Test Runs themselves would not be that useful, since a Test may have multiple runs; therefore, you board would be over populated . Besides it, Test Runs are not issue types so they cannot be included in Agile boards.

Test Executions may be assigned to a Sprint and may be tracked in a board. However this may not scale if Continuous Integration is being used, due to the potential huge amount of Test Executions that may be created.

Sub-Test Executions are an excellent way for visualy identifying the associated Test Executions that validate a given requirement, since they're created as sub-tasks for the requirement issue and will appear accordingly in the board. A limitation is that a Sub-Test Execution is a sub-task of only one issue, in this case a requirement. Sometimes this may not be applicable, since it may be necessary to have Test Executions with Tests associated with multiple requirements.

A Test Plan tracks a group of Tests, independently of the amount of Test Executions, for a given version of the SUT. Test Plans may be used to group the Tests in the scope a given Sprint and thus consolidate the testing results.

 

In sum, you may extend Agile boards for testing purposes, for addressing two points:

  • specification & organization
  • planning & execution

 

 Possible usagesNotes
Test
  • track the test specification progress/lifecycle, namely if a specific workflow is being followed (e.g. for reviewing purposes)
 
Pre-Condition
  • track the test specification progress/lifecycle, namely if a specific workflow is being followed (e.g. for reviewing purposes)
 
Test Set
  • track the test specification progress/lifecycle, namely if a specific workflow is being followed (e.g. for reviewing purposes)
 
Test Execution
  • track the daily execution related tasks
  • including "Test Execution Status" custom field provides a quick overview of all the Tests that are part of the Test Execution
  • hard to scale, specialy if CI is being adopted

Sub Test Execution

  • per each requirement, track the execution of the related Tests
  • including "Test Execution Status" custom field provides a quick overview of all the Tests that are part of the Sub-Test Execution
  • hard to scale with many executions
Test Plan
  • using scoped Test Plans (i.e. in a context of a Sprint) quickly provides an overview of the progress of the execution of your Tests
  • including "Test Plan Status" custom field provides a quick overview of all the Tests that are part of the Test Plan
  • requires adding the "Sprint" field to the Test Plan

 

Usage scenarios

A typical concern with Agile boards is having them as more clear, "non-polluted", as possible, so you can focus on what's important.

Some relevant and high-level information may be obtained from specific custom fields associated to requirements, or (Sub) Test Executions, or Test Plans. These fields may be included in the board cards.

Note that you are limited on the amount of fields (3) you're able to include in each card present on the board. 

Next, you may find some possible scenarios for integrating testing into your Agile boards, although you're free to adapt each one to your needs.

Requirement Status on Agile Board

You can add the Requirement Status custom field to the requirement issues in the Active Sprint. It’s actually a useful feature provided by JIRA that gives you the possibility to add custom fields in both views: Active Sprint and Backlog. Adding certain Xray custom fields, as the Requirement Status, may be a good improvement for your testing teams because it provides a quick overview about what are the current statuses of the requirement issues. 

 

In order to add the Requirement Status on Agile Board you have to perform the following steps:

Step 1: Open the Agile Board you wish to add the Requirement Status.

Step 2: Click the Board button and then click the Configure button.

 

Step 3: Click the Card Layout and add the Requirement Status to the Backlog and Active Sprint.

 

Step 4: The Backlog View and the Active Sprint View now have the Requirement Status custom field.

  1. Backlog View



  2. Active Sprint View





 

As a suggestion, you may also add the Test Environments custom field. It may be useful to have different Sub Test Executions to test the requirement in different environments.

Quick view of Executions for Requirements from Agile Board

Creating a Sub Test Execution from the Requirement Issue will let you track related executions in the Agile Board, so you will see all work that needs to be done to “finish” a requirement, either from developers or testers.

You can have a quick view of all test executions of a requirement, directly from the JIRA Agile board, as long as the executions are created as Sub Test Execution issues.

Test Plans as a way to consolidate test results

You may create one or more Test Plans and associate them with a given Sprint.

By including the Test Plan Status custom field, you are able to see right away the overal progress of your Test Plans. 

You may also include include the Test Execution Status custom field in your cards, thus Sub Test Executions progress may be promptly visualized.

Requirement Status may also be included on the card configuration, allowing the user to assess the coverage status of the requirements present on the board.

 

  • No labels