Worksoft Certify: Reuseable Processes with Looping Recordsets

The Problem of Recordset Placement

In our example, let say that we have a standard Certify process (test case) for called VA01_Create_Sales_Order.  Imbedded within that process is a sub-process called VA01_sub_Item_Entry.  We want 2 variations of these with different data, so we’ll have a total of 4 recordsets.  For sake of brevity, lets call the recordsets:

• RS_SO_Stock
• RS_SO_Stock_Items
• RS_SO_Direct
• RS_SO_Direct_Items

If we assigned the recordsets directly to the processes, we would have to change those recordsets each time we ran one of the test cases.  A problem here is that somebody may not realize that there is a sub-process that needs to have its recordset changed as well.  This could be really problematic if we had 2 testers executing different scenarios at the same time since the assigned recordset gets saved right before you execute.

Solution

The answer for the overall sales order recordset would be to create a super-Process for each of your scenarios.  You would attach the overall recordset RS_SO_Stock or RS_SO_Direct at the super-Process level, and that process would have VA01_Create_Sales_Order as the only process within it.
This still leaves the problem of getting the right recordset attached to the item entry sub-process.  An elegant solution to this problem is to use a variable as the recordset name for the sub-process.  In your overall recordsets, you would set that variable to the proper sub-process recordset name RS_SO_Stock_Items or RS_SO_Direct_Items.
The image below shows where to set the recordset variable name for the sub-process.  You will add this variable as a field in your overall recordsets and fill with the appropriate recordset name.