Generative AI-Based Testing Certification
Managing Multiple Environments
testRigor gives testing teams the flexibility to run the same test cases on different environments. This can be done in several ways, so the right way depends on the development team’s structure.
Create branches from the UI
testRigor allows users to create a branch from the UI. A branch is basically a copy of the main version or baseline that runs without making permanent modifications to that baseline. To do that in the testRigor UI, go to Test Suite Details, click Additional run settings, and fill in the Run name, Branch and Commit fields. To change the environment from the one currently in the URL field, simply type the URL of the desired one in the same field before triggering the run with the Rerun button.
The great thing about branches is that all run will be executed behind the scenes, so testers can continue to build new scenarios or modify older ones while a branch run is in progress. To see the progress of a branch run, go to All Runs and find the run in progress with the run, branch, and commit names that were added.
Copying test cases
It is possible to copy test cases from one suite to another. When copying test cases, the test data and reusable rules are automatically copied as well.
To copy test cases, go to the Test Cases section and click Select multiple, then select all the desired cases. You can select all at once or use search filters to help locate them and click Copy.
The Copy button will open a popup that will provide options to select the test suite where the case should be copied and whether the test data and reusable rules linked to the case should be overwritten in the destination suite.
*Note: Only rules and test data with the exact same name will be overwritten. If a rule has changed steps, the steps will be overwritten if this is enabled. If the rule name has been changed, a new rule will be created.
Shared test suites
testRigor also has a mode of managing environments that allows users to inherit test cases, rules and/or test data from another test suite, which we call the parent suite. For example, you may have to create a suite for an Android application for which you have already created an iOS suite. After creating the new suite, go to Shared Suite and select the assets you wish to inherit from the parent suite. It’s important to understand that the parent suite is selected from within the child suite.
Sharing facilitates environment management because child suites can borrow only what they need from the parent while also keeping their base URL, test data, and rules unique to one environment. At the same time, cases in all child suites are maintained by modifications made in the parent suite, so there is minimal overhead no matter how much projects scale.
Once paired, new test cases, test data, and/or rules added to the parent suite will automatically appear in the child suite with a tag called “Inherited.”
A common scenario arises when the information for a shared child test suite needs to differ slightly from its parent. In such a case, you can create a new rule or variable in the child test suite using the same name to handle discrepancies. This new rule or variable will override the inherited one and will be specific to the child test suite.
*Note: A parent can be the parent of many suites; however, once a suite becomes a parent, it cannot become a child of a different suite.
Trigger from CI/CD
Test suites can be integrated via the use of API calls. testRigor provides pre-populated Bash or Powershell scripts in the CI/CD section to trigger different sets of actions. CI/CD APIs allow users to trigger baseline, branch, and label-based runs. In addition, users can modify most settings and even maintain repositories of their test cases in the CI/CD tool of their choice.
