Issue Types

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

	Category	Description	Optional
	Requirement	There 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.
	Test Case Template	Only 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 Case	Only 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.
	Defect	You 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.

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

	Build	Plan	Execute
Requirement
Test Case Template
Test Plan
Test Case
Defect

Relationships between issue types are shown below.

Relationship	Description	Suggested 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 optional	If 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).