|Anonymous | Login | Signup for a new account||2019-12-13 03:26 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008261||TestLink||Requirement to Test Case Assignment||public||2018-05-11 15:07||2018-06-19 17:58|
|Product Version||1.9.14 (2015 Q3)|
|Fixed in Version|
|Summary||0008261: Link between versioned requirements and version test cases|
|Description||Dear TestLink team and users,|
When a test case is linked to a user requirement, it is the current version of the requirement which is linked to the test case, and the current version of the test case which is linked to the requirement.
This, for me, is fine.
However, if the requirement is modified into a new version, the version of the requirement already linked to a test case is then updated to the latest version.
And as the link is done globally between a test case and a requirement, so the update is done also for all previous versions of the test case.
If the test case is modified into a new version, the version of the test case already linked to a requirement is then updated to the latest version.
And as the link is done globally between a test case and a requirement, so the update is done also for all previous versions of the requirement.
This, for me, is not correct. The link between a given version of a requirement and a given version of a test case should be fixed at some stage of the process.
Am I under the wrong assumption ? Or is there a possiblity to fix this link between "requirement ID - version " and "test case ID - version" ?
Thank you very much for your help
|Steps To Reproduce||- Create a requirement version 1|
- Create a test case version 1
- Link the requirement version 1 to the test case version 1
- Create a version 2 for the requirement
- Create a version 2 of the test case
- Link the requirement version 2 to the test case version 2
The version 2 of the requirement is now linked to the test case version 1.
|Tags||No tags attached.|
|QA Team - Task Workflow Status||TBD|
edited on: 2018-05-12 07:23
Design choice has been to link always the latest version of both entities, maybe because this was implemented a long time before the addition of revision on both entities.
Anyway probably this is not completely wrong if changes between versions are minor, but if the new version is completely different then the requirement is not anymore the original one, then IMHO you must create a completely new one, and the same logic applies to the test case that you will need to verify the requirement.
changes to these require a big change at Database level, and impacts on several features.
There are no plans for this change.
@fman I agree that this is a huge change.
However I disagree with your opinion that a requirement should not "change too much".
In a regular project the content of a testcase or requirement may change a lot over time (e.g. if the project life time is very long).
Hence the linkage between test cases and requirements may become invalid over time if an old test case version is still linked against an updated requirement.
Have you ever thought about introducing some kind of "baselining" feature which preserves the versions + revisions of the linked items at the time of the creation of the baseline?
This way it would be possible to reproduce the exact state of the test cases + requirements at the time of the baseline, e.g. also in various reports.
These reports may be created at any time in the future as the baseline is a frozen "snapshot" which cannot change any more.
>> However I disagree with your opinion that a requirement should not "change too much".
never said this.
The Effort to create a baseline feature is also not low.
my opinion, short version :
Coverage and attachments should be linked to Requirement version and TestCase version
The long version :
Our TestLink Use Rules :
- we NEVER delete any information, for traceability
When starting a new project, Requirements, TestCases and coverage are always good : X requirements, all testcases linked to requirements, every item is V1
But after the first increment, when the customer has changed his mind for few features, we update requirements, that change related Testcases content and coverage.
An example for just one Requirement update : our user want to trace modification into TestLink :
from Req1(V1, applicable, 1 attachment) <=> TC1(V1, applicable, 1 attachment) + TC2(V1, applicable, 0 attachment) before the first increment
to Req1(V2, applicable, UPDATED content, 1 UPDATED attachment) <=> UNLINK TC1(V1, OBSOLETE, 1 attachment) + TC2(V2, applicable, UPDATED content, 0 attachment) + LINK TC3(V1, applicable, 1 attachment) after the first increment
Because attachments and coverage are declared based on ID and not version, our user will set :
Req1(applicable, 1 legacy attachment + 1 UPDATED attachment) <=> TC1(OBSOLETE, 1 attachment) + TC2(applicable, 0 attachment) + TC3(applicable, 1 attachment) after the first increment
Our major problem for post analysis :
- Req1 V1 seems to be covered by TC3 that didn't exist when execution has been done
- Req1 V2 is still linked to TC1 to keep link for Req1 V1 for traceability but obsolete testcase will not be executed
- Req1 V1 and V2 are linked to 2 attachments, but only 1 attachment is relevant for each version
Not a problem to post analysis this use case, but there are others reasons that modify Req/Testcases/Coverage :
- during test execution, some testers has found that testcases steps are not applicable (theory VS reality)
=> TestCases are reworked : new version, content modified (steps)
- some requirements are dropped (obsolete) because the original need is not confirmed anymore
=> Requirements updated : new version, status Obsolete
=> related TestCases are reworked : If testcase doesn't cover an applicable requirement, TestCase status is set to obsolete
and with 1000+ requirements, the effort to understand the history is huge, impossible to be honest.
If Coverage and attachments are linked to Requirement version and TestCase version, the situation will be better : in TestLink, user will declared
before the first increment :
Req1(V1, applicable, 1 attachment) <=> TC1(V1, applicable, 1 attachment) + TC2(V1, applicable, 0 attachment)
after the first increment :
Req1(V1, obsolete, 1 attachment) <=> TC1(V1, obsolete, 1 attachment) + TC2(V1, applicable, 0 attachment)
Req1(V2, applicable, 1 UPDATED attachment) <=> TC2(V2, applicable, 0 attachment) + TC3(V1, applicable, 1 attachment)
Dear TestLink team,
I agree that introducing links between the versions of the test case and requirements, as well as versioning in the attachments to a test case seem to be a major task as it requires changes in the database and impacts a lot of functionalities.
However, it is something that we really need.
Would you help evaluating the effort and maybe give us technical guidelines to achieve these changes ?
Best things for me is:
1)You sponsor the change => pay for the implementation
2) I do the implementation
That could be potentially discussed.
Clearly you should be the best to get quickly into the code!
Would you please give me an email where to contact you directly?
|2018-05-11 15:07||e.p.||New Issue|
|2018-05-12 07:13||fman||Note Added: 0027446|
|2018-05-12 07:23||fman||Note Edited: 0027446||View Revisions|
|2018-05-12 07:24||fman||Assigned To||=> fman|
|2018-05-12 07:24||fman||Status||new => feedback|
|2018-05-17 08:53||hughkay||Note Added: 0027483|
|2018-06-02 18:55||fman||Note Added: 0027510|
|2018-06-02 20:45||Mr.Bricodage||Note Added: 0027511|
|2018-06-06 13:16||e.p.||Note Added: 0027551|
|2018-06-06 13:16||e.p.||Status||feedback => assigned|
|2018-06-06 13:50||fman||Note Added: 0027552|
|2018-06-06 18:03||fman||QA Team - Task Workflow Status||=> TBD|
|2018-06-06 18:03||fman||Severity||major => feature request|
|2018-06-06 18:03||fman||Category||Internal issue => Requirement to Test Case Assignment|
|2018-06-06 18:03||fman||Summary||Link between versioned requirements and version test cases does not work => Link between versioned requirements and version test cases|
|2018-06-08 08:28||e.p.||Note Added: 0027556|
|2018-06-08 10:18||fman||Note Added: 0027557|
|2018-06-09 09:16||fman||Issue cloned: 0008289|
|2018-06-09 09:16||fman||Relationship added||related to 0008289|
|2018-06-19 17:58||fman||Relationship added||child of 0008303|
|Copyright © 2000 - 2019 MantisBT Team|