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

Additional statuses manually via database

Hi,

there’s a limit of how many statuses can be used - there’s a few “system statuses” and seven “custom statuses” that are initially disabled. There’s no way to add a new status. There’s the option of adding a new one through the database.

My question now is: are there any known problems that arise if I were to create a 13th status? I have already noticed an error (just a “notice”) on the “Test Runs & Plans” tab. But looking at the line in the source code makes it seem like something that has nothing to do with statuses?

I don’t think 12 statuses is enough. For example, if a testing strategy changes and different statuses are needed, you can’t just rename the old ones as that would also affect pre-existing test runs. I would disable the old ones and create new ones. But that’s not possible.

@dj91

Can you give us an example of what statuses are you using? Theses statuses are pretty default to what is the status of a test case. I can’t imagine using even one of the custom statuses (Passed, Blocked, Untested, Retest, Failed seems as everything you will ever need as a status :smiley: ).

We heavily use test automation and have the following non-standard statuses:

  • Passed (with limitations) - a minor deviation from what’s expected, but PO says that’s ok for now
  • Failed (Accepted) - a bug, but it won’t be fixed for the upcoming release (only “Failed” means that the bug either needs to be fixed or a decision is still needed)
  • Retest - when test automation executes a test plan/run again, all test cases that will be executed will get status “Retest” until the new results are available (the API doesn’t allow to set a test back to “Untested”)

The first two are set manually when we assess the result of the automation run or for manual test runs.

Since we have been using TestRail for some time, we also have some old status types that we don’t use anymore, but we can’t just rename them as that would influence previous test runs. So now we’re very close to running out of status types.

We don’t have any plans on adding new ones anytime soon, but I’m tinkering with the idea of giving “iteration” executions (one test case executed with different parameters) their own status, which would add a new “Passed” and “Failed” status.