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

General Improvements about Test Plans


#1

I’ve been using TestRail for almost 5 years, and Test Plans are still painful to use for our team.

  • We are often adding new suites to our Test Plan and need to re-organize them. It’s tedious to click up & down arrows, when we have the ability to Drag cases and Sections within the Suite itself. It would help us a lot if we could click and drag Suites within the Edit Test Plan area too.

  • We have team members who have their own ways of doing things, and this is one thing that I’ve struggled with since the beginning. When we have new features or bugs that require a new test case, they only get Automatically added to the Plan if the Suite is set for “All cases”, OR require us to MANUALLY edit the test case if we select out cases that aren’t needing to be tested.
    We have people who like a clean workspace and will pre-select the cases, which leads to MANY edits of the Test Plan, and also increases the events of multiple, simultaneous edits. But, if I try to leave it as “all cases” for convenience, a lot of times they will get confused with all the extra, unneeded tests, and well… this causes friction sometimes.

What I am suggesting, and this might even be a bug, I don’t know… is that when we “Select Cases” and select the Checkbox for a whole Section, that any cases that get added to that section also get added Automatically/Instantly to the Test Plan. This alone would make everyone here happy, and a lot more efficient, and also keep our analytical pie chart a bit more accurate.


#2

The second point is also a problem with Test Runs as well. Point one may also be present in Test Runs but I am part of a small team and generally never need to reorder the cases in the run. If that needs to be done then I need to actually change the case list in the specific project itself.

I believe there is also a request out there to make it possible to change how it currently works.


#3

Yeah, we have a small team also, but we have a very large project. Our suites are broken down into smaller functional areas, and our test plans are built around areas that are being ‘touched’ by a release. As more cases are added to the release, or resolved to us for testing, we have to add to adapt our Plan, and also refactor/add cases too.


#4

Hi folks - I plan on looking at these kind of issues with the team for potential inclusion within TestRail 6.0, early next year.

If you’re open to having a more in-depth discussion/interview about the context for your request(s), I’d be very happy to schedule something.

Cheers,
Simon


#5

I would be open to it, yes. I don’t see any harm in trying to help improve things for my team, and it might benefit others too. I learned a saying, “The worst kind of improvement is a silent one.”

Is there a main discussion topic for 6.0 plans already? I tried searching for one, but came up empty.


#6

Hi - no, there isn’t a 6.0 discussion topic. I normally do interviews by way of a conference call.


#7

And do you do that for several people at once, or limit it to one user? How can we know what to discuss if we don’t even know what you’re contemplating :-)?


#8

Hi George - with several people, or an individual. It depends on the team and organisation.

Normally I’m just trying to get a sense of context; understand how the specific team or individual is using TestRail, what challenges they face, what they like and don’t like - that kind of thing. Then we might drill down to some specifics, and cover off any feature requests.


#9

@sjpknight: It would be an honor to have a chat about how we use TestRail for our testing, and these couple of common hurdles we face.