| ... |
... |
@@ -27,7 +27,7 @@ |
| 27 |
27 |
* **Chaos Engineering**: Verifying that a system can withstand unusual conditions makes it robust. |
| 28 |
28 |
** **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. |
| 29 |
29 |
** You should always test **happy path** requirements, where a user story works as expected, and **unhappy path** requirements, where something goes wrong, such as a dependency returning an error, a file access problem, unusual input, network problems and so on. Writing tests for the latter makes the software robust against failure and misuse. |
| 30 |
|
-** O |
|
30 |
+** On an operational level, this could include measure such as killing processes, shutting down server, cutting of networks, etc. |
| 31 |
31 |
* If needed: |
| 32 |
32 |
** **Performance requirements** |
| 33 |
33 |
** **Security requirements** |
