Agile

Scrum

If you're following Agile, particularly Scrum, you'll have sprints of one or more weeks. Each sprint represents one iteration until, at the end, you have a shippable product. Testing can occur during the sprint or more closely to the end. In any case, you can have a Test Plan per sprint to track the results of the Tests you want to execute, including the ones that validate the features implemented in that sprint. Besides this, you may also want to have a Test Plan for regression testing to ensure you're staying within that sprint.

Please note

A sprint is a more manageable way of dividing the complexity of an entire release. A sprint has a short, well-defined period.

Kanban

In Kanban, you're limiting the amount of WIP (work-in-progress) issues in a given state, namely, the ones in testing. Because you're not dividing your release into several periods, as you do with Scrum, you can manage it as if the period would embrace the time frame of the release.

Thus, you can have a Test Plan to track the Tests related to the features being addressed on the Kanban board. You may complement it with additional Test Plans for tracking the regression testing. It may be an excellent approach to have the Test Plan with regression tests, or smoke tests, as an independent Test Plan, so it is more apparent if regression is occurring.

Waterfall

In this scenario, testing is done as a separate phase at the end of development. Bugs may be found during testing, which will be directed back to requirements analysis/development. You wait for changes/fixes and then test it again.

Having a Test Plan assigned to the version currently being developed to group the results from multiple testing cycles may be enough.

Iterative Waterfall

In this approach, a release is split into several internal mini-releases, with subsets of the features implemented. It is assumed that some of these features may not be complete/stable/finished.

Each intermediate release may have one specific Test Plan to track the Tests and their results. The Test Executions made in the context of each of these Test Plans can also be associated with a broader Test Plan, so their results would also get reflected in a broader sense.

In sum, you can create one Test Plan for tracking all the Tests you want to validate in that version, along with additional Test Plans, one per iteration/intermediate release. Then, you must ensure that all Test Executions created in the context of your intermediate release's Test Plan are also reflected in the "master" Test Plan.  


Example using Dynamic Test Plans

Dynamic Test Plan is a Xray Enterprise Feature



Dynamic Test Plans is a feature of Xray Enterprise. If you do not have Xray Enterprise installed, the Dynamic Test Plans are not available in the Test Plan issue, and it is impossible to configure dynamic test lists. When installing Xray Enterprise for the first time, please re-enable Xray to load all properties from Xray Enterprise.


Depending on the "methodology" used, your team may have different needs or approaches regarding Tests.

We will share an example that can be extended for other methodologies using different JQL Queries. Still, for this one, we are considering the Agile Scrum methodology, and we want to have a Dynamic Test Plan with all the Tests that matter for the sprint.

For that we have created a JQL Filter named: "Sprint Tests" that list all Tests covering user stories in the Sprint 1.


We create a Dynamic Test Plan based on that JQL Query.

As you can see, the Tests are automatically added to the Test Plan; not only added but if they are removed from the filter they will be automatically removed from the Dynamic Test Plan.


Additional tips for building Dynamic Test Plan queries

To obtain the tests we need, we can  use JQL functions and saved filters. Some examples follow ahead.

Tests that cover requirements assigned to the current sprint

Context

  • Tester wants to create a Test Plan with all the tests that cover requirements in the current active sprint.

How to

  1. In the Issues navigator, create a filter (e.g., "saved_filter") for the following JQL query.
    1. Sample JQL
      project = BOOK and issuetype in (Story, Epic) and sprint = "Sprint 1"
  2. Use the requirementTests JQL function. This will allow you to obtain the issues on the Issue navigator/search page.
    1. Sample JQL
      issue in requirementTests('saved_filter')

Tests that cover requirements for the current version

Context

  • Tester wants to create a Test Plan with all the tests that cover requirements assigned to the current version.

How to

  1. Use the testsWithReqVersion JQL function. This will allow you to obtain the issues on the Issue navigator/search page.
    1. Sample JQL
      issue in testsWithReqVersion('BOOK', '2.0')
  2. Or ...
    1. In the Issues navigator, create a filter (e.g., "saved_filter") for the following JQL query.


      Sample JQL
      project = BOOK AND issuetype in (Story, Epic) AND fixVersion = 2.0
    2. Use the requirementTests JQL function. This will allow you to obtain the issues on the Issue navigator/search page.


      Sample JQL
      issue in requirementTests('saved_filter')

Tests that cover requirements from previous versions

Context

  • Tester wants to create a Test Plan with all the tests that cover requirements from previous versions.

How to

  1. Use the testsWithReqVersion JQL function. This will allow you to obtain the issues on the Issue navigator/search page.
    1. Sample JQL
      issue in testsWithReqVersion('BOOK', '1.0', '1.1', '1.2')
  2. Or ...
    1. In the Issues navigator, create a filter (e.g., "saved_filter") for the following JQL query.


      Sample JQL
      project = BOOK AND issuetype in (Story, Epic) AND fixVersion in (1.0, 1.1, 1.2)
    2. Use the requirementTests JQL function. This will allow you to obtain the issues on the Issue navigator/search page.


      Sample JQL
      issue in requirementTests('saved_filter')