Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Which Test Cases have been reviewed?

 This question would apply to Plans/Suites/Scripts too but I'm struggling to find a way to lets me view which test cases have been reviewed.  


If I'm looking at the filterable grid under Construction\Browse\Test Cases, there's several missing attributes that would be very helpful to sort and mass update on:
  • Reviewer(s)
  • Reviewed State
  • Approver(s)
I have test team that's writing test cases, and am trying to implement the current process:
  1. Test Engineer (TE) writes the initial Test Case draft
  2. TE adds Reviewer(s) to test case -> Design Engineers
  3. TE adds Approver(s) to test case -> Myself
  4. TE changes the state to "Ready for Review"
  5. Design Engineer adds comments and marks either "reviewed" or "Rejected".
  6. TE incorporates or rejects feedback.  
  7. Approver goes in to approve or Reject
From Steps 5 - 6 is where it's proving to be very difficult to find which test cases have been reviewed/commented.  I suppose that the author could wait for all test cases within a suite to be reviewed and commented on, but that doesn't seem to support the continuous engineering approach. 

Appreciate any help on this.  I can only envision a roundabout way where the design engineer becomes the approver, and has the ability to change the test case state after they're reviewing it, but I'd prefer not to go that route.  
Thank you!  

Tom

0 votes


Accepted answer

Permanent link

Hi Tom,

As of now, the only way to make sure the QM artifacts are reviewed/approved upon is by using the formal review process and setting the condition where in once the  approver after approving approves , automatically change the state of the artifacts to Approved. This can also be tracked via the history of the artifact.

Currently there are no out of the box facility available for the end user to look for these columns where the artifact is in the states mentioned below. However, I suggest you try creating global categories with these names and make these categories mandatory so that user undergoing the review process needs to fill the data under these categories and can also add these custom categories as columns while browsing the test artifacts.

  • Reviewer(s)
  • Reviewed State
  • Approver(s)


Global Categories Info :https://jazz.net/help-dev/clm/index.jsp?topic=%2Fcom.ibm.rational.test.qm.doc%2Ftopics%2Fc_organize_with_categories.html


Hope this helps,

Krupa

Tom Leser selected this answer as the correct answer

0 votes

Comments

 Krupa,


Thank you for the response.  I will have to do this.  It seems as though in the formal review section then, there is not much value for reviewers to set the state to "reviewed" or "Rejected".  

I found an enhancement that was logged by another user back in 2012, and still hasn't been implemented.  

I might explore using the excel exporter as a workaround for adding reviewers to the test cases too.  


3 other answers

Permanent link

0 votes


Permanent link

GlobalCustomCategory

0 votes


Permanent link

We went about resolving this problem in a different way. We changed the workflow so that it was like this:
Key:   (State)   [Action]
(Draft)    [Ready for Review] >  (Awaiting Review)  ... development complete but not yet submitted for review
[Initiate Review]  >  (Under Review)  ... formal review initiated (i.e. emails sent)
[Approve]  >  (Approved)   ...obvious
[Reject]  >  (Reopened)    ... instead of going back to draft where it would be indistinguishable from before being reviewed
The actual workflow we have implemented is a little more complex, defining the various allowed state transitions, but it illustrates the solution to the original poster's question.  I just wish that RQM came out of the box with a more workable workflow (the default is far too simplistic), rather than us have to invent our own and have to propagate the workflow to all the other artifacts.

However, there doesn't seem to be an obvious way to automatically trigger the [Initiate Review] action as a result of raising a formal review.  My colleague has raised this question as a separate article on the forum.

0 votes

Comments

Thanks Mike. Is your modified workflow going from Reject to Reopened?

Yes. It is important to be able to distinguish between artifacts that are in development (Draft) from those that have been reviewed and rejected (now Reopened, but formerly it would have gone back to Draft).

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,016
× 1,381
× 32

Question asked: Jul 24 '17, 6:22 p.m.

Question was seen: 2,935 times

Last updated: Jul 31 '17, 4:14 a.m.

Confirmation Cancel Confirm