... |
... |
@@ -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 |
|
-** On an operational level, this could include measure such as killing processes, shutting down server, cutting of networks, etc. |
|
30 |
+** For example, at the operational level, this could include actions such as killing processes, shutting down servers, disconnecting networks, even simulating entire data center failures due to disasters, etc., while verifying that the system is still fully functional, available, and able to automatically recover. |
31 |
31 |
* If needed: |
32 |
32 |
** **Performance requirements** |
33 |
33 |
** **Security requirements** |