New option for rules to "Disallow parallel execution"
We’ve introduced a new option in the Additional Fields section (formerly “Fields related to auto-apply rules and auto-discovery”) that allows customers to disable parallel execution for reusable rules.
When this option is enabled, any tests using the rule will run sequentially—each test will wait its turn to take ownership of the rule before proceeding. This ensures safe and conflict-free execution for scenarios where parallel access could cause issues.
Important Considerations:
Performance Impact: Disabling parallel execution will slow down the test suite, as affected tests will no longer run concurrently.
Nesting Restriction: Rules with parallel execution disabled cannot contain other rules that also have parallel execution disabled. This prevents issues and ensures predictable test execution.
You can find this option in Reusable Rules -> Additional Fields.
Caption: Disallow parallel execution location.
Copy and Sync Test Cases Between Folders in Azure DevOps (ADO) and Other External Systems
We’ve introduced a powerful new feature that allows users to copy and sync test cases from one folder (e.g., Folder A) to another (e.g., Folder B) in Azure DevOps (ADO) or other external systems like Zephyr or TestRail. This enhancement ensures that test cases retain their links to external systems during the copying process, maintaining integration consistency.
Key Requirements for Link Synchronization:
For a test case to retain its external link when copied, the target suite must have the same configuration setup for the integration system as the source suite.
For example, if a test case is linked to an external project in TestRail, the target suite must also have active integration with TestRail configured for the same project. Without matching integration settings, the test case will be copied, but its external link will not appear in the newly created test case.
Caption: Links copy option.
Caption: Link copy result.
“Wait until page is non-blank before proceeding” new setting
This new feature allows users to customize how testRigor responds when a page takes longer than expected to load, ensuring greater flexibility and control over test execution.
How It Works:
By default, testRigor stops execution if a page remains blank and fails to load within the specified timeout. However, with this new setting, you can adjust the behavior based on your testing requirements. The available options include:
Default Behavior: Stop execution if the page never loads or remains blank without any elements.
Generate an Error or Warning: Log an error or warning but continue executing the test suite.
Skip Waiting: Proceed with test execution without checking if the page has fully loaded.
This setting is particularly useful for scenarios where delayed page loads are expected or where partial loading is acceptable for testing purposes. You can configure this feature under Settings -> Speed Optimizations.
By leveraging this new option, you can reduce unnecessary test failures caused by slow-loading pages and tailor your tests to match real-world performance expectations.
Caption: Wait until page is not blank location.
Caption: Comparison result using the new setting.
Caption: Comparison result not using the new setting.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article