Generative AI-Based Testing Certification

Your Progress: out of 27

Reusable Rules

A reusable rule is a step or sequence of steps which can be called into a test case by a name or description given by the user. Reusable rules are designed to exponentially increase productivity in test case creation and preemptively decrease overhead maintenance. They are also key in involving non-technical, non-testing, or high-level team members (e.g., product managers) into testing.

The most common application of reusable rules is for frequently performed sequences that apply to several scenarios.

login
click "Men Clothing"
scroll down
click "Men's cargo shorts"
click "brown"
click "Size 34"
click "Add to cart"
check that page contains "Your order is nearly complete!"

go to checkout page
check page contains "Add to cart"

• Save – will simply save the steps included in the rule
• Save, then Find and Update Name – will save the steps that have been changed and search for any test cases using the rule if the name of the rule has been modified, inserting the new name of the rule into the cases where the rule was found.
• Save, then Find and Replace Steps – will scan for the test cases that contain the steps in the rule and provide the option to replace those steps with the rule name.

Replacing the steps in a test case with rules preemptively decreases maintenance because changes to a rule automatically apply to all the test cases where the rule is used, so there is no need to refactor all cases individually.
You can also use rules inside 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

It is possible to create rules that have the same steps but need different values to replace certain variables. Double quoted "" strings within the rule name will replace variables of the same name in the script. To simplify, let’s take the steps we used to parameterize the login rule above.

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

customUser and customUserPwd are variables in the steps, so if we add these steps to a new rule and name the rule sign in as "customUser" using "customUserPwd" as the password, whatever is placed inside the quotation marks when the rule is used inside of a test case becomes the value of the variables inside the rule steps.
In other words, if we modify the rule name in the script to be sign in as "[email protected]" using "abcd1234" as the password, the variables customUser and customUserPwd will be replaced by the values user@example and abcd1234, respectively.

It is also possible to use variables to replace the double-quoted strings:

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

Since information like passwords are sensitive,, it is recommended to use a hidden variable for passwords in test data so that they will not be revealed.

Auto-apply rules

Auto-apply rules were created to deal with unpredictable circumstances (e.g., ads and popups that may appear at different times in the same flow). To create an auto-apply reusable rule, there’s a section below the steps called “Fields related to auto-apply rules and auto-discovery.” Open this section and enable “Auto apply on every step of every test case”

All we need to know to compensate for the unpredictable circumstance is something unique about the page when it occurs, like text on the popup or even the container name of the popup. That information can then be used as the pre-condition that triggers the auto-apply rule.

When this feature is used, steps do not need to be written in test cases, but rather they are added to the test case automatically when the preconditions are met. This means that a conditional check must be done on every single step of every single case. To optimize the time of runs of suites that contain auto-apply rules, as the image shows, you can also set how many steps the auto-apply rule should be considered. In this case, 0 = every step from start to finish.

Another mechanism to optimize time is the ability to define how many times an auto-apply rule can be applied each time a test case is executed. If the case uses the auto-apply rule the number of times specified, testRigor will no longer perform the conditional check for the pre-condition regardless of the step number limit.

Empty rules

It is possible to create reusable rules that do not have any steps. This feature specifically was created to allow project managers to define specifications for testers. This is especially useful in a BDD framework where tests are designed before the platform that will be tested. This also helps in the case where project managers want to copy and paste the scenarios from their test management tool.

Just add the rule names into the test case steps and upon executing the test, you will see the option to create an empty rule. Project managers can fill out as many scenarios as they desire, and testers can focus on filling in the specifications of those scenarios.

Note: With all types of rules, it is recommended to use standardized language so that everyone on the organization’s team understands it and there is no confusion.

Using test cases as reusable rules for dependencies

In short, a dependency is a test case that needs something to happen before it runs in order to be executed successfully. This is possible using test suite hooks or API calls for setup. A less efficient way to do setup for one test case is with another test case. testRigor was not built to encourage the use of dependencies on other test cases. We encourage optimizing speed; test suite hooks and API calls still allow as test cases to run in parallel, but dependencies on other test cases do not, which means much, much longer full runs.

That said, some users insist on dependencies, and reusable rules are the way to accomplish it. An entire case can be put into a reusable rule, so to create dependencies, put the cases into rules with organized names. Once the rules are ready, they can be added sequentially as steps in a test case.