Issue Types



 

 There are several issue types categories recognized and used in TestFLO.


CategoryDescriptionOptional
RequirementThere can be several issue types in this category even subtasks (for example main requirement divided into acceptance criteria). The requirement is defined in project configuration in Requirements tab.(tick)
Test Case TemplateOnly one issue type can be Test Case Template which is a entity in your test cases repository. Those issues are used to build Test Plan. The Test Case Template is defined in TestFLO Settings in Test Case Template tab.

Test Plan


It aggregates Test Cases. You can use it for your test plans, cycles, scenarios. Only one issue type can be configured as main Test Plan but you can indicate additional issue types (Story, New Feature, Improvement, Task, etc.) that inherit all the features of the Test Plan. The main Test Plan is defined in TestFLO Settings in Test Plan tab and the additional issue type as Test Plan is defined in project configuration in Test Execution tab.
Test CaseOnly one issue type can be defined as Test Case and it must be a subtask because it exists under Test Plan. This is executable instance of Test Case Template. You can also create Test Case directly under Test Plan without Test Case Template. The Test Case is defined in TestFLO Settings in Test Case tab.
DefectYou can decide what issue type will be your defect. It can be any issue type. The defect is defined in project configuration in Defects tab.(tick)


There are three main phases in Test Management supported by TestFLO: build, plan, execute. Below is matrix showing which issue type is created (red star) or actively used (blue star) in given phase:



BuildPlanExecute
Requirement(red star)

Test Case Template(red star) (blue star)

Test Plan


(red star) (blue star)
Test Case
(red star) (blue star)
Defect

(red star)


Relationships between issue types are shown below.



RelationshipDescriptionSuggested connection mechanism
It describes parent (TP) - child (TC) relationship. It is very strong in JIRA and cannot be changed. Similar situation is in test management where TP is a composition of TC that should be executed. That's why we choose this kind of relationship.JIRA Built-in subtasks

Test Plan can link to Requirement, because it may test functionality described in given Req.

One Requirement can have many Test Plans. You can track then executions progress of tests.

TestFLO - Enhanced Issue Picker


Test Case Template can be created for Requirement. This is obvious relationship as test cases are created out of Requirement.

One Requirement can have many Test Case Templates. You can measure then test case coverage of Requirement.

Enhanced Issue Picker

Test Cases are created out of Test Case Templates (repository). It is good to keep this relationship (originator) in case of TCT changes and other TestFLO's features.

TestFLO - Issue Link Field

Bugs are created during Test Cases execution. It is very handy for developers to have this relationship in order to replicate defect. On the other hand, testers can track how many bugs are reported for given TC.JIRA Built-in issue linking
When bug is created it is related (via TC and TP) with Requirement. It is vital for requirement's verification and test progress to track this relationship. In TestFLO we give mechanism (Create Defect) that based on REQ <- TP relationship links bug with Requirement.

Enhanced Issue Picker 

Other relationships are optionalIf you need to establish any other relationships between issues you are free to do it.

Enhanced Issue Picker

or

Issue Link Field [old]

or

JIRA Built-in issue linking


A wider context how TestFLO/Test Management issues integrate with Requirement/Change Management (blue) and Development Management/Bug Tracking (red).