| ... |
... |
@@ -27,7 +27,7 @@ |
| 27 |
27 |
* You should always test **happy path** requirements, where a user story works as expected, and **unhappy path** requirements. For the latter, we need **chaos engineering**, i.e., verifying that a system can withstand unusual conditions makes it robust against failure and misuse. |
| 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 and values with special meaning. |
| 29 |
29 |
** **Error cases**: Exceptions, dependencies returning errors, a file access or existence problem, network problems etc. Anything could could potentially go wrong. |
| 30 |
|
-** **Failure Injection**: For example, at the operational level, this could include actions such as killing processes, shutting down servers, disconnecting networks, hardware resource even simulating entire data center breakdowns due to disasters, etc., while verifying that the system is still fully functional, available, and able to automatically recover. |
|
30 |
+** **Failure Injection**: For example, at the operational level, this could include actions such as killing processes, shutting down servers, disconnecting networks, insufficient hardware resources (CPU, memory, disk space), even simulating entire data centers failing due to disasters, etc., while verifying that the system is still fully functional, available, and able to automatically recover. |
| 31 |
31 |
** **Security requirements**: For example, simulate all potential attack scenarios and verify that the software can withstand them. |
| 32 |
32 |
* **Performance requirements**: Interactions with software often need to be completed in a certain amount of time. |
| 33 |
33 |
* **Load requirements**, when software is expected to handle a certain number of requests per second. |
