Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Trusted Contributor.. bton99 Trusted Contributor..
Trusted Contributor..
495 views

New versions of requirements show coverage and status of OLD version

We have an issue with ALM which is currently causing a major headache.

In a version controlled project Requirements are version controlled.

BUT.

Coverage (by Test plans), execution status (of those tests), and defect linkage, is NOT included in Version control.

As an example.

A requirement says that “The value must be XYZ”

You create a test (TC 123) for this, with coverage linked.

You run that test, and find that indeed the Value is “XYZ” and so the test passes.

The REQUIREMENT will show that it is Covered by TC 123, and that the requirement status is “Passed”

 

Now, somebody decides the value should in fact be ABC.

So you “up-version” the requirement to Version 2, in which you edit the requirement to say that “The value must be ABC”

 

But this requirement will continue to show that it is Covered AND passed – by the test that checked for XYZ!

 

Are we missing something in the way we use ALM? How can we get round the limitation that a new version of a requirement appears to be ignored?

0 Likes
5 Replies
sheyenne Outstanding Contributor.
Outstanding Contributor.

Re: New versions of requirements show coverage and status of OLD version

My understanding is that is by design.  It is stated in the User Guide that Coverage (by Test plans), execution status (of those tests), and defect linkage, are NOT included in Version control.

 

You have a point though that when a requirement is edited, it shouldn't reflect that that same requirement was successfully executed.  Though again, the design of the ALM tool is such that the coverage status of a requirement will reflect on the latest and greatest execution of it's associated test.  So the logic doesn't account for when the requirement is locked out or not.  Perhaps, that is something that HP could take into consideration when re-designing or revising the new version of the tool.

0 Likes
Highlighted
Trusted Contributor.. bton99 Trusted Contributor..
Trusted Contributor..

Re: New versions of requirements show coverage and status of OLD version

Thanks Sheyenne,

 

I think it probably is 'by design', but can't help feeling that this design doesn't work in the way one would expect ( or at least that I expect).
My basic assumption is that if you change something it should NOT automatically be flagged "The same as..."

At least with Version controlled tests, any RUN is tagged with the test plan version actually run
so you can build in some sanity checks to ensure that the Latest version of a test has been run, though even that is un-necessarily complicated.
But at least to me it appears the Requirements versioning leaves a lot to be desired.

 

Our solution at the moment seems equally bonkers - but at least it does work for us.
Our unique identifier for Requirements is a text field, with the format ("Unique_string_for_requirement_V##)
where V## is V01, V02 etc.
When we need to up-version a requirement we in fact copy it and create a whole new entity.
And we then edit the unique identifier field and increment the V##
The new requirement is automatically marked Not_covered, and Not_Run,
but by simple search on the "Unique_string_for_requirement" part we get all the details of the previous 'Versions' and their coverage.
And can then force a re-link to test plan, check if test plan still valid etc.

 

Actually, while the process is true, the reality is all of this is much easier to achieve in other tools than in ALM, so we DO NOT (or CANNOT) use ALM for requirements management. We use an external system and push changes into ALM (via OTA) for test traceability, and in that the process is more or less automated.

 

Now,  if anybody has some better solution that we've missed, where we could use ALM with Version control for  Reqs management, we'd love to at least try to use ALM for Requirements management, but for now haven't seen anything to suggest that ALM is good for that task.

 

 

0 Likes
Contributor.. WiscoWorm Contributor..
Contributor..

Re: New versions of requirements show coverage and status of OLD version

You have a process problem here.  When a requirement is changed - you should create and/or update your test case.  The fact that you are updating the requirement and NOT the test case is the process problem (not Tool problem).  Leave the requirement at version 1.0.  Go to the test case and make a copy of it and update it to be version 2.0 with ABC instead of XYZ.  Link that test case now version 2.0 to the requirement.  Once you establish that new updated test case to the requirement, your requirement converage will change to Not Completed. 

0 Likes
Trusted Contributor.. bton99 Trusted Contributor..
Trusted Contributor..

Re: New versions of requirements show coverage and status of OLD version

Hi WiscoWorm,
Thanks for taking the time to reply.

Just to clarify, Of course, yes, if a requirement changes to a new version you have to edit the test case to match the requirement. And yes we do update the tests, so there isn't a problem, and certainly no process issue there.
BUT, my problem is- there is no trigger in the Tool to flag a need for that Test case rework.

At least as far as I can figure out, ALM does nothing to highlight that the requirement has even changed - in terms of test management and traceability to test coverage - apart from a record in history of some fields changing.

It blindly - and incorrectly - retains the linkage to the previous coverage and execution.
(I say incorrectly because if there was a need for a new version of the requirement then there must be some substantial change, so assuming the old one isn't right )
It's the fact that it retains the incorrect information that really makes it a problem.

 

So as regards changing the tests - ALM actually doesn't care whether you do or not. You and I know we need to edit the test - ALM does not.
Hence, as you describe for the test case rework, you need to 'remember' or have some manual process to trace the old requirement to its tests and work on those before your new version is covered correctly, or at least flag the need for that rework.
We could even, relatively easily, code a trigger so that if a req version updates, all tests that cover the previous version are flagged in some way.

Hey, guess what - that's the job of a requirements and test management tool. Thats th efunctionality I really think is missing in ALM.  A requirement has changed and the TOOL chooses to ignore that change in its coverage traceability.
Therefore I maintain it is completely a tools issue.
That is not requirements management, or lifecycle management in my book.
That is "Here is a basic repository, and if you put in place your own process you can use it for Requirements coverage management, but I, the tool will not help you."

I'm still hoping that it's not as bad as I'm seeing it, and that someone more experienced in ALM than myself can say -
"Why are you not using the blah blah functionality in ALM - that does all the traceability you describe".
Anyone?

0 Likes
Contributor.. WiscoWorm Contributor..
Contributor..

Re: New versions of requirements show coverage and status of OLD version

You are missing the functionality known as RTM or Requirements Traceability Matrix. I am using ALM 12.01. With that functionality, you can see which requirements map to what test cases and therefore the impact of what needs to be modified in your test suite as a result of a changing requirement. Also, you need to enable the auto email functionality that will alert someone when a requirement is being modified. 

Do you have a testing team or are you by yourself looking for this tool to tell you everything?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.