Skip to content

Commit dcec8b7

Browse files
authored
Chaos testing - first draft of tolerance for green (#133)
* Update quality-checks.md * Update quality-checks.md * Update quality-checks.md * Update quality-checks.md
1 parent 3e39427 commit dcec8b7

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

quality-checks.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,7 @@ We recommend tracking progress on an Engineering Quality dashboard, for example:
5252
| Capacity tests | Resilience | Contextual | Identify the application's breaking point in terms of heavy load | Without this test, we don't know how much load the application can handle before the application breaks | | | |
5353
| Stress tests | Resilience | Contextual | Check whether sudden spikes in load cause a problem | Without this test, we don't know if the application will fail under a sharp increase in load | | | |
5454
| Soak tests | Resilience | Contextual | Check whether sustained heavy load causes a problem | Without this test, we don't know if application performance will suffer under prolonged heavy load | | | |
55-
| Chaos tests | Resilience | Contextual | Continuously and randomly cause failures in a system, to test the resiliency of the system and the environment, and help the team to understand their MTTR | Give the team confidence that failures in a given environment will not lead to unplanned downtime or a negative user experience | | | |
55+
| Chaos tests | Resilience | Contextual | Cause failures in a system to test the resiliency of that system and its environment, and to help the team to understand their MTTR | Give the team confidence that failures in a given environment will not lead to unplanned downtime or a negative user experience<br/><br/>Ensures that the team has visibility (e.g. dashboards and alerts) to be able to identify issues | Builds fail if any test fails - note, these tests are slow, and are likely to be part of an infrequently-triggered (e.g. overnight) build<br/><br/>The tests cover whether the system self-heals, auto-scales, and alerts as expected | | |
5656
| Code coverage | Maintainability | Universal | The proportion of the application code which is executed (in this context: during testing) | The higher the code coverage, the more thorough the testing, and therefore the higher the likelihood of detecting functional issues early | For new code: 70% | | |
5757
| Duplicate code scan | Maintainability | Universal | Check whether the same code is used in multiple places | Duplicate code increases the cost and risk of making software changes and will increase exponentially over time | | | |
5858
| Code smells scan | Maintainability | Universal | Check whether the software code adheres to the principles, patterns and practices of writing clean code | The code is written once but read and executed many times. If the code is not clean, the cost and risk of making software changes both increase exponentially over time | | [SonarQube](https://www.sonarqube.org/) | [Clean Code: Smells and Heuristics](https://moderatemisbehaviour.github.io/clean-code-smells-and-heuristics/) |

0 commit comments

Comments
 (0)