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

Set TestCase status back to "untested"?


Adding my vote to not only allow setting back to untested, but also provide additional statuses to customize. Sometimes you do make a mistake and just need to set the case back to untested.

In my case, I previously re-purposed ‘untested’ to represent more of a default ‘new’ case due to the way it reports (in our world there is a difference between new and untested). Now, I have used all available statuses and have a new critical one that needs to be added so I have to sacrifice an existing one. To do this I am trying to move a batch from a current status over to the untested status before I re-purpose it. (FYI, this is another missing feature, the ability for a master admin to batch move tickets from one status to another at the project level). Since you can’t set cases back to ‘untested’, I am not able to do this and now have no way to make this status field change successfully.


Thanks for your feedback, happy to add another vote! TestRail can have up to 7 custom statuses and have you used them all already? Maybe you could use one of the built-in statuses instead?



Thanks. Unfortunately we are actively using all 12, the 5 system statuses and the 7 custom statuses.


Do you have the option to combine a few of them? Or maybe use additional custom fields to track additional information?



I’m still not able to set status back to “untested”. When will this feature be implemented? Please add my vote for this feature request. Thanks!


Hi there,

Thank you for the feedback. I have gone ahead and added your vote for this.


This is one major issue that a tester cannot continue the execution for same test run after saving. This gives a false impression that the test was run multiple times when in actuality it was due to product shortcoming.

Please add my vote for this feature to be implemented. Not a great user experience.


Hi Swati,

Thank you for the post. I have gone ahead and added your vote.


I am relatively new to TestRail and have been wondering about this test status as well. We use steps in our test runs and there are times when all Steps pass with the exception of 1. I created a Pending custom status but it doesn’t really pend it.
It seems also that once I start a test run but can’t finish it that day but would like to continue it the next day, the overall status is set to Passed and I cannot change that status but have to perform a re-run? Is this correct functionality or hopefully I am missing some step?
thank you.



Thanks for your reply! You can use a custom status (e.g. you can create an ‘In Progress’ status) that can be used for situations such as these where you’re unable to complete the test. You can then just add a new result to take over where you left off and override the ‘In Progress’ status with the completed status. TestRail would always use the most recent result status that has been submit for reporting/metrics, and you can include any comment as needed in the final result to clarify the result history as needed (e.g. in case some steps were completed on one result and the rest on the other). Hope this helps!



Hi guys,

I think this is an important feature that should be added. The issue with using custom statuses is that they count towards the overall completion percentage of the test run/project. If we mark a TC incorrectly there should be an option to revert the status to untested so it is excluded from these stats. Our workaround was to create a custom status called ‘Untested’ but this is included in the final stat.

We have marked this as ‘Not a final status’ in the customisations section but it still seems to count as an executed case. What is the significance of this field?


I would like to add my vote to this as well.

If a defect is blocking several Untested tests, then you would naturally set them to blocked.
Once the defect is removed, you would want to set them back to their original state of Untested.
Retest doe not make any sense, as you haven’t started testing them.

If they were blocked mid test execution, then In Progress or Retest.


Been 4 years so I doubt this is getting changed, but it’s irritated me me enough during those 4 years to up-vote this. Not going to create a custom field to represent the name of something that already exists simply because the back-end does does’t jive with the front-end. Re-test means…well, re-test it. As in, you tested it >= 1 times before. Not “whoops I need to undo this, that wasn’t actually tested” like we all need this for.


+1 same re-test means it was already tested. untested means never looked at it.


We would like this option as well - to be able to set a test back to Untested. Would help when a test was incorrectly set to a status but it truly hasn’t been tested yet.