| ... |
... |
@@ -17,7 +17,7 @@ |
| 17 |
17 |
|
| 18 |
18 |
* **Quality Assurance** |
| 19 |
19 |
** **Automated Testing**: Minimizes the need for human source code checking or manual testing, providing a cost-effective way to ensure continuous quality assurance and the correct functioning of software at all times. |
| 20 |
|
-** **Early Feedback**: Tests provide immediate bug feedback. This is especially true for detecting accidentally introduced bugs caused by code changes. The earlier bugs are detected, the cheaper they are to fix. |
|
20 |
+** **Early Feedback**: Tests provide immediate bug feedback. This is especially true for detecting accidentally introduced bugs caused by code changes. The earlier bugs are detected, the cheaper they are to fix. This also eliminates the fear of introducing bugs when writing or modifying code. |
| 21 |
21 |
** **Bug Location Detection**: Tests identify bug locations, saving debugging time. |
| 22 |
22 |
* **Testable Design** |
| 23 |
23 |
** Writing tests automatically enforces design best practices, resulting in a 'testable design' and higher quality code. Good code and architecture are testable, and vice versa. |
| ... |
... |
@@ -32,9 +32,9 @@ |
| 32 |
32 |
Every functionality you expect the software to provide at any moment. You should test: |
| 33 |
33 |
|
| 34 |
34 |
* **Functional Requirements** |
| 35 |
|
-** Use cases that are defined in project requirements. Tests are actually specification translated into code. |
| 36 |
|
-** Lower-level use cases derived from high-level project 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 functions, classes, modules, and components. |
|
35 |
+** **High-level use cases** that are defined in project requirements. Tests are actually specification translated into code. |
| 37 |
37 |
* **Non-Functional Requirements** |
|
37 |
+** **Lower-level use cases** derived from high-level project 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 functions, classes, modules, and components. |
| 38 |
38 |
** **Border cases** that could theoretically occur, such as maximum/minimum values, nulls, invalid input, zeroes, negative numbers, empty lists, values with special meaning, exceptions, etc. |
| 39 |
39 |
** **Performance requirements** |
| 40 |
40 |
** **Security requirements** |
