Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.
 

Test Cases - Section list - Capability to sort sub sections


#1

We have currently created parent folder for Defects under which we are creating folders for individual defects. We know TestRail has facility to manually order it, but currently we have approx 2500 sections and more than 20000 cases. Now when we try to find section, it is getting difficult very difficult.

We think if this is available it will be useful in test runs as well for selecting cases easily.

Is there any feature so that we can sort the section list for sub-sections?


#2

Hi Anand,

Thanks for your posting. Have you thought about using a dedicated field to manage the defects instead of sections? This would make it easy to sort/order cases by defects and has some additional advantages if you manage the defects in an external system. For example, I can recommend looking into using the References field and this integrates well with external systems such as issues stored in JIRA, for example:

http://docs.gurock.com/testrail-integration/references-introduction

Cheers,
Tobias


#3

Thank you for your reply/suggestion. But I cannot use the extra field. My current structure is a below:

Defects [Section]
-> 1001-2000 [Section]
—> 1001 [Section]
---------> TC1, TC2,… [Test Cases]
—> 1003 [Section]
----------> TC1, TC2, TC3,… [Test Cases]
-> 2001-3000
----> 2001
---------> test cases
----> 2002
---------> test cases

So group of cases can only better managed using folders/sections and not with extra field.

Now consider that an old defect for which our cases are not written comes into testing. This time we need to create new section which always goes to end of the section. In such cases if that directly goes in sorted place then that can be best, but if not there there should some sorting mechanism which help the user in easy navigation.


#4

Hi Anand,

Are the sections/numbers the defect IDs? We would recommend reconsidering this approach to be honest and cases are often structured by functional area instead. You can manage defect IDs independently of this structure via the References field for example and this field also integrates with many issue trackers such as JIRA (so, you would be able to look up the issue details in TestRail or see linked results/cases in JIRA):

http://docs.gurock.com/testrail-integration/tools-jira
https://blog.gurock.com/testrail-5-0-jira-test-management/

You can then also easily order your cases by the defect IDs by adding the References field to the tables and clicking on the column header.

If the section approach works better for you, you can reorder your section/defects anytime via drag & drop and move the section to the suitable position in the hierarchy.

Cheers,
Tobias


#5

Generally cases are structured by functional area. Our regression pack is already in that form but it is not possible for defects. Grouping has to be done using defect ID only.

We already have more than 1000 defects (with few thousands cases for these defects). Sorry to say but what you are suggesting is not a solution.


#6

Sounds like it’s an issue with the way you have structured your tests within TestRail.

I don’t see why you’d want to / need to have a separate structure for Defects. Doing so would make it virtually impossible to see all of the coverage for a given functional area considering the defects would belong to a functional area too.

If your cases are structured by functional area, you could add a custom field to act as a flag so that each test can indicate whether it is part of your regression pack or not. You could do the same for Defects if you really wanted, but again it doesn’t make sense to differentiate between the two - it’s either part of regression, or it’s not.

It’s pretty easy to build up your Test Plan based on Filters within TestRail.


#8

Thanks for your feedback, Glenn. Yes, we would also recommend looking into restructuring this a bit. I’m sure there are good reasons why the structure currently is the way it is but a different approach as explained above usually works better in our experience.

Cheers,
Tobias