One of the challenges with automated testing is building your test scripts or processes at the right level of granularity to allow for reusing them over and over in different scenarios. The Worksoft Certify automated testing tool is built around the idea of object oriented test scripts and reuseability. The ideal test script can be used to satisfy many test scenarios by simply feeding it different data. This article will discuss how to deal with data (recordsets) within an SAP and Certify context in such a manner that you can maximize reuseability of your scripts with the least amount of tweaking required at the time of script execution.
Setting the Stage
Take for instance 2 separate test cases. Each test case utilizes SAP t-code VA01 (Create Sales Order). Each of the sales orders being created will have 1 or more line items. To get multiple line items on a sales order through Certify, you typically create a recordset that contains multiple line items that will loop at the specific point of entering the line items. This recordset cannot be the overall recordset for the sales order since the multiple line items would end up looping the entire transaction, resulting in multiple Sales Orders instead of multiple Line Items. So ultimately, we will need 2 different recordsets for each of these test cases. One recordset will be the overall recordset for the entire sales order, excepting the line items. The second recordset will contain the line items that will be looped through in the line item entry sub-process.
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:
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.
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.
Feel free to share any tips and tricks or references you have in the comments below!