Is there a way to improve the test case creation process?

Hi everyone!

I’m looking to get some ideas and inspiration around test case creation, as I feel our current process at work isn’t the best. I’d really like to do something to improve it, and I thought why not start by seeing what other testers do!

Currently at my work we use TestRail for our test cases. We create test cases for every single ticket we work on, and I would say about 90% of the time they are never used or looked at again after the ticket has been passed. For example, we may end up writing 5 tests for one ticket, and then reusing 0 of them.

The rest of the time the ‘most useful’ test case will be moved into our regression suite when the feature is complete, but these will usually end up needing a rewrite. We also carry out end to end testing when required, but again that normally results in taking the ‘most useful’ cases and then rewriting them so they actually are useful for testing.

I’m finding this to be lot of wasted time spent on admin, when we could be putting our energy into other things.
So i’m really interested to hear how other testers work and manage this part of the job - does anyone use a different process when it comes to creating and organising test cases, or use different tools? What changes would you suggest?



Have you considered moving away from scripted testing? Since it seems like it’s taking up a lot of time and it mounts down to a formality - test cases get designed but they are not executed continuously.

That’s what I did at one of my previous contacts, I was the only tester and writing test cases took way too much of my time, so I abandoned the traditional approach and went with just doing exploratory testing - I just had a small test set of smoke tests so anyone could go over those when I’m not around.



A place I used to work at also used TestRail for test case creation. While working there I tried out a few things (some worked, some didn’t). I would encourage you to get the team together (including devs) and discuss the current process for developing these tests, generate ideas for improvements and give them a go. If these ideas work, stick with them. I’d also recommend doing this regularly, maybe once a month or so, as improvement something is a continuous process and team members may get new ideas as time goes on.

Sometimes the issue isn’t just with creating the test cases, but the whole process of developing and testing.

Here are some things we tried out:

  1. Remove unnessessary information by improving the templates
    In test rail, you can create and edit templates. If you are using a default template, then it might not be the right one for your team and encourage you to include information that isn’t needed. Generate your own template based on information you actually need to include. If other information is needed, then add new fields that contain this information. Creating a new template should be a team task, so get the team together and discuss the template and ways to improve it.
  2. Create a template for exploratory testing
    Test cases can be exploratory based. Some testing needs to be scripted (in my experience, managers like to see evidence of what was tested so scripted tests are useful for documentation) but some cases testing can be exploratory and evidence of what exploratory testing took place can be just as useful if the right information is included. I created a template for scripted tests and another for exploratory testing. The exploratory testing template included a section that briefly explains what we’re testing, what we’re trying to find out, test ideas, suggested time blocks, and a section for briefly logging what was tested and what we discovered.
  3. Shift Left - start test planning/admin sooner
    Think about how you are managing your time. When do you start test planning? Planning can begin as soon as the ticket has been approved, and before the developers have started working on it. If you start planning and admin as soon as possible, then you will complete the work a lot sooner and avoid the testing bottleneck. When development is complete, and the work is ready for testing, think about how much faster testing would be if all the planning and documentation is already done. All you have to do is run through the test cases, add notes about the results, and you’re done.
  4. Look at how you organise past tests, learn from them
    You say 90% of tests aren’t looked at again. I have found referring back to past tests, especially if I’m testing something in the same area or with similar steps, can be useful when writing new tests. If you create an archive of past tests, with the tests categorised or tagged with things like feature name, then these tests can be easier to find and that past knowledge can be reused on new tests.

With one-off tests / ad-hoc tests you can usually skip creating test cases in my experience. It is better to start a test session so you can plan/design the details to test and also add the findings/notes/results at the same time. There are different tools to manage test sessions, and most traditional test case tools only focus on test cases.

E.g. here’s what test sessions look like in Testmo (full disclosure: Testmo founder here), which we support besides test case management and automation. But there are also other tools out there, so this is just an example:

1 Like

@tiermo : This is the basics issues that we all are facing and the way I handled this and also got success.

  1. Re-usability: For every Single ticket , check if test case exist or not , if not then only create new test case. This will solve issue that test case will not phased-out and team know where and what to update
  2. Re-usability-Add Step: Sometimes for new dev ticket , we created new test case where as test case already exist , so rather then creating new test case , add step to the existing test case
  3. Use folder structure to maintain test case for example below and categorise test case related to feature in same folder so its easy to find old test case and to update
1 Like

This is typical at bad companies or teams. So, learn whatever you can from them and then get out as soon as possible. I know this story well. First you will write useless and trivial tests, get an over bloated suite and then spend time to remove the garbage on a regular basis. Repeat. I’d suggest that you only keep test cases which show all the crucial user flows. Also write self documenting automation tests to serve as test documentation. But, looking at your question I doubt if your company has automated tests or if they are even maintainable & readable. You could also make rough estimates of the time wasted with the old approach and present to your manager. If it fails to make any impact, then improve your skills and start preparing to interview. Such places are usually sinking ships with no chance of improving.

1 Like