| || |
QC requirements structure: SV&V vs. Business (UAT)
There are currently two testing teams in our company. One is the SV&V team performing functional and non functional
testing. The second team is Business Support Services coordinating user acceptance testing. We are using Quality
Center for our test management efforts. The SV&V team is entering the requirements in QC. They are using the following hierarchy. Business requirements >> Functional Requirements >> Testing requirements.
The SV&V team has stated that we (Business Supp) cannot by any means enable traceability in QC. That is using their requirements structure.
In other words, we cannot trace UAT cases or UAT processes to the requirements they (SVV) created. They believe we can break their traceability/progress reports, etc.
What can the options be here?
Should we create a separate requirements folder (for UAT, using ONLY business requirements) that we can use for traceability purposes to our UAT cases/processes?
The above is what SV&V has recommended?
Should we create instead a bunch of high level business processes in the QC requirements space to use for traceability purposes to our UAT cases/processes in the QC Test Plan space?
In my views, the SV&V team can set traceability to their testing requirements and our team Business Support
can trace to business requirements only? Will this break traceability reports?
What would be the ideal scenario to go with?
Re: QC requirements structure: SV&V vs. Business (UAT)
Traceability is not “broken”, as long as requirements are linked correctly. We have defined different requirement types and icons for functional, business, and testing. At our site, business requirements “drive” requirements definition, and we link all other requirements to the business requirement. Selecting a business requirement in the Quality Center “Requirements Detail View”, displays affected requirement types in the “Requirements Traceability” tab.
In contrast, the “Trace To” section of the “Requirements Traceability Relationship tab” will list the business requirements affected by the selected non business requirements.
Are both testing teams participating in testing efforts for the same project? There is much to gain by the two teams working more closely together to determine overall project requirement coverage, instead of coverage by one testing team.
Hope this helps! It is not easy to communicate these concepts in writing.