...
Test case document provides three levels of functional decomposition (or grouping). The first level is Test Suites (TS). Each Test Suite has one or more Test Cases (TC). Each Test Case typically has many Test Assertions (TA) and Test Steps. Test Steps are optional. It is a human readable version of test scripts. Having them as a prelude to test script writing will make the task easier. However, it could be cumbersome to keep them in sync as some ideas may change quite a bit when writing the test script.
...
Although there is no one correct way to structure and decompose a functionality into Test Suites, Test Cases, and Test Assertions, typically there is one Test Suite is for a functionality. A functionality typically maps to a menu item of the application, for example, a BIE Management Test Suite for the whole BIE Management menu. But the most important point about the decomposition is to make the authoring and scripting of different testing situations simpler and more manageable. Therefore, the test case author may feel like it helps him/or to decompose the functionality of the BIE Management Test Suite View/Edit BIE menu into Standard Developer BIE Management Test Suite and End User BIE Management Test Suite, because there are potentially differences in business rules when the Standard Developer uses the functionality vs. when the End users user uses it. This is absolutely fine. On the other hands, the test case developer and the test script developer may together decide to combine them later to make the test script and its execution more efficient.
After Test Suite, Test Case provide another level of grouping and decomposition of the system behavior. Test Assertion then indicates a specific compliance. We may say that Test Case is a grouping of Test Assertions that can share a common pre-condition, i.e., system and data set up, but there may be other grouping criteria such as a certain sub-functionality. Test Assertions are typically written in a monotonic sequence such that the system condition is ready for the next Test Assertion with little or no need to delete, rollback, or rollback reinitialize data. Test Assertion (TA) is a single condition/behavior of a TC.
As mentioned earlier, Test Steps are optional. They describe a sequence of actions that lead to the verification of each test assertion. Some Test Steps are just preparation steps. It is a good practice to provide links to Test Assertions on the step, which verifies one or more Test Assertions.
Example: “Test Suite 10: Working branch Core Component Management Behaviors for Developer” consists of TCs that test the functions related to Core Components in the Working branch when a developer user account is logged into Score. “Test Case 10.3: Editing a brand-new developer ACC” test the editing functionality of a brand-new ACC when it is being edited by a developer. “TA 1.5 A warning should be given when the Definition is empty” checks the behavior related to the Definition field of a ACC in “Test Case 10.3: Editing a brand-new developer ACC”.
Test document format
Each Test Suite is written in Markdown, and consists of the description and multiple test cases. Each Test Case has the description, pre-conditions, assertions, and test steps. Here’s a form of the test suite:
...