Actions v/s Functions?

When implementing automation for real projects using QTP, one question that puzzles many framework designers is whether to use Actions or Functions?

Well in this article I will be discussing the challenges associated with the use of Actions and why I personally prefer using Functions over Actions. The article is only based on my professional experience and personal opinions about the subject. One may or may not agree with the same

Before we start it is important for us to understand difference between Action and Function.

An Action is a feature of QTP while Function is a VBScript feature. An Action can have associated DataTable, Object Repository, Input/Output Parameters and return values. Functions on the other hand can only have input/output parameters (using ByVal or ByRef) and return values.

Consider the details on an Automation project which needs to be implemented

• No. of scripts = 1200
• No. of Unique code components (Re-usable + Non re-usable) = 500
• Shared object repository with all objects
• All scripts to be stored in HP Quality Center

First we will assume that we use Actions to implement the above project

• The 500 re-usable actions that need to be created can be stored using different approaches

1. One re-usable script per Test: We can store each re-usable action in an individual script. The problem with this approach though would be that finally we would have around 500 (hosting re-usable actions) + 1200 QTP scripts in the suite
2. Store all re-usable actions in a Single Test: We can store all 500 re-usable actions in a single script. The problem with this approach is the Test containing all actions would become huge in size and any small corruption in the same can lead to disasters as it would require re-linking of all actions used in script
3. Store multiple re-usable actions in scripts base on category: Assuming avg. 10 re-usable actions per script, we would have 50 scripts supporting these re-usable actions. This is better than above 2 approaches

• To create the test case we need to make calls to external re-usable actions. The path to the test needs to be provided in such a case. One can provide an absolute path of the test where the re-usable action resides. But this creates a huge problem when the scripts containing re-usable actions are moved to a different location. This problem can be sorted out by using relative paths of the Test instead of an absolute path.

Now consider the challenges we will face using the above action approach

• While debugging a test we come to know that one of the Actions needs to be updated with some additional code. To do so we will have to close the current script and open the script containing the re-usable action. Update the code and save the script. Then re-open the script which we were debugging and re-run the script. If during re-run we realize that there are few more changes required then we would have to repeat the process. This make maintenance a painful task
• When upgrading QC or moving actions from one location to another location there is a risk of QTP scripts giving error in missing actions in missing resources pain. This would require to open each script and fix the issue
• Since we are using shared object repository, each local object repository would be empty. When we use a blank action (No Code + No Local OR) the size occupied by the Action is 197KB. This means for 500 actions we would have ~96MB of space wasted for no reason. This is a huge overhead when using QC as the scripts are downloaded from the QC server to the local machine

To summarize the key challenges we faces using Actions are

• Painful maintenance as QTP doesn’t allow opening multiple tests at the same time
• Missing actions in script when moving re-usable actions from one location to another or QC version is upgraded
• Corruption of the script containing the re-usable action will require all the callee tests to update the call. This would require to open each callee script and fix the call
• Each actions consume additional 197KB of space

Now if we move to functions over Actions we can easily do away with above challenges

• Instead of action the code would be stored in Function. These functions would be present in the library files.
• QTP allows opening multiple library files at the same time. This makes debugging and maintenance also easier
• Functions will only take the space required for the script code and no additional overhead
• Functions are more flexible when it comes to re-usability

To conclude, Functions over Actions has many advantages and should be preferred in implementing any keyword or data driven framework