Versions Compared

Old Version 6

changes.mady.by.user Angelica Salazar

Saved on

compared with

New Version Current

changes.mady.by.user Bernhard Doleschel

Saved on

Key

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

Overview

Test Management for Jira is a native Jira Server add-on that provides extensive test management capabilities for your project. T4J extends Jira with views and features that support testing. T4J can be used with any Jira project.

Table of Contents

Features

  • Definition and management of test cases
    Single test cases are represented by Jira issues extended with test steps and test parameters. You can define your test cases just like any other issues, using all of Jira’s features: data fields, labels, links, issue operations, etc. Additionally, you can organize test cases in a tree structure for every project individually.

  • Creating test plans
    T4J provides extensive features for creating and structuring test plans, making it easy to handle complex test scenarios.

  • Manual test execution
    An execution runner is provided for manually executing single tests and test plans.

  • Automatic test execution
    T4J integrates with other applications via its REST API. The test case definitions and test data are managed in Jira, while the actual testing is carried out by a separate testing application. The results are then transferred back to T4J, which provides execution statistics and reports.

  • Export
    T4J provides features for exporting tests cases, test plans, test case executions and execution statistics. Standard export formats are supported.

  • Coverage
    Since test cases in T4J are extended Jira issues, it is easy to link them to other project issues (e.g. requirements or development tasks), thereby establishing coverage. T4J provides views to determine the extent of test case coverage. You can create test cases and link them to uncovered issues directly in the coverage view itself. 

Process

The complete T4J process consists of four activities: Test Case Definition, Test Planning, Test Execution and Test Coverage Evaluation. These activities are the main concepts of T4J and each encompasses various tasks. Although the full process ideally includes these activities, you don't have to use all of them. They should be seen as guidelines rather than a rigid process. This makes it easy to integrate T4J with existing testing processes in your organization.

A testing process in T4J can be as simple as creating a single test case, executing it once or many times and tracking the results. You can extend the test process by structuring test cases hierarchically. You can also create test plans representing more complex test scenarios and tracking the coverage of your requirements by test cases. It is up to you to use the features of T4J to establish a testing process that works for your organization.

Activity

Tasks

Explanation

Test Definition

  • Create issues that represent single test cases.

  • Use the definition tree of a project to organize the test cases.

  • Add test steps and parameters to the test cases.

Structuring test cases using the definition tree makes it easy to understand the cases and how they fit into the overall project. It also facilitates the creation of test plans in the project. We recommended adding all test cases, or at least those that are needed in test plans, to the project’s definition tree. (But note that you don't have to use a definition tree for test planning, since you can also add tests to a test plan even if they aren't part of a definition tree.)

Info

T4J does not require the use of any special issue types, but using a particular issue type to distinguish test cases from other sorts of issues is a good idea. Therefore, if you do not already have an issue type such as Test Case, we highly recommended having your Jira administrator create it. See Recommended Issue Type for Test Cases.

Test steps and parameters are added to a test case in the T4J Issue Detail View. This view is accessed through the definition tree, so a test case must appear in the definition tree in order to manage its test steps and test parameters. (But note that you don't have to specify test steps and parameters to add a test case to a test plan or to execute it.)

Single test cases can already be executed from the definition tree. Test case parameters can be overwritten when you start the execution.

Test Planning

  • Create test plans.

  • Structure the content of test plans using the plan tree.

Test plans are used to bundle different test cases together in order to handle complex test scenarios. (Note that you don't have to create test plans to execute tests.) The test cases in a plan can be organized hierarchically.

Test Execution

  • Create test case executions and run them.

  • Track execution statistics.

Test case executions can be created in the execution view, in a test plan or in the definition tree. Test cases can be run manually using the execution runner or via the REST API of T4J. Note that test case parameters can be overwrittenduring execution.

Test execution statistics are available in the Execution View. The statistics can also be exported in different formats.

Test Coverage Evaluation

  • Track the coverage of requirements or other issues by test cases.

  • View the status of test case executions.

  • Track the coverage of failed tests by bugs.

  • Fix coverage gaps by linking test cases to requirements and other issues.

  • Fix gaps in execution failure coverage by linking bugs to test cases.

The Coverage View is used with the goal of ensuring that:

  • Every requirement or issue is covered by a corresponding test case.

  • Every execution failure is covered by a corresponding bug.

The view allows you to determine the degree to which these goals are achieved, allowing the project to identify and fix weak points in testing.

The Coverage View optionally provides information on the execution of test cases - for example, whether the latest execution status is pass or fail.

Coverage views can be configured individually, using as many coverage levels as make sense in the project.