These guidelines are intended to help teams create a usable and efficient feature breakdown of the set of system functionalities that are tested by the team. There are a few goals in defining features of the system under test and re-organizing tests into this hierarchy:
As the MTS migration process is implemented, it should be easy to start identifying where similar tests may be overlapping and can be combined (or duplicates removed as obsolete)
When looking for a test to update or include in a test cycle, it should be natural and easy to navigate the folder structure to find the related tests. It’s important that this is easy to follow to people outside the core teams, as other teams may start re-using existing tests instead of writing their own
When adding a new test to the MTS there is a natural structure for the new test to fit into, which naturally helps encourage maintenance of tests. When related tests are co-located, it’s much easier to see when new duplication or ability to merge tests can be done
Feature Definition Guidelines
Thus, in order to maximize the usability of the defined structure, we would recommend:
Keep names clear and concise to the functionality it represents
Ensure agreement between QE/Dev/SM/PO on the definition and naming of features so the entire team is using the same view of how the system is broken down
Keep the feature breakdown to Features and Sub-Features only (2 level hierarchy, not deeper)
Banner/Component specific folders can be created inside features/sub-features when actually migrating tests in the future, but when defining the Feature and Sub-Feature breakdown it should be at an overall level.
If a Sub-Feature would have more than 25-30 tests mapped to it, consider breaking it into multiple Sub-Features. The more tests that are co-located, the harder it is to find specific tests and prevent duplication, etc.
Let natural groupings of existing test cases help define some of the initial feature definition
