I just joined today. I have been hired as a freelance tester to write test cases for a company that has an existing TestRail database of test cases. The previous tester who set it up was fired because a major bug was missed, and I looked at the test cases and saw they were missing a lot, but still would like to incorporate some of the previous tester’s work into new test cases. I would like to split up some of them, because they were too complex and had multiple expected results in each test case. Does anyone know of a quick way to split them up by expected result, or will I need to copy them and selectively delete duplicate expected results?
how do you identify the cases?
How do they look like, “multiple expected results” or too complex doesn’t help very much…
One way might be to export the cases and analyse outside, but it depends how they look like…
It’s things like "navigate to this page and enter this info, and click this button - expected result login; enter invalid email address - expected result error message; after login, go to dashboard - expected result dashboard displays; click user profile button - expected result user profile is displayed.
This seems to be several test cases but it’s also a series of steps for one test case that depends on the others so I see why they wrote it that way.
It appears that the test case template that was used has expected results for every test step, which is why there are multiple expected results for a test case. I’m not sure if this is the case for all test case templates in TestRail, but it’s not a method I’ve used before.
first the Tool question: In the standard installation you also have a template without separated steps. There you can add one description and goal only.
Not to sound too overly didactic, this is a question on how deep you want to describe your test cases. Usually depending on the question who prepares the case descriptions and who is finally executing them. If separated, it is a useful investment.
The example above is a reqular description of a kind of click stream with a detailed discription for a tester who does not really need to be familiar with the system under test. Having an expected result er step/action helps a lot.
So, it depends what your predecessor tries to achieve with this detailed description AND yes I had a lot of discussion about this point.
Hopefully the discrition is enriched with an overal goal describing what should be reached by the case at all. I don’t want to go through all the steps to understand the idea of the case - although this is an additional effort.
Following your example I don’t see the need to split up your cases - simple sequences or even bigger E2E sequences. I’m a friend of detailed descriptions using separated steps.
Of course you can invest effort to shorten the case descriptions but I would suggest to invest your time to close your leaks in the test coverage.
You can mix the detail level or follow the current level.
Hope this helps.