Here at TestRail Towers we know how important it is to be able to supplement the design and results of your testing with screenshots, gifs, documents and other artefacts. Attaching that information to your test cases and inserting it into fields so it can be viewed alongside instructions or testing results are important capabilities for any tester. And so, it’s with great pride that we announce TestRail 7.1, containing a range of enhancements intended to make life easier for attachment power users – and everybody else!
This will be a phased release, so if you don’t notice the new features in your TestRail Cloud instance just yet, hold tight—TestRail 7.1 will be coming your way soon!
The TestRail 7.1 release contains improvements to the attachments dialogue throughout TestRail, geared towards more flexible and intuitive use of attachments when creating test cases, runs, plans and milestones, and when adding results or pushing defects to your integrated tools.
To make life easier for administrators, we also added a new attachment management area in the administration console, and included a filter to help you identify exactly which attachments may be ripe for pruning.
We also fixed a bunch of issues along the way, and made some performance improvements under the hood… Keep reading for the details!
One of the main things you’ll notice in 7.1 is the new attachment dialogue when it comes to uploading attachments to your TestRail entities (cases, runs, plans, milestones, test results, and defect pushes where supported).
The dialogue introduces the idea of a media library. In addition to simply uploading artefacts and attaching them to your test cases in an ad-hoc fashion (‘scuse the testing pun!), your attachments now become part of a library from which they can be re-used in future.
As such, the dialogue includes a number of other features intended to support the use and re-use of attachments across TestRail entities, including across projects if needed. You can upload attachments to the attachment library by browsing your local filesystem or drag-and-drop.
As you build up a library of attachments, you can sort through them to find the attachments you need by Date, Name or Size. You can also search for a specific attachment(s) by name—and to make that easier, we’ve added the capability to change the names of your attachments by clicking on the attachment and viewing its details:
The Attachment Details view opens a wealth of further information and adjustment opportunities. You can:
We think you’ll agree: that’s all pretty swish.
In addition, you also have the ability to refer to an attachment throughout TestRail, and update the referenced attachment in all places using the Replace function.
But that’s not all…
In TestRail 7.1, we continue to improve the administrators’ lot by introducing a new attachment management console in the Admin area. If you have a hosted TestRail Cloud instances, you’ll see that as of 7.1 we’ve split out the data functions onto different tabs within the Data Management menu:
On the new Attachments tab, administrators will also be able to carry out all of the actions available in the improved attachments dialogue, with the benefit of being able to see all attachments across all projects.
Which means that administrators can also take advantage of the search and filtering mechanisms to prune attachments from their instances if they’re no longer needed, helping to reduce the storage footprint of the instance.
While adding these features, we’ve made some significant changes under the hood of TestRail, implementing a whole new database structure for the management of attachments to improve performance and help make sure that attachments can be searched and filtered for effectively.
For our hosted TestRail Cloud customers, no actions are required to take advantage of this benefit. It’s all done in the background for you.
For server customers, some additional installation requirements need to be followed to enable the configuration of a Cassandra database.
We’ve made a few adjustments to the attachment API endpoints as well.
By popular request, we’ve added run_id, plan_id and plan_entry_id’s to the associated get_attachments_for_run, get_attachments_for_plan and get_attachments_for_plan_entry endpoints.
We’ve improved the behaviour of the various add and get attachment endpoints so that they align better with what we’ve come to understand is the (still somewhat complex) expected behaviour:
Other things to mention here are that the ID of the attachments returned via get_attachment endpoints has changed from a simple integer to a reference:
{
“attachment_id”: “2054f652-fe2f-4542-acb0-422910ed87e3”
}
You’ll also see some additional attachment metadata fields in the attachment response bodies. Please do check the attachments API page for further details.
Whilst carrying out these improvements, we fixed or tweaked behaviour in a number of other places too:
© Copyright 2000-2023 COGITO SOFTWARE CO.,LTD. All rights reserved
