Our requirements managements team sometimes writes requirements which contains tables with multiple rows, say for eg. 50 rows. Each row in this table can require multiple test cases (N) to test it. So we end up having 50 * N test cases linked to one requirement. And a change to any one row of the table flags all the 50 * N test cases as suspect which is not correct.
The simplest way to overcome this is to split the table across multiple items such that each row of the table represents a single item in Jama. But managing the table across multiple items may not make proper sense to the requirements management team.
Has anyone faced similar issues? Are there any best practices for managing such requirements and linking test cases to them?
Vikas, I think in your case we would recommend using separate items (as onerous as that might be for some teams, that's really how Jama is designed to function). I'm going to check in with some colleagues and see what they think, though.
Vikas, I just wanted to follow up that after speaking with some of my colleagues in our services & product departments, we agree that the best approach is to create separate item types. I'm sorry there isn't a more efficient way for your requirements management team to look at this.
We also have a similar problem. Not as complex as yours but we will have compound requirements that require multiple complex test cases. They are written this way so specific people can use the Reading View and not be concerned with information that is not applicable for them ("read it like a book/manual"). The most complex I can remember is a single test case with ~40 steps and also 42 test cases linked to a single requirement.
It becomes a real pain with change management and suspect links when someone goes in and changes a requirement typo or alters existing content.
Anyone have suggestions? I wish there was a different way...
Thanks Kristina for the follow up. And thanks Noah for putting more light on this.
I believe other customers too must be encountering this challenge of having to link multiple test cases to a single requirement and then having to managing the relationships and suspect flags.
It will be interesting to see if anyone has any better ideas of managing this.
HEADQUARTERS|135 SW Taylor Suite 200, Portland, Oregon, 97204