Global variables and data sets are a great way to replace values used at multiple points in the test suite with a single variable. Actually, it is not just about the variables in particular, a lot of things in automation testing point towards eliminating repetitive work using method A or B. For instance, we introduced programming into testing just to replace the repetitive manual actions of a tester and hand this responsibility over to the computer. At a granular level, now we look forward to optimizing the code (or instructions in no-code automation tools) and eliminating repetitive pieces. Global variables are an example of this and so are reusable rules in testRigor.

In this post about reusable rules in testRigor, we will expand our learnings of the last post to implement the same concept but on a larger level. With headings reflecting the definitions and practical demonstrations, the reader can expect the following major sections:

• What are reusable rules in testRigor?
• How to create a reusable rule in testRigor?
• How to use reusable rule in testRigor test case?
  • How to change the reusable rule in testRigor?
• How to create a reusable rule after test cases?

What are reusable rules in testRigor?

Global variables help us define one variable that can be used in several places. The variable is replaced by the defined value at runtime and we get the control of editing this value everywhere from a single place. In short, for example, when we need to change a URL in 100 test cases, all we need is to make a single change. However, to understand further, let's look at the complete instruction set for two test cases:

Test case 1

• open url stored value "loginURL"
• enter stored value "username" into "UserName"
• enter stored value "password" into "Password"
• click "XYZ"

Test case 2

• open url stored value "loginURL"
• enter stored value "username" into "UserName"
• enter stored value "password" into "Password"
• click "ABC"

In the above two test cases, in the first one, we log in and click a button called "XYZ". For the second test case, we log in and click a button called "ABC". In both of these test cases, multiple instructions are exactly the same. Now, let's say in the future, your organization changes "UserName" to "UName". For a tester, it will become a day's job to change this in hundreds of test cases using the Login feature. What if we get another such requirement the next day? This repetitive work can be tiring and not advisable since it often leads to costly errors. It is also just plain inefficient.

Reusable rules in testRigor help us avoid such situations by replacing the entire instruction set with one rule. Since this rule is used again and again, testRigor terms it "Reusable" and the alias we provide for these test steps is termed a "Rule". This is very similar to the Global variable but instead of a single value, we replace the entire instruction sets that play a part in a test case. As a result, efficiency is increased as all we need to do is make a single change whenever the requirement changes.

How to create a reusable rule in testRigor?

Creating a reusable rule is a simple process in testRigor. For this, we take the following steps:

First, sign up on testRigor or Login if you have already done so.

Create a test suite where these reusable rules will be implemented.

Select "Reusable Rules" from the left panel:

Here, the screen is divided into two sections. The left section is for displaying the list of reusable rules and filtering them (if there are too many) to find one:

Since currently we do not have any rules added, this section is blank for us. The right section, on the other hand, is used to add the reusable rules in testRigor:

This part has three input fields to fill:

• Name: The name of the reusable rule the tester wishes to assign.
• Labels: This field takes the label name to attach to the rule. There can be more than one label attached by separating it with a comma. It helps in identifying the theme of the rule (like Login) and gets attached to the test case in which this rule is used.
• Steps: The steps that will be replaced when this rule name is encountered in the tests.

Let's fill these input fields with suitable values as follows:

• Name - AFW (For Alerts, Frame & Windows)

• Label - AFW

• Instructions -

• open url stored value "URL"

• click on "Alerts, Frame & Windows"

• click on "Browser Windows"

These three instructions navigate to the Browser Windows page on DemoQA. We want them as a rule because they will be used repeatedly in various test cases. Also note that in the above rule, we have also used Global variables.

Click "Save" to save the reusable rule. It will appear on the left side panel.

We are now ready to use it in the test cases.

How to use reusable rule in testRigor test case?

To use the rule we created (by the name "AFW"), we need to edit our test case and insert the rule there. For now, let's consider our test case does the following:

• Open the demoqa home page.
• Click on Alerts, Frame & Windows.
• Click on "Browser Windows".
• Click on the "New Tab" button.

For this, we write the instruction set in testRigor test case as:

• open url stored value "URL"
• click on "Alerts, Frame & Windows"
• click on "Browser Windows"
• click on "New Tab"

We can observe here that the first three lines are similar to our reusable rule. So, we can replace these lines with rules by writing AFW directly instead:

• AFW
• click on "New Tab"

Execute this test to verify the results:

We have successfully optimized the test case instruction set. Similarly, consider there is one more test case where we execute all the same steps except that for clicking the "New Tab" button, we wish to click the "New Window" button.

Since we know all the steps will remain the same, we can directly use the rule here:

AFW

click on "New Window"

Executing both test cases shows positive results.

This is how we can use reusable rules in testRigor test cases and reduce repetitive code. You can observe that the label we used in the rule is also attached to the test case. It will help us identify the usage of this test case without opening it. For instance, when I see "AFW", I know it will be opening the page Alerts, Frame & Windows while in execution.

How to change the reusable rule in testRigor?

Apart from eliminating repetitiveness, the next main strength of reusable rules we discussed is increasing the efficiency of the tester to maintain the test cases. To demonstrate this part, let's jump back to the "Reusable Rules" section from the left panel and make changes to the steps here.

Let's consider that the requirement has changed to moving on to the "Browser Windows" section. The new requirement is to go to the Alerts, Frame & Windows section only from the side panel and not from the home page directly. This means we need to first navigate to some other element and then select Alerts, Frame & Windows from there.

For now, we choose to go from the "Forms" element. So our reusable rule changes to:

• open url stored value "URL"
• click on "Forms"
• click on "Alerts, Frame & Windows"
• click on "Browser Windows"

Save this rule by clicking the "Save" button and execute test cases again. This time the new steps will be taken into account without making changes to all the test cases in all places (or even opening any test case). It significantly cuts down time and therefore costs associated with maintenance.

How to create a reusable rule after test cases?

In the above section, we created a reusable rule in testRigor and then used it in the test case. However, a lot of the time you may find yourself in situations where there are already a few test cases previously created, and you need to convert them into rules. Doing this manually one by one is not a great solution. For this, testRigor gives us an explicit option which we will see below.

First, we need to have a test case with a pre-written instruction set and for which no rules currently exist:

Now, to create a rule with instructions already used in the above test case, select "New Rule" from the "Reusable Rules" panel:

Create a rule with the instructions discussed above:

To save the rule, we have three options:

• Save
• Save, then Find and Update Name
• Save, then Find and Replace Steps

The first option will just save the rule and there will be no reflection of it in the test cases. The second option is in a disabled state because we did not change the name of an existing rule.

The third saving option not only saves the rule, but also finds its usage in all the test cases and replaces the steps accordingly. So in a way, we don't even need to open any test case and all our changes completes even if we have a thousand test cases in our test suite. For our situation, this is exactly what we need.

Click on Save, then Find and Replace Steps. This will search and ask for our confirmation with the list of all the found test cases:

To replace, select "Replace Selected". Now head back to the test case and verify that the changes (Steps as well as Labels) reflects there:

With just a couple of clicks, we can refactor all of the test cases and eliminate all the manual work in the test suite maintenance.

What's next?

Automation testing is not just about putting instructions and executing them on the system at any time we want. While script writing does take time, it is often a one-time job. Later, our time will go into maintenance and debugging. Therefore we should make sure to stay efficient and our tests are optimized. testRigor is known for needing minimal test maintenance compared to other tools, which partially comes from test stability and partially from the mechanisms provided to optimize the process. Global variables and reusable rules are two concepts that help us shorten this time and reduce project costs. The lesser repetitive code we have, the faster we will be able to maintain it.

In the next chapter, we will stick to avoiding repetitiveness and focus on how we can avoid executing the same automation script again and save it to run on different projects instead of creating it multiple times.