SaveLink updates SaveTest: requirements tracing, branch analysis, and run planning
The SaveTest testing management platform has received five groups of new capabilities: requirements tracing, change-impact analysis, identification of problematic tests, run-distribution planning, and expanded integrations. Requirements are imported from Jira or Confluence, or added manually, and are displayed in a coverage matrix. The system compares test cases across different branches, showing additions, changes, and deletions, and lets users immediately build a run from the changed cases. Separate reports identify cases that found defects, successful cases, and flaky tests whose results vary even though the code hasn't changed. • **Requirements matrix** — import from Jira and Confluence, tracking of links to test cases, export to Excel and CSV • **Branch comparison** — analysis of added, changed, and deleted cases with differences displayed • **Run planning** — distribution of cases among executors based on the actual duration of past runs
AI-processed from CNews; edited by Hamidun News
The SaveTest testing management platform has gained five groups of new capabilities, unveiled by SaveLink in October 2026. The update covers requirements tracing, change analysis between branches, defect and flakiness reports, run-distribution planning, and expanded integrations with popular development tools.
Requirements tracing and coverage matrix
The new requirements registry integrates data from three sources: Jira, Confluence, and manual entry directly in SaveTest. The coverage matrix visualizes links between requirements and test cases, flags requirements without linked tests, and shows the latest run results. This approach makes it possible to track coverage completeness and quickly spot gaps. The matrix can be exported in Excel and CSV formats and can be placed as a separate widget on the dashboard for ongoing monitoring of coverage status.
Change-impact analysis between branches
SaveTest lets users compare test cases across two branches, displaying added, changed, and deleted cases. For changed cases, the system shows differences in name, execution steps, classification tags, requirement links, and iteration membership. This is especially useful for assessing the scope of regression testing. From the added and changed cases, a user can immediately build and launch a test run. The feature is supported both in classic projects and in Git-linked projects.
Defect and flakiness reports
A new report on the case library for a selected period groups results into three categories. The first includes cases that detected defects in the code. The second contains cases that ran successfully without finding defects. The third represents flaky cases whose results varied between pass and fail even though the underlying code didn't change. Flagging flaky tests is critical for improving automation reliability and reducing false positives.
Run-distribution planning
A new tool automatically distributes test cases among executors based on the actual duration of past runs. Before saving the assignments, the user sees the number of cases, the expected execution time, and the projected workload for each participant. This makes it possible to optimize workload balancing and improve resource management. After confirmation, the assignments are recorded in the test run.
Expansion of existing features
Import from Allure has received several improvements: selection of a Git branch for importing results, the ability to disable uploading of screenshots and logs to speed up processing of large archives, an increased report size limit, automatic updating of the iteration set on every upload, and propagation of Python class tags to all tests in that class.
The Git project sync settings now include an option to specify the directory containing the tests.
The test case editor has gained the ability to paste images directly into case text, new filters by custom fields and AI-assigned results, support for multiple keyboard shortcuts for a single action, selection of the export format for classic projects, and a jump to the run from the statistics block.
The dashboard now allows moving widgets and resizing their width, with the layout saved. Epic reports are now generated on the epic's page based on the runs it includes.
The set of MCP scenarios has been expanded with tools for working with the requirements matrix, comparing branches, planning runs, analyzing flaky tests, and parsing failed autotests. These scenarios make it possible to automate routine test-management operations.
Key Questions Answered
What are the key details on Requirements tracing and coverage matrix?
The new requirements registry integrates data from three sources: Jira, Confluence, and manual entry directly in SaveTest. The coverage matrix visualizes links between requirements and test cases, flags requirements without linked tests, and shows the latest run results. This approach makes it possible to track coverage completeness and quickly spot gaps. The matrix can be exported in Excel and CSV formats and can be placed as a separate widget on the dashboard for ongoing monitoring of coverage status.
What are the key details on Change-impact analysis between branches?
SaveTest lets users compare test cases across two branches, displaying added, changed, and deleted cases. For changed cases, the system shows differences in name, execution steps, classification tags, requirement links, and iteration membership. This is especially useful for assessing the scope of regression testing. From the added and changed cases, a user can immediately build and launch a test run. The feature is supported both in classic projects and in Git-linked projects.
What are the key details on Defect and flakiness reports?
A new report on the case library for a selected period groups results into three categories. The first includes cases that detected defects in the code. The second contains cases that ran successfully without finding defects. The third represents flaky cases whose results varied between pass and fail even though the underlying code didn't change. Flagging flaky tests is critical for improving automation reliability and reducing false positives.
Build & Ship Production AI Apps with Vibe Coding
Join Zhemal Khamidun's hands-on Vibe Coding Intensive at hamidun.com/vibecoding — master Claude Code, Cursor, and autonomous agentic workflows.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.