View More Details
GitLab self-managed instances.
Azure Git Repos on cloud and private hosting.
Organize and arrange fields on the create, detail, and bulk operations screen for every module.
Customize separate field layouts for the create, detail, and bulk operations screen.
Copy field layout across module screens to maintain consistency.
Create sections and group similar fields for better visibility and accessibility of fields on the screen.
Show/hide or expand/collapse sections by default to enhance performance.
Introduced multilevel requirement review workflow to ensure that the linked test cases are authored to cover all use cases of the requirement.
Add one or more users at each level if there are multiple reviewers in the organization.
Review or request changes to requirements using bulk operations.
Define a multilevel workflow hierarchy to approve/request changes to the test cases and test executions.
Authorize one or more users at each level if there are multiple approves in the organization.
Approve or request changes to test cases and test executions using bulk operations.
Requirement Reviewer Workflow Status - View requirement, its linked test cases, and execution status along with their review and approval details.
My Pending Requirement to Review - List of requirements pending for review at my "Level" or my review.
My Pending Test Cases to Approve - List of test cases pending at my approver level for action.
My Pending Test Execution to Approve/Close - List of test executions pending at my approver level for approval/closure.
Filters applied on folders, system, custom, or Jira fields on the module are carried forward to the bulk operations.
Fields enabled on the module grid are also enabled while selecting records on the bulk operations screen.
The folder archive/unarchive actions are directly available from the folder tree structure.
QA Managers can make build selection mandatory to ensure testers assign test executions against a build.
QA Mangers can set a default build for a release & cycle combination so that test executions are auto assigned an intended build, so that testers do not have set them manually.
Now testers can assign a build for an individual test case execution. This helps when test cases in a same test suite are executed against multiple builds.
Now view test case executed build information in the Test case - Test Execution details section along with other execution details.
Easily filter test cases that are not planned for execution for a combination of Release and Cycle
Hide test cases already linked to a test suite to avoid duplicate linkage of test cases
Latest search filters will be preserved on link test case to test suite screen
View More Details (v8.3.1)
View More Details (v8.2.2)
View More Details (v8.2.1)