Also notice that Agile Runs also have a ‘Relationships’ tab. Initially no relationships will exist as it is not created from a master script in the Script Library. If an incident is raised during the agile run or if the Agile Run is later converted to a Script in the Script library, relationships will automatically be added.
From the Relationships tab, you can add a relationship to a requirement. To do this, click on the ‘Add’ button on the bottom right side of the screen:
The ‘Add Relationship’ pop up screen will appear allowing you to create a Coverage relationship:
- Source will automatically be populated with the name of the Agile Run.
- Relationship type will automatically populate with Coverage (AgileRun<-> Requirement).
- Destination is the target requirement that this Agile Run will cover. Select the requirement from the pop up selector.
Direction is the direction of the relationship. This will automatically be populated with Source to Destination. In this instance coverage can only be from the Agile Run to the Requirement. Agile Run is the Source and the Requirement is the Destination.
Field: Relationships
Description
Relationships allows filtering entities based on their relationships to other entities, relationships can be direct, for example:
- Scripts that provide coverage for requirements.
- Assignments in an execution package which are associated to their script.
- The bugs related/raised during the run of a script assignment.
They can also be indirect, such as:
- Parent requirements of requirements that are related to scripts.
- Bugs related to a script or a requirement, via their associated script assignments.
Querying of the relationships index is done via a sub-select, and takes the basic form of:
Code Block | ||
---|---|---|
| ||
Relationships IN { ... relationships sub-select query ... }
|
The query within the sub-select is executed against the Relationships Index and has access to all the Relationships index fields.
When searching the relationships index, you are effectively searching a list of all the relationships each entity has to other entities, both direct and indirect, so you compose your sub-select query in terms of the "Source" and "Destination" entities, the Destination entites expose a number of fields that start with "RelatedTo" which make it possible to identify the related entities.
Two convenience fields are also provided to simplifying searching for related entities RelatedTo and DirectlyRelatedTo which we recommend users become familiar with before branching out into learning how to use the Relationships index and it's fields.
Examples
All scripts related to requirements in the project 'Project X':
Code Block | ||
---|---|---|
| ||
EntityType = Script
AND Relationships IN {
RelatedToProject = 'Project X'
AND RelatedToEntityType = Requirement
}
|
All indirectly related requirements for scripts in 'Cycle 1':
Code Block | ||
---|---|---|
| ||
EntityType = Requirement
AND Relationships IN {
RelatedToPackage = 'Cycle 1'
AND RelatedToProject = 'Project X'
AND RelatedToEntityType = Script
AND RelationshipDepth > 1
}
|
All requirements related to bugs with a resolution of "Wont Fix" raised in the last week (demonstrates the use of the Destination field and a nested sub-select back into the Entities Index):
Code Block | ||
---|---|---|
| ||
EntityType = Requirement
AND Relationships IN {
Destination IN {
Type = Bug
AND Resolution = 'Wont Fix'
AND CreatedAt >= "-1 week"
}
}
|
See Also
Supported Operators
Supported Indexes
Supported Types
- AgileRun
- AutomatedTest
- AutomatedTestAssignment
- AutomatedTestRun
- Incident
- Requirement
- RequirementPackage
- ScriptRun
- TestExecutionPackage
- TestScript
- TestScriptAssignment
- TestScriptPackage
Supported Features
...