Purpose
The purpose of the test case document is to document expected behavior of the Score’s functionalities. This includes all rules and constraints on certain functionalities. This information is then used for developing acceptance test scripts and also user guide.
Test Case Document can be access at this link.
Document Structure
Test case document provides three levels of functional decomposition (or grouping). The first level is Test Suites. Each Test Suite has one or more Test Cases. Each Test Case typically has many Test Assertions and Test Steps. Test Steps are optional. They 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.
Pre-conditions may be needed in each of the level. They indicate the situation in which the Test Suite, Test Case, or Test Assertion are applicable and that the System Under Test (SUT) must be injected with data or actions such that its state satisfies those conditions before applying the test.
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 BIE Management Test Suite 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 Ender users 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 or rollback data.
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.