| ... |
... |
@@ -24,9 +24,8 @@ |
| 24 |
24 |
(% style="text-align: justify;" %) |
| 25 |
25 |
Every functionality you expect the software to provide at any moment. You should test: |
| 26 |
26 |
|
| 27 |
|
-* **Functional Requirements** |
| 28 |
|
-** **High-level business use cases** defined by the customer in project requirements. Tests are essentially requirements translated into code. And customer requirements are typically translated into acceptance tests. |
| 29 |
|
-* **Non-Functional RequirementLower-level technical use cases** derived from high-level business use cases that are not directly visible to end users, but form the backbone of software functionality. This includes the expected behavior of the underlying components, modules and units. |
|
27 |
+* **High-level business use cases** defined by the customer in project requirements. Tests are essentially requirements translated into code. And customer requirements are typically translated into acceptance tests. |
|
28 |
+* **Lower-level technical use cases** derived from high-level business use cases that are not directly visible to end users, but form the backbone of software functionality. This includes the expected behavior of the underlying components, modules and units. |
| 30 |
30 |
* **Border cases** that could theoretically occur, such as maximum/minimum values, nulls, invalid input outside the permissible value range, zeroes, negative numbers, empty lists, values with special meaning, exceptions, etc. |
| 31 |
31 |
* If needed: |
| 32 |
32 |
** **Performance requirements** |
