Configurable common data fields between related items from different item types (Incl. Use Case, Pro

Lien Bäcker
Lien Bäcker
edited July 2016 in
Use Case & Problems
For the product development, our team define everything about the product in a requirement.
Then the prototype is developed. The test specification is defined based on the requirement.
So in Jama, the requirement is at first created. A test specification is written with the relationship link to the requirement.
The Test team makes use of the test management in Jama for the testing. The test specification (test case) is included. The test cycle is created.
For us: it is important that the test team, during testing, should see not just the test specification but also the requirement. Right now, it is not possible during working with test run to see both test specification (Test case) and the upstream of this test specification
From our practical experience: when the requirement changes, the test specification should be updated also. With the relationship, Jama would make the status of relationship as “Suspect”. But this status change does not really bring up the message “Hey, things in test specification must be updated NOW”.

Idea/ Feature request:
It would be great, if there is an configurable option within Jama, to have data fields which are showing up on different items which belong to different item types.
For example here:
Requirement A has a data field called “Acceptance criteria”.
Test Specification TA is a downstream item from Requirement A
With the given option, Admin could configure to say, this “Acceptance criteria” is also shown in the Test specification TA.
When some changes were made in the “Acceptance criteria” of A, the people who are working TA would see the updated “Acceptance criteria” automatically.
This feature would really address both of our problems which I have mentioned above.

Comments

  • [Deleted User]
    [Deleted User]
    edited June 2016
    Thank you, Lien, for outlining so clearly what the problem is, and well as providing a well-considered solution. This makes a lot of sense—it's similar to conditional fields that populate based on other fields, yet has more configurability. The ability to reuse information at a field-level would be helpful in other uses cases as well. Thanks for bringing this up.

Categories