It's all about the answers!

Ask a question

Why "no items found" when "Coverage" selected under RQM requirements collection


Stuart Jewell (16915) | asked Oct 06 '15, 11:31 a.m.
edited Oct 06 '15, 11:39 a.m.
Using RQM/RRC 4.0.1:  After adding a requirements collection to test plan, selecting "View As" >> "Coverage" returns "No Items Founds".  Is this a known issue?  It seems like this may be a clue why I'm not able to reconcile requirements to test cases properly.  (i.e. in other posts have mentioned "Requirements that are no longer in plan since last reconciliation" when requirements are in plan, or Reconciliation Failed Due to Exceptions...with following exception example:  Unable to load /qm/proxy?uri=https%3A%2F%2Fffx-rtc-app.<my domain> %3A9443%2Frm%2Fresources%2F_0591f9b795674c9a8b56d2972ecc6b56 status:406

Comments
Stuart Jewell commented Oct 06 '15, 11:34 a.m.

Correction!  We're using version RQM/RRC version 4.0.3 and not 4.0.1

5 answers



permanent link
Brett Bohnn (94111153) | answered Oct 23 '15, 10:55 a.m.
Hi Stuart,

I have never seen " Negative time is not allowed" and did not get much from a Google search. Below is a har taken while adding and saving a requirements collection link to a test plan.

It may be best to simply start with a PMR that describes the problem, with a link to this forum post and the application logs (at least qm.log* and rm.log* files). We can assist with the collection of the .har as needed and we may need to look at increased logging for the rm.log

One question to also answer in the PMR - have you tried creating a new LPA project as a test and checking the behavior of linking when adding a collection or module to a new test plan?



permanent link
Brett Bohnn (94111153) | answered Oct 16 '15, 2:36 p.m.
Hi Stuart,

I think you need to collect these items and then open a PMR that references this forum post.
Please open the PMR from IBM SR PMR

1. Firebug trace from RQM taken while you add a module or collection to a test plan and save:
a.) Install firebug for Firefox
b.) Install NetExport for firebug from NetExport (just grab the latest version)
c.) Start firebug, go the NET tab in Firebug, reproduce the problem, use Export > Save As JSON to save a .har

2. The qm.log taken at the same time

3. The rm.log taken at the same time

4. Screen shots of module added to the test plan and the "no items found" from "View As > Coverage." It could also help to show screens shots from the RDNG links section of the module, which should be missing the validated by links

Thanks,
Brett

Comments
Stuart Jewell commented Oct 22 '15, 5:10 p.m.

Brett,

When generating Export file, HAR validator stated " Negative time is not allowed:" for about 5 different lines.  Is this normal?

Stuart


permanent link
Brett Bohnn (94111153) | answered Oct 15 '15, 2:08 p.m.
Hi Stuart,

This defect is fixed in 4.0.2 but is the same symptom https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/78326

As I noted in my last post, you may need to do a Firebug trace as described in that defect work item.

Thanks,
Brett

Comments
Stuart Jewell commented Oct 16 '15, 1:35 p.m.

Brett,

I still get "No Items Found".  I created a use case module based on our standard use case template which already had sample requirements.  I created a collection and included new module.  I created a new sandbox test plan and added collection to requirements collection.  When selecting "View Aa" "Coverage", I get "No Items Found".  Let me know what steps I need to take with Firebug if need be.


permanent link
Brett Bohnn (94111153) | answered Oct 14 '15, 10:20 p.m.
Hi Stuart,

You wrote "isn't the "Coverage" only suppose to drill into the "Use Case" artifact types associated with the collection and retrieve only those artifacts that are identified as "Requirement"?

I have both a module and collection linked to this test plan's requirement collection links and view-as > coverage shows headings, graphical artifacts, business rules, etc. It shows all of the artifacts in the collection and module.



As a simplified test, can you create a new module, add 1 artifact of type requirement to that module and add that module to the requirement collection links section of a new test plan. Then view as > coverage - do get "no items found" or do you see the requirement and its module?

I am not sure yet if something like a Firebug trace (Firebug is an Firefox add-on) from RQM while adding a module/collection to a test plan will be helpful (e.g. to see if there are any obvious exceptions). I don't see anything in the capture I ran that references the validated-by links but I will look closer.

Thanks,
Brett

permanent link
Brett Bohnn (94111153) | answered Oct 06 '15, 11:12 p.m.
Hi Stuart,

I have 4.0.3 installed and did a quick test to see if there is possibly a reproducible problem.

I am familiar with "View As > Traceability" which does show the "validates requirements collection" link when browsing test plans (if the test plan has a requirements collection link). I just don't yet see "Coverage" for "View As." I will do a bit more search. In the meantime, if you go to Planning > Browse Test Plans do you have "Traceability" in the "View As" drop-down? 

Thanks,
Brett

Comments
Stuart Jewell commented Oct 07 '15, 3:16 p.m.

Brett,

Firstly, thanks for looking into this.  I do have "Traceability" in the "View As" dropdown" for test plans.  When doing this, it highlighted another aspect of my issue.  The "View As" "Coverage" in test cases basically worked in the past.  On other test plans when I added a requirements collection (our collections are mostly use case modules), it would display the actual list of use cases rather than a link to the requirement collection.  This can be seen more clearly when using the "View" "Traceabilty" when browsing test plans.  In the ones where "View As" "Coverage" displays something, it's where the use cases are displayed rather than when just a requirements collection link is displayed:
Example:
"Product X Release Test Plan"      "12345: Requirements Collection Name"
VS.
"Product Y Release Test Plan"        "(1), (2), (3), (4), (5),...." where each one of these numbers is a link to a use case within a requirements collections


Stuart Jewell commented Oct 14 '15, 10:46 a.m.

Brett,

Here's an interesting update on our issue that we are still having but now seem closer to what may be wrong with back links etc. A portion of our problem appeared to be with browser caching (using Firefox...issue was discovered by switching to Chrome).  So now some items show up for "View As" > "Coverage" under "Requirements Collections Links".  What is showing up are file types in the collection identified as artifact type "Sketch".  Isn't the "Coverage" only suppose to drill into the "Use Case" artifact types associated with the collection and retrieve only those artifacts that are identified as "Requirement"?  Otherwise, we will never get our traceability to work correctly if not back linked to the requirements.  The "Collections" in this instance has:  1 module of type "Requirements", 4 modules of type "Requirement Specification", 2 files of type "Sketch", 14 modules of type "Use Case".  All are stored under project "root" folder.


Stuart Jewell commented Oct 14 '15, 11:21 a.m.

Brett,

Yet even more discoveries and final root problem.  By looking at the use cases that were correctly linked through requirements collection link in test plan, each use case module had a "Validated By" link that was created when the collections module was added to the test plan. So the actual current problem is that when now when we add a collection, the system is not creating the "Validated By" back links from the use case modules associated with the the select requirements collection.  If these are manually added from the use case side, then the use case shows up.  However, we obviously would like this to work correctly from the test plan perspective so that we do not have to manually add the links from the use case side.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.