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

Organize properly by maintaining ease of test flow



we currently organise our test cases by a mixture of “by feature” and “by user flow”. The effect is that we don’t have the cases all ordered correctly when we look for some test cases. As usually of course, when you change some features, you just have to look in the area of the feature touched and update test cases accordingly. But when the features are scattered among different folders it gets a little harder.

It would be of course a good option to change the structure to fit the feature structure. But by that we lose a lot of ease in the test flow. The reason: some features hand over to other regions, e.g. you might have a “teaser cards” feature which hands over to “product ordering”. When you structure your folders around features there will be different test cases in different folders. But how we do it now we sometimes have a test case which actually tests the teaser card, the handover to the ordering feature ordering and the ordering feature itself. Why? It’s easier to test because it represents a usual flow. Another benefit is that it’s more realistic.

I think we can agree upon that in many cases it’s easier not to follow the strict order of the test case structure, but instead to follow a specific journey through the app instead and pass all the test cases which lie on the path.

Unfortunately, TestRail has no feature (which i know of) that supports “user journey testing” as described.

But how are you doing it? Is there a better way? Is there a mixture of organisation “by page” and organisation “by feature” which actually gives you a good overview AND better test execution flow?

Thanks in advance!


Hi mnms,

TestRail doesn’t explicitly support this kind of workflow currently. For organizing, the folders/test case sections can be organized in anyway you see fit. Each folder could be a group of test cases that share the same “by feature” for instance.

Alternatively you can keep the test cases generalized to leave room to experiment during testing. For example, you could either specify the exact steps on how to test an import feature in great detail, or you could alternatively write general test cases titled e.g. “Verify import with XML files” and leave the exact steps (and variations) to perform to the tester. This would make your tests more flexible and if you create a run for “teaser cards”, this can then be Rerun to quickly create the same or similar set of tests for “product ordering”.


OK, that’s unfortunate, but thanks for your answer! @vtran