My Certificate Find a Certificate About Certification QA Terminology Basics of Software Testing Basics of Test Automation QA Processes Overview Basics of testRigor BDD & SDD Web Testing Overview Mobile Testing Overview Native Desktop App Testing Overview API Testing Overview Click / Drag / Hover Entering Data Variables Validations Scrolls and Swipes Dealing with Dates and Times Dealing with Emails Working with Tables Conditional Sequences Cycles & Loops Reusable Rules SMS and Phone Calls Managing Multiple Environments Settings Integrations AI and Prompt Engineering AI-Driven Test Case Generation with testRigor Using AI Coding Agents with testRigor Final Exam

Generative AI-Based Testing Certification

Managing Multiple Environments

Managing Multiple Environments

An environment is a version of an application used for a specific purpose.
For example, Developers might use a Development environment to build new features, a Staging environment to test changes before release, and a Production environment for the live application that users interact with.

Although these environments may have different URLs, test data, or configurations, we often want to run the same tests across all of them. testRigor provides several ways to do this, depending on how your project is structured.

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.

Use Case

Imagine your test suite normally runs against your staging environment, but you want to run the same tests against a different environment without changing your main test suite configuration. A branch run allows you to run those tests separately with different settings while keeping your baseline (the URL your test suite normally uses) unchanged.
For example, your baseline might use: https://staging.example.com
While your branch run could temporarily use: https://development.example.com

This allows you to test another environment without permanently changing the URL of your main test suite configuration.

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.

Use Case

Imagine you’ve already built a complete test suite for your staging environment and now need a separate suite for production. Many of the same tests, such as login, checkout, and account management, may still apply. Rather than recreating them, you can copy those existing test cases into the new production suite.

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 need to create an Android test suite after already creating one for iOS. After creating the Android suite, go to Shared Suite and select the assets you want to inherit from the iOS parent suite. It’s important to understand that the parent suite is selected from within the child suite.

In this example, the iOS suite would be the parent and the Android suite would be the child. Since the Android application may use many of the same tests, such as: Search for a product , Add product to cart , Complete checkout .
The Android suite can inherit these tests instead of maintaining separate copies. Changes made to inherited tests in the parent will also be reflected in the child, reducing maintenance as the project grows. The same applies to reusable rules and test data. New shared assets added to the parent will automatically appear in the child with an “Inherited” tag.
If something needs to be different for Android, you can create a rule or variable with the same name in the child suite to override the inherited version and will be specific to the child test suite.

*Note: A parent can have many child suites. However, once a suite becomes a parent, it cannot become the child of another suite.

Trigger from CI/CD

testRigor can be integrated with your CI/CD pipeline, allowing your automated tests to become part of the development process.
Instead of someone manually opening testRigor and starting a test run, a CI/CD pipeline can automatically trigger your tests when something happens in the development process.
For example, when developers deploy a new version of an application to the staging environment, the pipeline could automatically tell testRigor to run the staging tests.

testRigor provides APIs and pre-built Bash and PowerShell scripts that can be used to set this up. These can trigger baseline, branch, and label-based runs, as well as modify various test suite settings.

Test your knowledge

When you need to start a new project from scratch
When you need separate rules for each test suite
When you want to re-use your production environment test cases from a test environment
When you want to make major changes to a test suite
When you want to isolate a test suite from others
Modify the inherited test data directly
Delete the inherited test data and create a new one
Create a new rule or variable in the child test suite with the same name but different content to override the inherited one
Disconnect the child suite from the parent suite
Rename the inherited test data
© testRigor. All rights reserved.