Hi,
As soon as we can hope for flexible tree depth for Test cases, why not make Requirements Tree too as in Test Director? In that case, it would be rather simple to write macros for whole structured documents import to Requirements as well as to Test Cases. The present flat structure makes this job only manual.
If I was Test Link author , I would keep Reqs and test Cases in the same tree (and DB table) as Reqs also require additional fields - at least for notes.
The reqs_coverage entity will be nice if also will have Decription field with link description. In that case, coverage entity will also serve as Requirement Dependency to link dependent requirements mutually - almost whole Requisite Pro!!!
Your idea about requirement tree is some issue we have discussed on the development team.
About your suggestion of using the same table for testcases and requirements
I disagree.
At least for the first rounds of release of 1.7, there is no place for doing
changes in the requirement feature, because we have a lot of features
to re-write and improve in the Test Design and Execution areas,
that are our priority now.
Please note that the requirement struture is not as flat as you suggest,
only have two levels.
If you want to help with development just contact me or other developer
and we can assign you some piece to develop, with our mentoring
As a general rule, trees are not the best way to organise things. (You may have notice the success of tags.)
Specialy, it is important to be able to select, filter, choose the field that matters to you, print, export and so on.
So a tree may be usefull, but it should not be the only entry point. Actualy, there are no other way for test cases and even for requirement than to go throu the tree (even if it is only 2 level for requirement). As such, it is a limitation.
It should always be possible to have a flat list (like the one on Mantis for example).
Hi,
yes, but anyone knows that no-one can ever force the damned customers to use any requirements management system. So if we work with reqs - all we can is to support some mirrors of all this Word stuff (in best case). And most specs ARE trees from structure point of view.
By \"mirrors of all this Word stuff\" you mean Chapters ? The Table of Content is a tree, OK. But why keep this material limitation when we can be free to organize as a flat list, sortable, filtrable (?), selectable ...
At least allow many trees (facelets classification ?) ; allow multiple level (recursiv) and allow the tests to be put in the leaf or in the root.
Actualy, you can put everything as component and category. You could even use component as a first level requirement and categories as second, third, .. level requirement ...
There is no forced semantic to the actual tree. (that puzzled me at first !)
So we can agree that trees are OK as long as they don\'t introduce a limitation or a forced path to the tests.
, I would keep Reqs and test Cases in the same tree (and DB table) as Reqs also require additional fields - at least for notes.