Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Xray mainly uses Jira issue types for implementing Test Management related entities, such as:

  • Test - for specification
  • Pre-Condition - for complementing the specification of one or more test cases
  • Test Set - for organizing Tests in lists
  • Test Execution  - for scheduling executions of tests
  • Test Plan - for defining the test plan against some scope (e.g. version/sprint) and track its progress

The only relevant exception are Test Runs. A Test Run is an internal entity managed by Xray itself, which is an instance of a Test containing also its result related data.

...

  1.  "Unified" development process: define a process that can be applied to all teams in the way how to manage the STLC. Every team is different and has its own needs, therefore your process should not be too strict but it should provide some guidance on how development life cycle should be addressed, covering requirement management, bug management and test management. Having teams working completely in different ways, hardens communication and leads to unproper and unoptimized tool usage. If you have a well-defined process that can be used organization wide, better; this is the key to ensure an optimal usage and have the best performance.
  2.  Are you adopting Agile and Scrum? Check out Using Xray in an Agile context for tips on how you can take advantage of Xray in such scenarios;. Agile software development page provides high-level overview of Agile and Agile Testing and besides background information on them, it will also provide some useful tips so your team can be more Agile and avoid doing things that are unnecessary.
  3. Image Added Each Xray entity has a purpose/fit. This means that if you us You may  Find out more
  4. Entity / Issue Type

    Purpose

    Test

    For making the specification of some test; a test case template;

    Pre-Condition

    For abstracting some initial condition that one or more tests must assure; reusable, i.e. linked to one or more test cases

    Test Set

    For creating lists of test cases, so you can easily pick those test cases afterwards in case you need them

    Test Execution

    For scheduling a execution of a bunch of test cases in some version&revision of the SUT;

    a Test Execution contains several Test Runs, one per each ”linked” test cased

    Sub Test Execution

    Similar to a Test Execution; the difference between them is that the Sub-Test Execution is a sub-task and can be created within the context of a requirement.

    Creating a Test Execution as a sub-task of the requirement issue provides you the ability to track executions in the Agile board.

    Test Plan

    For grouping multiple Test Executions and presenting a consolidated overview of them; tracks the results of some Tests in some version/sprint of the SUT

    Test Run

    An instance of a Test in the context of some Test Execution; contains a copy of the original Test specification along with the recorded results. It’s not an issue type.

    Test Repository

    A per project hierarchical organization of Test cases using folders; an alternate approach to Test Sets for organizing test cases.

    Test Plan Board

    A per Test Plan hierarchical organization of Test cases, at the planning phase, using folders.

    It is used for...

    • grouping, organizing the tests in the context of the Test Plan and to easily track the results of certain Tests grouped in some folder;
    • easily change the ranking of the Tests, to create Test Executions for them afterwards.

Specification

  1.  Avoid having many sub-requirements (>100) per requirement (e.g. Stories per Epic) as it can impact the calculation of their statuses
    1. normally it is a signal that the requirement needs to be further decomposed. Besides hardening analysis and its management, it will also require additional resources during computation of its status upon changes in any of the related sub-requirements, that in turn is affected by the status of the related Tests.
  2.  Requirements being covered by many (>>100) Tests
    1. normally it is a signal that the requirement needs to be further decomposed. Besides hardening analysis and its management, it will also require additional resources during computation of its status, that in turn is affected by the status of the related Tests.

...