Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 2

Table of Contents
maxLevel2

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.

Info
titlePlease 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.

...

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

Info
titleDynamic Test Plan is a Xray Enterprise Feature


Image AddedImage Removed


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.


...

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

Image RemovedImage Added


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

Image RemovedImage Added

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.

Image RemovedImage Added


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. Code Block
      titleSample 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. Code Block
      titleSample 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. Code Block
      titleSample 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.


      Code Block
      titleSample 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.


      Code Block
      titleSample 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. Code Block
      titleSample 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.


      Code Block
      titleSample 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.


      Code Block
      titleSample JQL
      issue in requirementTests('saved_filter')

...