Which method are people using to review a RQM Test Plan?
Our team is currently investigating different methods of reviewing a RQM Test Plan and have come up with three generic options. The three methods we are investigating are:
These options obviously have their pros and cons so I am looking to get feedback from other RQM users regarding the method used to review a test plan and appreciate any pros and cons of those methods.
Thanks in advance
- use the RQM built in review function
- PRO - review process handled by RQM, no other tools needed
- CON - comments go in a review comments section and not in line with the text or section the comment is for
- export the test plan to a pdf and use external review tools
- PRO - can take advantage of other review tools
- CON - test plan in pdf format and can require many steps to work with other tools or where comments can be added in line with the text
- use Rational Publishing Engine to create a customized version of the test plan and test cases and then use external review tools (haven't used RPE but thought it may help us get around the issue of exporting to pdf)
- PRO - provides more control over the content of the test plan and test cases and resulting file format
-
CON - requires another Rational tool for users to access, still need a tool for reviewing the test plan
These options obviously have their pros and cons so I am looking to get feedback from other RQM users regarding the method used to review a test plan and appreciate any pros and cons of those methods.
Thanks in advance
Accepted answer
Hi Matt
We use number 1. I think you are probably asking this more because of traditional test plans have a lot of what I would call "boilerplate stuff" in them. That makes reviewing them harder as you describe. Test plans are really containers of test cases and execution plans with objectives. We consider the "meat" of the plan to be the test cases and they go through a separate review/approval process with development and other interested parties. Once they are approved they are considered as "fixed objects" until someone opens a workitem or task asking for the test case to be enhanced or modified - then it goes through another review/approval process. The test plan review becomes simpler to review because you can look at the requirements the test plan claims to validate, are the appropriate test cases associated with the test plan to validate those requirements and do you have the right mixture or coverage of test environments.
The review allows for comments and responses to the the comment much like what is done in work items. I am an approver of test plans and I will not approve a test plan until test plan owner has addressed all comments by responding to each comment in the review section and the reviewer has agreed by approving his/her review.
By exporting the test plan which 2 and 3 do - you lose this type of dialog or you have to manually have to re-enter it. It takes time for some people to get used to this methodology but they adapt - we have been doing it this way for over 5 years now and it is generally accepted by our users.
Dave
Comments
Hi Dave,
I understand your reasons for using RQM's built-in review function for reviewing Test Cases and can see the advantages of doing it that way.
I do have a couple of questions about how you handle the 'boilerplate stuff'
- do you include the information considered to be boilerplate in RQM or in a document external to RQM?
-
how do you review the boilerplate information?
Matt
2 other answers
Matt ..
I agree with Dave .. Go with 1 . For the cons ... we have created new section by name "Detailed Review" and included a table like below , with this you can keep reviewer comments in line with sections.
I agree with Dave .. Go with 1 . For the cons ... we have created new section by name "Detailed Review" and included a table like below , with this you can keep reviewer comments in line with sections.
|
S.no |
Section |
Review Name: Comments |
|
1 |
Test case Design |
User1 : design is not clear , include Topology diagram Testplan Owner: included diagram |
|
2 |
Summary Section |
User2 : Summary section has many typos TestPlan Owner: made the correction |
|
3 |
Test schedule |
Manager: Schedules are tight , keep some buffer Testplan Owner: Milestone testing consumes one week , buffer given for regression testing
|
