requirements Tag

Typically, you have your test suite structured in a hierarchic way to keep it organized. The way you structure your system test suite has a considerable impact on how effective and efficient you can use your tests. A good structure of a system test suite supports:

• maintaining tests when requirements change
• determine which part of your functionality has been tested, and to which degree (coverage)
• finding and reusing related tests while creating new tests
• selecting a set of test cases to execute (test plan)
• finding the root cause of a defect (debugging)

In my opinion, the first two points are the most important ones, as they touch the core of what system tests should do, namely to ensure that the system fulfills its requirements. Of course each project is different and no matter which structure I choose, I always run into the "tyranny of the dominant decomposition" (i.e. there is no such thing as THE best way to build a hierarchy) in the end. Nevertheless, I have seen a couple of anti-patterns in the past, which only very rarely make sense.