| || |
Hi. I want to include an additional field in the Test Step design which would contain the list of all possible requirements. I found a list called "Requirements". How can it be used?
Re: Requirements list
That list probably is empty. It is a relic from very old versions of the tool (up to version 6 if I remember well). I would recommend to not use it.
Re: Requirements list
Conventionally, one maps requirements, releases, and test cases together, rather than individual test steps. This is because steps can often include non-requirement-oriented instructions like "Open a web browser" - and because steps cannot be divided into smaller parts, it makes sense to put the most granular information to the step.
Regardless, each testing project, client, system, process, and need is unique. You should be able to add a custom field to your test step, and populate it using a custom list. These custom lists can be populated manually by an administrator or dynamically via workflow code. You'll need access to the Customization module to do any of this.
If you want this requirements population to be dynamic, then one would need to sync the requirements list with the custom list. So essentially, one would clear the list, loop through the relevant Requirements, then populate the list with each requirement.
Here is a function that should get you started. I haven't tested it, but it is fairly close to we're using currently for other syncing operations - so it should work (im sure all testers have heard that before).
<font class="small">Code:</font><hr /><pre>
Set tdc = TDConnection
Set cust = tdc.Customization
Set currentLists = cust.Lists
Set currentList = currentLists.List(""&strListName)
Set rootNode = currentList.RootNode
'clear the list
Set childrenList = rootNode.Children
For Each child In childrenList
'get requirements - pass a filter to NewList to filter reqs. This gets all reqs.
Set reqFactory = tdc.ReqFactory
Set requirementsList = reqFactory.NewList("") 'get all reqs
For Each requ In requirementsList
'save changes to customization
Keep in mind, this approach could cause problems if multiple requirements have the same name - as lists don't have a great deal of flexibility - and cannot handle duplicates.
This also assumes that all requirements go in a single linear list off the root node. If you want a treeCombo box, then change the code to add reqs to the appropriate nodes/childnodes.
I'd seriously consider working with the out of the box approach first, however, as it may save you headaches in the long-run. This would mean associating requirements at the testcase/release/requirements level and not per step.