You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: quality-checks.md
+26-26Lines changed: 26 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
This is part of a broader [quality framework](README.md)
4
4
5
-
# Summary
5
+
##Summary
6
6
7
7
Quality checks are at the heart of good engineering, and are essential for rapid and safe delivery of software changes. This page provides an index of the various quality checks described within our principles, patterns and practices.
8
8
@@ -13,7 +13,7 @@ The checks are classified here based on the concerns they help to address:
13
13
* Resilience
14
14
* Maintainability
15
15
16
-
# Usage
16
+
##Usage
17
17
18
18
All applicable quality checks should be applied. Not all checks are applicable in all contexts, for example accessibility testing is only applicable to applications with a user interface.
19
19
@@ -30,27 +30,27 @@ We rate our applications against each of these checks as follows:
30
30
* Red = the quality check is not applied
31
31
* N/A = the quality check is not applicable
32
32
33
-
# Details
34
-
35
-
| Quality check | Classification | Applicability | What it means | We we care | Tolerances for green | Endorsed tools / configuration | Further details |
36
-
|:---|:---|:---|:---|:---|:---|:---|:---|
37
-
| Unit tests | Functionality | Universal | Logic tests for individual blocks of code, e.g. individual methods | This is the quickest (to execute) type of functional test, so these are essential to achieve both rapid and thorough functional testing | Builds fail if any tests fail | - |[Test practices](./practices/testing.md)|
38
-
| Integration tests | Functionality | Universal ||| Builds fail if any tests fail |||
39
-
| API / contract tests | Functionality | Contextual ||| Builds fail if any tests fail |||
40
-
| UI tests | Functionality | Contextual ||| Builds fail if any tests fail |||
41
-
| Secret scanning | Security | Universal | Check for secrets (e.g. passwords, IP addresses, etc) accidentally included in software code | This protects us against accidentally leaking secrets (in source code) which could compromise the security of the application | Builds fail if any unexpected secrets are detected | TBC | TBC |
42
-
| Security code analysis | Security | Universal | Check for indications of possible security issues (for example injection weaknesses) | This gives fast feedback about security issues: it's not as thorough as security testing, but it's much quicker to execute, so both are important to achieve both rapid and thorough security testing ||||
43
-
| Security testing | Security | Contextual | Check for security issues (for example injection weaknesses) | More thorough than security code scanning, but much slower to execute, so both are important to achieve both rapid and thorough security testing ||||
| Performance tests | Resilience | Contextual | Check whether application performance is acceptable at different levels of load | Without this test, we don't know how load will affect the performance of the application ||||
46
-
| 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 ||||
47
-
| 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 ||||
48
-
| 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 ||||
49
-
| Chaos tests | Resilience | Contextual ||||||
50
-
| 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% |||
| Dead code scan | Maintainability | Universal ||||||
54
-
| Code review | Other | Universal | A second person manually checking a code change | Quality check by a human, as opposed to via a tool | Enforced & audited step within workflow | TBC |[Code review guidance](./patterns/everything-as-code.md#code-review)|
55
-
| Accessibility tests | Other | Universal ||||||
56
-
| Tech radar check | Other | Universal ||||||
33
+
##Details
34
+
35
+
| Quality check | Classification | Applicability | What it means | Why we care | Tolerances for green | Endorsed tools / configuration | Further details|
| Unit tests | Functionality | Universal | Logic tests for individual blocks of code, e.g. individual methods | This is the quickest (to execute) type of functional test, so these are essential to achieve both rapid and thorough functional testing | Builds fail if any tests fail | - |[Test practices](./practices/testing.md)|
38
+
| Integration tests | Functionality | Universal ||| Builds fail if any tests fail |||
39
+
| API / contract tests | Functionality | Contextual ||| Builds fail if any tests fail |||
40
+
| UI tests | Functionality | Contextual ||| Builds fail if any tests fail |||
41
+
| Secret scanning | Security | Universal | Check for secrets (e.g. passwords, IP addresses, etc) accidentally included in software code | This protects us against accidentally leaking secrets (in source code) which could compromise the security of the application | Builds fail if any unexpected secrets are detected | TBC | TBC|
42
+
| Security code analysis | Security | Universal | Check for indications of possible security issues (for example injection weaknesses) | This gives fast feedback about security issues: it's not as thorough as security testing, but it's much quicker to execute, so both are important to achieve both rapid and thorough security testing ||||
43
+
| Security testing | Security | Contextual | Check for security issues (for example injection weaknesses) | More thorough than security code scanning, but much slower to execute, so both are important to achieve both rapid and thorough security testing ||||
| Performance tests | Resilience | Contextual | Check whether application performance is acceptable at different levels of load | Without this test, we don't know how load will affect the performance of the application ||||
46
+
| 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 ||||
47
+
| 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 ||||
48
+
| 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 ||||
49
+
| Chaos tests | Resilience | Contextual ||||||
50
+
| 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% |||
| Code smells scan | Maintainability | Universal | Adhere to the principles, patterns and practices of writing clean code | The code is written once but read and executed many times. Without paying attention to the fundamental code quality checks maintainability, complexity and therefore the cost of the service increase exponentially with time, adding up to the cumulative technical debt ||[SonarQube](https://www.sonarqube.org/), [SonarCloud](https://sonarcloud.io/)|[Clean Code: Smells and Heuristics](https://moderatemisbehaviour.github.io/clean-code-smells-and-heuristics/)|
53
+
| Dead code scan | Maintainability | Universal ||||||
54
+
| Code review | Other | Universal | A second person manually checking a code change | Quality check by a human, as opposed to via a tool | Enforced & audited step within workflow | TBC |[Code review guidance](./patterns/everything-as-code.md#code-review)|
0 commit comments