Generative AI-Based Testing Certification

Your Progress: out of 29

Reusable Rules

A reusable rule is a step or sequence of steps saved under a name that can be called from a test case.

Reusable rules are useful for actions that are performed frequently across multiple test cases.

Reusable rules can make test cases easier to create, read, and maintain. If the steps inside a rule need to change, you can update the rule once and the change will apply wherever that rule is used. They are also key in involving non-technical, non-testing, or high-level team members (e.g., product managers) into testing.

For example, the first 7 steps below walk through selecting a product and adding it to your cart. If multiple test cases require these same steps, you can save them as a reusable rule instead of rewriting them each time.

login
click "Men Clothing"
scroll down
click "Men's cargo shorts"
click "brown"
click "Size 34"
click "Add to cart"
check that page contains "Cart (1)"

Next, go to the Reusable Rules section in testRigor, name the rule add item to cart, assign the label “shopping-cart”, and add the first 7 steps above. Labels are automatically added to test cases that execute the rule, making them easier to organize and filter.

Once saved, you can execute all 7 steps by calling the rule by name:

add item to cart
check that page contains "Cart (1)"

Upon creating the rule, you will notice three options:

Save: Saves the rule and its steps.
Save, then Find and Update Name: Saves the rule and, if its name has changed, finds test cases using the old name and updates them with the new one.
Save, then Find and Replace Steps: Finds test cases containing the same sequence of steps and lets you replace those steps with a call to the reusable rule.

Replacing repeated steps with reusable rules makes maintenance easier. When you update a rule, the changes automatically apply to every test case that uses it, so you don’t have to update each test case individually.

Note: You can also use reusable rules within other reusable rules.

Built-in rule

testRigor has a built-in rule called login, which uses credentials stored in Settings->Authentication->App-specific Authentication. Alternatively, if the user adds the variables username and password to the test data, either global or data set, those will override the credentials in the settings.

Another very common way to parameterize logging in would be setting the variable before executing the rule as follows:

save stored value "customUser" as "username"
save stored value "customUserPwd" as "password"
login

testRigor’s login rule is flexible in the sense that it figures out how to login for most login scenarios regardless of the individual steps that different user flows may have. The exception where the login rule may struggle is when there are several types of users (e.g., admin, non-admin, etc) and one must be selected on the login screen before entering a username and password. Even in this case, if the user type is selected first, the login rule should work if entered after.

Parameterized reusable rules

Sometimes you may want to reuse the same sequence of steps but with different values. Instead of creating a separate rule for each set of values, you can create a parameterized reusable rule.

A parameter acts as a placeholder. Double-quoted values in the rule name can be used as parameters, and the values provided when calling the rule will replace the corresponding values inside the rule’s steps.

save stored value "customUser" as "username"
save stored value "customUserPwd" as "password"
login

These steps can be saved as a reusable rule named:

sign in as "customUser" using "customUserPwd" as the password

Here, "customUser" and "customUserPwd" act as parameters.

When the rule is called from a test case, you can provide different values for them:

sign in as "[email protected]" using "abcd1234" as the password

"customUser" is replaced with "[email protected]" and "customUserPwd" is replaced with "abcd1234" when the rule executes.

You can also use stored values as parameters:

sign in as stored value "user1" using stored value "user1Pwd" as the password

Best practice: Sensitive information such as passwords should be stored using hidden variables in test data so that their values are not revealed.

Auto-apply rules

Auto-apply rules help handle unpredictable events, such as ads or popups that may appear at different points during a test.

To create one, open the “Fields related to auto-apply rules and auto-discovery” section below the reusable rule’s steps and enable “Auto apply on every step of every test case.”

Next, define a precondition that triggers the rule. This could be something unique to the popup, such as its text or container name.

You can control how long testRigor checks for an auto-apply rule and how many times the rule can run.

Apply at first: Defines how many test steps testRigor should check for the rule’s precondition. For example, a value of “20” means testRigor will check the first 20 steps. A value of “0” is a special case, meaning testRigor will continue checking for the precondition throughout the entire test case, no step limit.

Imagine your test has 100 steps and you have an auto-apply rule that closes a popup.

If Apply at first is set to 20 steps:

Step 1 → Is popup here? No
Step 2 → Is popup here? No
Step 3 → Is popup here? No
...
Step 20 → Is popup here? No
Step 21 → Stop looking for the popup

If you set it to 0, testRigor keeps looking for the popup for the entire test.

Step 100 → Is popup here? No

Apply at most: Defines how many times the auto-apply rule is allowed to run during a test case. Once the rule has run this many times, testRigor stops checking for its precondition.

If Apply at most is set to 2 times:

Step 1 → Is there a popup here? No
...
Step 5 → Popup appears → close it (1st time)
...
Step 12 → Popup appears → close it (2nd time)
↓
Maximum reached → stop looking for the popup

So even if you told testRigor to check for the popup for all 100 steps, after it has closed the popup twice, it stops checking.

Empty rules

Reusable rules can be created without any steps inside them. This allows someone, such as a project manager, to define what should happen in a test without having to define exactly how it will be automated yet.

For example, a project manager might want a test case with the following scenarios:

Login as a customer
Add a product to the cart
Complete checkout

This can be useful when tests are being planned before the automation has been built, such as in a BDD workflow. It also allows project managers to bring scenarios over from a test management tool and let testers handle the actual implementation.

To create an empty rule, add the rule name directly to the test case: Login as a customer. When you execute the test, testRigor will recognize that the rule does not exist yet and give you the option to create it as an empty rule.

Later, a tester can open the rule Login as a customer and fill in the actual steps needed to perform that action:

enter stored value "username" into "Email"
enter stored value "password" into "Password"
click "Login"

This allows one person to define what the test should do, while someone else can later define how those actions should be performed.

Note: When creating reusable rules, try to use consistent and standardized language. This makes the rules easier for everyone on the team to understand and helps avoid confusion.

Managing test case dependencies with reusable rules

A dependency occurs when a test case requires another test case to be completed before it can run successfully.

Test Case 1: Create a new customer account
Test Case 2: Place an order using that customer account

Test Case 2 depends on Test Case 1 because the customer account must exist before an order can be placed. Therefore, the tests must run sequentially: Create customer → Place order

Whenever possible, testRigor recommends using test suite hooks or API calls to perform the required setup instead. For example, the required customer could be created through an API before the order test begins. This makes the test independent of another test case.

With independent setup, multiple tests can run in parallel:

Test Case 1: Create customer through API → Test placing an order
Test Case 2: Create customer through API → Test updating an order
Test Case 3: Create customer through API → Test cancelling an order

These tests do not need to wait for one another and can run at the same time, reducing the total execution time.

If dependencies between test cases are necessary, an entire test case can be converted into a reusable rule. The rules can then be called sequentially within another test case to ensure they execute in the required order

By grouping each dependent test into a reusable rule, each part of the sequence remains organized as a separate unit. If a step fails, it is easier to identify which rule in the sequence failed while still maintaining the required execution order.

login
create customer
place customer order
process customer payment

Generative AI-Based Testing Certification Your Progress: out of 29