Skip to Content

Changes for page Testing

Last modified by chrisby on 2024/06/20 14:42
From version 4.41
edited by chrisby
on 2024/05/26 12:03
Change comment: There is no comment for this version
To version 4.43
edited by chrisby
on 2024/05/26 12:05
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -24,12 +24,11 @@
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, where something goes wrong, such as a , , unusual input, and so on.  Writing tests for the latter makes the software robust against failure and misuse.
28 -* **Chaos Engineering**: Verifying that a system can withstand unusual conditions makes it robust against failures and misuse.
29 -** **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, dependency returning errors, a file access problem, network problems etc. Anything could could potentially go wrong.
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, values with special meaning.
30 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  ** **Security requirements**: For example, simulate all potential attack scenarios and verify that the software can withstand them.
32 -* **Performance requirements**:
31 +* **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.
34 34  
35 35  === Table of Contents ===