Consider the scenario wherein I have two issues linked (Issue A and Issue B) together. I care about the type of link, and so specify the inward/outward link, no problem.
However, the link itself has one or more attributes that do not truly belong with either Issue A or Issue B -- I need a way to store more information about the relationship between the two issues than just the simple "blocks/is blocked by" or any other short label.
In practice, I am using jira for requirements management (not just in the software sense -- this is physical engineering involving things being built and verified via laboratory testing). Issue A is of type 'requirement', and Issue B is of type 'test.' Issue A "is verified by" Issue B, that's an easy enough link to set up. But I want to store the technical details about how Issue A is verified by Issue B -- what this or that multimeter reading must be, the threshold value of some telemetry point, etc., to say that the requirement has been verified during a test. This requires at very least a string or short text field as an attribute of the link itself. There are workarounds like via automation, but I'm not asking for workarounds.
Jira obviously doesn't have this out of the box.
Based on reading this database explanation, what I want involves extending the "issuelink" table that, if I understand it right, is a single table that belongs to each project. Imagine if one could add a custom field to the issuelink table itself. Any plugins that allow this? Any developers have experience attempting to write such a plugin?
The outcome of issue B (the test) is governed by the definition-of-done by the team doing the testing. In this document / instruction set / team-based-agreement, you'll find the prerequisites for performing the test in a reproducible way, meeting certain standards.
I would not store the definition of done (test-prerequisites and standard operating procedures for testing or even training prerequisites of lab technicians performing the testing) in any of the Jira issues. This is data that typically finds its way into a documentation system such as Confluence, where it can easily be accessed (with version history) to help auditing the entire testing procedures.
Kind regards,
Dick
Well, Jira also has history that can be audited, with approval workflows for if the team has reviewed and signed off. Test prerequisites and SOP, as you said, belong elsewhere.
I've had the thought balloon of an intermediate issue, of type "Verification Event," that is linked to exactly one requirement and exactly one test. This way, it can have as many attributes as I want, can have its own workflow and approvals, and so forth. A given requirement can have multiple verification events, and you can query a given test to see which verification events are attributed to it. A major purpose of what I want here is so the author of the detailed test procedure can quickly get a readout on exactly what measurements need to be taken to make sure the test is gathering all of the information it needs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.