| ... |
... |
@@ -20,15 +20,16 @@ |
| 20 |
20 |
=== What should be tested? === |
| 21 |
21 |
|
| 22 |
22 |
(% style="text-align: justify;" %) |
| 23 |
|
-Every functionality you expect the software to provide at any moment. You should test: |
|
23 |
+Every functionality you expect the software to provide at any moment. Depending on the overall requirements, you should test: |
| 24 |
24 |
|
| 25 |
25 |
* **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>>doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]]. |
| 26 |
26 |
* **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. |
| 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 |
|
-** **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 |
|
-** **Error cases**: Exceptions, dependencies returning errors, a file access or existence problem, network problems etc. Anything that 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, 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 |
|
-** **Security requirements**: For example, simulate all potential attack scenarios and verify that the software can withstand them. |
|
27 |
+* **Happy Path Requirements**: Always test scenarios where a user story works as expected. |
|
28 |
+* **Unhappy Path Requirements**: Test scenarios where things do not go as planned. This includes |
|
29 |
+** **Edge cases**: Test for maximum/minimum values, nulls, invalid input outside the allowed range, zeros, negative numbers, empty lists, and values with special meaning. |
|
30 |
+** **Error cases**: Handle exceptions, dependencies that return errors, file access or existence problems, network problems, and other potential failures. |
|
31 |
+** **Failure injection (chaos engineering)**: Perform chaos engineering to test the robustness of the system against unusual conditions. This includes actions such as killing processes, shutting down servers, disconnecting networks, simulating insufficient hardware resources (CPU, memory, disk space), and even simulating entire data center failures due to disasters. Ensure that the system remains functional, available, and able to recover automatically. |
|
32 |
+** **Security requirements**: Simulate potential attack scenarios and verify that the software can withstand them, ensuring robust security measures. |
| 32 |
32 |
* **Performance requirements**: Interactions with software often need to be completed in a certain amount of time. |
| 33 |
33 |
* **Load Requirements**: Verify that the software can handle the expected number of requests per second under normal operating conditions. |
| 34 |
34 |
* **Stress Testing**: Run tests with an unusually high number of requests to determine the system's breaking point and ensure that it can handle extreme load conditions without catastrophic failure. |
